近年来，AIGC与多智能体系统成为热门概念，产品人也开始幻想通过智能体分工合作解决一切问题。但在实际落地中，多智能体常常成为复杂、割裂、难以维护的噩梦。本篇文章将从产品角度揭示：构建多智能体或许并不是通往智能未来的最佳路径，反而可能拖慢协同效率、模糊交互边界。

devin产品发布了一篇文章关于是否需要构建多智能体，讲述了自己的看法。以下是原文翻译。

大语言模型（LLM）智能体的框架一直令人意外地失望。我想根据我们自己的试错经验，提供一些构建智能体的原则，并解释为什么一些诱人的想法在实践中实际上相当糟糕。

上下文工程原理

我们将逐步遵循以下原则：

1. 共享上下文

2. 行动蕴含着隐含的决策

为什么要思考原则？

HTML于1993年问世。2013年，Facebook向世界发布了React。如今到了2025年，React（及其衍生产品）主导着开发者构建网站和应用的方式。为什么呢？因为React不只是编写代码的框架，更是一种理念。通过使用React，你接受了以响应式和模块化模式构建应用的方式，如今人们已将其视为标准要求，但早期的网页开发者并非总能认识到这一点。

在大语言模型（LLM）和构建AI智能体的时代，感觉我们仍在摆弄原生HTML和CSS，摸索如何将它们组合在一起以创造良好的用户体验。除了一些绝对基础的内容外，目前还没有一种构建智能体的单一方法成为标准。

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

话虽如此，如果你刚接触智能体构建，有很多关于如何搭建基础框架的资源[1] [2]$。但在构建严肃的生产应用时，情况就不同了。

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

让我们从可靠性开始讲起。当智能体需要在长时间运行过程中保持可靠，并维持连贯的对话时，你必须采取某些措施来控制复合错误的潜在风险。否则，如果不小心，事情很快就会分崩离析。可靠性的核心在于上下文工程。

上下文工程

到2025年，现有的模型将极其智能。但即使是最聪明的人，如果不了解被要求做的事情的背景，也无法有效地完成工作。“提示工程”这个术语被创造出来，用于描述以理想格式为大语言模型（LLM）聊天机器人编写任务的工作。“上下文工程”则是这一概念的更高层次。它涉及在动态系统中自动完成这项工作。这需要更多的细微差别，实际上是构建AI智能体的工程师的首要任务。

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

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

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

3. 最后将这些结果整合

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

假设你的任务是“制作一个《飞扬的小鸟》克隆版”。

这会被分解为子任务1“制作一个带有绿色管道和碰撞箱的移动游戏背景”和子任务2“制作一只可以上下移动的小鸟”。

结果发现子代理1实际上误解了你的子任务，开始构建一个看起来像《超级马里奥兄弟》的背景。子代理2为你构建了一只鸟，但它看起来不像游戏素材，而且其移动方式与《飞翔的小鸟》中的鸟完全不同。

现在，最终代理只能承担起将这两个沟通失误的结果进行整合的棘手任务。

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

原则 1

共享上下文，并共享完整的代理跟踪信息，而不仅仅是单个消息

让我们再对我们的代理进行一次修订，这次要确保每个代理都有前一个代理的上下文。

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

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

原则2

行动蕴含着隐含的决策，而相互冲突的决策会带来不良后果

我认为原则1和原则2至关重要，而且极少值得违背，因此默认情况下，你应该排除任何不遵守这些原则的智能体架构。你可能觉得这很受限，但实际上仍有很大的空间可供你为智能体探索不同的架构。

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

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

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

在这个领域，我们推出了一个新的大语言模型（LLM），其主要目的是将一系列行动和对话的历史压缩成关键细节、事件和决策。这是一项难以做好的工作。这需要投入精力来确定哪些最终会成为关键信息，并创建一个擅长此任务的系统。根据不同的领域，你甚至可以考虑微调一个较小的模型（事实上，我们在认知公司已经这样做了）。

你得到的好处是一个在处理较长上下文时更有效的代理。不过，最终还是会遇到限制。对于求知欲强的读者，我鼓励你们思考更好的方法来处理任意长的上下文。这最终会是一个相当深奥的问题！

应用原则

如果你是一名智能体构建者，请确保你的智能体的每一个动作都能参考系统其他部分做出的所有相关决策的上下文。理想情况下，每个动作都应该能看到其他所有内容。不幸的是，由于上下文窗口有限和实际权衡，这并不总是可行的，你可能需要根据你所追求的可靠性水平来决定愿意承担何种复杂程度。

当你考虑设计你的智能体以避免决策冲突时，以下是一些值得思考的现实世界示例：

Claude代码子代理

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

编辑应用模型

2024年，许多模型在编辑代码方面表现很差。编码代理、IDE、应用构建器等（包括Devin）的常见做法是使用“编辑应用模型”。其核心思想是，给定你想要的更改的Markdown解释，让一个小模型重写整个文件实际上比让大模型输出格式正确的差异更可靠。因此，构建者让大模型输出代码编辑的Markdown解释，然后将这些Markdown解释提供给小模型，由小模型实际重写文件。然而，这些系统仍然存在很多问题。例如，小模型常常会误解大模型的指令，由于指令中最细微的歧义而进行错误的编辑。如今，编辑决策和应用更多地由单个模型在一个操作中完成。

多智能体

如果我们真的想让系统实现并行性，你可能会想到让决策者们相互“交流”，共同解决问题。

这就是我们人类在意见不合时（在理想世界中）会做的事情。如果工程师A的代码与工程师B的代码产生合并冲突，正确的做法是讨论分歧并达成共识。然而，如今的智能体还不太能够像单智能体那样可靠地进行这种长上下文的主动对话。人类在相互交流最重要的知识方面相当高效，但这种效率需要相当高的智能。

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

迈向更通用的理论

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

欢迎您在app.devin.ai试用我们的产品。如果您希望与我们一同探索这些智能体构建原则，请联系walden@cognition.ai

原文链接：https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering