大多数智能体框架都会给每个智能体分配独立的上下文窗口，并把它称为“记忆”。在只有一个智能体时，这套做法还能运转；一旦你同时运行多个智能体，它就会悄悄变成整个系统里最昂贵的设计决策。

我们运营着一支智能体集群，不同智能体有意使用不同模型：一个家族负责长文起草，另一个家族负责结构化抽取，还有几个走本地推理路径、完全不依赖外部推理服务。按能力路由只是容易的部分。真正难的是：当某个智能体学到新东西，它只是“独自”学会了。

这篇文章记录我们踩到的坑，以及最终采用的记忆设计。

失败模式

症状表现为重复劳动。

某个抽取智能体发现，某家供应商的发票把税额行放在小计上方。这是个有用的事实。两天后，另一个智能体——不同模型、不同提示词、同一条流水线——遇到同一家供应商时，又从零开始推导了一遍。接着，第三个智能体又重复了一次。

每个智能体都没有做错任何事；它们的行为全部正确。问题在于：系统整体没有任何积累能力，因为知识只存在于当时恰好打开的那个上下文窗口里。你等于在为一堆已经属于自己的事实，反复支付推理成本。

最直觉的修复方法是传入更多历史。这个方法会因为一个值得明确指出的原因而失败：上下文窗口是“每次调用”和“每个模型”的。某个模型的 200k 窗口，帮不到另一个只有 32k 窗口的模型；而且无论哪种窗口，都会在会话结束时消失。你不能用更大的缓冲区来解决持久化问题。

“统一记忆”必须满足什么

一旦你接受记忆必须存在于智能体之外，需求就变得具体了：

首先，存储必须与模型无关。如果记忆以某个模型的 embedding 形式存储，你就把记忆层和某个供应商绑定了。以后更换模型，就意味着重新索引全部数据。

其次，被一个智能体写入的内容必须能被所有智能体读取。否则你得到的只是“每个智能体各自的记忆”，只是多绕了几步。

第三，记忆必须可归因。当记忆出错时——而且它一定会出错——你需要知道是哪条记录、由哪个智能体、在哪个会话中写入的，才能定位、修正或回滚，而不是让错误记忆污染整个集群。

这就是我们最终采用的记忆设计：让知识独立于任何单一智能体、单一模型、单一上下文窗口；让集群中任何一个成员学到的东西，都能成为整个集群共享的资产。