面向无状态LLM API的对话数据系统架构设计：Hydration Proxy 模式

# 为无状态LLM API构建对话数据系统
来源：https://arxiv.org/html/2609.01834
会议：SAO Workshop at CAIS’26；2026年5月26日；美国加利福尼亚州圣何塞SAO Workshop at CAIS’26，2026年5月26日，美国加利福尼亚州圣何塞
水合代理模式

版权所有

###### 摘要

随着企业平台向对话式推理接口转型，高性能LLM API的无状态特性造成了根本性的架构鸿沟。虽然无状态性使AI提供商能够实现大规模水平扩展，但它迫使消费应用程序承担管理整个对话状态和语义记忆的负担。本文提出“水合代理模式”，这是一种从生产级分析平台的操作需求中综合而来的三层架构。通过将会话持久性与推理引擎解耦，该框架确保平台对对话数据拥有主权，同时支持安全的、多阶段的语义锚定。我们进一步提出“上下文稳定化准则”，以解决主权状态管理与基础设施级KV缓存之间的张力。

## 1. 挑战：无状态悖论

LLM在专业数据环境中的整合因“无状态悖论”而复杂化。分析探索本质上是一个迭代过程，依赖于先前查询、可视化状态和复杂推理步骤的连续性。然而，为了最大化水平扩展和多租户隔离，AI提供商将推理引擎构建为无状态函数[8]。这使得“记忆”的负担完全落在应用层，要求采用“全历史往返”模型，即每次查询都必须重新传输完整的对话历史和元数据。

在实践中，这种模型造成三个主要的运行摩擦领域：

- •治理鸿沟：当组织依赖集中管理的会话模型（由AI供应商存储历史记录）时，他们失去了对敏感对话日志的主权控制。这限制了组织实施细粒度、平台级安全策略或遵守地区数据驻留法律的能力。
- •缓存冲突：现代推理基础设施利用KV（前缀）缓存来减少延迟。简单的请求“水化”通常在提示开头包含轮换的安全令牌或动态元数据，这实际上会“击穿”提供商侧的缓存并增加令牌成本。
- •语义碎片化：精确的分析推理需要在数据模式中进行高保真锚定。从客户端包装器传递原始元数据既不安全又低效，特别是对于包含数千个字段的大规模企业模式。

表1. 架构原型比较

## 2. 架构框架：水合代理

为了解决这些摩擦，我们提出一个从生产级分析系统需求中综合而来的三层架构。该框架在UI、安全网关和持久层之间建立了明确的分离。

- •编排层（前端）：作为主要入口点，维护即时UI状态并为每次请求重组所需的时序消息历史。
- •水合代理（安全网关）：作为一个专门的后端桥接器，用权威的平台上下文“水合”原始客户端请求。该层负责动态注入安全凭证和治理元数据（例如模式），这些数据不能驻留在客户端层。
- •混合持久层：采用双存储策略，将会话管理与对话内容解耦，确保系统能够扩展以处理密集、高容量的交互日志。

## 3. 状态管理：解耦持久化

分析系统中的对话历史信息密集，包含包含查询结果和可视化元数据的大型JSON载荷。我们确定了一种解耦策略，在保证高吞吐量访问的同时不损害数据库性能：

- •关系账本（元数据层）：关系数据库维护会话的结构化“骨架”。该账本跟踪会话所有权、消息的时序序列以及指向完整对话数据的唯一指针。这允许系统执行快速查找和审计会话活动，而无需加载大型文本块。
- •对象存储层（内容层）：高容量、非结构化的载荷被卸载到加密的对象存储服务。这防止了关系数据库膨胀，并确保系统能够随着用户生成数千个数据密集的对话轮次而扩展。
- •全历史重组：在每次用户交互时，代理使用关系账本在对象存储中定位相关内容。它重组净化后的历史记录，确保推理引擎拥有解决后续问题所需的持久上下文。

## 4. 比较系统分析

我们评估了该模式与当前行业原型的架构权衡：

简单无状态包装器：常见于初始原型，这涉及使用标准的无状态端点，如OpenAI Chat Completions API [7]。虽然应用层内存库试图通过客户端摘要循环来管理上下文回忆，但它们容易出现严重的上下文膨胀，并通过将原始平台元数据和治理边界直接暴露给客户端层而引入安全漏洞[4]。

