作者：@walden_yan 时间：2026年4月23日

10个月前，我写了《不要构建多智能体》，认为大多数人不应该尝试构建多智能体系统。并行智能体会在风格、边界情况和代码模式方面做出隐含的选择。当时，这些决策经常相互冲突，导致产品脆弱。从那以后，很多事情都变了。

在Cognition，我们已经开始部署在实践中真正有效的多智能体系统。我们最初的观察对于并行写作智能体群体来说仍然成立：该领域大多数花哨的想法仍然没有获得有意义的采用。但我们发现了一类更狭窄的模式确实有效：多个智能体为任务贡献智能，而写入操作保持单线程。在这篇文章中，我将总结我们在构建它们时学到的东西。

上下文工程复习

在上一篇文章中，我们鼓励读者将智能体构建从"提示工程"重新定义为"上下文工程"。提示工程鼓励像"你是一名高级软件工程师"或"思考更久"这样的花哨技巧。上下文工程更加持久，专注于为模型提供正确的上下文，同时假设模型随着时间变得更加强大。由于许多原因，上下文工程在多智能体设置中可能变得非常具有挑战性。过去，我们推荐以下原则：

• • 在智能体之间共享尽可能多的上下文。
  确保它们看到相同的信息源，保持在同一页面上（待办事项列表、计划文件），并对它们应该完成的整体任务共享相同的先验知识。在需要时帮助它们沟通。
• • 操作带有隐含的决策。
  当一个智能体做出某些更改或编辑时，它可能会做出可能与其他并行智能体的隐含选择相冲突的隐含选择（风格、代码模式、某些边界情况应如何处理）。因此，在多个智能体都在执行写入操作的多智能体世界中，决策制定可能会变得非常分散。

尽管在过去几个月里许多事情都发生了变化，但对深思熟虑的上下文工程的需求没有变化。作为原则2的结果，世界上大多数多智能体设置仅限于"只读"子智能体，例如网络搜索子智能体和代码搜索子智能体。例如，Devin可以调用Deepwiki子智能体来获取代码库上下文。但这些类型的子智能体大多类似于工具调用，而不是真正的多智能体协作。我们想探索当智能体以更交互的方式协作时可以解锁哪些能力。

过去10个月发生了什么变化

首先，模型变得更加自然地"智能体化"。它们直观地理解工具使用、自身的上下文限制，以及如何为协作者（人类或其他）提炼它们的上下文。因此，智能体的使用量增长了……非常多。

即使我们查看Devin在最大型企业部门的使用情况——这个传统上对采用新技术持谨慎态度的部门——我们在过去6个月里也看到了爆炸式增长（约8倍）。

这种使用量的爆炸式增长导致了对多智能体的推动和拉动。

在推动方面，能力的提升导致用户自然地尝试了更多的多智能体设置。当你使用这么多智能体时，你自然会开始在这些智能体周围的所有事情上遇到瓶颈：管理、规划和审查。例如，一些人为Devin创建了脚本来管理其他Devin。许多人也倾向于让他们的编码智能体与他们的审查智能体来回迭代。

在拉动方面，智能体使用量的爆炸式增长导致了成本的爆炸式增长。随着新的Mythos级别的更大、更强大的模型即将出现，自然的问题是如何以更低的成本实现前沿能力。而多智能体系统可能是一个自然的答案。

还有一波关于将大量智能体投入大型工程项目的耸人听闻的演示。值得注意的例子包括构建一个Web浏览器（20万行代码）、构建一个C编译器（10万行代码）以及优化一个LLM训练脚本（1万+次迭代）。这些令人兴奋，但它们都共享一个大多数真实软件没有的属性：简单、可验证的成功标准。真实软件需要一个能够扩展人类品味和决策的系统，这正是我们开始探索多智能体系统的背景。

一些实用的多智能体实验

1) 代码审查循环，愚蠢到不应该工作

你会认为让一个模型审查自己的代码不会产生任何有用的发现。但即使在Devin编写的PR上，Devin审查器平均也能在每个PR上发现2个错误，其中大约58%是严重的（逻辑错误、缺失的边界情况、安全漏洞）。通常系统会循环多个代码审查周期，每次都发现新的错误（这并不总是很好，因为可能需要很长时间）。今天，我们让Devin和Devin审查器原生地相互迭代，以便当人类打开PR时，大多数错误已经得到解决。

反直觉的部分。 有趣的是，我们发现当编码和审查智能体事先不共享任何上下文时，这种技术效果最好。为什么？

