用于 LLM Agent 的框架一直以来都令人失望。我想基于我们自己的试错经验，提供一些构建 Agent 的原则，并解释为什么一些看似诱人的想法在实践中其实相当糟糕。
Context Engineering 原则
我们将逐步建立以下原则：
- 共享上下文
- 动作承载隐含决策
为什么要思考原则？
HTML 于1993年推出。2013年，Facebook 向世界发布了 React。现在是2025年，React（及其衍生物）主导着开发者构建网站和应用的方式。为什么？因为 React 不仅仅是编写代码的脚手架，它是一种哲学。通过使用 React，你接受了用响应式和模块化的模式构建应用，这现在被人们认为是标准要求，但对早期的 Web 开发者来说并不总是显而易见的。
在 LLM 和构建 AI Agent 的时代，感觉我们仍在玩原始的 HTML 和 CSS，试图弄清楚如何将这些组合在一起以获得良好的体验。除了一些绝对基础的内容外，还没有单一的构建 Agent 的方法成为标准。
在某些情况下，像 OpenAI 的 github.com/openai/swar… 和 Microsoft 的 github.com/microsoft/a… 这样的库积极推广我认为是构建 Agent 错误方式的概念。即使用多智能体架构，我会解释原因。
也就是说，如果你是 Agent 构建的新手，有很多关于如何设置基本脚手架的资源。但当涉及构建严肃的生产应用时，情况就不同了。
构建长运行 Agent 的理论
让我们从可靠性开始。当 Agent 必须在长时间运行中真正可靠并保持连贯对话时，你必须做某些事情来控制复合错误的可能性。否则，如果你不小心，事情会迅速崩塌。可靠性的核心是 Context Engineering。
Context Engineering
现有的模型极其智能。但即使是最聪明的人，如果没有他们被要求做什么的上下文，也无法有效地完成工作。"Prompt engineering"被创造为为 LLM 聊天机器人以理想格式编写任务所需努力的术语。"Context engineering"是这个的下一个层次。它是关于在动态系统中自动完成这项工作。它需要更多的细致入微，实际上是构建 AI Agent 的工程师的头号工作。
举一个常见类型 Agent 的例子。这个 Agent：
- 将工作分解为多个部分
- 启动子智能体来处理这些部分
- 最后合并这些结果
这是一个诱人的架构，特别是如果你在一个有几个并行组件的任务领域工作。然而，它非常脆弱。关键失败点是这样的：
假设你的任务是"构建一个 Flappy Bird 克隆"。这被分为子任务1"构建一个带有绿色管道和碰撞箱的移动游戏背景"和子任务2"构建一只你可以上下移动的鸟"。
结果子智能体1实际上误解了你的子任务，开始构建一个看起来像超级马里奥兄弟的背景。子智能体2为你构建了一只鸟，但它看起来不像游戏资产，移动也完全不像 Flappy Bird 中的那只。现在最终的 Agent 面临着合并这两个误解的不良任务。
这可能看起来很做作，但大多数现实世界的任务都有许多层次的细微差别，所有这些都有被误解的潜力。你可能认为一个简单的解决方案就是将原始任务作为上下文也复制给子智能体。这样，它们就不会误解它们的子任务。但请记住，在真正的生产系统中，对话很可能是多轮的，Agent 可能必须进行一些工具调用来决定如何分解任务，任何数量的细节都可能对任务的解释产生后果。
原则1
共享上下文，并共享完整的 Agent 轨迹，而不仅仅是单个消息
让我们对我们的 Agent 进行另一次修订，这次确保每个 Agent 都有前一个 Agent 的上下文。
不幸的是，我们还没有完全脱离困境。当你给你的 Agent 同样的 Flappy Bird 克隆任务时，这次，你可能最终得到一只鸟和背景的视觉风格完全不同。子智能体1和子智能体2无法看到对方在做什么，所以它们的工作最终彼此不一致。
子智能体1采取的行动和子智能体2采取的行动是基于事先未规定的冲突假设。
原则2
动作承载隐含决策，冲突的决策带来糟糕的结果
我认为原则1和2是如此关键，很少值得违反，以至于你应该默认排除任何不遵守它们的 Agent 架构。你可能认为这是限制性的，但实际上你仍然可以为你的 Agent 探索各种不同架构的广阔空间。
遵循这些原则的最简单方法就是使用单线程线性 Agent：
在这里，上下文是连续的。然而，对于有如此多子部分的非常大的任务，你可能会遇到上下文窗口开始溢出的问题。
说实话，简单的架构会让你走得很远，但对于那些真正有长期任务并愿意付出努力的人，你可以做得更好。有几种方法可以解决这个问题，但今天我只介绍一种：
在这个世界中，我们引入了一个新的 LLM 模型，其关键目的是将动作和对话的历史压缩成关键细节、事件和决策。这很难做对。需要投入精力弄清楚什么最终是关键信息，并创建一个擅长这个的系统。根据领域的不同，你甚至可能考虑微调一个较小的模型（这实际上是我们在 Cognition 做过的事情）。
你得到的好处是一个在较长上下文中有效的 Agent。不过你仍然会最终达到一个限制。对于热心的读者，我鼓励你思考管理任意长上下文的更好方法。最终会是一个相当深的兔子洞！
原则的应用
如果你是一个 Agent 构建者，请确保你的 Agent 的每个动作都由系统其他部分做出的所有相关决策的上下文来通知。理想情况下，每个动作都应该看到其他一切。不幸的是，由于有限的上下文窗口和实际权衡，这并不总是可能的，你可能需要决定你愿意为你追求的可靠性水平承担什么复杂性水平。
当你考虑架构你的 Agent 以避免冲突的决策制定时，这里有一些现实世界的例子供思考：
Claude Code 子智能体
截至2025年6月，Claude Code 是一个产生子任务的 Agent 的例子。然而，它从不与子任务 Agent 并行工作，子任务 Agent 通常只被任务回答问题，而不是编写任何代码。为什么？子任务 Agent 缺乏来自主 Agent 的上下文，否则需要这些上下文来做任何超出回答明确定义问题的事情。如果他们要运行多个并行子智能体，他们可能会给出冲突的响应，导致我们在早期 Agent 例子中看到的可靠性问题。在这种情况下拥有子智能体的好处是，所有子智能体的调查工作不需要保留在主 Agent 的历史中，允许在用完上下文之前有更长的轨迹。Claude Code 的设计者采取了故意简单的方法。
Edit Apply 模型
在2024年，许多模型在编辑代码方面真的很糟糕。编码 Agent、IDE、应用构建器等（包括 Devin）的常见做法是使用"edit apply 模型"。关键思想是，实际上让一个小模型重写你的整个文件，给定你想要的更改的 markdown 解释，比让一个大模型输出格式正确的 diff 更可靠。所以，构建者让大模型输出代码编辑的 markdown 解释，然后将这些 markdown 解释馈送给小模型来实际重写文件。然而，这些系统仍然会非常有缺陷。例如，小模型经常会误解大模型的指令，由于指令中最轻微的歧义而进行不正确的编辑。今天，编辑决策制定和应用更经常由单个模型在一个动作中完成。
多智能体
如果我们真的想从我们的系统中获得并行性，你可能认为让决策制定者彼此"交谈"并解决问题。
这是我们人类在不同意时所做的（在理想世界中）。如果工程师A的代码与工程师B的代码造成合并冲突，正确的协议是讨论差异并达成共识。然而，今天的 Agent 还不太能够以比你用单个 Agent 获得的可靠性更高的可靠性参与这种长上下文主动话语。人类在向彼此传达我们最重要的知识方面非常高效，但这种效率需要非平凡的智能。
自 ChatGPT 推出后不久，人们就一直在探索多个 Agent 相互交互以实现目标的想法。虽然我对 Agent 彼此协作的长期可能性持乐观态度，但很明显，在2025年，运行多个 Agent 协作只会导致脆弱的系统。决策制定最终过于分散，上下文无法在 Agent 之间充分共享。目前，我没有看到任何人专门努力解决这个困难的跨 Agent 上下文传递问题。我个人认为，当我们让我们的单线程 Agent 在与人类交流方面变得更好时，这会免费获得。当这一天到来时，它将解锁更大量的并行性和效率。
向更一般的理论发展
这些关于 Context Engineering 的观察只是我们有一天可能认为的构建 Agent 标准原则的开始。还有许多这里没有讨论的挑战和技术。在 Cognition，Agent 构建是我们思考的关键前沿。我们围绕这些我们反复发现自己重新学习的原则构建我们的内部工具和框架，作为强制执行这些想法的方式。但我们的理论可能不完美，我们期望随着领域的发展而改变，所以也需要一些灵活性和谦逊。
