第15篇：分布式 Agent 一致性 —— 上下文不丢的秘诀

分布式架构下用户会话上下文如何在多个 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流程活跃期用户请求经 Gateway 路由到 AgentContext 保持在内存中Agent 正常处理超时释放用户空闲超过设定时间如 30 分钟→ 从路由表删除该条目 → Context 落盘为静态文件Markdown 或 JSON→ 存入独立于 Agent 的 File System恢复期用户重新访问 → 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 系统的正确设计思路。