别再构建多智能体了

Multi Agent应用有望成为当前流行的大模型应用范式。

前两天，我们介绍了Anthropic有关构建multi Agent的最佳实践。

Anthropic谈如何构建生产级多智能体系统

然而，来自全球首位AI程序员Devin，热门AI应用DeepWiki（Devin化身最强文档Agent，完美破解程序员两大烦恼！）的开发团队，Cognition AI却持不同的观点。他们认为，在2025年的技术水平下，追求让多个AI智能体并行协作的架构，是一种脆弱且极易失败的歧途。

为什么？关键在于“上下文灾难”：

1. 信息孤岛： 并行工作的子智能体无法看到彼此的进展和决策，就像蒙着眼睛的工匠，最终做出的“零件”风格迥异、无法组装。
2. 决策冲突： 智能体的每一个行动都包含着“隐性决策”。当多个智能体独立决策时，这些决策极有可能相互冲突，导致整个项目走向混乱。

出路何在？拥抱“上下文工程（Context Engineering）”：

在笔者看来，上下文工程是基础，而多智能体应用是未来，两者都很重要，并非是二选一的问题，要只能选其一，上下文工程本身更为重要一些，低质量的扩展，带来的结果就和早期全自主 Agent应用（GPTs）一样，势必会受到模型能力的限制以及复杂度的提升而难以落地（也可类比web架构（单体 vs 分布式）之争），也正是如此，留给了dify，n8n这样过渡性产品以生存空间和获取用户的机会，并进而成长成为当下火热的Agent构建工具。

如无必要，勿增实体。有时候，简单实用远比“fancy”更重要！

这也是笔者反复强调高质量上下文重要性的原因，感兴趣的读者可以阅读本公众号之前的文章。

以下全文《Don’t Build Multi-Agents（别再构建多智能体了）》供大家参考。

上下文工程的原则

我们将逐步阐明以下原则：

• 共享上下文
• 行动承载着隐性决策
• 我们为何要思考这些原则？

HTML于1993年问世。2013年，Facebook向世界发布了React。如今已是2025年，React（及其衍生技术）主导了开发者构建网站和应用的方式。为什么？因为React不仅仅是一个编写代码的脚手架，它是一种哲学。通过使用React，你欣然接受了一种以响应式和模块化模式构建应用的方式——人们现在认为这是一种标准要求，但在早期Web开发者看来，这并非理所当然。

在LLM和构建AI智能体的时代，感觉我们仍像是在玩弄原始的HTML和CSS，试图弄清楚如何将它们组合起来以创造良好的体验。除了某些最基础的概念外，还没有哪一种构建智能体的方法成为标准。

在某些情况下，像OpenAI的Swarm和微软的AutoGen等库，正在积极推广一些我认为是构建智能体的错误方式。具体来说，就是使用多智能体架构，我将解释原因。

话虽如此，如果你是构建智能体的新手，有很多关于如何搭建基础脚手架的资源。但当涉及到构建严肃的生产级应用时，情况就完全不同了。

构建长时运行智能体的理论

让我们从可靠性说起。当智能体必须在长时间运行中保持可靠，并维持连贯的对话时，你必须采取某些措施来控制复合错误的潜在风险。否则，如果你不小心，系统会很快崩溃。而可靠性的核心，就是上下文工程（Context Engineering）。

上下文工程

在2025年，市面上的模型已经极其智能。但即使是最聪明的人，如果缺乏对任务上下文的理解，也无法有效地完成工作。“提示工程（Prompt engineering）”这个词被创造出来，指的是为LLM聊天机器人以理想格式编写任务所需的努力。而“上下文工程”则是它的下一个层次。它关乎在一个动态系统中自动完成这件事。这需要更精细的把握，并且实际上是构建AI智能体的工程师们的首要工作。

以一种常见的智能体类型为例。这种智能体：

1. 将工作分解成多个部分
2. 启动子智能体来处理这些部分
3. 最后将结果合并

这是一个诱人的架构，特别是当你的任务领域包含多个并行组件时。然而，它非常脆弱。关键的失败点在于：

假设你的任务是“构建一个Flappy Bird的克隆版”。它被分解为子任务1“构建一个带有绿色管道和碰撞区的移动游戏背景”和子任务2“构建一个可以上下移动的小鸟”。

结果，子智能体1实际上误解了你的子任务，开始构建一个看起来像《超级马里奥》的背景。子智能体2为你构建了一只鸟，但它看起来不像游戏素材，其移动方式也与Flappy Bird中的完全不同。现在，最终的智能体只能面对一个棘手的任务：将这两个沟通失误的产物组合起来。

这可能看起来像是刻意编造的，但大多数现实世界的任务都有许多层次的细微差别，所有这些都有可能被误解。你可能会认为，一个简单的解决方案是将原始任务作为上下文也复制给子智能体。这样，它们就不会误解自己的子任务了。但请记住，在一个真实的生产系统中，对话很可能是多轮的，智能体可能需要进行一些工具调用来决定如何分解任务，任何细节都可能影响对任务的解读。

