不要再构建多Agent了

不要再构建多Agent了

david david ●
●
214 次阅读
Agentic 杂谈

在 AI Agent 开发领域，上下文工程 (Context Engineering) 正成为构建可靠长时运行 Agent 的核心方法论。本文由 Cognition 团队撰写，提出了两个关键原则：共享完整的 Agent轨迹而非单条消息，以及识别行动中的隐式决策以避免冲突。文章深入分析了为何 OpenAI Swarm、Microsoft AutoGen 等多 Agent 架构存在固有缺陷——上下文分散导致子 Agent产生相互矛盾的输出。作者推荐采用单线程线性 Agent 架构，并介绍了使用 LLM 压缩对话历史来处理超长上下文的进阶方案。文中还以 Claude Code 子 Agent 设计和 Edit Apply 模型演进为例，展示了这些原则在生产环境中的实际应用。对于希望构建企业级 AI Agent 的开发者而言，这是一份不可多得的架构设计指南。

上下文工程原则

我们将逐步讲解以下原则：

  1. 共享上下文 (Share context)

  2. 行动蕴含隐式决策 (Actions carry implicit decisions)

为什么要思考原则？

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

在 LLM 和构建 AI Agent 的时代，我们仿佛仍在摆弄原始的 HTML 和 CSS，摸索如何将它们拼凑成良好的体验。除了一些最基本的共识外，目前还没有任何一种构建 Agent 的方法成为行业标准。

在某些情况下，像 OpenAI 的 https://github.com/openai/swarm 和 Microsoft 的 https://github.com/microsoft/autogen 这样的库，正在积极推广一些我认为是错误的 Agent构建方式的概念。具体来说，就是使用多 Agent 架构——我会解释原因。

话虽如此，如果你是 Agent 构建的新手，有很多资源可以帮助你搭建基本框架 [1] [2]。但当涉及到构建严肃的生产级应用时，情况就完全不同了。

构建长时运行 Agent 的理论

让我们从可靠性谈起。当 Agent 必须在长时间运行中保持可靠，并维持连贯的对话时，你必须采取某些措施来遏制错误累积的可能性。否则，稍不注意，一切就会迅速崩塌。可靠性的核心是上下文工程。

上下文工程 (Context Engineering)

在 2025 年，现有的模型已经极其智能。但即使是最聪明的人，如果不了解被要求做什么的上下文，也无法有效地完成工作。"提示工程 (Prompt Engineering)"这个术语的出现，是为了描述以理想格式为 LLM 聊天机器人编写任务所需的努力。"上下文工程" 是它的进阶版本。它是在动态系统中自动完成这一过程。这需要更多的细腻考量，实际上是构建 AI Agent 的工程师们的第一要务。

以一种常见的 Agent 类型为例。这个 Agent要完成下面的任务

  1. 将工作分解为多个部分

  2. 启动子 Agent 来处理这些部分

  3. 最后合并这些结果

    https://cdn.sanity.io/images/2mc9cv2v/production/721e44474051c62156e15b5ffb1a249c996f0607-1404x1228.png

这是一种很有吸引力的架构，特别是当你的任务领域包含多个可并行处理的组件时。然而，它非常脆弱。关键的故障点在于：

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

结果，子 Agent 1 实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子 Agent 2 给你做了一只鸟，但它看起来不像游戏素材，移动方式也完全不像 Flappy Bird中的那只。现在，最终的 Agent 只能被迫完成一个令人头疼的任务——将这两个误解的产物拼凑在一起。

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

原则 1

共享上下文，并且共享完整的 Agent 轨迹，而不仅仅是单条消息

让我们再次修改我们的 Agent 设计，这次确保每个 Agent 都拥有之前 Agent 的上下文。

e3bdf57c10a9b6c4531b93a10fb79a712464c712-1408x1232.png

