跨模型 AI Agent 集群共享内存的架构设计

大多数 Agent 框架给每个 Agent 自己的上下文窗口并称之为记忆。在你运行超过一个 Agent 之前这运作良好，然后它悄然成为系统中代价最高的设计决策。

我们运行的 fleet 中，不同的 Agent 背后故意使用了不同的模型——一个系列处理长篇起草，另一个处理结构化提取，还有几个运行在本地路径上完全不依赖外部推理。按能力路由是简单部分。困难的部分是，一个 Agent 学到的东西只有它自己知道。

这是关于什么崩溃了、以及我们最终设计方案的总结。

症状表现为重复工作

一个提取 Agent 确定某供应商的发票将税行放在小计之上。有用。两天后另一个 Agent——不同的模型、不同的 prompt、相同的管道——遇到同一个供应商并从零重新推导了一遍。然后第三个又来了一遍。

没有任何问题。每个 Agent 都行为正确。整个系统只是无法积累任何东西，因为知识存在于当时恰好打开的某个上下文窗口中。你正在支付推理成本来重新发现你已有的事实。

天真的修复方案是传递更多历史。这会因为一个特定原因失败，值得命名：上下文窗口是按调用和按模型来的。一个模型上的 200k 窗口无法帮助运行另一个 32k 窗口模型的 Agent，而且两者都无法在会话结束后存活。你不能用更大的缓冲区来解决持久化问题。

"统一记忆"必须意味着什么

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

模型无关的存储。 如果记忆以某个模型的 embeddings 存储，你就将记忆层与供应商耦合了。以后切换模型意味着重新索引一切。

一个 Agent 写入，所有 Agent 可读。 否则你只是有了带额外步骤的 per-agent 记忆。

可归因。 当记忆出错时——它会的——你需要知道是哪个 Agent、哪个会话、以及何时。无来源归因的记忆是无法修复的记忆。

有作用域。 不是每个 Agent 都应该看到一切。客服 Agent 不应该读取财务上下文。

可审计。 对于任何涉及受监管工作的事项，"Agent 知道 X"需要是一个你能举证的主张，而不是推断。

第 3 点是人们跳过的，也是伤害最大的。没有任何溯源的共享记忆存储会将每个糟糕输出变成无界限的调查。

我们最终采用的形态

两层，故意分离：

仅追加的事件日志是事实来源。每个记忆写入都是一个带有 Agent 身份、会话身份、通道和时间戳的事件。它永远不会被修改。如果一个事实被证明是错误的，你追加一条更正——而不是编辑历史。这一层使第 3 点和第 5 点成为可能，而且它是有意为之的枯燥设计。

派生索引是 Agent 实际查询的东西。它从日志重建，这意味着它是可丢弃的。更换你的 embedding 模型、更换你的分块策略、决定语义搜索对于给定路径是错误的选择——重建索引，日志纹丝不动。

重要的属性是依赖的方向。索引依赖于日志。没有任何东西依赖于索引。这正是让你无需迁移就能更换检索策略的原因，这也是"我们更换了 embedding 模型"这件事是一个下午就能完成还是需要一整个季度才能完成的区别。

我们目前的实现是在配置路径上运行文档索引后端，带有计划的 embed 周期，加上会话导出和保留窗口。具体的后端不重要，分离原则更重要——我们已经换过一次，而日志使得那成为了一件无关紧要的事。

检索是一个作用域问题，而不是搜索问题

本能的反应是让检索更智能。更好的 embeddings、重排序、混合搜索。

实际上收益来自于在任何排序之前缩小每个 Agent 的可搜索范围。一个询问发票格式的 Agent 不应该搜索支持对话记录。不是因为质量原因——而是因为正确性原因。跨域语义邻居正是那种会产生自信满满胡说八道的似是而非的错误上下文。

先确定作用域，再排序。 一个正确限定作用域的小候选集优于一个大候选集被很好地排序的结果，而且代价要低得多。

我们过早存储了摘要

在写入时将会话总结成记忆感觉高效，但破坏了以后当我们改变想法时重新派生任何东西的能力。存储原始事件；如果需要则在读取时再总结。

我们对身份的指定不足

早期，"谁写的这个"只意味着一个 Agent 名称，然后我们就重命名了它。使用一个能在重命名后继续存在的稳定标识符，并将模型分开记录——你会想要回答"当质量下降时模型是否改变了？"

我们以为检索失败就是检索失败

大多数其实是穿着马甲的作用域失败。

这真的值得吗

说实话：取决于 fleet 规模。对于一两个 Agent，per-agent 上下文没问题，这套架构是你不需要的开销。对我们来说，交叉点出现在大约五六个 Agent 共享一个领域时，重新发现成本和"为什么它这么做"的调查开始占据主导。

你已经跨越了这个门槛的最清晰信号：你发现自己向不同的 Agent 解释同一个事实，或者你无法回答为什么一个 Agent 产生了某个输出而不得不阅读原始日志。两者都是表现为 prompt 问题的记忆架构问题。

我们在 VYR 为新加坡企业构建和部署治理 AI Agent——每个 Agent 在任何写入、发送或支付的操作上都有人工审批门控，外加完整的执行日志。如果你在研究多 Agent 记忆，我真的很想在评论区比较心得。