【译】不要构建多智能体 (Multi-Agents)
为大型语言模型 (LLM) 智能体设计的框架出人意料地令人失望。我想根据我们自身的反复试错，为构建智能体提供一些原则，并解释为什么一些看似诱人的想法在实践中其实相当糟糕。
上下文工程的原则
我们将逐步引出以下原则：
- 共享上下文
- 行动承载隐性决策
为什么要思考原则？
HTML 于 1993 年问世。2013 年，Facebook 向世界发布了 React。如今已是 2025 年，React（及其衍生品）主导了开发者构建网站和应用的方式。为什么？因为 React 不仅仅是一个编写代码的脚手架，它是一种哲学。通过使用 React，你接纳了以一种响应式和模块化的模式来构建应用程序，这在今天被人们认为是标准要求，但对于早期的 Web 开发者来说，这并非总是显而易见。
在大型语言模型和构建 AI 智能体的时代，感觉我们仍然在摆弄原始的 HTML & CSS，并试图弄清楚如何将它们组合起来以创造良好的体验。除了某些绝对基础的东西之外，还没有任何一种构建智能体的方法成为标准。
在某些情况下，像 OpenAI 的 https://github.com/openai/swarm 和微软的 https://github.com/microsoft/autogen 这样的库，甚至在积极推广一些我认为是错误的智能体构建方式。具体来说，就是使用多智能体架构，我将解释原因。
话虽如此，如果你是构建智能体的新手，有很多关于如何搭建基本脚手架的资源 [1] [2]。但当涉及到构建严肃的生产级应用时，情况就完全不同了。
构建长时运行智能体的理论
让我们从可靠性开始。当智能体必须在长时间运行并保持连贯对话的同时保持可靠性时，你必须采取某些措施来控制复合错误的潜在风险。否则，如果你不小心，事情很快就会分崩离析。可靠性的核心是上下文工程 (Context Engineering)。
上下文工程
在 2025 年，市面上的模型都极其智能。但即使是最聪明的人，如果缺乏对任务要求的上下文理解，也无法有效地完成工作。“提示工程 (Prompt engineering)” 这个术语是为了描述为大型语言模型聊天机器人以理想格式编写任务所需的工作。而“上下文工程 (Context engineering)” 则是 bunun下一个层次。它关乎在一个动态系统中自动完成这项工作。这需要更精细的技巧，并且实际上是构建 AI 智能体工程师的头号工作。
举一个常见智能体类型的例子。这个智能体：
- 将其工作分解为多个部分
- 启动子智能体来处理这些部分
- 最后将这些结果合并
这是一个诱人的架构，特别是如果你处理的任务领域包含多个并行组件。然而，它非常脆弱。关键的失败点在于：
假设你的任务是“构建一个 Flappy Bird 的克隆版”。这被分解为子任务 1“构建一个带有绿色管道和碰撞箱的移动游戏背景”和子任务 2“构建一只可以上下移动的小鸟”。
结果，子智能体 1 实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子智能体 2 为你构建了一只鸟，但它看起来不像游戏素材，并且其移动方式也与 Flappy Bird 中的完全不同。现在，最终的智能体只能面对合并这两个沟通失误产物的棘手任务。
这可能看起来有些牵强，但大多数现实世界的任务都有许多层次的细微差别，所有这些都有可能被误传。你可能会认为一个简单的解决方案是，将原始任务也作为上下文复制给子智能体。这样，它们就不会误解自己的子任务了。但请记住，在一个真实的生产系统中，对话很可能是多轮的，智能体可能需要进行一些工具调用来决定如何分解任务，并且任何数量的细节都可能对任务的解释产生影响。
原则 1
共享上下文，并且共享完整的智能体轨迹，而不仅仅是单个消息
让我们再对我们的智能体进行一次修正，这次确保每个智能体都拥有前一个智能体的上下文。
不幸的是，我们还没有完全走出困境。当你给智能体同样的 Flappy Bird 克隆任务时，这次你可能会得到一只鸟和一个背景，它们的视觉风格完全不同。子智能体 1 和子智能体 2 无法看到对方在做什么，因此它们的工作最终会彼此不一致。
子智能体 1 采取的行动和子智能体 2 采取的行动是基于事先未明确规定的相互冲突的假设。
原则 2
行动承载隐性决策，而冲突的决策会导致糟糕的结果
我认为原则 1 和原则 2 至关重要，并且极少值得违背，因此你应该默认排除任何不遵守它们的智能体架构。你可能觉得这很有约束性，但实际上你仍然可以在此基础上探索各种不同的智能体架构。
遵循这些原则最简单的方法是只使用一个单线程的线性智能体：
在这里，上下文是连续的。然而，对于子部分非常多的大型任务，你可能会遇到上下文窗口溢出的问题。
老实说，简单的架构能让你走得很远，但对于那些任务持续时间真的很长，并且愿意投入精力的人来说，你可以做得更好。有几种方法可以解决这个问题，但今天我只介绍一种：
在这个世界里，我们引入一个新的 LLM 模型，其关键目的是将行动和对话的历史压缩成关键细节、事件和决策。这很难做到恰到好处。需要投入精力去弄清楚哪些信息是关键信息，并创建一个擅长此事的系统。根据领域的不同，你甚至可以考虑微调一个较小的模型（这实际上是我们在 Cognition 做过的事情）。
你得到的好处是一个在更长上下文中更有效的智能体。不过，你最终还是会达到一个极限。对于热衷于阅读的读者，我鼓励你们思考更好的方法来管理任意长的上下文。这最终会成为一个相当深的兔子洞！
应用原则
如果你是一位智能体构建者，请确保你的智能体的每一个行动都基于系统中其他部分所做的所有相关决策的上下文。理想情况下，每个行动都应该能看到其他所有信息。不幸的是，由于有限的上下文窗口和实际的权衡，这并不总是可能，你可能需要决定你愿意为达到的可靠性水平承担多大的复杂性。
当你思考如何架构你的智能体以避免冲突的决策时，这里有一些现实世界的例子可供参考：
Claude 代码子智能体
截至 2025 年 6 月，Claude Code 是一个会产生子任务的智能体示例。然而，它从不与子任务智能体并行工作，并且子任务智能体通常只负责回答问题，而不编写任何代码。为什么？子任务智能体缺乏主智能体的上下文，而这些上下文对于执行超越回答明确定义问题之外的任何事情都是必需的。而且，如果它们要运行多个并行的子智能体，它们可能会给出相互冲突的响应，导致我们之前智能体示例中看到的可靠性问题。在这种情况下，拥有子智能体的好处是，所有子智能体的调查工作都不需要保留在主智能体的历史中，从而在耗尽上下文之前允许更长的轨迹。Claude Code 的设计者采取了一种刻意简化的方法。
编辑-应用模型
在 2024 年，许多模型在编辑代码方面表现很差。编码智能体、IDE、应用构建器等（包括 Devin）的常见做法是使用“编辑-应用模型”。其核心思想是，让一个小模型根据你想要的更改的 markdown 解释来重写整个文件，实际上比让一个大模型输出格式正确的 diff 更可靠。因此，构建者让大模型输出代码编辑的 markdown 解释，然后将这些 markdown 解释提供给小模型来实际重写文件。然而，这些系统仍然会有很多缺陷。例如，小模型常常会因为指令中最轻微的含糊之处而误解大模型的指令，从而做出不正确的编辑。如今，编辑决策和应用更多地由单个模型在一个动作中完成。
多智能体
如果我们真的想从我们的系统中获得并行性，你可能会想让决策者互相“交谈”并解决问题。
这是我们人类在意见不合时所做的事情（在理想世界中）。如果工程师 A 的代码与工程师 B 的代码发生合并冲突，正确的协议是讨论分歧并达成共识。然而，今天的智能体还不能以比单个智能体高出多少的可靠性，来进行这种长上下文、主动性的话语交流。人类在相互交流我们最重要的知识方面相当高效，但这种效率需要不可忽视的智能。
自从 ChatGPT 推出后不久，人们就一直在探索多个智能体相互交互以实现目标的想法 [3][4]。虽然我对智能体相互协作的长期可能性持乐观态度，但很明显，在 2025 年，运行多个协作的智能体只会导致脆弱的系统。决策最终会过于分散，上下文无法在智能体之间充分共享。目前，我没有看到有人投入专门的努力来解决这个困难的跨智能体上下文传递问题。我个人认为，随着我们让单线程智能体在与人类沟通方面做得更好，这个问题会迎刃而解。当这一天到来时，它将解锁更大程度的并行性和效率。
迈向更通用的理论
这些关于上下文工程的观察，仅仅是我们有朝一日可能认为是构建智能体标准原则的开始。还有许多挑战和技术本文没有讨论。在 Cognition，构建智能体是我们思考的一个关键前沿领域。我们围绕这些我们反复发现自己需要重新学习的原则来构建我们的内部工具和框架，以此来强化这些想法。但我们的理论可能并不完美，我们预计随着领域的发展，情况会发生变化，因此也需要一些灵活性和谦逊。
原文：https://cognition.ai/blog/dont-build-multi-agents
【非原文内容】学习总结
本文探讨了构建可靠的大型语言模型 (LLM) 智能体的核心原则，并对当前流行的多智能体架构提出了批评。作者认为，多智能体系统因上下文共享不足和决策冲突而非常脆弱，容易导致复合错误。
文章提出了两个核心原则：“共享上下文”和“行动承载隐性决策”，强调应让智能体的每个行动都基于完整的历史轨迹和相关决策。作者推荐从简单的单线程线性智能体架构入手，并为处理超长任务提出了通过一个专门的LLM模型来压缩历史上下文的方案。
最后，文章通过分析 Claude Code、编辑-应用模型等实例，论证了当前多智能体协作的局限性，并指出解决跨智能体上下文传递问题是未来实现高效并行处理的关键。