对此有哲学和技术理由的混合。首先，我们必须记住，将相同的模型放在两个智能体中，即使智能体框架完全相同，也不会像你想象的一个人完成两项任务那样使它们产生自我偏见/相关。这些智能体最终是根据其上下文执行的系统。它们没有自我意识，任何可能存在的共同偏见最终都来自它们的训练过程，而现在我们可以认为这是相当高质量的。

具有完全干净上下文的审查智能体也有助于它更深入地研究原始编码智能体可能没有的领域。一方面，这是因为它被迫在没有规范的情况下从实现反向推理，并且可以公开质疑原始智能体可能由于用户指令中的错误而忽略的事情（例如，用户告诉智能体实现一个不安全的模式）。但也许更重要的是，由于注意力的数学原理，拥有干净的上下文使智能体更智能。

上下文腐烂是一个有充分记录的现象，是模型在越来越长的上下文长度下做出较不智能决策的结果。模型通常具有有限数量的注意力头，当它们需要处理不断增长的指令、提示、代码等上下文时，重要的细节可能无法完全纳入其决策制定。当编码智能体在一个任务上工作了数小时，阅读仓库、运行命令、思考不同的方法、修复错误时，它会快速建立一个大的上下文。专用的审查智能体可以跳过这些无关的上下文，只查看差异，并在从头开始阅读代码时重新发现它需要的任何上下文。通过更短的上下文，改进的智能自然会导致对细微问题的检测增加。

使这个系统真正良好工作的最后一个关键部分是编码智能体和审查智能体之间的通信桥梁。基本上，Devin是否正确使用其用户指令、决策等更广泛的上下文来过滤从Devin审查器返回的错误？这是防止循环、不服从用户、做超出范围的工作等的关键。我们发现，通过一些专门的提示，今天的模型可以在这里做出合理的判断，并且你最终会在两个智能体和人类之间得到一些非常有趣的交互。

要点： 当使用生成器-验证器循环时，干净的上下文会导致能力的显著提高。但是，与整体上下文的清晰沟通和综合对于连贯的体验很重要。

2) 大型、昂贵的模型回来了——介绍"聪明的朋友"

如果你查看过去几个月最流行的模型，你会看到一个明显的转变，从像Anthropic的Sonnet级模型这样的中型模型转向像Anthropic的Opus级模型这样的大型模型，以提高性能。随着Mythos的到来，我们基本上可以说"缩放回来了"。

这其中的隐含含义是，前沿智能很快将对大多数日常任务来说太昂贵（也许太慢）。同时，你面临着较小模型的困境——一个任务可能比最初预期的更困难。

我们如何才能两全其美？在Windsurf中，我们在10月推出SWE-1.5时尝试了一个以此为目标的实验，这是一个950 token/秒的亚前沿模型。我们发现，当与Sonnet 4.5配对进行"规划"时，我们能够在保持低成本和快速速度的同时，弥补一小部分性能差距。

我们用来实现这一点的实际架构是将更聪明/昂贵的模型作为"聪明的朋友"工具提供，主要/较小的模型可以调用它。基本上，让主要/较小的模型决定什么时候情况足够棘手，值得咨询更聪明/昂贵的模型。但我们很快发现，设计上下文传输和通信很棘手：

1. 主要模型需要知道如何与聪明的朋友交谈。

这个设置的核心棘手之处来自于"一个较笨的模型如何知道它已达到极限？"这个问题。与更流行的由聪明的主要模型向较小的子智能体委派任务的倒置设置不同，决定何时委派的模型不是更聪明的那个。这里有一些潜在的解决方案。一方面，你可以鼓励主要智能体总是至少调用一次聪明的智能体来评估它是否认为有一些被遗漏的棘手问题。你还可以提示调整或训练主要模型，使其对这个决策进行更好的校准。根据主要模型的智能，某些类型的领域特定的规定性指导可能是必要的，例如总是为合并冲突调用聪明的朋友。

关于这种通信方法的另一个棘手问题是，主要模型应该与聪明的朋友共享什么上下文？此外，主要模型应该问聪明的朋友什么？如果主要模型只共享其总上下文的一个子集，那么聪明的模型可能不会做出完全知情的决定。我们发现，对于今天的模型，一个合理的80/20解决方案是与聪明的模型共享主要模型完整上下文的一个分支。同样，我们发现鼓励主要模型问广泛的问题（"我应该做什么？"）并让聪明的模型决定什么是值得讨论的会更好。

