Feimore AI
开始使用

多智能体系统的可靠性，取决于上下文如何交接

2026 年 4 月，Cognition 的 Walden Yan 发表了一篇文章，标题是《Multi-Agents: What's Actually Working》（多智能体：到底什么在起作用）。这篇文章值得注意，因为写它的人，正是十个月前发表《Don't Build Multi-Agents》（别做多智能体）的同一个团队。

他们的新结论是：多智能体系统现在确实能用了，但只在一种很窄的形态下成立，即多个智能体可以一起贡献判断，写入必须保持单线。他们也明确说，当初的判断对“多个智能体并行写入”的设计依然成立；至于让任意多个智能体互相协商的网络式设计，他们的评价是“基本是在分散注意力”。

从 2025 年的“该不该拆”，到 2026 年的“怎样拆才不出事”，行业讨论的焦点已经变了。本文梳理这一年里最重要的几项公开进展，说明它们共同指向的那个问题，再分享 Feimore AI 作为一个多智能体内容系统，在这个问题上踩过的坑和找到的解法。

一、从一场争论到一组共识

起点是 2025 年 6 月的一场争论。 Cognition 当时认为，把任务拆给多个子智能体，每个子智能体只知道主智能体交代的那一句话，彼此看不到对方的决定，结果往往是“各自合理、合起来不对”。几乎同时，Anthropic 公布了他们的多智能体研究系统：一个主智能体规划，多个子智能体并行搜索，在内部研究评测上比单个 Claude Opus 4 智能体高出 90.2%，代价是约 15 倍于普通对话的 token 消耗。两边的分歧被 LangChain 总结为一句话：以“读”为主的多智能体系统，比以“写”为主的容易得多。

一年多过去，几项研究和一线经验让答案清晰了很多。

1. 失败主要来自系统设计，而不只是模型不够聪明。 伯克利团队的 MAST 研究最早发布于 2025 年 3 月，2025 年 10 月的版本把数据扩充到 7 个主流多智能体框架的 1,642 条运行记录，归纳出 14 种失败模式。出现最多的四类是：重复执行同一步骤（15.7%）、推理与实际行动不一致（13.2%）、不知道何时该结束（12.4%）、没有遵守任务要求（11.8%）。作者的判断是，许多失败源于组织设计与智能体之间的协调，只提升底层模型的能力不足以解决全部问题。

2. 被验证有效的模式都很“克制”。 Cognition 在 2026 年的文章里列出了三种在生产中站得住的模式：

  • 生成与审查分离：写代码的智能体和审查代码的智能体互相迭代，而且审查方最好不共享写作方的上下文，从干净的状态出发反而更容易发现问题。他们的审查智能体平均每个 PR 能发现约 2 个缺陷，其中约 58% 属于严重问题；
  • 向更强的模型求助：便宜的主模型遇到难题时，把自己完整上下文的一份副本交给更强的模型来判断；
  • 经理与子任务：一个经理智能体拆分任务、派生子智能体并负责协调。

同一篇文章也坦率列出了仍然失败的地方：经理智能体倾向于下达过细的指令；智能体会默认子智能体和自己共享某些状态，而实际上并没有；智能体之间的沟通不会自动发生。作者把剩下的难题都归结为一类：沟通问题。

3. 上下文不再被当作一个“往里塞东西的文本框”。 Google 在 2025 年 12 月介绍其智能体开发框架 ADK 的设计时提出：上下文是“对一个更丰富的有状态系统编译出来的视图”。会话、记忆、产物是源数据，每次调用模型前，按规则编译出这一次需要的那一部分。默认原则是每次调用和每个子智能体只看到所需的最小上下文；交接时还要做“翻译”，把上一个智能体的发言标注为别人说过的话，否则接手的智能体可能误以为那些动作是自己做的。

把这些放在一起看，结论很一致：拆不拆不是核心问题，拆开之后，上下文怎么交接才是。

二、上下文交接的三种典型失效

“上下文”可以简单理解为：智能体在做决定时，眼前能看到的全部信息。人类团队里，交接不清会导致返工；在智能体系统里，交接不清的后果更隐蔽，因为模型从不会说“我没看到”，它会基于看到的部分，给出一个看起来很合理的答案。

下面三种失效，都能在公开讨论里找到对应，也都是 Feimore 自己遇到过的问题：前两个出现在真实运行中，第三个是在一次全链路排查中发现的。

1. 交接丢失：传了指令，没传被否决的东西

场景。 增长总监智能体提出四个内容方向，运营看完回复，大意是“要和之前的不一样”。系统正确理解了这是“重做方向”，并把运营的这句话传给了重做的环节。

问题。 被否掉的那四个方向，没有作为必传内容一起交接。它们只存在于一个“可选上下文”里，在篇幅紧张时会被裁掉。于是重做的智能体知道“要不一样”，却不知道“和什么不一样”。复盘时我们还发现，那次新旧两轮方向的标题在字面上完全没有重合，所以即便新方向换汤不换药，也无法靠文本相似度在事后发现，只能在交接时就把被否决的内容交给模型。

这正是 Cognition 在 2026 年文章里点名的问题：上游默认下游“应该知道”某些信息，而下游其实并没有拿到。

解法。 我们把“人看到了什么”和“人说了什么”绑定成一个不可拆分的单元，称为一个评审回合。下游读取人的意见时，必须同时读到这条意见针对的具体内容；重做的每个方向还要写明自己和被否决方向的区别，质检发现重复时直接判为不合格。目前这套做法已经覆盖增长总监和创意导演两个环节的审批。

