摘要：Cognition 联合创始人 Walden Yan 总结 10 个月摸出的 multi-agent 可行模式：写入保持单线程，额外 agent 只贡献智力而非动作。
10 个月前，我写过 Don’t Build Multi-Agents ，主张大多数人不该去建 multi-agent 系统 [1]。并行的 agent 会对风格、边缘情况、代码模式做出隐含的选择。当时，这些决定经常互相冲突，产品因此很脆弱。从那以后，很多事情变了。
在 Cognition，我们开始部署一些在实践中真正能跑通的 multi-agent 系统。我们最初的观察在今天对并行写入型 swarm 仍然成立：那个方向上大多数性感的想法至今仍没看到有意义的采用。但我们找到了一类更窄的可行模式：多个 agent 为一项任务贡献智力，而写入保持单线程。在这篇文章里，我会总结我们构建它们时学到的东西。
Context Engineering 回顾
上一篇文章里，我们鼓励读者把 agent 构建从「prompt engineering」重新框为「context engineering」。Prompt engineering 会鼓励一些花招，比如「you’re a senior software engineer」或「think for longer」。Context engineering 更耐用，关注的是——在假定模型会随时间变得更强的前提下——为模型提供合适的 context。出于很多原因，context engineering 在 multi-agent 设定下会变得非常有挑战。过去，我们推荐以下原则：
- 在 agent 之间尽可能多地共享 context。确保它们看到同样的信息来源、保持在同一页（todo list、计划文件），并对要完成的整体任务共享相同的先验。必要时帮它们沟通。
- 行动承载着隐含的决定。当一个 agent 做某些改动或编辑时，它可能做出一些隐含选择（风格、代码模式、某些边缘情况该怎么处理），这些可能与其他并行 agent 的隐含选择相冲突。结果是，在多个 agent 都在执行写入动作的 multi-agent 世界里，决策会变得相当碎片化。
过去几个月变了很多事情，但对细致 context engineering 的需求并没有变。作为原则 2 的后果，世界上大多数 multi-agent 设定都被限制在「readonly」的 subagent 上，比如 web search subagent 和 code search subagent。比如，Devin 可以调用一个 Deepwiki subagent 去获取代码库 context。但这类 subagent 更像工具调用，而不是真正的 multi-agent 协作。我们想探索：当 agent 以更具交互性的方式协作时，能解锁什么能力。
过去 10 个月变了什么
首先，模型变得自然得多地「agentic」。它们直觉上就理解 tool use、自己的 context 上限、以及如何为协作者（人类或其他）蒸馏自己的 context。结果是，agent 的使用量涨了……一大坨。即便看 Devin 在我们最大的那一块企业客户段内的使用量——这一段历史上对采用新技术一直比较谨慎——过去 6 个月里也看到一次爆炸（约 8 倍）。
这种使用量的爆炸从 push 和 pull 两端都推向了 multi-agent。
push 那一端，能力的增强让用户自然地试起了更多 multi-agent 设定。当你在用这么多 agent 时，你自然会开始被围绕这些 agent 的一切卡住：管理、规划、review。比如有人已经写脚本让 Devin 去管其他 Devin。也有很多人开始让 coding agent 与 review agent 来回迭代。
pull 那一端，agent 使用量的爆炸带来了成本的爆炸。随着新一批 Mythos class 更大、更强的模型即将到来，一个自然的问题浮现：怎么以更低的成本达到前沿能力。而 multi-agent 系统可能就是一个自然的答案。
也出现了一波耸动的 demo——把大量 agent 扔到大型工程项目上。著名例子包括 构建一个 web 浏览器 （200k LOC）、构建一个 C compiler （100k LOC）、以及 优化一个 LLM 训练脚本 （10k+ 次迭代）。这些很令人兴奋，但它们都有一个大多数真实软件不具备的属性：一个简单、可验证的成功标准。真实软件需要一个能放大人类品味与决策的系统，这正是我们探索 multi-agent 系统的背景。
一些实用的 multi-agent 实验
1）蠢到不该 work 的 Code-Review-Loop
你会以为让模型 review 它自己写的代码不会得出什么有用的发现。但即便是 Devin 写的 PR，Devin Review 平均每个 PR 也能抓到 2 个 bug，其中大约 58% 是严重的（逻辑错误、漏掉的边缘情况、安全漏洞）。系统常会循环跑多轮 code-review，每轮都找到新的 bug（这并不总是好事，因为会拖时间）。如今我们让 Devin 和 Devin Review 原生地互相迭代，所以等人打开 PR 时，大多数 bug 已经解决了。
反直觉的部分。有意思的是，我们发现这个技术在 coding agent 和 review agent 事先不共享任何 context 的时候效果最好。为什么？
对此有一组哲学和技术混在一起的理由。首先，我们必须记住：把同一个模型放进两个 agent——哪怕 agent harness 完全一样——也并不会像你想象中同一个人做两件事那样让它们自我偏置/相关。这些 agent 归根到底是基于它们的 context 而表现的系统。它们没有 ego，任何可能存在的共享 bias 最终都来自训练过程，而如今我们可以假定这个过程的质量相当高。
review agent 拥有一个完全干净的 context 也帮它深入到原 coding agent 可能没到达的区域。一方面，这是因为它被迫在没有 spec 的情况下从实现反推，并能公开质疑那些原 agent 可能因为用户指令的错误而忽略的东西（例如用户让 agent 去实现一个不安全的模式）。不过也许更重要的是，出于 attention 的数学，干净的 context 能让 agent 更聪明。Context Rot 是一个有文献记录的现象——模型在越来越长的 context 长度下做出越来越不聪明的决定。模型通常只有有限数量的 attention head，当它们需要处理一个不断增长的指令、prompt、代码等的 context 时，重要细节可能无法被完整纳入决策。当 coding agent 已经为一项任务工作了好几个小时、读 repo、跑命令、思考不同方法、修错误时，它会很快积起一个很大的 context。专门的 review agent 可以跳过这些多余的 context，只看 diff，并在从头读代码时重新发现它需要的任何 context。在更短的 context 下，随之提升的智力自然会让它更多地发现那些微妙的问题。
让这套系统真正跑得很好的最后一个关键部分，是 coding agent 和 review agent 之间的沟通桥。基本上就是：Devin 有没有好好用它更宽的用户指令、决定等 context，来过滤 Devin Review 返回的 bug？这对避免循环、避免违抗用户、避免做超出范围的工作等等都很关键。我们发现，通过一些专门的 prompting，如今的模型能在这里做出合理的判断，最终你会在两个 agent 和人之间看到一些非常有意思的互动。
要点：在 generator-verifier loop 中，干净的 context 能带来能力上明显的提升。但清晰的沟通以及与整体 context 的综合，对一个连贯的体验很重要。
2）大而贵的模型回来了——介绍「Smart Friend」
如果你看过去几个月最流行的模型，会看到一个明显的转移：为了性能，从 Anthropic 的 Sonnet 级中型模型转向 Anthropic 的 Opus 级大型模型。而随着 Mythos 将至，我们基本可以说「scaling 回来了」。
这里安静的含义是：前沿智力很快就会对大多数日常任务来说太贵（也许也太慢）。与此同时，你还会在小模型上面对一个两难——一项任务可能比最初预期更难。
怎么两全？在 Windsurf，我们在 10 月 推出 SWE-1.5 时做过一个朝这个目标的实验——一个 950 tok/sec 的次前沿模型。我们发现，当它和 Sonnet 4.5 搭档做「规划」时，我们能在保持低成本和快速度的同时，补回一小块性能差距。
我们为实现这个而采用的实际架构，是把更聪明/更昂贵的模型作为一个「smart friend」工具暴露出来，供主/较小模型调用。基本上就是让主/较小模型自己决定，什么时候情况棘手到值得去咨询更聪明/更贵的模型。但我们很快发现，设计 context 的迁移和沟通很棘手：
- 主模型需要知道怎么和 smart friend 说话。
这套设定的核心棘手处来自这个问题：「一个更蠢的模型怎么知道自己到了极限？」和更流行的倒过来的设定——由聪明的主模型把任务委派给更小的 subagent——不同，这里决定什么时候委派的那个并不是更聪明的那个。这里有几个潜在的解。一方面，你可以鼓励主 agent 总是至少调用一次 smart agent，来评估它认为是否漏掉了什么棘手之处。你也可以 prompt-tune 或训练主模型，让它在这个决定上更校准。根据主模型的智力水平，某些领域特定的规定性指导可能是必要的，比如遇到 merge conflict 时总是调用 smart friend。
这种沟通方式的另一个棘手问题是：主模型该和 smart friend 分享哪些 context？更进一步，主模型该问 smart friend 什么？如果主模型只分享自己总 context 的一个子集，smart model 可能做不出信息充分的决定。我们发现，对于今天的模型而言，一个合理的 80/20 解是直接把主模型完整 context 的一个 fork 分享给 smart model。同样地，我们发现鼓励主模型问宽泛的问题（「我该怎么做？」）、让 smart model 自己决定什么值得聊，效果更好。
- smart friend 需要知道怎么反过来和主模型说话
不管 (1) 调得多好，你大概率还是会因为 context 丢失而看到质量上的 gap。调另一方向的沟通能补上这些 gap。比如，假设主模型从没看过 important_file.py，却问了 smart model 一件需要这个文件内容才能回答的事。这种情况下，smart model 的正确答案不是编出一些理论（这经常是默认行为），而是明确指示主模型去调查这个文件，稍后再问。类似地，让 smart friend 看得比主模型问的问题更远、并基于 agent 的轨迹提出任何重要的指引——哪怕主模型没问——通常也是有成果的。我们发现这种「超范围」的 smart friend 通常会带来更有意思的互动。
Smart Friend 实际发生了什么
我们应该把话说在前面：SWE 1.5 还没好到能作为这套设定里的主模型让它真正 work。它和 Sonnet 4.5 之间的 gap，在对这套设定最关键的那些地方——知道什么时候 escalate、知道该问什么——都太宽了。成本和速度上的胜利是真实的，但质量上限由主模型设定，而主模型还不够强。SWE 1.6（一个 最近的后续 ，在 SWE-bench 上达到 Opus-4.5 级别的表现）有了实质性的提升，并合上了足够多的 gap，使这个模式开始有回报，但仍然没到我们想要的地方。我们相当有信心这是一个训练问题，未来的 SWE 模型会在训练时把这种来回考虑进去 [2]。
这个模式真正 work、而且 work 得很好的地方，是在前沿模型之间。我们在生产里把 Claude 和 GPT 在这套设定里一起跑了相当一段时间，它在最棘手的场景下带来了真实的收益。有意思的发现是，prompt-tuning 的问题和 small-model-to-large-model 的情形不同。跨前沿的沟通更少是关于一个更弱的模型知道何时去问更强的那个，更多是关于路由到在具体子任务上最合适的那个模型。有些模型调试更好，有些处理视觉推理更好，有些写测试更好。委派逻辑变成了一个 capability router，而不是一个 difficulty escalator。
要点：smart-friend 今天在两个模型都强的时候能 work。让它在主模型不对称地更弱的版本下也能 work——那才是能带来最大解锁的版本——仍然是一个开放问题，我们认为这是个训练问题。想比对笔记的话，欢迎联系。
展望：更高层次的委派
上面两个模式共享一个结构：一个 writer，由其他 agent 围绕它贡献智力来增强。明显的下一个问题是，这是否能扩展到 agent 去拥有更大的作用域——比如一个横跨十个 PR 的产品 feature、一场触及十几个服务的迁移、一个星期而非一个下午的工作量。
这在 Devin 里今天就已经上线。一个 manager Devin 可以把一项更大的任务拆成碎片、生成子 Devin 去做它们，并通过一个内部的 MCP 协调它们的进度。让它感觉连贯，花了比我们预期更多的 context engineering。为小作用域委派训练出来的 manager 默认会过度规定细节，当 manager 缺乏深度的代码库 context 时，这会反噬。Agent 会假设自己和子 agent 共享状态，实际上并没有。跨 agent 的沟通——一个 sub-agent 往回给它的 manager 写消息、让后者转交给 agent 团队里的其他 agent——默认并不会发生，因为模型没有在需要这样做的环境里被训练过。这其中每一条都需要专门的工作去修，而我们在所有这些上都仍在改进。
那 unstructured swarm 呢？我们认为 unstructured-swarm 的方法——agent 任意地组网、互相谈判——大体上是一种干扰。实际的形态是 map-reduce-and-manage：一个 manager 拆分工作、子 agent 执行、manager 综合并回报。让这类系统感觉起来像一个单一 agent 在做单一任务那样连贯，是我们 2026 年即将推出的一部分工作的核心。
今天我们知道的
所有这些实验都有一条共同的主线：multi-agent 系统在今天 work 得最好的时候，是写入保持单线程、额外的 agent 贡献智力而非行动。一个 context 干净的 reviewer 能抓到 coder 看不见的 bug。一个前沿级的 smart friend 能抓到较弱主模型漏掉的微妙之处。一个 manager 跨子 agent 协调作用域，而不让决策碎片化。
开放的问题全都是沟通问题。一个更弱的模型怎么学会什么时候 escalate？一个 sub-agent 怎么把一个应该改变其同级工作内容的发现浮出来？怎么在 agent 之间迁移 context 而不淹没接收方？你靠 prompting 能走得相当远，但我们也预期下一代模型——包括我们自己训练的那些——会开始合上这些 gap。
我们在朝着一个这样的世界构建：智力在软件开发生命周期的每一个阶段——规划、编码、review、测试、监控——被注入，不是作为一群自治的 actor，而是作为一个放大人类品味的协调系统。
欢迎你在 devin.ai 或 windsurf.com 试试我们的工作。如果你愿意和我们一起发现这些 agent 构建原则，请联系 walden@cognition.ai
[1] 巧合的是，Anthropic 第二天 就出了一篇相关博文，关于构建一个 multi-agent research 系统。两篇博文都触及了 context engineering 上类似的挑战，并在「第一块适用领域是 readonly agent」上得出了类似的结论。
[2] 最近，Anthropic 发布了一个类似的 beta 实验 ，让他们的小模型以相同方式调用他们的大模型。至少，这说明「smart friend」那一端的模型也会在反过来和主模型沟通这件事上变得更好。