不幸的是，我们还没有完全脱离困境。当你给 Agent 同样的 Flappy Bird 克隆任务时，这一次，你可能会得到视觉风格完全不同的小鸟和背景。子 Agent 1 和子 Agent 2无法看到对方在做什么，因此它们的工作最终彼此不一致。

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

原则 2

行动蕴含隐式决策，而相互冲突的决策会导致糟糕的结果

我认为原则 1 和原则 2 是如此关键，如此不值得违反，以至于你应该默认排除任何不遵守它们的 Agent架构。你可能觉得这很有局限性，但实际上，在这些约束下，你仍然可以探索广泛的不同架构空间。

遵循这些原则最简单的方式就是使用单线程线性 Agent：

06f64ae3557594588f702b2608d43564edc98c3d-1404x1230.png

在这种架构中，上下文是连续的。然而，对于非常大的任务，如果子部分太多，你可能会遇到上下文窗口开始溢出的问题。

4a36b048810fb2cba4ee4055ed2d3c80f188befc-1394x1218.png

说实话，这种简单架构能让你走很远，但对于那些真正需要长时间运行的任务，并且愿意付出努力的人来说，你可以做得更好。有几种方法可以解决这个问题，但今天我只介绍其中一种：

836a7407ddf3dfacc0715c0502b4f3ffc7388829-1406x1230.png

在这种架构中，我们引入了一个新的 LLM 模型，其核心目的是将行动和对话的历史压缩为关键细节、事件和决策。这很难做好。你需要投入精力去弄清楚什么最终是关键信息，并创建一个擅长此任务的系统。根据领域不同，你甚至可以考虑微调一个较小的模型（事实上，这是我们在 Cognition 做过的事情）。

你获得的好处是一个在更长上下文中依然有效的 Agent。不过，你最终仍会遇到限制。对于热衷探索的读者，我鼓励你思考更好的方法来管理任意长度的上下文。这最终会是一个相当深的兔子洞！

应用这些原则

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

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

Claude Code 子 Agent

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

Edit Apply 模型

在 2024 年，许多模型在编辑代码方面表现非常糟糕。在编程 Agent、IDE、应用构建器等（包括 Devin）中，一个常见的做法是使用"Edit Apply 模型"。核心思想是：给定一个描述你想要更改的markdown 说明，让一个小模型重写整个文件，实际上比让大模型输出格式正确的 diff 更可靠。因此，构建者让大模型输出代码编辑的 markdown 说明，然后将这些 markdown 说明输入给小模型来实际重写文件。然而，这些系统仍然非常容易出错。例如，小模型经常会因为指令中最轻微的歧义而误解大模型的指令，从而做出错误的编辑。如今，编辑决策和应用更常由单个模型在一个行动中完成。

多Agents

如果我们真的想让系统实现并行化，你可能会想让决策者们相互"交谈"并协调一致。

这就是我们人类在意见不一致时所做的事情（在理想情况下）。如果工程师 A 的代码与工程师 B 产生合并冲突，正确的做法是讨论差异并达成共识。然而，今天的 Agent还不太能够以这种长上下文主动对话的方式进行交流，其可靠性并不比单个 Agent 高多少。人类在相互传达最重要的知识方面相当高效，但这种效率需要非凡的智能。

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

迈向更通用的理论

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

译者注释

在AI发展突飞猛进的时代，这篇文章虽然有些“老‘写于2025年的6月份，但是文中所提出的问题直到今日2026年1月份依然存在。可以说是Agentic应用开发者不可多得的值得学习的文章。

作者并不是反对构建多agents系统，而是指出了多agents系统所存在的问题，以及解决该问题的观点：

  1. 上下文共享，所有的agents都对任务有完整的认知

  2. 上下文压缩，使用最少的tokens传递最多有价值的信息

  3. 对于并行的多agents引发冲突，如何使agents能有效的达成共识，才是解决问题的关键

原文地址：Don’t Build Multi-Agents