原则一：共享上下文，而且是完整的智能体追踪记录，而非孤立信息。

让我们再次审视我们的智能体，这次确保每个智能体都拥有前序智能体的上下文。

不幸的是，我们仍未走出困境。当你给智能体同样的Flappy Bird克隆任务时，这一次，你可能会得到一只鸟和一个背景，但它们的视觉风格完全不同。子智能体1和子智能体2无法看到对方在做什么，因此它们的工作最终变得不一致。

子智能体1和子智能-体2采取的行动，是基于事先未明确规定的、相互冲突的假设。

原则二：行动承载着隐性决策，冲突的决策导致糟糕的结果。

我认为，原则1和原则2是如此关键，以至于几乎不值得去违背它们，因此你默认就应该排除任何不遵守这些原则的智能体架构。你可能觉得这限制太多，但实际上，你仍然可以探索广阔的不同架构空间。

遵循这些原则最简单的方法就是使用单线程线性智能体：

在这里，上下文是连续的。然而，对于子部分非常多的大型任务，你可能会遇到上下文窗口溢出的问题。

老实说，简单的架构就能让你走得很远。但对于那些真正面临超长时任务，并愿意投入精力的人来说，你们可以做得更好。解决这个问题的方法有几种，但今天我只介绍一种：

你得到的好处是一个能有效处理更长上下文的智能体。不过，你最终还是会达到一个极限。对于热衷于此的读者，我鼓励你们思考更好的方法来管理任意长的上下文。这最终会成为一个相当深的兔子洞！

应用原则

如果你是一个智能体构建者，请确保你的智能体的每一个行动都基于系统中其他部分所做的所有相关决策的上下文。理想情况下，每个行动都应该能看到其他所有东西。不幸的是，由于有限的上下文窗口和实际的权衡，这并不总是可能的，你可能需要决定你愿意为所追求的可靠性水平承担多大的复杂性。

当你思考如何设计智能体架构以避免冲突决策时，这里有一些现实世界的例子可供思考：

• Claude Code的子智能体： 截至2025年6月，Claude Code是一个会生成子任务的智能体范例。然而，它从不与子任务智能体并行工作，并且子任务智能体通常只负责回答一个问题，而不是编写任何代码。为什么？因为子任务智能体缺乏主智能体的上下文，而这些上下文对于执行任何超出回答一个定义明确的问题之外的任务都是必需的。而且，如果它们并行运行多个子智能体，它们可能会给出相互矛盾的响应，导致我们之前例子中看到的可靠性问题。Claude Code的设计者刻意采取了一种简单的方法。

• 编辑-应用模型（Edit Apply Models）： 在2024年，许多模型在编辑代码方面表现很差。编码智能体、IDE、应用构建器等（包括Devin）中一个常见的做法是使用“编辑-应用模型”。其核心思想是，让一个小模型根据你想要的更改的Markdown解释来重写整个文件，实际上比让一个大模型输出格式正确的差异补丁（diff）更可靠。因此，构建者让大模型输出代码编辑的Markdown解释，然后将这些解释提供给小模型来实际重写文件。然而，这些系统仍然非常容易出错。例如，小模型常常会因为指令中最轻微的含糊不清而误解大模型的指令，从而做出错误的编辑。如今，编辑决策和应用执行更常由单个模型在一次行动中完成。

• 多智能体（Multi-Agents）： 如果我们真的想从系统中获得并行性，你可能会想，让决策者们互相“交谈”并解决问题。

这就是我们人类在出现分歧时的理想做法。如果工程师A的代码与工程师B的代码发生合并冲突，正确的流程是讨论分歧并达成共识。然而，今天的智能体还远不能以比单个智能体高出很多的可靠性，来进行这种风格的长上下文、主动式对话。人类在相互沟通最重要知识方面效率很高，但这种效率需要非凡的智能。

自ChatGPT推出后不久，人们就一直在探索多个智能体相互交互以实现目标的想法。虽然我对智能体之间协作的长期可能性持乐观态度，但很明显，在2025年，运行多个协作的智能体只会导致脆弱的系统。决策最终变得过于分散，上下文无法在智能体之间得到足够彻底的共享。目前，我没有看到有人投入专门的努力来解决这个困难的跨智能体上下文传递问题。我个人认为，随着我们让单线程智能体在与人类沟通方面做得更好，这个问题将迎刃而解。当那一天到来时，它将释放出更大的并行性和效率。

迈向更通用的理论

这些关于上下文工程的观察，仅仅是我们未来可能认为是构建智能体标准原则的开端。还有许多未在此处讨论的挑战和技术。在Cognition，构建智能体是我们思考的一个关键前沿。我们围绕这些我们反复重新学习的原则来构建我们的内部工具和框架，以此来强化这些理念。但我们的理论可能并不完美，我们预计随着领域的发展，情况会发生变化，因此也需要一些灵活性和谦逊。

原文：https://cognition.ai/blog/dont-build-multi-agents