这篇解决的问题是：多智能体从概念争议走向工程落地后，哪些形态真的可用、哪些仍是歧途。
最值得拿走的是三个已验证模式：一是「干净上下文」的评审循环——评审 Agent 不共享编码 Agent 的上下文，反而因上下文更短、智能更高而抓到更多 bug，这可以直接复制到任何有 Agent 的团队；二是跨前沿模型的能力路由，把委派逻辑从「难度升级器」改成「能力路由器」；三是「映射-归约-管理」的委托结构。最容易出现误用的是把非结构化蜂群当成多智能体的正解——作者明确称之为歧途。
中文读者要读这篇，因为国内多智能体讨论多停留在框架演示层面，这篇提供了难得的生产级反面教训与正面模式对照。国内语境要叠加的是成本视角：跨模型调用要按 token 价格做预算约束，且开源模型在评审角色上的适配需自行验证。
读完建议做一件事：为自己的 Agent 加一个零共享上下文的评审循环，用真实缺陷数验证其信号价值。
—— FDEChina编辑部 · 犀利评审
10 个月前，我写了《Don’t Build Multi-Agents》（别建多智能体），主张大多数人不该尝试构建多智能体（multi-agent）系统[1]。并行的 Agent 会对风格、边缘情况和代码模式做出隐式选择。在那时，这些决定经常互相冲突，导致脆弱的产品。而从那以后，很多事情变了。
在 Cognition，我们已经开始部署在实践中真正有效的多智能体系统。我们对「并行写者蜂群（parallel-writer swarms）」的原始观察至今依然成立：那个方向上大多数性感的点子仍然没有获得实质性的采用。但我们找到了一个更窄的、确实有效的模式类别：多个 Agent 为一个任务贡献智能，而写入（writes）保持单线程。本文将总结我们构建它们以来的所学。
上下文工程回顾
在上一篇文章里，我们建议读者把构建 Agent 的思路从「提示工程（prompt engineering）」重构为「上下文工程（context engineering）」。提示工程鼓励各种花招式技巧，比如「你是一名资深软件工程师」或者「再想久一点」。上下文工程更持久：它聚焦于给模型正确的上下文，同时假设模型会随时间变得更强。出于许多原因，上下文工程在多智能体设置下会变得极具挑战。当时我们推荐了以下原则：
- 在 Agent 之间尽可能多地共享上下文。确保它们看到同样的信息源、保持同一进度（待办清单、计划文件），并对要完成的整体任务持有同样的先验认知。如有需要，帮助它们互相沟通。
- 行动携带隐式决定。当一个 Agent 做出某些修改或编辑时，它可能做出隐式选择（风格、代码模式、某些边缘情况该如何处理），而这些选择可能与其他并行 Agent 的隐式选择冲突。结果是，在多个 Agent 同时执行写操作的多智能体世界里，决策会变得相当碎片化。
尽管过去几个月很多东西都变了，但对深思熟虑的上下文工程的需求没有变。作为原则 2 的推论，世界上大多数多智能体设置都被限制在「只读」子代理（subagent）上，比如网络搜索子代理和代码搜索子代理。例如 Devin 可以调用一个 Deepwiki 子代理来获取代码库上下文。但这类子代理更像工具调用，而非真正的多智能体协作。我们想探索的是：当 Agent 以更具交互性的方式协作时，能解锁哪些能力。
过去 10 个月发生了什么变化
首先，模型在「Agentic」上自然得多了。它们直觉性地理解工具使用、自身的上下文限制，以及如何为协作者（人类或其他）蒸馏自己的上下文。结果是 Agent 的使用量……出现了爆炸式增长。即使看我们最大企业客群（历来对采用新技术最谨慎的群体）的 Devin 使用量，过去 6 个月也出现了约 8 倍的爆发。
这波使用量爆发，对多智能体同时形成了推力与拉力。
推力一侧：能力提升让用户自然地试验更多多智能体设置。当你同时跑这么多 Agent，你自然开始在 Agent 周围的一切上遇到瓶颈：管理、规划、评审。比如，有人写了让一些 Devin 管理另一些 Devin 的脚本；也有很多人让编码 Agent 与评审 Agent 来回迭代。
拉力一侧：使用量爆炸带来了成本爆炸。随着新一代 Mythos 级别、更大更强的模型在地平线上出现，一个自然的问题浮出水面：如何以更低的成本获得前沿能力？多智能体系统可能是一个自然的答案。
此外还有一波轰动性的演示：往大型工程项目里堆海量的 Agent。著名的例子包括构建一个 Web 浏览器（20 万行代码）、构建一个 C 编译器（10 万行代码）、优化一个 LLM 训练脚本（1 万次以上迭代）。这些很激动人心，但它们都共享一个大多数真实软件并不具备的属性：一个简单、可验证的成功标准。真实软件需要一个能规模化人类品味与决策的系统——这正是我们出发探索多智能体的语境。
一些实用的多智能体实验
1）简单到「不该奏效」的代码评审循环
你会以为让模型评审自己写的代码不会带来任何有用的发现。但即便评审的是 Devin 写的 PR，Devin Review 平均每个 PR 能抓到 2 个 bug，其中约 58% 属于严重问题（逻辑错误、缺失的边缘情况、安全漏洞）。系统经常要跑上好几轮代码评审循环，每一轮都发现新 bug（这并不总是好事，因为可能耗时颇久）。今天，我们让 Devin 与 Devin Review 原生地互相迭代，因此当人类打开 PR 时，大多数 bug 已经被修掉了。
反直觉之处。有趣的是，我们发现这个技巧在编码 Agent 与评审 Agent 事先不共享任何上下文时效果最好。为什么？
对此既有哲学层面的也有技术层面的解释。首先要记住：把同一个模型放进两个 Agent，即使 Agent 的执行框架（harness）完全相同，也不会像「同一个人做两件事」那样产生你想象中的自我偏好或自我相关。这些 Agent 归根结底是基于其上下文来表现的系统。它们没有自我（ego），任何可能存在的共享偏见最终来自它们的训练过程——如今我们可以认为这个过程质量相当高。
评审 Agent 拥有完全干净的上下文，还能帮助它深入到原编码 Agent 可能覆盖不到的地方。一方面，这是因为它被迫在没有规格说明（spec）的情况下从实现反推，可以坦率地质疑原 Agent 因用户指令错误而忽略的东西（比如用户让 Agent 实现一个不安全的模式）。也许更重要的是，干净的上下文让 Agent 变得更聪明，原因是注意力（attention）的数学原理。「上下文腐坏（Context Rot）」是有充分记录的现象：随着上下文长度越来越长，模型做出的决策质量会下降。模型的注意力头数量有限，当它需要在不断增长的指令、提示、代码等上下文中工作时，重要细节可能无法被完整纳入决策。当编码 Agent 为一个任务工作了数小时——翻遍代码库、运行命令、思考不同方案、修复错误——它的上下文迅速膨胀。而专职评审 Agent 可以跳过这些无关上下文，只看 diff，并在从零阅读代码的过程中重新发现自己需要的上下文。上下文更短，智能水平更高，自然带来对细微问题更强的检出能力。
让这套系统真正运转良好的最后一个关键，是编码 Agent 与评审 Agent 之间的沟通桥梁。本质上说：Devin 是否恰当地运用它更宏观的上下文（用户指令、各种决定等）来过滤 Devin Review 返回的 bug？这是防止循环空转、违抗用户、做超范围工作的关键。我们发现，通过一些专门的提示，今天的模型能在这里做出合理的判断，你还能看到两个 Agent 与人类之间发生一些非常有意思的交互。
要点：在生成者-验证者（generator-verifier）循环中，干净上下文带来显著的能力提升；但与整体上下文进行清晰的沟通与综合，对连贯的体验同样重要。
2）大型昂贵模型的回归——「聪明朋友」（Smart Friend）
观察最近几个月最受欢迎的模型，你会看到一个明显的迁移：为了性能，从 Anthropic Sonnet 级别的中型模型，转向 Opus 级别的大型模型。随着 Mythos 即将到来，我们基本可以说「扩展定律回来了」。
一个安静的推论是：前沿智能很快会对大多数日常任务而言过于昂贵（也许还太慢）。与此同时，小模型又面临一个困境：某个任务可能比预想的更难。
如何两全其美？在 Windsurf，我们朝这个目标做过一次实验：10 月上线的 SWE-1.5，一个每秒 950 token 的次前沿（sub-frontier）模型。我们发现，当它与 Sonnet 4.5 搭档负责「规划」时，能弥补一小段性能差距，同时保住低成本与高速度。
我们实现这一点的实际架构，是把更聪明/更昂贵的模型作为一个「聪明朋友」工具，供主力/更小的模型调用。基本思路是：让主力/小模型自己判断当前情形是否棘手到值得请教更聪明/更贵的模型。但我们很快发现，设计上下文传递与沟通机制非常棘手：
其一：主力模型需要知道怎么和聪明朋友说话
这套设置的核心难题来自一个问题：「一个更笨的模型怎么知道自己到了能力极限？」与更流行的反向设置（聪明的主力模型把任务委派给更小的子代理）不同，这里做委派决定的不是更聪明的那个。有几个潜在的解法。其一，你可以鼓励主力 Agent 永远至少调用一次聪明 Agent，评估是否存在被漏掉的棘手点。你也可以通过提示词调优或训练，让主力模型在这个决定上更有分寸。依据主力模型的智能水平，可能还需要某种领域特定的指令性规则，比如遇到合并冲突就一定调用聪明朋友。
这种沟通方式的另一个棘手问题是：主力模型应该把什么上下文分享给聪明朋友？进而，主力模型应该问聪明朋友什么？如果主力模型只分享其全部上下文的一个子集，聪明模型可能无法做出信息完备的决策。我们发现，对今天的模型来说，一个合理的「八二开」方案是：直接把主力模型完整上下文的一个分叉（fork）分享给聪明模型。同样，我们发现鼓励主力模型提出宽泛的问题（「我该怎么做？」）、让聪明模型自己决定什么值得讨论，效果更好。
其二：聪明朋友需要知道怎么回话
无论你把（1）调得多好，你多半仍会发现因上下文丢失造成的质量缺口。调优另一个方向的沟通可以弥补这些缺口。举个例子：假设主力模型从没看过 important_file.py，却向聪明模型问了一个需要知道该文件内容的问题。此时聪明模型的正确答案不是编造几套理论（这往往是默认行为），而是明确指示主力模型去调查这个文件、稍后再问。类似地，让聪明朋友超越主力模型正在问的问题，基于 Agent 的行动轨迹主动提出任何重要建议——即使主力模型没有问——往往也很有成效。我们发现这种「超范围」的聪明朋友通常带来更有意思的交互。
聪明朋友实际发生了什么
我们应该坦白：SWE-1.5 作为主力模型还不够强，这套设置因此没能真正跑通。它与 Sonnet 4.5 的差距，恰恰落在这套设置最要命的地方：知道何时升级、知道该问什么。成本与速度的收益是真实的，但质量天花板由主力决定，而主力不够强。SWE-1.6（最近的后续版本，在 SWE-bench 上达到 Opus-4.5 水平）明显更好，补上了足够多的差距，让这个模式开始产生回报，但离我们的目标还有距离。我们比较有把握这是一个训练问题，未来的 SWE 模型会带着这种双向交互来训练[2]。
这个模式真正奏效、而且效果很好的场景，是在前沿模型之间。我们已在生产中把 Claude 与 GPT 放进这套设置跑了相当长一段时间，在最棘手的场景里产生了真实的收益。有趣的发现是：提示调优的问题与「小模型配大模型」的情形不同。跨前沿模型的通信，重点不在于较弱的模型知道何时求教更强的模型，而在于路由到哪个模型最擅长当前这个子任务。有的模型更擅长调试，有的更擅长视觉推理，有的更擅长写测试。委派逻辑由此变成一个「能力路由器」，而不是「难度升级器」。
要点：聪明朋友在两个模型都够强时今天就可用；让「主力明显更弱」的版本跑起来——那才是带来最大解锁的版本——仍是开放问题，而我们认为是训练问题。想交流心得的话欢迎联系我们。
展望：更高层级的委托
上面两个模式共享同一个结构：一个写者，由其他在其周围贡献智能的 Agent 增强。顺理成章的下一个问题是：这是否能扩展到 Agent 拥有更大范围的任务？比如横跨十个 PR 的产品功能、触碰十几个服务的迁移、一周的工作量而非一个下午的。
这在 Devin 上已经上线。一个「经理 Devin」可以把大任务拆成小块，派出子 Devin 分头处理，并通过一个内部 MCP 协调进度。让它运转得连贯一致，所花的上下文工程超出了我们的预期：在小范围委派上训练出来的经理，默认过度指令化，而当经理自己缺乏深层代码库上下文时，这样做会适得其反。Agent 会假设自己与子代理共享状态，而实际没有。跨 Agent 通信——子代理把消息写回经理、再由经理转给团队中其他 Agent——默认不会发生，因为模型没有在需要它的环境中被训练过。其中每一项都花了专门的工作去修复，而且我们仍在持续改进。
那么非结构化蜂群呢？我们认为非结构化蜂群——任意拓扑的 Agent 彼此谈判协商——大体上是个歧途。务实的形态是「映射-归约-管理」（map-reduce-and-manage）：经理拆分工作，子代理执行，经理综合并汇报。让这类系统运转得像单个 Agent 处理单个任务一样连贯，是我们 2026 年部分即将开展工作的核心。
我们今天所知道的
所有这些实验有一条共同的贯穿线：多智能体系统在当下最有效的形态，是写入保持单线程、而额外的 Agent 贡献智能而非行动。干净上下文的评审者能抓到编码者看不见的 bug。前沿级的聪明朋友能捕捉较弱主力错过的细节。经理 Agent 能在子代理之间协调范围，而让决策保持完整不碎裂。
悬而未决的问题全部是沟通问题。较弱的模型如何学会何时升级？子代理如何把一个足以改变同伴工作的发现浮上报？如何在 Agent 之间传递上下文而不把接收方淹死？靠提示词你能走很远，但我们同样期待下一代模型——包括我们自己训练的模型——开始填补这些缺口。
我们正在朝这样一个世界构建：智能被注入软件开发生命周期的每个阶段——规划、编码、评审、测试与监控——不是作为一群自主行动者的蜂群，而是作为一个能规模化人类品味的协调系统。
欢迎到 devin.ai 或 windsurf.com 体验我们的工作。如果你也想和我们一起探索这些构建 Agent 的原则，欢迎通过 Cognition 官方渠道与我们联系。
[1] 巧合的是，Anthropic 在次日也发布了关于构建多智能体研究系统的相关博文。两篇文章都触及了类似的上下文工程挑战，并得出了类似的结论：第一个适用领域是只读 Agent。
[2] 最近，Anthropic 上线了一个类似的 beta 实验，让其较小的模型以同样的方式调用其更大的模型。这至少说明，「聪明朋友」一端的模型也会在与主力模型的回传沟通上变得更好。
小结与下一步
这篇立场更新最有价值的地方，是把多智能体的讨论从「要不要做」推进到「哪种形态可做」：并行写者的蜂群依然不可靠，而「单写者 + 多贡献智能」的生成者-验证者循环、能力路由与经理式委托已经过生产验证。其中「干净上下文让评审更聪明」这一发现，与注意力预算的原理互为印证，任何团队都可以零成本复制试验。
下一步，建议你先在自己的项目里搭一个最小评审循环：让一个不共享上下文的评审 Agent 只看 diff，统计它抓到的真实缺陷；再逐步引入跨模型的「聪明朋友」路由。
延伸阅读：关于 Agent 构建与上下文管理的更多方法，可阅读站内 Agent 专题与 AI Coding 专题；上下文工程系统方法参见 FDE 实践指南；这些模式在交付场景中的落地可参考 FDE 项目生命周期。
本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。