2. 截断与“上下文腐烂”：模型看到的不是你以为的

公开研究。 向量数据库公司 Chroma 在 2025 年 7 月发布了一项名为“上下文腐烂”（Context Rot）的研究，测试了 18 个模型，结论是在所有实验里，模型表现都随输入变长而持续下降；哪怕只加入一条相似的干扰信息，表现也会变差，而且输入越长，干扰的影响越大。“上下文窗口很大”不等于“模型能用好这么多上下文”。

我们的案例。 运营对成片提出返修意见后，有一个智能体负责把意见翻译成具体的修改操作。它的输入有 18,000 字符的硬上限，而真实的上下文有 30,000 到 35,000 字符。更糟的是，内容按字段名的字母顺序排列后直接截断，结果排在后面的运营反馈、质检意见、语速的可调范围全被截掉了。

模型没看到任何反馈，于是正确地返回了“没有需要修改的地方”。但系统的格式校验认为“修改列表不能为空”，要求它重来。模型只好照着说明文档里的示例编了一组修改，其中把语速写成了一个超出可用范围的值，最终导致返修失败。表面上是“模型乱改”，根源是“模型根本没看到该看的东西”，以及“没有修改”这个合法答案被当成了错误。

解法。 三处同时改：只传成片里真正用到的素材，而不是全部素材；各部分按优先级分配篇幅，超出时按事先定好的顺序逐项精简，绝不从尾部一刀切，并明确告诉模型哪些内容因篇幅被省略；“没有需要修改的地方”是合法答案，不再强迫模型凑出内容。

3. 身份漂移：同一个东西，在不同环节叫不同的名字

场景。 创意导演一次会给同一个平台出多个方案，界面上以“抖音-1”“抖音-2”这样的编号展示，运营也习惯用编号回复：“抖音-2 的开头改一下。”

问题。 早期有好几个下游环节在读不到编号时，会按方案的排列位置自己补一个，同一个方案在不同环节可能被叫成不同的号。我们改成集中登记之后，在排查中又发现一处隐患：登记表在某些情况下没有被各环节共享，每个方案拿到的都是一张空表，同一平台的每个方案都会被编成“抖音-1”。运营再用编号回复时，系统就无法判断指的是哪一个。

这类问题在多智能体系统里很常见：只要同一个对象的“身份”可以在多处被生成，迟早会在某一处出现分歧。

解法。 身份只在一处铸造，下游只读。方案编号在创意卡生成时确定一次，后续环节按“登记表、已保存的编号”的顺序读取，所有按位置临时编号的兜底逻辑全部删除。正在运行中的任务也不重新编号，因为已经给人看过的编号必须保持不变。

三、从这些坑里总结出的几条原则

读可以并行，写尽量单线。 Feimore 的市场研究由多条线并行搜索、各自带着原始引用返回，这是典型的“读”。而从方向、脚本到成片的创作链路是接力式的串行，每一步的产出都是下一步的输入。我们没有让多个智能体同时修改同一份脚本。

生成和审查分开。 Feimore 的创意导演写方案，创意质检官逐个挑问题；视频制作人出片，质量审核员独立打分。审查方的意见交回生成方修改，但写入只由生成方完成。这与 Cognition 在 2026 年验证的“生成与审查分离、写入单线”是同一种结构。

交接的是“工件加依据”，不是摘要。 摘要会丢掉被否决的选项、隐含的约束和做决定的理由。我们的做法是：整轮只有一份共享状态作为源数据，交接的内容是结构化的产物本身，以及它的来源和审批记录；每个智能体的输入再从这份状态里按需组装，而不是把全部内容都塞给它。这和 Google 所说的“上下文是编译出来的视图”是同一个思路。

必需和可选要分层，预算先算必需。 上下文不是越多越好，但必需的信息一条都不能少。哪些内容可以被裁剪、按什么顺序裁剪，要事先定义，而不是到了长度上限再从尾部一刀切。

身份、审批和计数由代码持有，不交给模型。 方案编号、谁批准了什么、某个问题已经来回了几轮，这些都是需要绝对可靠的事实。它们由代码维护，模型只读取，不书写。模型输出里自带的审批字段，系统一律不采信。

给智能体更多信息，而不是更多关卡。 很多“智能体做错了”的问题，根源是它缺少某个事实，而不是它需要人来盯。我们的第一选择是把缺失的信息补给它、把工具做得更好用、让工具在失败时当场告诉它原因；只有真正需要人来判断的事情，比如创意方向和最终发布，才留给人。

用真实运行回放来验证，而不只是手写测试数据。 我们曾有一项产前检查，在单元测试里一直通过，在真实运行中却从未生效过：它读取的字段名和智能体实际输出的字段名不一致，而测试数据恰好用了它读取的那个名字。手写的测试数据很容易和代码犯同样的错误，真实运行的状态则会把这种错位暴露出来。

结语

从 2025 年的争论到 2026 年的共识，最后落到了同一个地方：系统的可靠性，取决于每个环节在做决定时，能不能看到它需要看到的东西。 拆分本身不是目的，它带来的并行和专业分工是有代价的，代价就是交接。

对于内容增长这样的任务，研究阶段适合并行，创作阶段适合接力，人的判断则要和它所针对的内容牢牢绑在一起。这是我们在 Feimore AI 上的做法，也是我们认为多智能体系统真正值得投入工程精力的地方。

参考资料