Context Engineering：不要构建多代理

与Anthropic: 如何构建多智能体研究系统文章中表达的观点不同，这篇来自Devin母公司Cognition的博客从他们自己的实践做了不同的分析，非常值得一读。它提出了一个与当前主流（如AutoGen等框架）相悖的观点：不要构建多代理（Multi-Agent）。

文章的核心在于“上下文工程”（Context Engineering），强调为了保证系统的可靠性，应尽可能共享完整的上下文，避免因信息割裂导致子代理做出相互冲突的决策。这个来自一线的反思视角非常犀利，对于如何构建更稳定的生产级Agent极具参考价值。

以下原文，Enjoy!

LLM 代理框架的表现出人意料地令人失望。我想根据我们自己的试错经验，为构建代理提供一些原则，并解释为什么一些看似诱人的想法在实践中其实相当糟糕。

上下文工程原则

我们将逐步引出以下原则：

1. 1. 共享上下文(Share context)
2. 2. 行动承载隐性决策(Actions carry implicit decisions)

为什么要思考原则？

HTML 于 1993 年问世。2013 年，Facebook 向世界发布了 React。现在是 2025 年，React（及其后继者）主导了开发者构建网站和应用的方式。为什么？因为 React 不仅仅是一个编写代码的脚手架，它是一种哲学。通过使用 React，你接纳了以响应式和模块化的模式来构建应用，人们现在已将其视为标准要求，但这对于早期的 Web 开发者来说并非总是显而易见的。

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

在某些情况下，像 OpenAI 的 https://github.com/openai/swarm 和微软的 https://github.com/microsoft/autogen 这样的库，正在积极推广一些我认为是构建代理的错误方式的概念。也就是使用多代理架构，我将解释原因。

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

构建长时间运行代理(Long-running Agents)的理论

让我们从可靠性说起。当代理必须在长时间运行并保持连贯对话的同时保持可靠时，你必须采取某些措施来控制潜在的累积错误。否则，如果你不小心，事情会很快分崩离析。可靠性的核心是上下文工程。

上下文工程(Context Engineering)

在 2025 年，市面上的模型都极其智能。但即使是最聪明的人，如果缺乏任务所需的上下文，也无法有效地完成工作。“提示工程”（Prompt engineering）这个术语被创造出来，指的是为了让 LLM 聊天机器人能理想地执行任务而需要进行的指令编写工作。“上下文工程”（Context engineering）是其更高一个层次。它关乎在动态系统中自动完成这项工作。这需要更精细的处理，并且实际上是构建 AI 代理的工程师们的首要任务。

以一个常见类型的代理为例。这个代理：

1. 1. 将其工作分解为多个部分
2. 2. 启动子代理来处理这些部分
3. 3. 最后将这些结果合并

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

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

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

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

原则 1
共享上下文(Share context)，并且要共享完整的代理轨迹，而不仅仅是单个消息

让我们再次修改我们的代理架构，这次确保每个代理都拥有前一个代理的上下文。

不幸的是，我们仍未完全摆脱困境。当你给代理同样的 Flappy Bird 克隆任务时，这次，你最终可能会得到一只鸟和一个背景，它们的视觉风格完全不同。子代理 1 和子代理 2 看不到对方在做什么，因此它们的工作成果最终会相互不一致。

子代理 1 和子代理 2 采取的行动是基于事先未明确的、相互冲突的假设。

原则 2
行动承载隐性决策，而冲突的决策会导致糟糕的结果

我认为原则 1 和原则 2 至关重要，几乎不值得去违背，因此你默认就应该排除任何不遵守它们的代理架构。你可能觉得这很有约束性，但实际上，你仍然有广阔的空间去探索适用于你代理的各种不同架构。

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

在这里，上下文是连续的。然而，你可能会在处理非常庞大的任务时遇到问题，这些任务有太多子部分，以至于上下文窗口开始溢出。

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

在这种模式下，我们引入一个新的 LLM 模型，其主要目的是将行动和对话的历史压缩成关键的细节、事件和决策。这很难做到完美。你需要投入精力去弄清楚哪些信息是关键信息，并创建一个擅长此事的系统。根据具体领域，你甚至可以考虑微调一个较小的模型（实际上，我们在 Cognition 就这么做了）。

你得到的好处是一个在更长上下文中同样高效的代理。不过，你最终还是会遇到极限。对于热心的读者，我鼓励你们思考管理任意长度上下文的更好方法。这最终会成为一个相当深的兔子洞！

应用原则

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

在思考如何设计你的代理以避免冲突决策时，这里有一些现实世界的例子值得深思：

Claude Code 子代理

截至 2025 年 6 月，Claude Code 就是一个会生成子任务的代理示例。然而，它从不与子任务代理并行工作，而且子任务代理通常只负责回答问题，而不是编写任何代码。为什么？因为子任务代理缺乏主代理的上下文，而这些上下文对于执行超出回答一个明确定义问题之外的任何事情都是必需的。如果它们要并行运行多个子代理，它们可能会给出相互矛盾的响应，从而导致我们之前代理示例中看到的可靠性问题。在这种情况下，拥有子代理的好处是，子代理的所有调查性工作都不需要保留在主代理的历史记录中，从而允许在耗尽上下文之前有更长的追踪记录。Claude Code 的设计者特意采用了一种简单的方法。

“编辑-应用”模型

在 2024 年，许多模型在编辑代码方面表现非常糟糕。在编码代理、IDE、应用构建器等（包括 Devin）中，一种常见的做法是使用“编辑-应用模型”（edit apply model）。其核心思想是，相比于让一个大模型输出格式正确的 diff，让一个小模型根据你想要的更改的 Markdown 解释来重写整个文件，实际上更可靠。因此，构建者们让大模型输出代码编辑的 Markdown 解释，然后将这些解释提供给小模型来实际重写文件。然而，这些系统仍然会非常容易出错。例如，由于指令中最轻微的模糊性，小模型会误解大模型的指令并进行错误的编辑。如今，编辑决策和应用更多地是由单个模型在一次行动中完成的。

多代理

如果我们真的想从系统中获得并行性，你可能会想让决策者们相互“交谈”并解决问题。

这就是我们人类在意见不合时所做的事情（在理想世界中）。如果工程师 A 的代码与工程师 B 的代码发生合并冲突，正确的流程是讨论分歧并达成共识。然而，今天的代理还无法以比单个代理高得多的可靠性来进行这种长上下文、主动性的对话。人类在相互交流最重要知识方面效率很高，但这种效率需要相当高的智能。

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

迈向更普适的理论

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