2. 聪明的朋友需要知道如何与主要模型交谈

无论你如何调整（1），你可能会发现由于上下文丢失，质量仍然存在差距。调整另一个方向的通信可以弥补这些差距。例如，假设主要模型从未查看过important_file.py，并向聪明的模型询问一些需要了解此文件内容的事情。在这种情况下，聪明的模型的正确答案不是编造一些理论（这通常是默认行为），而是具体指示主要模型调查此文件并稍后再问。同样，让聪明的朋友超越主要模型正在问的问题，并根据智能体轨迹建议任何重要的指导，即使主要模型没有要求，也通常是富有成效的。我们发现这种"超范围"的聪明的朋友通常会导致更有趣的交互。

聪明的朋友到底发生了什么

我们应该坦率地说：SWE 1.5不够好，无法成为这个设置真正工作的主要模型。它与Sonnet 4.5之间的差距在这个设置真正重要的地方太宽了：知道何时升级，知道问什么。成本和速度的优势是真实的，但质量上限由主要模型设定，而主要模型不够强大。SWE 1.6（最近的后续版本，在SWE-bench上达到Opus-4.5级别性能）明显更好，并且缩小了足够多的差距，使该模式开始获得回报，但它仍然不是我们想要的地方。我们有理由相信这是一个训练问题，未来的SWE模型将考虑这种来回交互进行训练。

这个模式确实有效且效果良好的地方是跨前沿模型。我们在生产中将Claude和GPT一起以这种设置运行了相当长的一段时间，并且在最棘手的场景中产生了真正的收益。有趣的发现是，提示调整问题与小模型到大模型的情况不同。跨前沿通信不太关于较弱的模型知道何时询问较强的模型，而更多关于路由到最擅长特定子任务的模型。一些模型调试更好，一些处理视觉推理更好，一些编写测试更好。委派逻辑变成了一个能力路由器，而不是难度升级器。

要点： 当两个模型都很强大时，聪明的朋友今天就可以工作。让它与不对称的较弱主要模型一起工作——这是导致最大解锁的版本——仍然是一个开放问题，我们认为这是一个训练问题。如果你想比较笔记，请联系我们。

展望：更高级别的委派

上述两个模式共享一个结构：一个写入者，由围绕它贡献智能的其他智能体增强。显而易见的下一个问题是，这是否扩展到拥有更大范围的智能体，例如，跨越十个PR的产品功能，触及十几个服务的迁移，一周的工作而不是一个下午的工作。

这今天在Devin中已经上线。一个经理Devin可以将更大的任务分解成碎片，生成子Devin来处理它们，并通过内部MCP协调它们的进度。让它感觉连贯比我们预期的需要更多的上下文工程。在小范围委派上训练的经理默认过于规定性，当经理缺乏深入的代码库上下文时，这会适得其反。智能体假设它们与子级共享状态，而实际上它们没有。跨智能体通信——一个子智能体写消息回给它的经理，以传递给智能体团队中的其他智能体——不会默认发生，因为模型没有在需要它的环境中训练。每一个都需要专门的工作来修复，并且我们仍在所有这些方面改进。

非结构化群体怎么样？

我们认为非结构化群体方法——智能体的任意网络相互协商——主要是一种干扰。实用的形状是map-reduce-and-manage：经理拆分工作，子级执行，经理综合并报告回来。使这种类型的系统感觉像一个单一智能体在单个任务上工作一样连贯，是我们2026年即将进行的一些工作的核心。

我们今天知道什么

所有这些实验都有一个共同的主线：多智能体系统在写入保持单线程并且附加智能体贡献智能而非操作时效果最好。干净上下文的审查器捕获编码者看不到的错误。前沿级别的聪明的朋友捕获较弱主要模型遗漏的细微差别。经理在不分散决策的情况下协调子智能体之间的范围。

开放问题都是通信问题。较弱的模型如何学习何时升级？子智能体如何发现应该改变其兄弟姐妹工作的发现？你如何在智能体之间传输上下文而不淹没接收者？你可以通过提示走得相当远，但我们也期望下一代模型，包括我们自己训练的模型，将开始缩小这些差距。

我们正在构建一个世界，其中智能被注入到软件开发生命周期的每个阶段——规划、编码、审查、测试和监控——不是作为自主参与者的群体，而是作为一个扩展人类品味的协调系统。

https://x.com/walden_yan/status/2047054401341370639