一句话定性：这篇文章正面否定了多智能体架构，并给出两条可以直接拿来审查自己 Agent 设计的原则。
最值得拿走的是两条原则：第一，共享上下文，且要共享完整的 Agent 轨迹而不是零散的单条消息；第二，行动携带隐含决策，冲突的决策会产出糟糕的结果。最容易误用的地方有两处：一是以为把原始任务原样复制给子智能体就能避免误解，但真实生产系统中多轮对话和中间工具调用会不断改变任务解读；二是以为让多个决策者互相对话就能解决冲突，而今天的模型尚不具备这种长上下文主动式讨论所需的智能。文中 Claude Code 子代理与编辑应用模型两个案例，展示了在不违背原则的前提下如何获得子代理与独立编辑模型的收益。
中文读者为什么要读：国内 Agent 开发热度极高，多智能体框架被大量照搬，这篇来自 Devin 生产一线的反向判断是极好的清醒剂，可与站内《多智能体到底什么在起作用》对照阅读。国内语境下还需叠加一层：不少团队按组织分工把系统切成多个 Agent 并行开发，这种结构恰恰最容易违反共享上下文原则，值得先用这两条原则自查架构。
行动建议：把你当前的 Agent 架构图拿出来，逐个行动检查它能否看到系统中其他部分的相关决策，凡是不能的，标出来重新设计。
—— FDEChina编辑部 · 犀利评审
上下文工程的原则（Principles of Context Engineering）。我们会一路推导出下面这两条原则：
- 共享上下文（Share context）
- 行动携带隐含决策（Actions carry implicit decisions）
为什么要去思考原则？
HTML 诞生于 1993 年。2013 年，Facebook 向世界发布了 React。如今已是 2025 年，React（以及它的各路后继者）主导着开发者构建网站与应用的方式。为什么？因为 React 不只是一套写代码用的脚手架，它是一种哲学。选择 React，意味着你接受了以「响应式与模块化」的模式来构建应用——今天人们已经把它当作理所当然的标准要求，但对早期的 Web 开发者来说，这一点并非一直显而易见。
在 LLM 与 AI Agent 的时代，我们的处境仿佛还停留在玩弄原始 HTML 与 CSS 的阶段，正在摸索如何把它们拼装出好的体验。除了少数绝对基础性的共识之外，构建 Agent 还没有哪一种方法成为标准。某些情况下，OpenAI 的 Swarm 和微软的 AutoGen 这类库甚至在积极推广一些我认为属于错误构建方式的概念——具体来说就是多智能体（multi-agent）架构。我会在下文解释为什么。
话虽如此，如果你刚入门 Agent 构建，关于如何搭建基础脚手架的资源已经很多 [1][2]。但当你要构建的是严肃的生产级应用时，就是另一回事了。
一个关于构建长时程 Agent 的理论
先从可靠性说起。当 Agent 必须在长时间运行中真正可靠、并维持连贯的对话时，你必须采取某些做法来抑制误差不断叠加（compounding errors）的可能性；否则稍不留神，事情会迅速崩坏。而可靠性的核心，正是上下文工程（Context Engineering）。
上下文工程
在 2025 年，市面上的模型已经极其聪明。但即便是绝顶聪明的人，如果缺少「要他做什么」的上下文，也无法有效地完成工作。「提示词工程（prompt engineering）」这个词，描述的是为 LLM 聊天机器人把任务写成理想格式所需的功夫；「上下文工程」是它的下一个层级：在一个动态系统中自动地做到这件事。它需要更多细微的功夫，而它实际上就是构建 AI Agent 的工程师的头号工作。
以一类常见的 Agent 为例。这类 Agent 会：
- 把工作拆成多个部分
- 启动子智能体（subagent）分别处理这些部分
- 最后把结果合并起来
这是一个很有诱惑力的架构，尤其当你的任务领域天然带有多个可并行的组件时。然而，它非常脆弱。关键失败点在这里：假设你的任务是「构建一个 Flappy Bird 克隆」，它被拆分为子任务 1「构建带绿色管道与碰撞盒的滚动游戏背景」和子任务 2「构建一只可以上下移动的鸟」。
（图：原始任务被拆成两个子任务，分别交给两个子智能体执行，最后由一个合并步骤把结果拼回一起。）
结果，子智能体 1 实际上理解错了自己的子任务，开始构建一个看起来像《超级马力欧兄弟》的背景；子智能体 2 给你造了一只鸟，但它看上去不像游戏素材，动起来的方式也和 Flappy Bird 里那只相去甚远。于是最终那个 Agent 只剩下一件苦差事：把这两次沟通失败的结果拼合到一起。
这听起来可能有点刻意，但现实世界的任务带有层层叠叠的细节，每一层都有被误传的可能。你也许会想，简单的解法就是把原始任务也复制一份、作为上下文一并交给子智能体，这样它们就不会误解各自的子任务。但请记住：在真实的生产系统里，对话大概率是多轮的，Agent 可能已经做过若干次工具调用才决定如何拆分任务，而任何数量的细节都可能影响对任务的解读。
原则一：共享上下文，并且共享完整的 Agent 轨迹，而不只是单条消息
我们再改造一次前面的 Agent，这一次确保每个 Agent 都能拿到之前那些 Agent 的上下文。
（图：两个子智能体各自带着彼此的轨迹工作，但产出仍然不一致。）
遗憾的是，我们并没有因此脱险。当你把同一个 Flappy Bird 克隆任务交给它，这次你可能会得到一只鸟和一个背景，但两者的视觉风格完全不同。子智能体 1 与子智能体 2 看不到对方正在做什么，所以它们的工作成果彼此不一致。
子智能体 1 采取的行动与子智能体 2 采取的行动，各自建立在事先未被规定、且相互冲突的假设之上。
原则二：行动携带隐含决策，而冲突的决策会带来糟糕的结果
我想说的是：原则一与原则二至关重要，以至于几乎从不值得被违反——你应该默认排除任何不遵守它们的 Agent 架构。你可能觉得这是一种束缚，但实际上，仍然有一片广阔的架构空间等待你去探索。
遵守这两条原则的最简单方式，就是使用单线程线性 Agent：
（图：单个 Agent 顺序完成任务，上下文在全程中连续传递，没有任何信息被截断或丢失。）
在这种架构里，上下文是连续的。但对于子部件多到上下文窗口开始溢出的超大型任务，你会遇到困难。
说实话，这个简单架构已经能带你走得很远；但如果你手上真的有超长时程的任务，并且愿意投入精力，你还可以做得更好。解法有好几种，今天我只介绍其中一种：
（图：引入一个压缩模型，把行动与对话历史压缩成关键细节、事件与决策。）
在这个方案里，我们引入一个新的 LLM 模型，它的核心职责是把行动与对话的历史压缩成关键细节、事件与决策。这件事很难做对：需要投入精力弄清楚究竟什么才是关键信息，并构建一个擅长此事的系统。视领域而定，你甚至可以考虑对一个小模型做微调（我们在 Cognition 内部实际上就是这么做的）。
你得到的回报，是一个在更长上下文下依然有效的 Agent。不过你最终仍会撞上某个上限。对于热心的读者，我鼓励你去想出管理任意长上下文的更好办法——这最终是一个相当深的兔子洞！
把原则落到实处
如果你在构建 Agent，请确保它的每一个行动，都参考了系统中其他部分所做出的全部相关决策。理想状态下，每个行动都能直接看到其他一切行动。遗憾的是，受限于有限的上下文窗口与现实中的种种权衡，这并不总是可能的；你可能需要在自己愿意承担的复杂度与想要达到的可靠性水平之间做出取舍。
在你思考如何设计 Agent 架构以避免决策冲突时，这里有几个真实世界的案例供你琢磨：
Claude Code 的子智能体
截至 2025 年 6 月，Claude Code 是一个会派生子任务的 Agent 案例。不过，它从不与子任务代理并行工作，而且子任务代理通常只被要求回答一个问题，并不写任何代码。为什么？因为子任务代理缺少来自主 Agent 的上下文——缺少这些上下文，它无法可靠地完成「回答一个定义清晰的问题」之外的任何事情。而如果并行运行多个子智能体，它们可能给出相互冲突的回应，造成我们前面例子中看到的那类可靠性问题。在这种情况下使用子代理的好处是：子代理所做的全部调查性工作不必留在主 Agent 的历史里，从而让主 Agent 在上下文耗尽之前能走得更远。Claude Code 的设计者采取了一个刻意从简的方案。
编辑应用模型（Edit Apply Models）
2024 年，许多模型在编辑代码这件事上表现糟糕。各类编码 Agent、IDE、应用构建器（包括 Devin）的一种常见做法，是使用「编辑应用模型（edit apply model）」。其核心想法是：给一个小模型一份 markdown 格式的修改说明、让它重写整个文件，实际上比让一个大模型直接输出格式正确的 diff 更可靠。于是构建者让大模型输出代码修改的 markdown 说明，再把这些说明喂给小模型去真正重写文件。然而这类系统仍然毛病不断：比如小模型经常误读大模型的指令，仅仅因为说明中最轻微的歧义就做出错误的修改。如今，编辑的决策与应用更多是由单一模型在一个动作内完成的。
多智能体
如果你真的想从系统中榨出并行度，你可能会想到让各个决策者相互「交谈」，把分歧协商清楚。
（图：多个决策型 Agent 之间相互通信的架构示意。）
这正是我们人类在有分歧时的做法（在理想世界里）。如果工程师 A 的代码与工程师 B 的代码产生合并冲突，正确的流程是谈拢分歧、达成共识。然而今天的 Agent 还做不到这种长上下文的主动式讨论，其可靠性并不比单个 Agent 高出多少。人类在彼此传递最重要的知识时相当高效，但这种效率本身需要可观的智能来支撑。
自 ChatGPT 发布后不久，人们就一直在探索让多个 Agent 相互协作以达成目标的想法 [3][4]。虽然我对 Agent 之间长期协作的可能性保持乐观，但显而易见：在 2025 年，让多个 Agent 协同运行只会得到脆弱的系统。决策过于分散，上下文也无法在 Agent 之间被足够彻底地共享。目前我还没有看到有人在专门下功夫攻克这个困难的跨 Agent 上下文传递问题。我个人认为，随着我们把单线程 Agent 打磨得更擅长与人类沟通，这个能力会随之「免费」到来。到那一天，它将解锁多得多的并行度与效率。
迈向更通用的理论
这些关于上下文工程的观察，只是起点——未来某天，它们或许会被视为构建 Agent 的标准原则的一部分。此外还有许多这里没有讨论到的挑战与技术。在 Cognition，构建 Agent 是我们持续思考的关键前沿。我们围绕这些一再被自己重新领会的原则来搭建内部工具与框架，以此把理念固化下来。但我们的理论很可能并不完美，我们也预期随着领域前进，事情会发生变化，因此同样需要一些灵活性与谦逊。
欢迎到 app.devin.ai 试用我们的工作。如果你也乐意和我们一起发现这些构建 Agent 的原则，欢迎联系 Walden Yan（Cognition）。
延伸阅读
关于多智能体架构的另一面，即哪些多 Agent 实践确实有效，参见站内《多智能体到底什么在起作用》；系统性地了解 Agent 架构与上下文管理，可到 Agent 主题页查阅；如果你正在用编码类 Agent 改造日常工作流，参见 AI Coding 主题页；更多可上手的工程方法，见 FDE 实战指南。
本文由 FDEChina 团队翻译自原文，转载已注明出处；如需引用请以原文为准。