为什么你的智能体需要只读副本：智能体记忆的读写分离

大多数 Agent 内存都是一个无差别的存储库。循环在每一步开始时从中读取以组装上下文，并在每次动作后向其写入 —— 新的观察结果、运行摘要、暂存器编辑。同样的存储，同样的访问路径，没有分离。它在演示中运行良好，但一旦 Agent 运行时间足够长、存储库变大，它就开始腐烂。

它腐烂的原因对于任何扩展过数据库的人来说都很熟悉。一个同时提供读写服务的单一存储库就像是一个没有副本的单主数据库，它继承了该拓扑结构在负载下的每一个问题：写入与读取竞争，更新中途读取到写了一半的记录，且易失性工作集与持久记录之间没有隔离。几十年前，我们就通过读写分离解决了数据库的这个问题。Agent 内存也理应得到同样的对待。

解决方法不是更大的向量索引或更智能的嵌入模型。这是一个架构上的解决方法 —— 认识到 “内存” 是冠以同一名称的两种不同工作负载，并为每种负载提供其真正需要的存储规约。

一个存储库，两种工作负载

拆解 Agent 实际对内存的操作，你会发现这两种操作几乎没有任何共同点。

写入路径是重追加且容忍延迟的。在每次工具调用后，Agent 会记录发生了什么：观察结果、压缩摘要、更新后的计划。这些写入非常频繁，大多是追加而非更新，而且 —— 关键点在于 —— 没有人会因为等待它们而被阻塞。如果摘要在轮次结束后 200 毫秒才进入持久存储库，用户是察觉不到的。

读取路径则恰恰相反。在每个推理步骤开始时，Agent 会查询内存以组装上下文：相关事实、之前的决策、当前的暂存器。此读取操作直接处于轮次的关键路径上。它需要速度快，需要在该轮次持续期间保持一致，而且它是用户唯一能真正感受到的内存操作。

这两种工作负载的需求各不相同。写入路径需要吞吐量和持久性，不在乎延迟。读取路径需要低延迟和稳定的视图，不在乎两秒钟前的写入是否尚未完全传播。强制它们通过同一个存储库意味着每一个设计决策都是一种折中，对两者都没有好处。你为了快速检索而优化索引，写入就会变慢；你为写入吞吐量进行优化，读取就会返回底层正在被修改的存储库的不一致切片。

正是这一认识推动了数据库走向读写分离：将写入路由到主库，将读取路由到副本，并让每一端都能独立进行优化。这种模式在应用架构中也有一个名称 —— 命令查询职责分离（CQRS）—— 它将改变状态的模型与读取状态的模型分离开来。Agent 内存已在悄然间成长为一个大到需要同样分离的系统，而大多数团队尚未察觉。

内存写一半的问题

未分离设计最明显的症状就是读取捕捉到了正在进行的写入。

考虑一个长期运行的 Agent，它在轮次之间运行合并流程：将最后十个观察结果总结为一条简练的笔记并剪除原始条目。这是一个多步变动 —— 先写入摘要，然后删除原始记录。如果下一轮的读取发生在这两个步骤之间的窗口期，Agent 就会同时看到新的摘要和它本应替换掉的过时原始记录。现在它拥有了重复且部分矛盾的上下文，而且它无法知晓这一点。检索到的片段看起来和其他任何检索到的片段别无二致。

这正是 Agent 内存失效变得真正危险的地方。当内存失效时，它很少抛出错误。它会产生一个充满自信的错误响应，将过时的上下文与当前信息混合在一起。Agent 检测不到检索到的事实已经过期 —— 它处理内存注入的方式与处理任何其他提示词文本的方式相同，因此只应用了一半的合并操作就直接成为了推理输入的一部分。更糟糕的是，这种失败是无声的：分页、淘汰和合并策略在不表现出错误的情况下运行失常，因此测试套件依然显示通过，而回答质量却在下降。

在多 Agent 系统中，这个窗口期会变得更宽，损坏情况也会变得更糟。当多个 Agent 并发读写一个共享内存存储库时，同步操作会产生甚至难以重现的内存冲突 —— 一个 Agent 正在写入中的合并操作，就是另一个 Agent 损坏的读取结果。共享存储库已经变成了一个并发 bug 的温床，而原本没有人设计它承载这种复杂性。

主库/副本分离从结构上关闭了这个窗口。写入 —— 包括多步合并 —— 落在写入端，并且只有在整个变动被提交并传播后才对读取者可见。读取端永远不会观察到中间状态，因为它读取的是一个稳定的快照，而不是正在变动中的实时存储库。

最终一致性没问题 —— 除非它出了问题

加载中…