多智能体（Multi-Agents）：究竟什么模式才真正有效？
快速阅读
本文总结了Cognition团队在过去10个月中开发和部署多智能体（Multi-Agent）系统的经验教训。10个月前，作者曾建议“不要构建多智能体”，因为并行智能体会产生隐性决策冲突，导致系统脆弱。但随着模型能力的大幅提升和使用成本的考量，多智能体的需求再次爆发。
如今在实践中真正奏效的，是**“单线程写入+多智能体提供智力支持”的模式，而非随意让多个智能体同时修改代码。文章分享了两个关键实验：一是“代码审查循环（Code-Review-Loop）”，发现审查智能体在不共享**原有上下文时表现最佳，能有效避免“上下文腐烂（Context Rot）”；二是“聪明朋友（Smart Friend）”模式，通过让模型在遇到难题时向更强大的前沿模型求助来降低成本，揭示了模型间通信与上下文传递的挑战。最终结论是：无结构的网络群体（Swarms）只是一种干扰，未来的方向应是“Map-Reduce-and-Manage”（分配、执行再汇总），通过协调系统来扩展人类的决策品味。
10个月前，我写了一篇题为《不要构建多智能体》（Don’t Build Multi-Agents）的文章，认为大多数人不应该尝试构建多智能体系统。原因是并行智能体在处理代码风格、边界情况和代码模式时，往往会做出许多隐性的选择；而这些决策经常相互冲突，导致脆弱的产品体验。
但从那以后，情况发生了很大变化。
在Cognition，我们已经开始部署真正在实践中行之有效的多智能体系统。我们关于“并行写入的群体（parallel-writer swarms）”的最初观察依然成立——这个领域中大多数性感的想法仍然没有看到有意义的采用。但我们发现了一类更狭窄、却非常有效的模式：多智能体共同为一项任务提供智力支持，但写入操作始终保持单线程。在这篇文章中，我将总结我们在构建它们时学到的东西。
重温“上下文工程（Context Engineering）”
在上一篇文章中，我们鼓励读者将构建智能体的思维从“提示词工程（Prompt Engineering）”转变为“上下文工程（Context Engineering）”。提示词工程往往鼓励一些花哨的技巧，比如“你是一个高级软件工程师”或者“思考得更久一些”。而上下文工程则更持久，它侧重于为模型提供正确的上下文环境，并假设模型本身的能力会随着时间变得越来越强。
由于种种原因，在多智能体设置中，上下文工程可能会变得非常具有挑战性。过去我们推荐了以下原则：
- 尽可能在智能体之间共享上下文。 确保它们看到相同的信息源，保持同步（如待办事项列表、计划文件），并在要完成的整体任务上拥有相同的先验知识。
- 行动带有隐性决策。 当一个智能体进行特定更改时，它可能会做出可能与其他并行智能体冲突的隐性选择。因此，在多个智能体都在执行写入操作的多智能体世界中，决策往往会变得非常碎片化。
在过去的几个月里，虽然许多事情发生了变化，但对深思熟虑的上下文工程的需求并没有改变。由于原则2的存在，世界上大多数多智能体设置都局限于“只读”的子智能体（例如网络搜索和代码搜索子智能体）。例如，Devin可以调用Deepwiki子智能体来获取代码库上下文。但这更像是工具调用，而非真正的多智能体协作。我们想探索，当智能体以更具交互性的方式协作时，我们能解锁哪些能力。
过去10个月发生了什么变化
首先，模型自然而然地变得更加“具有智能体特质（Agentic）”。它们能直观地理解工具的使用、自身的上下文限制，以及如何为合作者（人类或其他模型）提取上下文。结果就是，智能体的使用量出现了爆炸式的增长。即使在我们最传统、对采用新技术持谨慎态度的大型企业客户群体中，Devin的使用量在过去6个月里也增长了约8倍。
这种爆炸式的使用既带来了“推力”，也带来了“拉力”，促使人们转向多智能体：
- 推力： 能力的提升促使人们自然而然地去实验更多类型的多智能体。当大量使用智能体时，管理、规划和代码审查就成了瓶颈。比如，有人写脚本让Devin去管理其他的Devin，很多人也倾向于让编写代码的智能体与审查代码的智能体反复交互。
- 拉力： 智能体使用量的暴涨导致了成本的激增。随着像Mythos级别这样更大、更强模型的出现，“如何在降低成本的同时达到前沿能力”成了一个自然的问题，多智能体系统似乎是顺理成章的答案。
此外，市场上还出现了一波引人注目的演示，比如让大批智能体去构建包含20万行代码的网络浏览器，或10万行代码的C语言编译器。这很令人兴奋，但它们都有一个真实软件并不具备的特性：拥有一个简单、可验证的成功标准。真实的软件需要一个能够扩展人类品味和决策的系统，这就是我们探索多智能体系统的背景。
一些实用的多智能体实验
1) 笨到“不该起作用”的 Code-Review 循环
你可能会认为，让同一个模型去审查自己写的代码不会有什么有用的发现。但实际上，即使是Devin编写的Pull Requests (PRs)，Devin Review平均每个PR也能揪出2个Bug，其中大约58%是严重的（如逻辑错误、缺失的边缘用例或安全漏洞）。通常系统会经历多次代码审查循环，每次都能发现新的问题。今天，我们已经让Devin和Devin Review原生支持相互迭代，使得大多数Bug在人类审阅PR之前就已经被解决。
反直觉的部分在于： 我们发现，当编写代码的智能体和审查代码的智能体事先没有任何共享上下文时，这项技术效果最好。 为什么呢？
从技术上讲，即使两个智能体的底层模型相同，它们也不会像人类那样产生“自我偏见”。它们完全是根据提供的上下文来表现的。更重要的是，“干净的上下文”能迫使审查智能体更加聪明。这就是**“上下文腐烂（Context Rot）”**现象：随着上下文长度增加，模型做出的决策通常会变得不够明智。当编写代码的智能体连续工作了几个小时，阅读代码库、运行命令、修复错误后，它积累了极其庞大的上下文，可能会漏掉重要的细节。而专门的审查智能体跳过了这些无关信息，只看Diff（代码差异），并在从头阅读代码时重新发现需要的上下文。这种“干净的上下文”自然带来了更强的洞察力。
最后，系统运作良好的关键在于编写和审查智能体之间的沟通桥梁——编写智能体需要运用其原有的上下文来过滤审查智能体返回的Bug，从而防止死循环或偏离用户意图。
2) 大型昂贵模型的回归——引入“聪明朋友（Smart Friend）”
最近几个月，为了追求性能，最受欢迎的模型出现了向Anthropic的Opus级别等大型模型转移的趋势。而随着更强模型的到来，可以说“Scaling is back”。
这意味着前沿的智能体很快对日常任务而言将变得过于昂贵。我们如何两全其美呢？
我们尝试了一种架构：将更聪明/昂贵的模型作为“Smart Friend”工具提供给主要/较小的模型调用。让小模型决定什么时候遇到了足够棘手的情况，需要咨询更聪明的朋友。但我们很快发现，工程化这种上下文传递和通信非常棘手：
- 较小的模型必须知道如何以及何时求助。 小模型怎么知道自己“到了极限”？这可能需要特殊的提示词调整或训练。
- 小模型应该分享什么上下文？ 如果分享不全，大模型无法做出充分知情的决策。目前比较合理的做法是，把小模型的完整上下文“分叉（fork）”一份给大模型，并让小模型问些宽泛的问题（比如“我该怎么办？”）。
- 大模型需要知道如何“回话”。 如果小模型没有提供某份关键文件的信息，聪明的大模型不应该凭空捏造理论，而是应该具体指示小模型去调查那个文件。这种“超范围”的指导往往会带来更有趣的互动。
在实践中，我们发现较小的模型（如SWE 1.5）作为主模型的效果还不够好，因为它不知道何时该升级问题。然而，当我们在两个前沿模型（比如Claude和GPT）之间运行这种模式时，效果非常好。这时候，沟通就不再是“较弱模型向较强模型求助”，而变成了“能力路由（Capability Router）”，即把子任务分配给最擅长该领域的模型。
展望未来：更高层次的委托
上述两种模式都有一个共同结构：一个单线程写入者，周围辅以其他贡献智力的智能体。
这是否可以扩展到更大范围的任务（比如涉及十几个服务迁移的一周工作量）？Cognition目前已经在Devin中上线了管理功能：一个经理级别的Devin可以将大任务拆解，生成子Devin来执行，并通过内部机制协调进度。
让这种体验变得连贯需要大量的上下文工程。那些习惯于小范围委托的经理往往会过度发号施令，如果缺乏深度的代码库上下文，这就会适得其反。此外，子智能体之间跨智能体的交流在默认情况下也不会发生。这些都需要进行专门的修复。
至于**“无结构的网络群体（Unstructured Swarms）”——也就是任意数量的智能体在网络中相互协商——我们认为这主要是一种干扰**。在多智能体协作中，最实用的形态依然是 Map-Reduce-and-Manage：由经理分配工作，子节点执行，最后经理进行综合和报告。
今天的结论
通过这些实验，有一条主线贯穿始终：在今天的环境下，当写入操作保持单线程，而其他智能体仅提供智力支持时，多智能体系统的工作效果最好。
无论是拥有干净上下文的审查智能体发现Bug，还是前沿级别的“聪明朋友”捕捉微妙问题，抑或是管理智能体在不造成决策碎片化的情况下协调工作范围，核心都在于此。
剩下的未解难题全是沟通问题：较弱的模型如何学会何时上报？子智能体如何传递应该改变兄弟节点工作轨迹的发现？如何在不淹没接收者的情况下传递上下文？这些都可以通过提示词得到一定程度的缓解，我们也期待下一代模型能在底层训练中开始弥补这些差距。
我们正在构建的世界，是将智能注入软件开发生命周期的每一个阶段（规划、编码、审查、测试和监控），它不是一个毫无头绪的自治者蜂群，而是一个能够有效扩展人类品味的协调系统。