Devin联合创始人：别搞多智能体系统！

OpenAI 和 微软正在宣传一些错误的 Agent 理念！OpenAI 的 Swarm 走的是一条“歧路”！

刚刚过去的周末，Devin 联合创始人 Walden Yan 发布了的帖子语出惊人，引起了业界的关注和讨论。

Walden Yan 先是在帖子中含蓄地说道：

我看到很多人在构建智能体时犯了同样的错误，所以我们分享了一些我们常用的原则。

然后再博文中进一步点名 OpenAI 和微软，称两者旗下的 Swarm 和 AutoGen 这两款开源产品库正在积极推广一些错误的代理构建理念，并明确指出是二者所推荐的多代理架构的构建方式是错误的！

Yan 在文章开头直截了当地批评道：

“（现在市面上）多智能体框架的表现远不如预期。我想基于我们的试错经验，分享一些构建智能体的原则，并解释为何一些看似诱人的构想，在实践中却糟糕透顶。”

这篇文章从 Devin 的视角揭示了业内构建 Agent 的现状：多智能体虽然看起来很酷，但 2 年多过去，除了最基本的套路外，依旧仍在匍匐式摸索。

构建Agent，我们仍然处于“原始 HTML + CSS”时代！真正的生产级环境，完全是另外一回事！

Yan 在博文中解释了原因，指出目前的大模型智能体还不具备稳定的长上下文协同对话能力，所以根本不能完成主智能体和子智能体的并行工作，并提出了“共享上下文原则”和“行为暗含决策”两个核心原则的重要性。

此外，Yan 还举了几个不错的有力证据，比如：Claude Code 是一个具有子任务能力的智能体，但它从不并行运行主智能体与子智能体；子智能体通常只用来“回答问题”，不涉及写代码。

可以说，这绝对不是“碰瓷” OpenAI、微软，是有很多真东西输出给了大家。

话不多说，这就为大家奉上原文。

Devin 可以说是自 ChatGPT 诞生以来最早出圈的 AI 编程智能体。近日，Devin 团队发现：其实市面上多智能体框架的表现远不如预期。

许多开发者自然而然地被多智能体（Multi-Agent）架构所吸引，它通过将复杂任务分解给多个并行工作的子智能体来提升效率。然而，这种看似高效的架构实则非常脆弱，容易因上下文共享不充分和决策冲突而导致系统性失败。

Yan 表示：我想基于我们的试错经验，分享一些构建智能体的原则，并解释为何一些看似诱人的构想，在实践中却糟糕透顶。”

“多智能体框架的表现远不如预期。我想基于我们的试错经验，分享一些构建智能体的原则，并解释为何一些看似诱人的构想，在实践中却糟糕透顶。”

HTML 发布于 1993 年。2013 年，Facebook 推出了 React。到了 2025 年，React 及其后代几乎统治了网站与 App 的开发方式。为什么？因为 React 不只是写代码的脚手架，它是一种哲学。你一旦采用 React，就等于接受了响应式、模块化的构建范式。而这一点，对早期的网页开发者而言并非显而易见。

今天，在构建基于大模型的 AI 智能体领域，我们仍然处于“原始 HTML + CSS”时代——还在摸索如何拼凑各种部件，才能打造出良好的体验。目前为止，除了最基本的套路外，还没有一种智能体构建方式成为真正的行业标准。

更糟的是，像 OpenAI 的 Swarm 或 微软的 Autogen 这类库，居然还在鼓吹一种我们认为错误的架构方式：多智能体架构。我会解释为什么这是一条歧路。

当然，如果你是初学者，依然有很多资源可以帮助你搭好基本结构，但构建严肃的生产级应用，完全是另一回事。

让我们从可靠性讲起。当智能体需要长时间运行、并维持连贯的对话与行为时，必须采取某些机制来避免错误的逐步积累——否则系统会很快崩溃。而这一切的核心，就是我们所说的：上下文工程。

