分布式架构下，用户会话上下文如何在多个 Agent 实例之间保持一致，同时不牺牲负载均衡的弹性。这是生产环境中要面对的实际问题，也是从"Demo"到"产品"必须跨越的坎。

核心矛盾很简单：用户期望对话是连续的（记得之前说了什么），但分布式系统希望请求可以被任意实例处理（负载均衡）。 这两者天然冲突。

一、分布式 Agent 架构

用户 → Gateway（网关）
         ├─ Agent 进程 1（机器 A）
         ├─ Agent 进程 2（机器 B）
         └─ Agent 进程 N（机器 C...）

各 Agent 进程代码相同，部署在不同机器上，目的：提升吞吐量，避免单机阻塞。

二、Context（上下文）是什么

Agent 运行时的核心数据，包括：

• 对话记忆（Memory）：历史对话内容，决定了 Agent 是否"记得"用户之前说了什么
• Tool 使用记录：已调用的工具及返回结果，避免重复调用
• Runtime 状态：运行时临时信息，如当前 ReAct 循环的步数

连续对话依赖 Context 的持久保持。如果 Context 丢了，用户会感觉"每次都是第一次见面"。

三、一致性问题

因素	影响
单机架构	Context 持久化简单（存文件/数据库），但不是所有的请求都指向同一台机器
分布式架构	Context 分散在不同机器的内存/磁盘中，请求可能被路由到任何机器

四、方案一：路由表绑定（会话粘连）

Gateway 维护路由表，记录 User → Agent 的映射，同一用户的所有请求固定路由到同一 Agent。

听起来合理对吧？用户 A 永远去 Agent 1，用户 B 永远去 Agent 2。

问题：用户被永久绑定到某台机器。100 万用户假设分配到 10000 个 Agent，但大部分用户在夜里不活跃，活跃的可能只有 3000 个用户集中在 5000 台机器上——另外 5000 台空闲但无法为新用户服务（因为新用户也按规则绑定了特定机器）。

资源浪费严重，违背了分布式架构的初衷。这就是所谓的"会话粘连（Session Sticky）"问题。

五、方案二：状态持久化 + 文件系统（推荐）

核心思路：Agent 保持无状态/短状态，Context 落盘到独立文件系统。 不依赖"请求必须去同一台机器"，而是"不管去哪台机器，都能拿到最新的上下文"。

活跃期：用户请求 → Gateway → Agent A（内存中保持 Context）
空闲超时：Agent A → Context 落盘到 File System
恢复期：新请求 → Gateway → Agent B（从 File System 加载 Context）

流程

1. 活跃期：用户请求经 Gateway 路由到 Agent，Context 保持在内存中，Agent 正常处理
2. 超时释放：用户空闲超过设定时间（如 30 分钟）→ 从路由表删除该条目 → Context 落盘为静态文件（Markdown 或 JSON）→ 存入独立于 Agent 的 File System
3. 恢复期：用户重新访问 → Gateway 按负载均衡规则分配新 Agent → 新 Agent 以 UID 从 File System 检索 Context → 仅加载关键记忆（而不是全部历史）到 Runtime

优势

• Agent 保持无状态，负载均衡有效——任何 Agent 都可以服务任何用户
• 数据持久性有保障——即使所有 Agent 都重启，Context 不会丢
• 吞吐量与数据一致性达到平衡——活跃用户 Context 在内存中，不活跃用户的 Context 落盘但不丢失

六、MCP 在记忆检索中的作用

File System 作为 MCP Server 提供记忆检索服务：

• 首次加载：拉取关键 Memory Markdown（用户画像、核心偏好、重要约定）
• 按需补充：通过 MCP 协议从 File System 获取更详细的历史记录，而不是一开始就把所有历史都加载到 Context 中

这种"懒加载"模式在分布式系统中至关重要——把 Context 精简到最小必要，降低每次请求的 Token 消耗。

七、核心原则

“如果用户永远固定访问同一个 Agent，那么多 Agent 有什么意义？”

Agent 应该是无状态或短状态的进程——它不应该一直把用户信息保存在内存中。把 Context 持久化到独立服务，让负载均衡真正发挥作用。这才是分布式 Agent 系统的正确设计思路。