集中管理会话模型：像OpenAI Assistants API [1]这样的提供商在专有基础设施上存储历史记录并管理上下文窗口。虽然这最小化了实施复杂性，但它对企业数据主权和多云可移植性提出了挑战。

生态系统集成代理模型：分析平台如Databricks Genie [2]、Snowflake Cortex [3]或BigQuery中的Gemini [9]使用紧密集成的模型。在这些系统中，AI推理引擎是数据仓库生态系统的一个内在组件。虽然这实现了高性能，但造成了显著的供应商锁定并限制了多云灵活性。

## 5. 上下文稳定化准则

水合代理的一个实质性设计挑战是与提供商侧KV缓存的张力。现代推理基础设施[6]利用KV缓存来存储静态前缀的注意力状态。简单的水化——在提示开头注入轮换的安全令牌或动态元数据——会击穿此缓存，增加延迟和成本。

我们确定“线性上下文策略”是生产代理的核心要求。代理必须保持稳定的提示结构，确保重复的上下文在每次请求中保持相同：

1. (1)静态前缀：高令牌平台模式和系统指令在提示开头固定，以最大化跨多个轮次的缓存重用。
2. (2)半稳定历史：时序日志在不进行修改的情况下重组，以保持跨轮次的字节一致性，确保缓存仅被追加，从不失效。
3. (3)易变后缀：临时数据，包括轮换的OAuth令牌、用户位置元数据和当前查询，被分配到后缀。

## 6. 系统优势与设计综合

水合代理模式的架构优势综合如下：

- •主权持久化：通过将消息载荷卸载到组织控制的存储层，对话状态保持平台驻留。这确保用户可以在多个设备上恢复复杂推理上下文，而无需涉及AI供应商的存储。
- •受控语义锚定：代理层防止敏感平台模式暴露给客户端。这允许在推理任务执行前动态注入权威的字段级安全约束，确保模型仅在用户有权访问的数据中进行锚定。
- •响应式交错：通过代理层的实时流解析，系统可以将模型的内部推理步骤（思考）[5]与面向用户的答案分离。这使得UI能够驱动即时进度状态，缓解复杂分析任务固有的延迟。
- •策略性上下文缩放：代理充当“上下文调节器”，实施“递归摘要”和“可移除推理”。通过定期压缩历史记录或剥离高令牌内部推理步骤[5]，代理保持运行可靠性。虽然压缩会导致瞬时缓存未命中，但它重置了提示的令牌基线，确保随着对话密度增加，会话保持可行。

## 7. 结论

通过识别水合代理模式和上下文稳定化准则，我们可以构建可扩展、安全且与供应商无关的对话数据系统。该架构允许平台保持对系统“记忆”和“治理”的主权控制，同时利用无状态推理API实现“智能”。它解决了数据隐私与前缀缓存基础设施级经济必要性之间的张力。

## 参考文献

- (1) OpenAI. 2024. 助手API概述. 检索自https://platform.openai.com/docs/assistants/overview
- (2) Databricks. 2024. Databricks Genie：AI驱动的数据助手. 检索自https://www.databricks.com/blog/introducing-databricks-genie
- (3) Snowflake. 2024. Snowflake Cortex Analyst. 检索自https://www.snowflake.com/en/data-cloud/cortex/
- (4) K. Greshake, 等. 2023. 与你签约的不同：通过注入提示妥协现实世界LLM集成应用. arXiv预印本 arXiv:2302.12173.
- (5) S. Yao, 等. 2023. ReAct：在语言模型中协同推理与行动. ICLR 2023.
- (6) Meta AI. 2024. Llama 3介绍. 检索自https://ai.meta.com/blog/meta-llama-3/
- (7) OpenAI. 2024. Chat Completions API指南. “API是无状态的，意味着服务器不保存任何先前请求的记录.” 检索自https://platform.openai.com/docs/guides/text-generation
- (8) Google DeepMind. 2024. Gemini 1.5 Pro：可扩展的无状态推理. 检索自https://deepmind.google/technologies/gemini/
- (9) Google Cloud. 2024. BigQuery中的Gemini. 检索自https://cloud.google.com/bigquery/docs/gemini-introduction