1. 先给结论多 Agent 协作的瓶颈根本不是模型能力这两年做 AI Agent 的人越来越多从单 Agent 的 Demo 走向多 Agent 协作时大家嘴上说的都是“我的模型太笨了”“推理能力不够”“需要上一个更强的模型”。但在我实际折腾过的几个项目里真正让整个系统翻车的几乎都不是模型智商而是“失忆”。所谓失忆就是多个 Agent 之间无法共享、继承和回溯上下文——前一个 Agent 说过的话、做出的中间决策、已经完成的状态到了后一个 Agent 那里全部归零。你让 A Agent 去检索资料B Agent 拿着它产出的结果去写报告结果 B 根本不知道 A 干了什么于是又自己脑补一遍资料最后两份内容对不上。这种事情在单 Agent 场景里几乎不会暴露因为单 Agent 聊着聊着还能靠对话历史撑一撑但多 Agent 一拆开记忆链条一断整个系统立刻露出原形。这篇文章的读者应该是已经在跑 Agent 项目、或者正准备从单 Agent 升级到多 Agent 架构的人。不管你是用 OpenAI 的 Assistants API、LangGraph、AutoGen还是自己手搓了一套 Pipeline“失忆”问题你大概率都会碰到。我把自己的踩坑过程、排查思路和最后的工程方案都写下来希望能让你少走一两周弯路。1.1 “失忆”不是比喻是上下文窗口的物理局限先聊本质。很多刚入门的人会觉得Agent 不就是 LLM 套个循环吗只要模型强对话历史长它不就“记住了”吗这个理解在单 Agent 场景近似成立但在多 Agent 场景会出大问题。核心原因在于每个 Agent 的模型上下文窗口是有限的。你不可能把所有 Agent 的历史对话、中间输出、工具调用结果全都塞进同一个上下文里塞不下的后果有两个——一是成本爆炸。Tokens 是按量收费的上下文越长越贵多 Agent 系统里如果每个节点都拷贝全量历史那开销是呈指数级上涨的。二是注意力稀释。模型在处理超长上下文时对中段信息的关注度会显著下降信息不是“没在那”而是“看到了等于没看到”这就是所谓的“Lost in the Middle”。当你指望 B Agent 回忆起 A Agent 在 20 轮之前埋下的关键字段时它可能真的“忘了”——不是模型笨是注意力机制天生有取舍。这还只是物理层面的局限。更麻烦的是工程层面的问题你给 Agent 之间传什么、怎么传是传原始对话传摘要传结构化 JSON传向量索引每一步都涉及“信息损耗”而损耗的累积最终就表现为协作系统的失忆。1.2 “模型强”和“协作稳”完全是两码事我见过不少团队一开始用 GPT-4o 或者 Claude 级别的模型跑多 Agent觉得既然每个 Agent 都那么聪明整体肯定没问题。结果真跑起来发现聪明的模型反而更容易“自由发挥”——因为推理能力强它会在上下文缺失时自动脑补出合理的中间步骤然后基于脑补的内容继续往下走最后给出的结果看起来逻辑通顺实际上从根上就是错的。这种错误很隐蔽排查起来极其痛苦。而弱一点的模型遇到信息缺失可能直接报错、说“我不知道”反而更早暴露问题。所以要清楚多 Agent 协作的稳定性严重依赖记忆机制——谁来存、谁来取、什么时候失效、失效了怎么办。模型只是执行机构记忆系统才是整个协作网络的地基。地基没打牢你换再强的执行机构它也只是在废墟上跳舞。2. 多 Agent 协作里失忆的三种典型形态为了让你对“失忆”有更具体的感知我把踩过的坑分成三种形态链路型失忆、并行型失忆和动态拓扑型失忆。它们成因不同、表现不同、排查方法也不同。2.1 链路型失忆后一个 Agent 不知道前一个 Agent 说了什么这是最常见的一种也是大部分人的“第一个多 Agent 项目”会遇到的情况。比如你搭了一条流水线Planner - Researcher - Writer - Reviewer。Planner 定好大纲Researcher 根据大纲查资料Writer 根据资料写文章Reviewer 最后审核。表面上这是合理的流程设计但实际运行时问题一个接一个地冒出来Researcher 可能没有拿到 Planner 的完整大纲只拿到了一个方向性关键词于是搜出来的资料和计划完全无关。Writer 看到的是 Researcher 返回的一堆原始 URL 和摘要却不知道哪些是重点、哪些是排除项只能凭感觉写。Reviewer 看到的是一篇已经写好的文章却不知道最初的用户需求是什么只能基于“文章本身的合理性”来评审等于没审。你说“那我在调用下一个 Agent 时把前一个 Agent 的输出传进去不就行了吗”——这是最朴素的传参思路但它有个致命缺陷你需要手动定义每一跳的参数映射。项目一复杂比如 Planncr 产出 30 个字段Researcher 产出 80 条资料Writer 只用到其中 12 条Reviewer 又需要原始用户诉求加上 Writer 的自我说明……你会发现信息链越来越臃肿每个环节都在“精简-失真-再精简-再失真”等到最后一个 Agent它拿到的东西可能只剩第一跳的 20%。我在一个实际项目里就碰到过这种状况系统生成了看起来很专业的行业研究报告但里面引用的数据来源和最初用户指定的数据范围完全对不上。后来一查日志发现是第三跳的 Agent 在传参时把“用户指定年份”这一个字段丢了而后面的 Agent 全都没有校验直接在错误年份上继续查、继续写最后产出了一个“看起来很美、实则全错”的结果。这个还不是模型能力问题就是我说的链路型失忆。2.2 并行型失忆各写各的谁也不知道别人改了啥比链路更坑的是并行场景。多 Agent 协作里经常要并行处理多个子任务比如同时让几个 Agent 分别调研不同方向然后汇总。并行带来一个严重问题子任务之间天然是隔离的彼此看不到对方的中间状态。举个例子。我做过一个内容聚合系统三个 Agent 分别负责写“行业趋势”“竞品动态”“技术方案”三个章节最后有一个 Summarizer 汇总。刚开始觉得很简单跑起来才发现竞品动态 Agent 引用了“某厂商在 6 月份发布了新版本”这个信息这个信息其实来自行业趋势 Agent 的某条资料但因为两个 Agent 并行跑竞品动态 Agent 只能靠自己的检索能力去猜猜错了就自己编了一个日期。技术方案 Agent 在写建议时会自然地引用趋势章节的结论但由于它在并行环境下没有拿到趋势章节的最终结果只能基于一个早期草稿来引用结果汇总时发现方案和趋势内容打架了。这种并行型失忆的本质是缺乏共享状态。单个 Agent 的成功不意味着系统的成功你需要的是一个公共的“白板”——每个 Agent 在上面写自己做了什么、产出了什么、依赖了什么其他 Agent 可以去读也可以在冲突时回溯。如果这块白板不存在你面临的就不是“某个 Agent 能力不足”而是整个系统的信息孤岛化。每个 Agent 都在局部最优解上努力但因为看不到全局最后拼出来的整体反而是矛盾百出的。2.3 动态拓扑型失忆Agent 数量一变记忆全乱还有一种更隐蔽的情况发生在动态 Agent 拓扑的系统里。比如你用 Agent 来动态判定子任务该交给谁处理或者在多轮对话中动态创建新的 Agent 去完成临时任务。动态拓扑的难点在于你不仅要维护每个 Agent 自己的记忆还要维护 Agent 之间的“关系记忆”——谁是谁的上游、谁消费了谁的结果、哪个 Agent 是被临时创建出来处理某个子问题的。我有一次做“智能招聘助手”的 MVP用了一个动态规划的思路第一轮让 HR Agent 解析招聘需求然后动态决定要不要创建“技术面 Agent”“人力面 Agent”“背景调查 Agent”。测试初期没有问题因为流程都是顺序执行的。但当我加了一个“补充面试 Agent”——因为技术面 Agent 觉得候选人的项目经验不够清晰需要进一步追问——问题立刻来了。补充面试 Agent 结束后它需要把新信息并入原来的候选人评价但主 Agent 已经基于早期的评价给候选人打了分。新信息来了之后主 Agent 完全不知道该更新哪些分数、更新后需不需要重新走一遍后续流程。于是系统里出现了一个诡异的现象候选人最开始被评价为“不推荐”但补充面试完又被标注为“强烈推荐”而终态报告里两个结论同时存在没有任何冲突检测。这就是动态拓扑失忆——新增节点没有妥善接入既有记忆网络导致信息在结构层面发生了断裂。3. 一次印象深刻的失忆大排查根因居然在缓存层前面讲的都是形态这一章我完整复盘一次真实排查过程。这个案例特别典型因为最终根因既不是模型弱也不是逻辑设计失误而是出在很多人根本不会多看一眼的中间缓存层。3.1 业务背景和故障现象当时我们在做一个多 Agent 的智能客服系统。结构是一个意图识别 Agent负责判断用户要什么一个知识库检索 Agent负责找答案一个回答生成 Agent负责组织话术一个转人工判定 Agent负责判断要不要把用户转到真人客服。上线头几天效果不错用户满意度也挺高。但一周后运营反馈用户经常问“我刚刚说了什么”之类的问题客服系统回答得驴唇不对马嘴。比如用户问了一句“订单怎么还没到”意图识别判定为“物流查询”检索 Agent 查了物流信息回答 Agent 给了标准的“您的包裹正在运输中”话术。但当用户在下一轮继续追问“那退款呢”系统居然还回复物流信息完全没有识别出“退款”是新意图。一开始我们怀疑是意图识别模型的问题换了几种模型现象还在。又怀疑是链路编排问题但人工回放日志每一步的输入输出都是按流程走的逻辑上没有任何跳步。后来才发现问题真正出在缓存。3.2 排查链路从模型到 Prompt 再到缓存我们当时的排查分了三步。第一步对比单轮与多轮表现。把同样的用户对话喂给一个“不经过多 Agent 编排”的裸模型发现裸模型在多轮语境下能正确识别“退款”意图。这说明基础模型的上下文能力没有问题问题出在多 Agent 编排过程中的信息传递。第二步导出各 Agent 的实际输入。我们发现检索 Agent 的输入里只包含当前用户问题完全没有上一轮用户的原始诉求。这不是设计图上的样子设计图上明确写了“需要传入最近三轮对话上下文”。那上下文去哪了第三步追踪上下文的来源。发现上下文是由一个叫 ConversationMemory 的模块提供的而这个模块为了“提高性能”在内存里做了一层 LRU 缓存只保留高频命中的对话片段。由于“物流查询”相关的历史对话比较容易命中缓存而“退款”相关的上下文片段在用户第一次提出时根本没有被写进缓存当时系统判定暂不需要退款能力于是一个新意图出现时缓存里没有它需要的上下文ConversationMemory 返回了一堆无关的历史内容检索 Agent 也就跟着跑偏了。现在看这个根因很搞笑——缓存层的淘汰策略和多 Agent 的上下文需求完全错配。缓存关心的是“哪些内容被频繁访问”而 Agent 需要的是“哪些内容属于当前逻辑链路”。这两者根本不是一个维度。我们用了很多精力去优化模型、优化 Prompt最后却栽在了一个表现层为了性能而做的缓存上。3.3 从这次排查中得到的三个判断这件事给我带来三个后续一直受用的判断第一排查多 Agent 问题时先看“信息是否忠实传递”而不是先怀疑模型。很多表层的错误往深处挖都是某个中间环节把信息丢掉了。大部分 Agent 框架自带的日志默认记录每个节点的输入输出但不会告诉你“某个输入字段是否被意外丢弃”你需要自己去拼链路。第二任何中间状态管理模块缓存、向量库、内存存储都必须知道自己在为谁服务。缓存不是越强越好而是要能理解 Agent 协作的语义边界。简单说你在缓存设计里必须允许“按会话 ID 任务 ID 绑定上下文”而不是只按内容相似度匹配。第三人肉复现成本很高但不可跳过。我们当时为了定位这个问题连续人工跑了三天同一个用户场景每一步都截图保存才终于确定了丢失发生在哪一环。虽然事后看如果能更早跟踪缓存肯定能省时间但如果你不做这种“土法复现”很多问题是根本定位不到的。4. 工程上到底怎么解决“失忆”我的分层记忆架构聊了这么多问题肯定要给方案。经过好几个项目迭代我把自己的实践整理成了一套自认为目前最稳的架构——分层记忆服务加两条共享链路规则。不需要引入特别复杂的外部组件用常见的 Redis、向量库和消息队列就能搭起来。4.1 工作记忆、情景记忆、语义记忆三者分开存我先把记忆空间分成三层对应不同生命力周期的数据工作记忆服务于当前正在进行的任务链。比如“用户当前这个问题的原始诉求”“上一个 Agent 返回的中间结果”“正在等待哪个 Agent 的回复”。这类数据生命周期极短任务一结束就可以清掉但读写频率最高。我通常用 Redis 的 Hash 结构存储键格式为session:{会话ID}:task:{任务ID}:memory字段按照 Agent 名称命名。情景记忆记录“这个会话发生了什么事”。比如用户在第 3 轮问过物流第 4 轮问退款检索 Agent 当时返回了什么结果。这类数据需要跨任务保留但不需要像向量库那样做复杂语义检索直接用结构化日志存储就行。我习惯用 MongoDB 或者 PostgreSQL JSONB 存按会话 ID 和轮次索引。语义记忆沉淀到全局的、可以复用的事实知识。比如“这个店铺的退款政策是什么”“这个知识库里的某个知识点最近被高频命中”。这类数据适合放向量库比如用 pgvector、Qdrant 或者 Chroma用来支撑“跨用户、跨会话的知识召回”。为什么要分层因为不同生命周期的数据它的读写模式、容量需求和一致性要求完全不同。如果你把工作记忆和语义记忆都塞进同一个向量库结果就是短时任务里的临时状态被向量相似度匹配污染需要精确读取时拿不到完整字段而长时知识又因为夹杂太多临时噪声召回质量变差。分层之后你还可以针对每一层单独做性能调优和容量规划。4.2 写入比读取更重要别让记忆变成垃圾桶很多刚开始做记忆系统的团队把大把精力花在“怎么优雅地读取记忆”却很少设计“怎么写入记忆”。结果就是什么数据都往记忆里塞过两天检索出来的全是垃圾于是得出结论记忆没用。我的经验是写入阶段就要做取舍。有三个基本规则每条记忆必须带来源标签。谁产生、在哪个任务、什么时间缺失这三项的直接过滤掉。这不仅能帮你做审计回溯也能让后续 Agent 在读取时知道“这条记忆的置信度该打几分”。比如带 Reviewer 确认标签的记忆优先级就应该高于某个 Agent 自己写的草稿。高价值信息做强结构化低价值信息做摘要。拿多 Agent 协作来说不是所有中间字段都需要进记忆。我们把“每个 Agent 的输入、输出、调用的工具列表”这些核心信息以结构化 JSON 方式原样写入而“中间推理过程”“被剪掉的草稿片段”这些冗余信息则用摘要方式写入摘要丢掉细节可以接受。删除与更新要显式触发。多 Agent 系统里最怕的就是一个 Agent 更新了自己记忆但不知道下游 Agent 已经读取了旧版本。所以我们的记忆服务必须支持版本号每次写入都会产生新版本下游 Agent 读到的记忆都会带上版本标记。一旦发现版本落后可以触发级联刷新或者至少发起冲突提醒。4.3 用事件总线做同步而不是让 Agent 互相直连另一个关键设计是不要让 Agent 之间直接互相读取记忆而是通过一个事件总线来同步。为什么要绕一层是因为直接互连会形成网状的强耦合链路编排一动就散。我的做法是每个 Agent 在完成任务后把结果发布为一个领域事件。比如ArticleWritten、SearchCompleted、ScoreUpdated。事件总线负责把事件写入情景记忆层并完成一次语义索引更新。下游 Agent 在需要时向记忆服务发起查询而不是直接去拿上游 Agent 的内存对象。这样做的好处至少有四点解耦。上游 Agent 挂了、换版本了下游 Agent 感知不到它只依赖记忆服务里的数据。可重放。事件总线支持按时间窗口重放事件这意味着如果某次协作中 Agent A 的执行结果有误你可以修正后重放 A 的事件下游 B、C 就能基于修正后的记忆自动重新产出不需要人工手动改。审计友好。任何一次跨 Agent 信息流转在事件总线里都有记录出了问题可以沿着事件链路回溯而不是靠猜。并发控制。并行 Agent 同时写同一记忆条目时可以通过事件总线的顺序化来避免互相覆盖。4.4 每个 Agent 还必须有自己的“记忆接口层”除了中央记忆服务每个 Agent 内部也建议封装一个轻量的 memory 适配器而不是直接调用模型 API。这个适配器的职责只有一个在上文构造时从中央记忆服务拉取当前任务需要的记忆片段然后拼装成符合当前模型上下文长度的输入。这个适配器至少要实现三个函数remember()从记忆服务拉取指定维度的上下文支持白名单字段。forget()主动丢弃不再相关的记忆片段减少上下文噪声。review()在 Agent 输出之后做一次一致性检查比对关键事实与记忆里的记录是否冲突。有了这层你在换模型、调 Prompt、增删 Agent 时大部分改动都会集中在这个适配器里而不是重写整个编排逻辑。这也算是我踩过那么多坑之后比较推荐的“反脆弱设计”。5. 一份可以直接抄的失忆排查清单前面讲了很多原理和架构最后给你一份我每次遇到多 Agent 行为异常时都会跑的排查清单。这个清单是按顺序执行的每查一步都可以直接操作不用绕弯子。5.1 五步定位法确认当前 Agent 实际拿到的上下文内容。这一步最容易被忽略。不要看代码里传了什么要看运行时真正到达 Agent 的 Prompt 长什么样。大部分框架支持在调试模式打印完整 Prompt如果框架不支持直接在 Agent 入口打一行日志输出收到的上下文。很多人这一步一做问题就解决了一半——因为绝大多数“失忆”都发生在传输层不是你逻辑写错了而是某个字段没传过来。检查记忆写入的时机。如果 Agent 读取时发现缺少某个信息先问这条信息在源头上有没有被写入记忆很多时候不是因为读取逻辑有问题而是因为写入逻辑压根没触发。比如上一轮 Agent 结果只在内存里被下游直接消费而没有同步进记忆服务那一旦链路重来这个信息就永久丢失了。对比单 Agent 与多 Agent 的行为差异。用同样的输入跑一遍裸模型或单个 Agent看它是否产出正确答案。如果裸模型能答对而多 Agent 答错那和模型智商无关九成是信息传递问题如果裸模型也答错那才回去检查模型和 Prompt。引入版本号追踪。在所有记忆读写接口加一个version字段。当系统出现“下游用了旧数据”的迹象时通过版本号可以快速判断是哪一环更新了数据却未通知下游。做一次全链路回放。把事件总线的所有事件按时间排个序检查有没有逻辑断裂——某个 Agent 引用了另一个 Agent 根本未发布的事件类型这种情况在动态拓扑里特别常见。5.2 一些容易踩的隐藏坑再说几个你以为你知道了但真到项目里还是会踩的隐藏坑。第一摘要型记忆千万别太“贪心”。很多团队会把上一层 Agent 的完整输出直接硬塞给模型去生成摘要然后把摘要存进记忆。问题在于模型摘要终究有信息损耗特别是一些数字、日期、ID 类的字段模型会为了“流畅”而改写。后来我们咬咬牙把结构化关键字段一律按原始文本存取只有纯文本叙述性内容才走摘要。第二别让 Agent 之间的“礼貌社交”占用宝贵上下文。多 Agent 协作时上游 Agent 的输出经常会包含“好的我来帮你查一下”“根据您的需求以下是我找到的信息”之类的对用户说话的话术。这些花边内容完全不适合作为下游 Agent 的输入我们的做法是定义中间消息格式{role: assistant, content: 纯数据结果, meta: {结构化字段}}每个 Agent 输出前统一做一次“脱壳”把面向用户的话术剥离只留纯数据和分析。第三测并发时一定不要只看最终结果对不对要看中间产物是否一致。并行 Agent 最容易出现的一种情况是每个 Agent 最终输出都正常但中间互相引用的数据来自不同的时间快照导致汇总时出现“左右互搏”。我们的解决方案是在中央记忆服务里加入快照隔离每个任务开始执行前给它固定一个记忆版本这个版本在整个任务生命周期内不发生变化保证所有读取都基于同一份数据。收尾一个关于“记忆”项目的个人体会最后说点比较个人化的东西。我做了几个多 Agent 项目之后最大的感受是Agent 系统的复杂度并不体现在模型调用上而体现在状态管理上。每一个 Agent 都是一个有行为的小单元但它们能否协同工作取决于整个网络有没有一套可靠的“记忆神经系统”。而这套神经系统的构建远比选哪个模型、调什么温度参数要费心思。如果你现在正准备启动多 Agent 项目我的建议是先把核心流程跑通哪怕用最丑的方式传参然后把所有中间状态打印出来对着日志梳理一遍信息流。梳理完之后你自然会发现哪些信息是必须共享的、哪些是可有可无的、哪些环节需要记忆服务介入。到这一步再上分层记忆也好、事件总线也好都会觉得顺理成章。以后再遇到“Agent 行为很奇怪”的问题先别急着甩锅给模型。给记忆系统做个体检大概率你会发现真正该升级的不是模型卡而是你们的记忆线路。
1. 先给结论多 Agent 协作的瓶颈根本不是模型能力这两年做 AI Agent 的人越来越多从单 Agent 的 Demo 走向多 Agent 协作时大家嘴上说的都是“我的模型太笨了”“推理能力不够”“需要上一个更强的模型”。但在我实际折腾过的几个项目里真正让整个系统翻车的几乎都不是模型智商而是“失忆”。所谓失忆就是多个 Agent 之间无法共享、继承和回溯上下文——前一个 Agent 说过的话、做出的中间决策、已经完成的状态到了后一个 Agent 那里全部归零。你让 A Agent 去检索资料B Agent 拿着它产出的结果去写报告结果 B 根本不知道 A 干了什么于是又自己脑补一遍资料最后两份内容对不上。这种事情在单 Agent 场景里几乎不会暴露因为单 Agent 聊着聊着还能靠对话历史撑一撑但多 Agent 一拆开记忆链条一断整个系统立刻露出原形。这篇文章的读者应该是已经在跑 Agent 项目、或者正准备从单 Agent 升级到多 Agent 架构的人。不管你是用 OpenAI 的 Assistants API、LangGraph、AutoGen还是自己手搓了一套 Pipeline“失忆”问题你大概率都会碰到。我把自己的踩坑过程、排查思路和最后的工程方案都写下来希望能让你少走一两周弯路。1.1 “失忆”不是比喻是上下文窗口的物理局限先聊本质。很多刚入门的人会觉得Agent 不就是 LLM 套个循环吗只要模型强对话历史长它不就“记住了”吗这个理解在单 Agent 场景近似成立但在多 Agent 场景会出大问题。核心原因在于每个 Agent 的模型上下文窗口是有限的。你不可能把所有 Agent 的历史对话、中间输出、工具调用结果全都塞进同一个上下文里塞不下的后果有两个——一是成本爆炸。Tokens 是按量收费的上下文越长越贵多 Agent 系统里如果每个节点都拷贝全量历史那开销是呈指数级上涨的。二是注意力稀释。模型在处理超长上下文时对中段信息的关注度会显著下降信息不是“没在那”而是“看到了等于没看到”这就是所谓的“Lost in the Middle”。当你指望 B Agent 回忆起 A Agent 在 20 轮之前埋下的关键字段时它可能真的“忘了”——不是模型笨是注意力机制天生有取舍。这还只是物理层面的局限。更麻烦的是工程层面的问题你给 Agent 之间传什么、怎么传是传原始对话传摘要传结构化 JSON传向量索引每一步都涉及“信息损耗”而损耗的累积最终就表现为协作系统的失忆。1.2 “模型强”和“协作稳”完全是两码事我见过不少团队一开始用 GPT-4o 或者 Claude 级别的模型跑多 Agent觉得既然每个 Agent 都那么聪明整体肯定没问题。结果真跑起来发现聪明的模型反而更容易“自由发挥”——因为推理能力强它会在上下文缺失时自动脑补出合理的中间步骤然后基于脑补的内容继续往下走最后给出的结果看起来逻辑通顺实际上从根上就是错的。这种错误很隐蔽排查起来极其痛苦。而弱一点的模型遇到信息缺失可能直接报错、说“我不知道”反而更早暴露问题。所以要清楚多 Agent 协作的稳定性严重依赖记忆机制——谁来存、谁来取、什么时候失效、失效了怎么办。模型只是执行机构记忆系统才是整个协作网络的地基。地基没打牢你换再强的执行机构它也只是在废墟上跳舞。2. 多 Agent 协作里失忆的三种典型形态为了让你对“失忆”有更具体的感知我把踩过的坑分成三种形态链路型失忆、并行型失忆和动态拓扑型失忆。它们成因不同、表现不同、排查方法也不同。2.1 链路型失忆后一个 Agent 不知道前一个 Agent 说了什么这是最常见的一种也是大部分人的“第一个多 Agent 项目”会遇到的情况。比如你搭了一条流水线Planner - Researcher - Writer - Reviewer。Planner 定好大纲Researcher 根据大纲查资料Writer 根据资料写文章Reviewer 最后审核。表面上这是合理的流程设计但实际运行时问题一个接一个地冒出来Researcher 可能没有拿到 Planner 的完整大纲只拿到了一个方向性关键词于是搜出来的资料和计划完全无关。Writer 看到的是 Researcher 返回的一堆原始 URL 和摘要却不知道哪些是重点、哪些是排除项只能凭感觉写。Reviewer 看到的是一篇已经写好的文章却不知道最初的用户需求是什么只能基于“文章本身的合理性”来评审等于没审。你说“那我在调用下一个 Agent 时把前一个 Agent 的输出传进去不就行了吗”——这是最朴素的传参思路但它有个致命缺陷你需要手动定义每一跳的参数映射。项目一复杂比如 Planncr 产出 30 个字段Researcher 产出 80 条资料Writer 只用到其中 12 条Reviewer 又需要原始用户诉求加上 Writer 的自我说明……你会发现信息链越来越臃肿每个环节都在“精简-失真-再精简-再失真”等到最后一个 Agent它拿到的东西可能只剩第一跳的 20%。我在一个实际项目里就碰到过这种状况系统生成了看起来很专业的行业研究报告但里面引用的数据来源和最初用户指定的数据范围完全对不上。后来一查日志发现是第三跳的 Agent 在传参时把“用户指定年份”这一个字段丢了而后面的 Agent 全都没有校验直接在错误年份上继续查、继续写最后产出了一个“看起来很美、实则全错”的结果。这个还不是模型能力问题就是我说的链路型失忆。2.2 并行型失忆各写各的谁也不知道别人改了啥比链路更坑的是并行场景。多 Agent 协作里经常要并行处理多个子任务比如同时让几个 Agent 分别调研不同方向然后汇总。并行带来一个严重问题子任务之间天然是隔离的彼此看不到对方的中间状态。举个例子。我做过一个内容聚合系统三个 Agent 分别负责写“行业趋势”“竞品动态”“技术方案”三个章节最后有一个 Summarizer 汇总。刚开始觉得很简单跑起来才发现竞品动态 Agent 引用了“某厂商在 6 月份发布了新版本”这个信息这个信息其实来自行业趋势 Agent 的某条资料但因为两个 Agent 并行跑竞品动态 Agent 只能靠自己的检索能力去猜猜错了就自己编了一个日期。技术方案 Agent 在写建议时会自然地引用趋势章节的结论但由于它在并行环境下没有拿到趋势章节的最终结果只能基于一个早期草稿来引用结果汇总时发现方案和趋势内容打架了。这种并行型失忆的本质是缺乏共享状态。单个 Agent 的成功不意味着系统的成功你需要的是一个公共的“白板”——每个 Agent 在上面写自己做了什么、产出了什么、依赖了什么其他 Agent 可以去读也可以在冲突时回溯。如果这块白板不存在你面临的就不是“某个 Agent 能力不足”而是整个系统的信息孤岛化。每个 Agent 都在局部最优解上努力但因为看不到全局最后拼出来的整体反而是矛盾百出的。2.3 动态拓扑型失忆Agent 数量一变记忆全乱还有一种更隐蔽的情况发生在动态 Agent 拓扑的系统里。比如你用 Agent 来动态判定子任务该交给谁处理或者在多轮对话中动态创建新的 Agent 去完成临时任务。动态拓扑的难点在于你不仅要维护每个 Agent 自己的记忆还要维护 Agent 之间的“关系记忆”——谁是谁的上游、谁消费了谁的结果、哪个 Agent 是被临时创建出来处理某个子问题的。我有一次做“智能招聘助手”的 MVP用了一个动态规划的思路第一轮让 HR Agent 解析招聘需求然后动态决定要不要创建“技术面 Agent”“人力面 Agent”“背景调查 Agent”。测试初期没有问题因为流程都是顺序执行的。但当我加了一个“补充面试 Agent”——因为技术面 Agent 觉得候选人的项目经验不够清晰需要进一步追问——问题立刻来了。补充面试 Agent 结束后它需要把新信息并入原来的候选人评价但主 Agent 已经基于早期的评价给候选人打了分。新信息来了之后主 Agent 完全不知道该更新哪些分数、更新后需不需要重新走一遍后续流程。于是系统里出现了一个诡异的现象候选人最开始被评价为“不推荐”但补充面试完又被标注为“强烈推荐”而终态报告里两个结论同时存在没有任何冲突检测。这就是动态拓扑失忆——新增节点没有妥善接入既有记忆网络导致信息在结构层面发生了断裂。3. 一次印象深刻的失忆大排查根因居然在缓存层前面讲的都是形态这一章我完整复盘一次真实排查过程。这个案例特别典型因为最终根因既不是模型弱也不是逻辑设计失误而是出在很多人根本不会多看一眼的中间缓存层。3.1 业务背景和故障现象当时我们在做一个多 Agent 的智能客服系统。结构是一个意图识别 Agent负责判断用户要什么一个知识库检索 Agent负责找答案一个回答生成 Agent负责组织话术一个转人工判定 Agent负责判断要不要把用户转到真人客服。上线头几天效果不错用户满意度也挺高。但一周后运营反馈用户经常问“我刚刚说了什么”之类的问题客服系统回答得驴唇不对马嘴。比如用户问了一句“订单怎么还没到”意图识别判定为“物流查询”检索 Agent 查了物流信息回答 Agent 给了标准的“您的包裹正在运输中”话术。但当用户在下一轮继续追问“那退款呢”系统居然还回复物流信息完全没有识别出“退款”是新意图。一开始我们怀疑是意图识别模型的问题换了几种模型现象还在。又怀疑是链路编排问题但人工回放日志每一步的输入输出都是按流程走的逻辑上没有任何跳步。后来才发现问题真正出在缓存。3.2 排查链路从模型到 Prompt 再到缓存我们当时的排查分了三步。第一步对比单轮与多轮表现。把同样的用户对话喂给一个“不经过多 Agent 编排”的裸模型发现裸模型在多轮语境下能正确识别“退款”意图。这说明基础模型的上下文能力没有问题问题出在多 Agent 编排过程中的信息传递。第二步导出各 Agent 的实际输入。我们发现检索 Agent 的输入里只包含当前用户问题完全没有上一轮用户的原始诉求。这不是设计图上的样子设计图上明确写了“需要传入最近三轮对话上下文”。那上下文去哪了第三步追踪上下文的来源。发现上下文是由一个叫 ConversationMemory 的模块提供的而这个模块为了“提高性能”在内存里做了一层 LRU 缓存只保留高频命中的对话片段。由于“物流查询”相关的历史对话比较容易命中缓存而“退款”相关的上下文片段在用户第一次提出时根本没有被写进缓存当时系统判定暂不需要退款能力于是一个新意图出现时缓存里没有它需要的上下文ConversationMemory 返回了一堆无关的历史内容检索 Agent 也就跟着跑偏了。现在看这个根因很搞笑——缓存层的淘汰策略和多 Agent 的上下文需求完全错配。缓存关心的是“哪些内容被频繁访问”而 Agent 需要的是“哪些内容属于当前逻辑链路”。这两者根本不是一个维度。我们用了很多精力去优化模型、优化 Prompt最后却栽在了一个表现层为了性能而做的缓存上。3.3 从这次排查中得到的三个判断这件事给我带来三个后续一直受用的判断第一排查多 Agent 问题时先看“信息是否忠实传递”而不是先怀疑模型。很多表层的错误往深处挖都是某个中间环节把信息丢掉了。大部分 Agent 框架自带的日志默认记录每个节点的输入输出但不会告诉你“某个输入字段是否被意外丢弃”你需要自己去拼链路。第二任何中间状态管理模块缓存、向量库、内存存储都必须知道自己在为谁服务。缓存不是越强越好而是要能理解 Agent 协作的语义边界。简单说你在缓存设计里必须允许“按会话 ID 任务 ID 绑定上下文”而不是只按内容相似度匹配。第三人肉复现成本很高但不可跳过。我们当时为了定位这个问题连续人工跑了三天同一个用户场景每一步都截图保存才终于确定了丢失发生在哪一环。虽然事后看如果能更早跟踪缓存肯定能省时间但如果你不做这种“土法复现”很多问题是根本定位不到的。4. 工程上到底怎么解决“失忆”我的分层记忆架构聊了这么多问题肯定要给方案。经过好几个项目迭代我把自己的实践整理成了一套自认为目前最稳的架构——分层记忆服务加两条共享链路规则。不需要引入特别复杂的外部组件用常见的 Redis、向量库和消息队列就能搭起来。4.1 工作记忆、情景记忆、语义记忆三者分开存我先把记忆空间分成三层对应不同生命力周期的数据工作记忆服务于当前正在进行的任务链。比如“用户当前这个问题的原始诉求”“上一个 Agent 返回的中间结果”“正在等待哪个 Agent 的回复”。这类数据生命周期极短任务一结束就可以清掉但读写频率最高。我通常用 Redis 的 Hash 结构存储键格式为session:{会话ID}:task:{任务ID}:memory字段按照 Agent 名称命名。情景记忆记录“这个会话发生了什么事”。比如用户在第 3 轮问过物流第 4 轮问退款检索 Agent 当时返回了什么结果。这类数据需要跨任务保留但不需要像向量库那样做复杂语义检索直接用结构化日志存储就行。我习惯用 MongoDB 或者 PostgreSQL JSONB 存按会话 ID 和轮次索引。语义记忆沉淀到全局的、可以复用的事实知识。比如“这个店铺的退款政策是什么”“这个知识库里的某个知识点最近被高频命中”。这类数据适合放向量库比如用 pgvector、Qdrant 或者 Chroma用来支撑“跨用户、跨会话的知识召回”。为什么要分层因为不同生命周期的数据它的读写模式、容量需求和一致性要求完全不同。如果你把工作记忆和语义记忆都塞进同一个向量库结果就是短时任务里的临时状态被向量相似度匹配污染需要精确读取时拿不到完整字段而长时知识又因为夹杂太多临时噪声召回质量变差。分层之后你还可以针对每一层单独做性能调优和容量规划。4.2 写入比读取更重要别让记忆变成垃圾桶很多刚开始做记忆系统的团队把大把精力花在“怎么优雅地读取记忆”却很少设计“怎么写入记忆”。结果就是什么数据都往记忆里塞过两天检索出来的全是垃圾于是得出结论记忆没用。我的经验是写入阶段就要做取舍。有三个基本规则每条记忆必须带来源标签。谁产生、在哪个任务、什么时间缺失这三项的直接过滤掉。这不仅能帮你做审计回溯也能让后续 Agent 在读取时知道“这条记忆的置信度该打几分”。比如带 Reviewer 确认标签的记忆优先级就应该高于某个 Agent 自己写的草稿。高价值信息做强结构化低价值信息做摘要。拿多 Agent 协作来说不是所有中间字段都需要进记忆。我们把“每个 Agent 的输入、输出、调用的工具列表”这些核心信息以结构化 JSON 方式原样写入而“中间推理过程”“被剪掉的草稿片段”这些冗余信息则用摘要方式写入摘要丢掉细节可以接受。删除与更新要显式触发。多 Agent 系统里最怕的就是一个 Agent 更新了自己记忆但不知道下游 Agent 已经读取了旧版本。所以我们的记忆服务必须支持版本号每次写入都会产生新版本下游 Agent 读到的记忆都会带上版本标记。一旦发现版本落后可以触发级联刷新或者至少发起冲突提醒。4.3 用事件总线做同步而不是让 Agent 互相直连另一个关键设计是不要让 Agent 之间直接互相读取记忆而是通过一个事件总线来同步。为什么要绕一层是因为直接互连会形成网状的强耦合链路编排一动就散。我的做法是每个 Agent 在完成任务后把结果发布为一个领域事件。比如ArticleWritten、SearchCompleted、ScoreUpdated。事件总线负责把事件写入情景记忆层并完成一次语义索引更新。下游 Agent 在需要时向记忆服务发起查询而不是直接去拿上游 Agent 的内存对象。这样做的好处至少有四点解耦。上游 Agent 挂了、换版本了下游 Agent 感知不到它只依赖记忆服务里的数据。可重放。事件总线支持按时间窗口重放事件这意味着如果某次协作中 Agent A 的执行结果有误你可以修正后重放 A 的事件下游 B、C 就能基于修正后的记忆自动重新产出不需要人工手动改。审计友好。任何一次跨 Agent 信息流转在事件总线里都有记录出了问题可以沿着事件链路回溯而不是靠猜。并发控制。并行 Agent 同时写同一记忆条目时可以通过事件总线的顺序化来避免互相覆盖。4.4 每个 Agent 还必须有自己的“记忆接口层”除了中央记忆服务每个 Agent 内部也建议封装一个轻量的 memory 适配器而不是直接调用模型 API。这个适配器的职责只有一个在上文构造时从中央记忆服务拉取当前任务需要的记忆片段然后拼装成符合当前模型上下文长度的输入。这个适配器至少要实现三个函数remember()从记忆服务拉取指定维度的上下文支持白名单字段。forget()主动丢弃不再相关的记忆片段减少上下文噪声。review()在 Agent 输出之后做一次一致性检查比对关键事实与记忆里的记录是否冲突。有了这层你在换模型、调 Prompt、增删 Agent 时大部分改动都会集中在这个适配器里而不是重写整个编排逻辑。这也算是我踩过那么多坑之后比较推荐的“反脆弱设计”。5. 一份可以直接抄的失忆排查清单前面讲了很多原理和架构最后给你一份我每次遇到多 Agent 行为异常时都会跑的排查清单。这个清单是按顺序执行的每查一步都可以直接操作不用绕弯子。5.1 五步定位法确认当前 Agent 实际拿到的上下文内容。这一步最容易被忽略。不要看代码里传了什么要看运行时真正到达 Agent 的 Prompt 长什么样。大部分框架支持在调试模式打印完整 Prompt如果框架不支持直接在 Agent 入口打一行日志输出收到的上下文。很多人这一步一做问题就解决了一半——因为绝大多数“失忆”都发生在传输层不是你逻辑写错了而是某个字段没传过来。检查记忆写入的时机。如果 Agent 读取时发现缺少某个信息先问这条信息在源头上有没有被写入记忆很多时候不是因为读取逻辑有问题而是因为写入逻辑压根没触发。比如上一轮 Agent 结果只在内存里被下游直接消费而没有同步进记忆服务那一旦链路重来这个信息就永久丢失了。对比单 Agent 与多 Agent 的行为差异。用同样的输入跑一遍裸模型或单个 Agent看它是否产出正确答案。如果裸模型能答对而多 Agent 答错那和模型智商无关九成是信息传递问题如果裸模型也答错那才回去检查模型和 Prompt。引入版本号追踪。在所有记忆读写接口加一个version字段。当系统出现“下游用了旧数据”的迹象时通过版本号可以快速判断是哪一环更新了数据却未通知下游。做一次全链路回放。把事件总线的所有事件按时间排个序检查有没有逻辑断裂——某个 Agent 引用了另一个 Agent 根本未发布的事件类型这种情况在动态拓扑里特别常见。5.2 一些容易踩的隐藏坑再说几个你以为你知道了但真到项目里还是会踩的隐藏坑。第一摘要型记忆千万别太“贪心”。很多团队会把上一层 Agent 的完整输出直接硬塞给模型去生成摘要然后把摘要存进记忆。问题在于模型摘要终究有信息损耗特别是一些数字、日期、ID 类的字段模型会为了“流畅”而改写。后来我们咬咬牙把结构化关键字段一律按原始文本存取只有纯文本叙述性内容才走摘要。第二别让 Agent 之间的“礼貌社交”占用宝贵上下文。多 Agent 协作时上游 Agent 的输出经常会包含“好的我来帮你查一下”“根据您的需求以下是我找到的信息”之类的对用户说话的话术。这些花边内容完全不适合作为下游 Agent 的输入我们的做法是定义中间消息格式{role: assistant, content: 纯数据结果, meta: {结构化字段}}每个 Agent 输出前统一做一次“脱壳”把面向用户的话术剥离只留纯数据和分析。第三测并发时一定不要只看最终结果对不对要看中间产物是否一致。并行 Agent 最容易出现的一种情况是每个 Agent 最终输出都正常但中间互相引用的数据来自不同的时间快照导致汇总时出现“左右互搏”。我们的解决方案是在中央记忆服务里加入快照隔离每个任务开始执行前给它固定一个记忆版本这个版本在整个任务生命周期内不发生变化保证所有读取都基于同一份数据。收尾一个关于“记忆”项目的个人体会最后说点比较个人化的东西。我做了几个多 Agent 项目之后最大的感受是Agent 系统的复杂度并不体现在模型调用上而体现在状态管理上。每一个 Agent 都是一个有行为的小单元但它们能否协同工作取决于整个网络有没有一套可靠的“记忆神经系统”。而这套神经系统的构建远比选哪个模型、调什么温度参数要费心思。如果你现在正准备启动多 Agent 项目我的建议是先把核心流程跑通哪怕用最丑的方式传参然后把所有中间状态打印出来对着日志梳理一遍信息流。梳理完之后你自然会发现哪些信息是必须共享的、哪些是可有可无的、哪些环节需要记忆服务介入。到这一步再上分层记忆也好、事件总线也好都会觉得顺理成章。以后再遇到“Agent 行为很奇怪”的问题先别急着甩锅给模型。给记忆系统做个体检大概率你会发现真正该升级的不是模型卡而是你们的记忆线路。
