多智能体系统实战：什么真正奏效

10 个月前，我写了一篇题为《不要构建多智能体 (Don't Build Multi-Agents)》的文章，认为大多数人不应该尝试构建多智能体系统 [1]。并行的智能体往往会在代码风格、边缘情况和代码模式上做出隐性选择。在当时，这些决策经常相互冲突，导致产品变得极其脆弱。但从那时起，情况发生了很大的变化。

在 Cognition，我们已经开始部署在实际应用中真正有效的多智能体系统。我们最初对“并行写入群集（parallel-writer swarms）”的观察在今天依然成立：这个领域中大多数听起来很酷的想法仍然没有得到有意义的实际应用。但我们发现了一类更为具体的模式确实行之有效：在这些架构中，多个智能体为一项任务提供智力支持，而写入操作始终保持单线程（single-threaded）。 在这篇文章中，我将总结我们在构建这些系统时学到的经验。

上下文工程回顾 (A Refresher on Context Engineering)

在上一篇文章中，我们鼓励读者将构建智能体的思路从“提示词工程（prompt engineering）”转变为“上下文工程（context engineering）”。提示词工程倾向于使用诸如“你是一名高级软件工程师”或“思考得再久一点”之类的小伎俩。上下文工程则更为持久，它侧重于为模型提供正确的上下文，并建立在“模型的能力会随着时间的推移而不断增强”这一假设之上。由于种种原因，在多智能体架构中进行上下文工程会变得非常具有挑战性。过去，我们推荐了以下原则：

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

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

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

首先，模型在自然表现上变得更具“智能体特性（agentic）”了。它们能直观地理解工具的使用、自身的上下文限制，以及如何为协作者（无论是人类还是其他模型）提炼其上下文。结果就是，智能体的使用量……呈现了爆炸式增长。 即使我们观察我们在最大企业客户群体（这一群体通常对采用新技术持谨慎态度）中 Devin 的使用情况，我们也能看到过去 6 个月内出现了爆发式的增长（约 8 倍）。

这种使用量的爆发对多智能体的发展既产生了推力，也产生了拉力。

在推力方面，能力的提升促使用户自然而然地尝试更多的多智能体架构。当你使用大量智能体时，自然会开始在围绕这些智能体的各个环节遇到瓶颈：管理、规划和审查。例如，有些人编写了脚本，让一组 Devin 去管理其他的 Devin。许多人也倾向于让他们的编码智能体与审查智能体进行反复的迭代。

在拉力方面，智能体使用量的爆发导致了成本的激增。随着即将面世的规模更大、能力更强的新型 Mythos 级别模型出现，一个自然而然的问题随之而来：如何以更低的成本实现前沿的模型能力？而多智能体系统可能是一个顺理成章的答案。

同时，也涌现出了一批引人瞩目的演示项目，它们将大量的智能体投入到大型工程项目中。著名的例子包括构建网页浏览器（20万行代码）、构建 C 编译器（10万行代码）以及优化大语言模型训练脚本（1万次以上迭代）。这些成就令人兴奋，但它们都有一个大多数真实软件所不具备的特征：一个简单且可验证的成功标准。真正的软件开发需要一个能够扩展人类品味（taste）和决策能力的系统，这正是我们着手探索多智能体系统的大背景。

一些实用的多智能体实验

1) 简单粗暴却意外有效的代码审查循环

你可能会认为，让一个模型审查自己的代码不会产生任何有用的发现。但即使是 Devin 自己编写的 PR（拉取请求），Devin 审查员（Devin Review）平均每个 PR 也能发现 2 个 bug，其中约 58% 是严重问题（逻辑错误、遗漏的边缘情况、安全漏洞）。通常，系统会循环进行多个代码审查周期，每次都会发现新的 bug（这并不总是好事，因为可能会耗费一些时间）。如今，我们让 Devin 和 Devin 审查员原生进行相互迭代，这样在人类打开 PR 时，大部分 bug 就已经被解决了。

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

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

审查智能体拥有完全干净的上下文，也有助于它深入探究原始编码智能体可能未涉及的领域。一方面，这是因为它被迫在没有说明文档的情况下从代码实现反向推理，并可以公开质疑由于用户指令错误（例如，用户让智能体实现一个不安全的模式）而导致原始智能体可能忽略的事情。不过，也许更重要的是，由于注意力机制的数学原理，拥有干净的上下文会让智能体变得更聪明。上下文衰退（Context Rot）是一个被充分记录的现象，即随着上下文长度的不断增加，模型做出的决策会变得越来越不智能。模型通常拥有有限数量的注意力头，当它们需要处理不断增长的指令、提示词、代码等上下文时，重要的细节可能无法完全纳入其决策中。当编码智能体在一项任务上工作了几个小时，通读代码库、运行命令、思考不同方法、修复错误时，它会迅速积累大量的上下文。而专门的审查智能体可以跳过这些多余的上下文，只查看代码差异（diff），并在从头阅读代码时重新发现所需的任何上下文。由于上下文更短，提升的智能水平自然会提高对细微问题的检测能力。

