别再乱建多智能体！我们试了10个月，只有这两个模式靠谱
作者背景
Cognition公司AI系统团队，负责Devin智能体核心架构与多智能体部署实践。
我们过去认为大多数多智能体系统不靠谱，因为并行写入会导致风格冲突和产品脆弱。经过十个月的实战，我们发现一个反直觉的事实：真正好用的多智能体模式，都遵循“单线程写入，多线程提供智能”的原则。
代码审查环和“聪明朋友”架构是两个成功案例。前者利用纯净上下文让审查智能体发现原始编码智能体看不到的漏洞，后者通过大小模型协作平衡成本与性能。
核心难点在于通信设计：弱模型如何知道该何时求助？子智能体如何影响同伴？未来需要从训练层面解决这些问题。
我们从并行写入的失败中学到了什么
十个月前，我们发表了一篇文章，核心观点是大多数人不要尝试构建多智能体系统。那时候，并行智能体在处理同一个任务时，会在代码风格、边界情况和设计模式上做出隐含的选择。这些选择互相冲突，导致最终产品极其脆弱，就像多个厨师同时往一道菜里加盐，每个人都不知道别人加了多少。
从那时到现在，情况发生了巨大变化。模型变得更自然具备“智能体性”，它们本能地理解如何使用工具，清楚自己的上下文窗口限制，也知道如何为协作者提炼关键信息。我们观察到，即使是在最谨慎的大型企业客户群体中，Devin的使用量在过去六个月增长了大约八倍。这个爆炸式增长既推动了多智能体系统的需求，也拉动了我们重新思考架构。
推动因素来自用户的天性。当大家大量使用智能体后，瓶颈不再是单个智能体的能力，而是围绕它们的管理、规划和审查工作。有人写脚本让Devin管理其他Devin，也有人让编码智能体和审查智能体反复迭代。拉动因素则是成本。随着更强大模型的到来，如何用更低成本获得前沿能力成了自然的问题，而多智能体系统可能就是答案。
但是，那些炫酷的演示——比如一次性用几百个智能体重写二十万行代码——有一个共同特点：成功标准简单且可验证。真实世界的软件不是这样的，我们需要一个能扩展人类品味和决策的系统。这就是我们探索多智能体系统的真正语境。
第一个有效模式：代码审查环
这个模式蠢到按理说不应该奏效。让一个模型审查自己写的代码，你觉得它会发现什么新问题吗？实际上，在Devin生成的拉取请求上，Devin Review平均能抓到两个漏洞，其中大约百分之五十八是严重的逻辑错误、遗漏的边界情况或安全漏洞。系统经常循环多次审查，每次都能找到新问题，虽然这会让过程变慢，但质量提升很明显。
反直觉的地方来了。我们发现，编码智能体和审查智能体事先完全不共享任何上下文时，效果反而最好。这听起来很怪，因为人类如果这样做肯定乱套。但智能体不是人，它们没有自我，也没有面子问题。审查智能体拿到一个完全干净的上下文，意味着它不会被编码过程中积累的长篇指令、运行记录和各种尝试干扰。
为什么纯净上下文会让审查更聪明？这是注意力机制的数学问题。当上下文越来越长时，模型的注意力头数量有限，重要细节可能会被淹没。编码智能体工作几个小时，读了仓库、跑过命令、尝试过不同方案、修复过错误，它的上下文又长又乱。而审查智能体只看到差异对比，从头读代码，重新发现需要的信息。上下文越短，智能越高，因此能发现更细微的问题。
让这个系统真正好用的最后一块拼图，是编码智能体与审查智能体之间的通信桥梁。编码智能体必须利用自己的完整上下文——包括用户指令和之前做过的决策——来过滤审查智能体返回的漏洞列表。这能防止无意义的循环、避免违背用户意图，以及杜绝做超出范围的工作。通过精心设计的提示词，当今的模型已经能做出合理的判断，你会看到两个智能体之间以及它们与人类之间产生非常有趣的互动。
总结一下这个模式：在生成-验证循环中，纯净上下文带来显著的能力提升。但同时，清晰的通信和对整体上下文的综合运用，对于获得一致的体验至关重要。
第二个有效模式：聪明朋友
如果你关注过去几个月最流行的模型，会发现一个明显的转变：从中型模型如Claude Sonnet类，转向大型模型如Claude Opus类，只为了追求性能。随着Mythos这类更大模型的出现，可以说“规模回归”了。但这意味着前沿智能很快就会对日常任务来说太贵，可能也太慢。同时，小模型又面临一个困境：任务可能比预期更难。
怎么才能两全其美？我们在Windsurf中做了一个实验，用一个每秒九百五十个令牌的次前沿模型作为主力，搭配Sonnet 4.5做规划，就能弥补一部分性能差距，同时保持低成本和高速。实际架构是：把更聪明、更昂贵的模型作为“聪明朋友”工具，让主模型在需要时调用它。
但上下文传输和通信的工程问题很棘手。第一个问题是：主模型怎么知道自己的极限？不像常见的反过来的架构——聪明主模型把任务委派给子智能体——这里做委派决策的模型不是更聪明的那一个。解决方案有几个：鼓励主模型至少调用一次聪明朋友来评估是否有遗漏的难点；或者对主模型进行提示调优甚至训练，让它更准确判断何时需要求助。根据主模型的智能水平，可能还需要领域特定的指导规则，比如遇到合并冲突时总是调用聪明朋友。
第二个问题是：主模型应该分享什么上下文给聪明朋友？该问聪明朋友什么问题？如果只分享部分上下文，聪明模型可能无法做出充分知情的决策。我们发现，对于当今的模型，一个合理的八二开方案是直接把主模型的完整上下文分叉一份给聪明模型。同时，鼓励主模型问开放性问题，比如“我该怎么做？”，让聪明模型自己决定什么值得讨论，效果更好。
第三个问题是：聪明朋友需要知道如何回复主模型。即使你优化了前两个问题，仍然会有上下文丢失导致的质量差距。从另一个方向调优通信可以弥补这些差距。比如，主模型从未看过某个重要文件，却问聪明朋友一个需要该文件内容的问题。这时聪明朋友正确的回答不是自己瞎猜，而是明确指示主模型去研究那个文件，然后再来问。同样，让聪明朋友超越问题本身，基于智能体的轨迹主动提出重要指导，即使主模型没问，也常常很有成效。
实际效果如何？SWE 1.5作为主模型还不够好，它与Sonnet 4.5的差距恰好体现在最关键的地方：知道何时升级、知道问什么。成本和速度的优势是真实的，但质量天花板由主模型决定，而它不够强。SWE 1.6表现好很多，但还没到我们想要的水平。我们相信这是一个训练问题，未来的模型会针对这种来回协作进行训练。
有趣的是，这个模式在前沿模型之间协作时效果很好。我们在生产环境中让Claude和GPT以这种方式一起工作了一段时间，在最棘手的场景中产生了真正的收益。跨前沿模型的通信，不再是弱模型向强模型求助，而是把任务路由到最适合处理特定子任务的模型。有些模型更擅长调试，有些更擅长视觉推理，有些更擅长写测试。委派逻辑从难度升级器变成了能力路由器。
总结第二个模式：聪明朋友架构在双方模型都足够强大时效果很好。让不对称的弱主模型也能用好这个模式，仍然是一个开放问题，而且我们认为这是一个训练问题。如果你也想交流这方面的笔记，欢迎联系我们。
扩展到更大范围：管理者与子智能体
上面两个模式共享一个结构：一个写入者，其他智能体围绕它贡献智能。很自然的问题是这个结构能否扩展到更大的范围，比如跨越十个拉取请求的产品功能，或者涉及十几个服务的迁移，需要一周的工作而不是一个下午。
这在Devin中已经上线了。一个管理者Devin可以把一个大任务拆解成小块，生成子Devin来处理，并通过内部MCP协调它们的进度。让它感觉协调一致，比我们预期的需要更多上下文工程。只在小范围委派任务上训练过的管理者，默认会过度指令化，当管理者缺乏深入的代码库上下文时就会适得其反。智能体默认假设它们与子智能体共享状态，但实际上没有。跨智能体通信——子智能体写消息给管理者，让管理者传递给团队中的其他智能体——不会默认发生，因为模型没有在需要这种通信的环境中训练过。每个问题都需要专门的工作去修复，我们还在持续改进。
那无结构的智能体群体呢？我们认为，智能体之间任意网络互相协商的方式，基本上是一个干扰项。实用的形状是“映射-归约-管理”：管理者拆分工作，子智能体执行，管理者综合并汇报。让这类系统感觉像单个智能体处理单个任务一样连贯，是我们2026年即将开展的一些工作的核心。
我们目前已知的结论
所有这些实验有一个共同的线索：当今多智能体系统效果最好的时候，是写入保持单线程，额外的智能体贡献智能而不是行动。拥有纯净上下文的审查者能捕捉到编码者看不到的漏洞。前沿级别的聪明朋友能发现弱主模型遗漏的微妙问题。管理者协调子智能体的范围，而不会让决策碎片化。
所有开放问题都是通信问题。弱模型如何学会何时升级？子智能体如何把发现的重要信息传递给同伴，从而改变同伴的工作？如何在智能体之间传输上下文而不让接收者被淹没？通过提示词可以走一段路，但我们也期待下一代模型——包括我们自己训练的模型——开始缩小这些差距。
我们正在构建一个世界，在这个世界里，软件开发生命周期的每个阶段——规划、编码、审查、测试、监控——都被注入智能，不是作为一群自主行动的角色，而是作为一个扩展人类品味的协调系统。
我们邀请你在我们的平台上尝试这些工作。如果你愿意和我们一起发现这些智能体构建原则，欢迎联系我们。巧合的是，Anthropic也发表了一篇相关的博客，关于构建多智能体研究系统，两篇博客都触及了类似的上下文工程挑战，并得出了相似的结论：第一个适用领域是只读智能体。最近，Anthropic还让他们的较小模型以同样的方式调用较大模型，这至少表明“聪明朋友”那一端的模型也会在回复主模型的通信上变得更好。