到了 2025 年，大模型已经非常聪明。但即使是最聪明的人，如果没有上下文，也无法高效完成任务。

“Prompt Engineering（提示工程）”这一术语最初是指手动设计任务提示。而“Context Engineering（上下文工程）”是它的进阶版，强调在一个动态系统中自动构建上下文。这是构建 AI 智能体时最重要的工程任务。

一个常见架构的例子：

这种方式对拥有并行组件的任务看上去很诱人，但实际上非常脆弱。

比如任务是“构建 Flappy Bird 游戏的克隆版”。你拆成两个子任务：

子任务1：制作背景与绿色管道；

子任务2：制作可上下飞的鸟。

然而子智能体 1 弄错了，做了一个超级马里奥风格的背景；子智能体 2 做的鸟不但不符合游戏资产的风格，行为也不对。最后主智能体要把这两个“不搭调”的结果硬拼在一起，几乎是灾难。

这不是瞎编，现实世界中的任务往往充满细节和歧义。而你可能会以为“把原始任务上下文也发给子智能体”就可以解决问题？不够的。因为真实系统往往是多轮对话，工具调用混杂，任何一个细节都可能影响任务理解。

重新设计你的系统，确保每个子智能体都拥有前一个智能体的上下文轨迹。

但问题还没完。如果你给同样的任务，这次可能得到了风格完全不一致的背景和鸟。为什么？因为子智能体之间看不到彼此的工作过程，于是默认了互相矛盾的隐含前提。

我想强调：原则1与原则2极其关键，几乎不应被打破。

任何违背这两个原则的架构，默认都应被淘汰。

你可能会觉得这限制太多，但实际上还有很多架构设计空间可以探索。比如最简单的一种方式：线性单线程智能体。

优点是上下文连续。问题是：当任务巨大、上下文窗口溢出，就会出问题。

有没有办法改进？当然有，只是更复杂一些。

说实话，简单的架构已经足够了，但对于那些真正需要处理长期任务，并且愿意付出努力的人来说，还可以做得更好。解决这个问题的方法有很多，但今天我只介绍构建更强长时智能体的一种方式——

我们引入一个专门的 LLM 模型，用于“压缩”历史上下文，将其提炼为关键的事件、决策和信息。这件事非常难，需要你理解什么才是真正重要的信息，并建立一个擅长提炼的系统。

有时你甚至需要微调一个小模型来做这件事——我们在 Cognition 就做过这类工作。

它的好处是：可以在更长时间尺度上保持上下文一致性。尽管最终还是会遇到极限，但这是往前迈出的一大步。

作为智能体构建者，你应该确保系统中每个行为，都能基于已有决策的上下文来执行。

理想状态是：所有动作彼此可见。但由于上下文窗口与资源限制，这并不总是可行。所以你需要在“可靠性 vs 系统复杂度”之间做出权衡。

以下是一些现实例子：

截至 2025 年 6 月，Claude Code 是一个具有子任务能力的智能体。但它从不并行运行主智能体与子智能体。子智能体通常只用来“回答问题”，不涉及写代码。

为什么？因为子智能体缺乏主智能体的上下文，无法胜任复杂任务。若运行多个子智能体，很可能得到互相冲突的答案。

这样设计的好处是：子智能体的查询不会污染主智能体的历史，可让主智能体保留更长的上下文轨迹。

Claude Code 的设计者有意选择了简单可靠的设计。

2024 年，很多模型还不擅长修改代码。于是流行一种叫“Edit-Apply Model”的做法：

虽然这比大模型直接输出代码 diff 更靠谱，但也有问题：小模型可能误解说明中的歧义，从而做出错误修改。

到了 2025 年，越来越多的系统选择将“改动决策 + 应用改动”合并为一个步骤，由单个模型完成，提高了整体可靠性。

你可能会想：我们能不能让多个决策者“交流”，像人类一样沟通、达成一致？