让这个系统真正良好运作的最后一个关键部分，是编码智能体和审查智能体之间的沟通桥梁。基本上就是：Devin 是否正确使用了其更广泛的上下文（用户指令、决策等）来过滤从 Devin 审查员返回的 bug？这是防止死循环、违背用户意愿、执行超范围工作等问题的关键。我们发现，通过一些专门的提示词设计，如今的模型可以在这里做出合理的判断，最终你会得到两个智能体之间以及与人类之间非常有趣的互动。

要点总结： 在使用“生成器-验证器循环”时，干净的上下文能显著提升能力。但是，清晰的沟通以及与整体上下文的整合，对于获得连贯的体验至关重要。

2) 昂贵的大模型回归了——引入“智能助手 (Smart Friend)”

如果你观察过去几个月中最受欢迎的模型，你会发现为了追求性能，趋势出现了明显的转变：从 Anthropic 的 Sonnet 等中型模型，转向了 Opus 等大型模型。而随着 Mythos 模型的即将到来，我们基本上可以说“规模扩展（scaling）又回来了”。

这其中暗含的意味是：前沿智能对于大多数日常任务来说，很快就会变得过于昂贵（也许还会很慢）。与此同时，你面临着使用较小模型时的困境，即一项任务可能比最初预期的要困难得多。

我们如何才能两全其美呢？在 Windsurf 中，我们在 10 月份发布 SWE-1.5 时尝试了一个带有这一目标的实验，这是一个推理速度高达 950 token/秒的次前沿模型。我们发现，当与 Sonnet 4.5 搭配用于“规划”时，我们能够弥补一小部分性能差距，同时保持低成本和高速度。

我们用来实现这一目标的实际架构是：将更聪明/庞大的模型作为一个“智能助手（smart friend）”工具，提供给主要/较小的模型调用。基本上，就是让主模型/较小模型来决定，情况何时复杂到值得去咨询更聪明/昂贵的模型。但我们很快发现，设计上下文转移和通信工程是非常棘手的：

1. 主模型需要知道如何与“智能助手”对话。

这种架构的核心难点在于“一个较笨的模型如何知道自己已达到极限？”。这与当前更流行的反向架构（聪明的的主模型将任务委托给较小的子智能体）不同，在这里，决定何时委派任务的模型并不是较聪明的那个。这里有几种潜在的解决方案。其一，你可以鼓励主智能体至少调用一次智能助手，以评估它是否认为遗漏了某些棘手的问题。你也可以通过提示词微调或训练，使主模型在做出这一决定时更加精确。根据主模型的智能程度，可能需要某些特定领域的硬性指导，比如“遇到合并冲突（merge conflicts）时总是调用智能助手”。

这种沟通方式的另一个棘手问题是，主模型应该与智能助手共享哪些上下文？此外，主模型应该向智能助手询问什么？如果主模型只分享其总上下文的一部分，那么更聪明的模型可能无法做出充分知情的决策。我们发现，对于当今的模型来说，一个合理的 80/20 解决方案是：直接将主模型完整上下文的一个副本（fork）共享给智能助手。同样，我们发现鼓励主模型问一些宽泛的问题（“我该怎么做？”），让智能模型来决定讨论什么更有价值，效果会更好。

2. “智能助手”需要知道如何向主模型回复。

无论你对第 (1) 点的调整有多好，你可能会发现，由于上下文的丢失，仍然存在质量上的差距。对反方向的沟通进行调整可以弥补这些差距。例如，假设主模型从未看过 important_file.py，却向智能助手询问了一些需要了解该文件内容的问题。在这种情况下，智能助手的正确回答不是编造一些理论（这通常是默认行为），而是明确指示主模型去调查这个文件，稍后再来提问。同样地，要求智能助手超越主模型所提的问题，根据智能体当前的执行轨迹提出重要的指导建议（即使主模型并没有主动要求），往往也卓有成效。我们发现，这种“超纲（over-scoped）”的智能助手通常能带来更有趣的交互。

智能助手实验的实际结果

我们应该坦诚地说：SWE 1.5 还不足以胜任作为主模型让这个架构真正发挥作用。它和 Sonnet 4.5 之间的差距在决定该架构成败的关键环节上太大了：即“知道何时升级请求”以及“知道问什么”。成本和速度上的优势确实存在，但质量的天花板是由主模型决定的，而主模型还不够强。SWE 1.6（最近的后续版本，在 SWE-bench 上达到了类似 Opus/4.5 级别的性能）有了显著提升，并大大缩小了这一差距，使得这种模式开始产生回报，但它仍然没有达到我们期望的理想水平。我们有理由相信这是一个训练问题，未来的 SWE 模型将把这种来回交互的模式纳入训练考量中 [2]。

