📰 来源：Towards Data Science　|　📅 翻译日期：2026年6月26日
🔗 原文：查看原文
🤖 翻译：DeepSeek AI · 仅供参考

TL;DR

我并非有意构建一种新的记忆架构，而是想弄明白为什么一个智能体会不断忘记另一个智能体做出的决策。基准测试是后来才做的。

多智能体系统丢失跨智能体决策，是因为平面转录和向量搜索都存在结构盲点——这不仅仅是噪声问题。

上下文图将事实存储为实体和关系，而不是文本块，因此能够回答需要组合两个事实的问题。

这不是一个概念。三种记忆架构、五个脚本化场景、18个分级查询，完全确定性，零LLM调用。

• 上下文图：准确率 88.9%，每个查询 26.9 个token
• 原始历史转储：准确率 61.1%，每个查询 490.9 个token
• 仅向量RAG：准确率 50.0%，每个查询 75.9 个token

构建过程中，我发现了两个真正的bug——陈旧事实检索和实体匹配缺口。详见文章。

促使我构建这一方案的问题

我构建了一个三智能体流水线，在短任务中表现出色。但一旦对话拉长，某个智能体需要回忆之前的决策时，整个系统就崩溃了。

具体问题如下：Agent_Planner 决定项目应该使用 PostgreSQL。随后经过了二十轮“听起来不错”和“我会去做的”等对话。最终，Agent_Reviewer 突然发问我们在使用什么存储技术。即使整个原始转录都完整地放在上下文窗口中，智能体仍无法可靠地回答。

我本地运行这个流水线作为 EmiTechLogic 的一个副项目，只是想看看多智能体协调在撞墙之前能走多远。结果发现，它并没有撑太久。

起初，我以为这只是模型限制。事实并非如此。这是一个记忆架构问题，通常会导致两种严重的麻烦之一，具体取决于你如何尝试修复它。

替代方案：向量搜索与关系陷阱

如果转向向量搜索，你能解决噪声问题，但会立刻制造一个新问题。向量存储检索与查询相似的文本块，但不检索事实之间的关系。

如果一个关键决策位于一个文本块中，而关于该决策的关键依赖注释在另一个文本块中，那么相似性搜索无论如何都无法将它们组合起来——无论你的嵌入模型有多好。

两种方法都遭遇了不同的结构上限。与其猜测哪种折衷方案“足够好”，我决定对它们进行量化测量。

这个问题的本质是什么

需要明确的是，本文不是关于token压缩问题，也不是陈旧性问题。这是一个结构检索问题。某些问题只能通过组合两个分别陈述的事实来回答，而无论是增大的上下文窗口还是向量索引都没有机制做到这一点。这是一种与我之前写过的完全不同的故障模式，需要不同的基准测试。

测试设置

为了测试，我构建了五个确定性场景，包含 18 个分级查询，并针对完全相同的对话运行了所有三种记忆架构。

以下所有结果均来自该基准测试的实际运行，使用本地化配置：

• 环境：Python 3.12，仅CPU（无需GPU）
• API调用：零
• 一致性：在两台不同机器上复现结果完全一致
• 代码仓库：你可以在以下地址找到完整实现并自行运行测试：https://github.com/Emmimal/context-graph-benchmark/

这里所说的“上下文图”是什么

平面记忆存储（无论是原始聊天转录还是向量索引）将每一轮对话视为独立的文本单元。检索时，只需找到最匹配查询的单元。

上下文图完全改变了底层结构。它将记忆视为具有类型化关系的不同实体：

• AuthModule —–> DEPENDS_ON —–> RateLimiter
• Agent_Implementer —–> ASSIGNED_TO —–> AuthModule

在这种模型中，检索意味着遍历这些关系，而不仅仅是匹配关键词或语义向量。

这种结构差异只对某一特定类别的问题有意义：任何需要组合两个分别陈述事实的问题。

考虑这样一个问题：“哪个团队拥有依赖于X选择的服务组件？”

原始对话历史中没有任何地方存在一个答案块。答案不存在于一个文本块中。它只作为一条穿过多个事实的路径存在。平面存储无法即时构建这条路径。而图可以轻松走通。

适用人群

这个方法值得构建，如果你运行的多智能体流水线中，一个智能体的决策必须在多轮对话后被另一个智能体正确检索。它适用于问题通常需要组合两个或更多分别陈述事实的系统，或者任何长时间运行的智能体对话，其中重新发送历史的token成本已成为实际开销。

你应该跳过它的情况：

• 单智能体、单轮任务，因为没有跨智能体状态会丢失。
• 你的查询总是单事实查找，无需连接。向量RAG能以极低的工程成本获得大部分准确率。
• 你的团队无法容忍额外的移动部件。图需要一个提取步骤（本基准测试中基于规则，但生产环境中需要LLM调用），而平面存储则避免了这一步。

如果你的多智能体系统在单次交换中完成工作，简单的上下文传递就足够。当对话变长且决策需要在做出后持续存在时，这个问题才会显现。

三种架构

（注：原文表格中“仅向量RAG”的成本列显示“Flat per query, los”，推测“los”为“lossy”的缩写，意为“有损”。）

参考资料

• 基准测试代码仓库：https://github.com/Emmimal/context-graph-benchmark/