理论上好，但目前的大模型智能体还不具备稳定的长上下文协同对话能力。人类的高效沟通靠的是复杂的元认知与语言技巧，这不是现在智能体擅长的。

多智能体概念早在 ChatGPT 时代就开始流行了。但截至 2025 年，这种系统仍然非常脆弱：决策分散、上下文共享困难、容错率低。

我相信未来单智能体能力提升后，智能体之间的高效协作将“顺带实现”，那将是并行性和效率的大突破。

这些关于“上下文工程”的原则，可能会成为未来构建智能体的标准方法论的一部分。

我们在 Cognition 内部不断将这些原则落实在工具和框架中，也在不断试错、迭代。当然，我们的理论也不是完美的，领域在发展，我们也需保持灵活性和谦逊。

网友：我们还要更多

这篇文章引起了不少构建智能体的人士的共鸣。“看来不止我一个人遇到了这些问题！”

甚至以为以为Devin的同事忍不住劝这位口无遮拦的老板：嘿，老板，别泄密呀！

也有网友认为，文中提到的一些观点有待商榷。比如文中讨论的主从代理并行处理的缺点。有网友认为：

这些缺点可能只适用于代码编辑领域。只要任务具有清晰的输入和输出、无副作用且只需有限的上下文传递，就应该能够协调好它们之间的执行，这和构建数据流水线和函数式编程是一样的道理。

还有一位网友支持这种观点。

“这将特定于域和子代理。但一个简单的方法是首先传入完整的上下文窗口，并在子代理完成时确定关键部分是什么。”

用于构建特定于任务的系统提示以进行上下文压缩。 对获取完整提示和压缩提示的代理运行 A/B 测试。如果发现差异，可以询问使用完整提示的代理，是什么导致它执行了不同的部分。并将这些差异合并到压缩提示中。这可以通过广泛使用 AI 来实现自动化。

最终，A/B 版本应该会趋于一致。 这样你可以继续使用系统提示和模型来压缩上下文，或者您可以从此上下文压缩工具收集样本来微调模型并加快速度并节省一些钱。

这位网友还表示：如果你使用像 o3 这样的模型，那么模型对于为什么能够或不能完成某项任务的推理会非常好，只需向他们询问如何改进事情的想法就可以取得很大进展。

一位网友更是直接在 Claude Research 上实际测试了一番：截图上显示，非编程任务上，大模型还是可以 hold 住 5 个并行运行的智能体的！

“尝试了一下 Claude Research，在非编程任务上它会同时运行 5 个（子任务）。结论也很自然：混合式架构才是正解。”

关于这一点，Yan 有些怀疑，并解释道：

“并行读取（readonly）文件的确问题不大，但我怀疑它其实只是一个传统工具，用来收集多个信息源，供主智能体进行综合。”

除此之外，网友的讨论中还有两个分歧点：其一是LLM 执行摘要提取（trace distillation）是否可靠？

网友 EddyLeeKhane 持否定态度，他认为压缩历史上下文容易出现“幻觉”和错判关键点，反而破坏上下文。

当然，不少评论者则默认为这是向长任务扩展的可行方法。

不过据小编了解，压缩历史是否比“强上下文保持”更有效，尚无统一答案，依赖具体模型表现和 trace 设计。

其二，单线程的智能体是否过于限制性能？

网友Adam Butler 提出质疑：单线程限制了并发处理的能力，未来必须依赖 o3 甚至更快模型才能实用。这也是 Yan 文中的观点——目前单智能体的性能还不够好和稳定。

好了，只能说现在的代理构建技术，还有很长很远的路要走。不过也正因如此，我们也看到了前所未有的创新的机会，比如 Anthropic 的 MCP，正在解决智能体跟工具之间的调用问题，再比如谷歌的 A2A 协议，再比如今天 Devin 提到的“上下文工程”，又何尝不是一种新希望呢？

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