这种模式真正奏效且效果很好的地方，是在各个前沿模型之间相互协作时。我们已经在生产环境中运用这一架构让 Claude 和 GPT 协同运行了很长一段时间，并在最棘手的场景中取得了实质性的收益。有趣的发现是，此时的提示词微调问题与“小模型求助大模型”的情况有所不同。前沿模型之间的跨界通信，更多的是将任务路由到最擅长特定子任务的模型，而不是较弱模型去学习何时请教较强模型。有些模型在调试代码方面更好，有些在处理视觉推理方面更好，有些在编写测试方面更好。委派逻辑变成了一个“能力路由器（capability router）”，而不是“难度升级器（difficulty escalator）”。

要点总结： 当两个模型都很强大时，“智能助手”模式在当下是有效的。而要让它在主模型不对称地处于较弱状态（这也是能带来最大潜力释放的版本）下工作，仍然是一个未解的难题，我们认为这属于训练层面的问题。如果你想交流心得，欢迎随时联系。

展望未来：更高层级的委派

上面的两个模式共享一个结构：一个执行写入操作的智能体（writer），外围辅以其他智能体提供智力增强。下一个显而易见的问题是：这种模式是否能扩展到智能体负责更大范围任务的场景？例如，一个跨越 10 个 PR 的产品功能，涉及十几个服务的系统迁移，或者是一周的工作量而不仅仅是一个下午的活儿。

这个构想目前已经在 Devin 中上线了。一个“管理者 Devin”可以将大型任务分解成小块，生成“子 Devin”来处理它们，并通过内部的 MCP（模型上下文协议）协调它们的进度。为了让整个过程感觉连贯，我们投入了比预期多得多的上下文工程。在小范围委派上训练出来的管理者模型，默认会表现得过于发号施令，当管理者缺乏深层代码库上下文时，这反而会适得其反。智能体会误以为它们与子节点共享着状态，但实际上并没有。跨智能体通信——即子智能体将消息写回给其管理者，再由管理者传递给智能体团队中的其他成员——在默认情况下是不会发生的，因为模型并没有在需要这种通信的环境中训练过。每一个问题都需要我们专门去修复，而且我们仍在继续改进所有这些方面。

那么无结构的群集（unstructured swarms）呢？我们认为，那种由相互协商的智能体组成的任意网络这种“无结构群集”方法，在很大程度上是一种干扰。实用的形态应该是“Map-Reduce 并加以管理”的模式：管理者拆分工作，子智能体执行工作，管理者进行综合整理并汇报结果。让这种类型的系统运行起来就像单个智能体执行单一任务一样连贯，是我们即将在 2026 年开展的重点工作之一。

我们今天所知道的

所有这些实验都有一个共同的脉络：在今天，当写入操作保持单线程，并且额外的智能体贡献的是智力而不是行动时，多智能体系统的效果最好。拥有干净上下文的审查员能捕获编码者发现不了的 bug；前沿级别的智能助手能捕捉到较弱的主模型遗漏的微妙细节；管理者能够协调子智能体的工作范围，而不会造成决策的碎片化。

尚未解决的开放性问题都属于沟通问题。较弱的模型如何学习在何时升级求助？子智能体如何将可能改变其他兄弟节点工作的发现呈现出来？你如何在智能体之间转移上下文而不让接收者被信息淹没？虽然通过提示词技术可以取得相当不错的进展，但我们也期望下一代模型（包括我们自己训练的模型）能开始弥补这些差距。

我们正在建设这样一个世界：在软件开发生命周期的每一个阶段——规划、编码、审查、测试和监控——都注入人工智能，它不是作为一群各自为政的自主行动者，而是一个能够扩展人类品味与决策能力的协调系统。

欢迎你在 devin.ai 或 windsurf.com 体验我们的工作成果。如果你有兴趣与我们一起探索这些构建智能体的原则，请联系 walden@cognition.ai

[1] 巧合的是，Anthropic 在第二天发布了一篇关于构建多智能体研究系统的相关博客文章。这两篇博文都谈到了在上下文工程中遇到的相似挑战，并得出了相似的结论，即多智能体的首个适用领域是只读（readonly）智能体。

[2] 最近，Anthropic 推出了一项类似的测试版实验，让他们较小的模型以同样的方式调用他们较大的模型。至少，这表明“智能助手”端的模型也将变得更擅长向主模型进行回复沟通。