在去年的文章里，我曾劝大多数人别折腾多智能体系统。并行 Agent 会在风格、边界情况、代码模式上产生隐性冲突，最终产品脆弱不堪。10 个月后，很多事情变了。
在 Cognition，我们已经部署了真正能在生产环境跑起来的多智能体系统。并行 writer swarm 的大部分想法依然不靠谱——但我们找到了一类真正有效的窄模式：多个 Agent 贡献智能，但写作行为保持单线程。
上下文工程.refresh()
之前的文章提倡把「Prompt 工程」思维转向「上下文工程」。后者更持久，核心是给模型正确的上下文，同时假设模型会越来越强。多智能体场景下，上下文工程会变得极其复杂，核心原则是：
- Agent 之间共享尽可能多的上下文：让它们看同一份资料、同一份任务清单和计划文件、对整体目标有相同的先验判断。
- 动作携带隐性决策：一个 Agent 做了某些修改或编辑，可能会做出与其他并行 Agent 冲突的隐性选择（风格、代码模式、边界情况处理方式）。
由于原则 2，大部分多智能体系统的实际形态是「只读子 Agent」——比如 Web 搜索子 Agent、代码搜索子 Agent。这更像是工具调用，而不是真正的多智能体协作。
10 个月里发生了什么
模型变得更本能地 agentic。它们自然理解工具使用、上下文限制，以及如何为协作者提炼上下文。Agent 用量爆炸式增长——即使在最大型企业的保守客户群里，过去 6 个月也增长了约 8 倍。
这种爆炸带来了两股力量：
- 推力：用户自然开始尝试更多多智能体设置——用 Agent 管理其他 Agent，让编码 Agent 和审查 Agent 来回迭代。
- 拉力：Agent 用量爆炸导致成本爆炸。在更大更强模型即将到来的背景下，如何以更低成本实现前沿能力成了自然问题。
还有一波性感 Demo：用大量 Agent 处理大型工程（20 万行代码、10 万行代码、1 万次迭代），但它们都有一个共同特点——成功标准简单可验证。真实软件需要的是放大人类品味和决策能力的系统。
模式 1：代码审查循环——简单到不该有效
让模型审查自己的代码看似无用，但 Devin Review 平均每个 PR 能发现 2 个 bug，其中约 58% 是严重问题（逻辑错误、缺失边界、安全漏洞）。系统通常会经历多轮代码审查循环，每轮都能发现新 bug。
反直觉的发现：编码 Agent 和审查 Agent 不要事先共享任何上下文，效果反而最好。
原因既有哲学的也有技术的。首先，两个 Agent 用的是同一模型、同一 harness，但这和让同一个人类既写代码又审查不一样——这些 Agent 没有自我，没有ego。其次，有干净上下文的审查 Agent 能更深入地审查原始编码 Agent 可能忽略的区域。
更关键的是注意力数学。模型在越来越长的上下文上做出智能决策的能力会下降。当编码 Agent 工作了几小时、读了大量仓库代码、运行了各种命令、思考了不同方案、修复了各种错误后，上下文已经非常庞大。专门的审查 Agent 则直接看 diff，从头重新发现上下文——更短的上下文带来更敏锐的问题发现能力。
让这个系统真正有效运转的最后关键，是编码 Agent 和审查 Agent 之间的通信桥。Devin 是否正确利用用户指令等更广泛的上下文来过滤 Devin Review 返回的 bug？这对防止循环、防止违反用户意图、防止做超出范围的工作至关重要。
经验：干净上下文在生成器-验证器循环中带来了显著的能力提升。但与整体上下文的清晰沟通和综合同样重要。
模式 2：Smart Friend——大模型回来了
过去几个月，最流行的模型从 Anthropic 的 Sonnet 级中模型明显转向了 Opus 级大模型。「Scaling is back」。
这带来一个隐含问题：前沿智能对大多数日常任务来说太贵了（也可能太慢）。同时，小模型也面临着一个困境——任务可能比预想的要难得多。如何兼得？
Windsurf 尝试了一个方案：把一个 950 tok/sec 的次前沿模型与 Sonnet 4.5 的「规划」能力配对。他们发现，如果把更强/更全面的模型作为一个「Smart Friend」工具，让主/小模型在遇到足够棘手的情况时调用它，可以弥补部分性能差距，同时保持低成本和高速。
核心架构是让主模型决定何时值得咨询更强/更贵的模型。但工程化这个上下文传递和通信非常棘手：
主模型需要知道如何与 Smart Friend 说话。 核心难题是「更弱的那个模型如何知道自己到了极限？」不像常见的 inverted setup（强主模型把任务委托给更小的子 Agent），这里决定何时委托的不是更聪明的那个。有几个可能的解决方案：鼓励主模型至少调用一次 Smart Friend 来评估是否有遗漏；根据主模型的智能程度，可能需要某些领域特定的预设指导（比如遇到合并冲突时总是调用 Smart Friend）。
另一个难题是主模型应该与 Smart Friend 分享什么上下文？主模型应该问 Smart Friend 什么？研究发现，一个合理的 80/20 方案是直接将主模型的完整上下文 fork 给 Smart Model。同样，鼓励主模型问宽泛的问题（「我应该怎么做？」），让 Smart Friend 决定什么是值得讨论的，比让主模型做过于具体的限定更有效。
Smart Friend 需要知道如何回馈主模型。 无论如何调优（1），质量上仍然可能存在差距。另一个方向的通信调优可以弥补这些差距。例如，如果主模型从未看过 important_file.py，却问了一个需要了解该文件内容的问题，Smart Friend 的正确答案不是编造理论（这往往是默认行为），而是具体指示主模型去查看这个文件，之后再问。同样，让 Smart Friend 超出主模型问题范围、基于 Agent 轨迹提供重要指导，往往更有收获。
Smart Friend 的实际表现。 必须坦诚：SWE 1.5 作为主模型，这个设置并没有真正发挥作用。差距太大——尤其是在「何时升级」和「问什么」这些关键地方。成本和速度优势是真实的，但质量上限取决于主模型，而主模型不够强。SWE 1.6 明显更好，让这个模式开始有价值，但还没有达到预期。这个问题本质上是训练问题，未来的 SWE 模型会在训练中考虑到这种来回交互。
在两个前沿模型之间，这个模式确实有效。在生产环境中让 Claude 和 GPT 以这种方式协作运行了一段时间，在最棘手的场景下产生了真实的收益。有趣的发现是，跨前沿通信的调优问题与小模型到大模型的情况不同——更多是关于路由到哪个模型最擅长特定子任务，而不是弱模型知道何时问强模型。委托逻辑变成了能力路由而不是难度升级器。
经验：Smart Friend 在两个模型都足够强的时候有效。把它变成弱主模型也能工作（这是带来最大突破的版本）仍然是一个开放问题，我们认为这是训练问题。
Manager + Child Agent
两个模式有一个共同结构：一个 writer，被贡献智能的其他 Agent 增强。一个自然的问题是，这能否扩展到更大范围？比如跨越 10 个 PR 的产品功能、涉及十几个服务的迁移、一周的工作而不是半天。
这已经在 Devin 中上线了。一个 Manager Devin 可以把大任务分解成小块、生成 child Devin 来处理，并通过内部 MCP 协调进度。
让这种协同感觉起来像单个 Agent 处理单个任务一样连贯，比预期需要更多的上下文工程。问题包括：训练过小范围委托的 Manager 默认过于规范，这在 Manager 缺乏深层代码库上下文时会适得其反；Agent 假定自己与 children 共享状态，但实际上没有；跨 Agent 通信——子 Agent 向 Manager 写消息，再由 Manager 传递给其他 Agent——不会自然发生，因为模型没有在这种需要跨 Agent 通信的环境中被训练。
无结构的 swarm 呢？我们认为任意的 Agent 网络相互协商的方式大多是一种干扰。实际的形态是 map-reduce-and-manage：Manager 分裂工作，children 执行，Manager 综合并报告。
结论
所有这些实验有一条共同主线：多智能体系统今天最好的使用方式，是让写作行为保持单线程，让额外 Agent 贡献智能而不是动作。干净上下文的审查者能发现编码者看不到的 bug。前沿级别的 Smart Friend 能发现较弱主模型遗漏的微妙之处。Manager 协调跨子 Agent 的范围而不碎片化决策。
开放问题都是通信问题：更弱的模型如何学会何时升级？子 Agent 如何呈现一个应该改变其兄弟姐妹工作的发现？如何在不同 Agent 之间传递上下文而不淹没接收者？
我们正在建设的是一个在软件开发生命周期每个阶段——规划、编码、审查、测试、监控——都注入智能的世界，不是作为一群自主行动者，而是作为协调系统放大人类品味。