AI智能体的有效上下文工程

# AI 智能体的有效上下文工程 来源：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 在提示工程（prompt engineering）成为应用 AI 焦点数年之后，一个新术语逐渐崭露头角：**上下文工程（context engineering）**。构建语言模型正在从寻找提示中的恰当词句，转变为回答一个更宏观的问题："什么样的上下文配置最可能让模型产生期望的行为？" **上下文**指的是从大型语言模型（LLM）采样时包含的 token 集合。**工程**问题则是优化这些 token 的效用，在 LLM 固有限制下持续实现期望结果。有效驾驭 LLM 通常需要*以上下文的方式思考*——换句话说：考虑 LLM 在任意时刻可用的整体状态，以及该状态可能产生的行为。在这篇文章中，我们将探讨上下文工程这一新兴技艺，并提供一个更精细的心智模型来构建可引导、高效的智能体。 在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是为获得最优结果而编写和组织 LLM 指令的方法（参见我们的文档 https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview 了解概述和实用的提示工程策略）。**上下文工程**指的是在 LLM 推理过程中策展和维护最优 token 集合（信息）的策略，包括所有可能进入其中的非提示信息。 在 LLM 工程的早期，提示是 AI 工程工作的最大组成部分，因为大多数日常聊天交互之外的用例都需要针对一次性分类或文本生成任务优化的提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，尤其是系统提示。然而，随着我们转向工程化能力更强的智能体——它们在多轮推理和更长的时间跨度上运行——我们需要管理整个上下文状态的策略（系统指令、工具、Model Context Protocol (https://modelcontextprotocol.io/docs/getting-started/intro)（MCP）、外部数据、消息历史等）。 在循环中运行的智能体会产生越来越多的数据，这些数据*可能*与下一轮推理相关，而这些信息必须被循环精炼。上下文工程是[一门艺术也是科学](https://x.com/karpathy/status/1937902205765607626?lang=en)，负责从不断演变的海量可能信息中策展将进入有限上下文窗口的内容。 **提示工程 vs. 上下文工程** *与编写提示这一离散任务不同，上下文工程是迭代的，策展阶段发生在每次决定向模型传递什么信息时。* ## 为什么上下文工程对构建能力强的智能体至关重要 尽管 LLM 速度越来越快，能处理的数据量越来越大，但我们观察到 LLM 和人类一样，在某一时刻会失去焦点或产生困惑。针对"大海捞针"式基准测试的研究揭示了[上下文腐化（context rot）](https://research.trychroma.com/context-rot)的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。虽然有些模型的衰减比其他模型更平缓，但这一特征在所有模型中都会出现。 因此，上下文必须被视为一种有限资源，其边际收益递减。与人类拥有[有限的工作记忆容量](https://journals.sagepub.com/doi/abs/10.1177/0963721409359277)类似，LLM 也有一个"注意力预算"，在解析大量上下文时调用。引入的每个新 token 都会以某种程度消耗这个预算，这增加了仔细策展 LLM 可用 token 的必要性。 这种注意力稀缺源于 LLM 的架构限制。LLM 基于 [transformer 架构](https://arxiv.org/abs/1706.03762)，该架构使每个 token 都能[关注到其他每个 token](https://huggingface.co/blog/Esmail-AGumaan/attention-is-all-you-need)，覆盖整个上下文。这导致 n 个 token 之间存在 n² 对关系。随着上下文长度增加，模型捕捉这些成对关系的能力被拉伸，在上下文大小和注意力聚焦之间产生了自然的张力。 此外，模型从训练数据分布中发展出的注意力模式通常是短序列比长序列更常见。这意味着模型对上下文范围的依赖关系经验较少，专门参数也较少。[位置编码插值](https://arxiv.org/pdf/2306.15595)等技术允许模型通过适应最初训练的较小上下文来处理更长的序列，但代价是 token 位置理解的一定退化。 这些因素形成了一种性能梯度而非硬性断崖：模型在较长上下文中仍保持高能力，但与较短上下文上的表现相比，信息检索和长程推理的精确度可能有所下降。这些现实意味着，周密的上下文工程对于构建有能力的智能体至关重要。 ## 有效上下文的解剖结构 鉴于 LLM 受限于有限的注意力预算，*良好的*上下文工程意味着找到*最小*的、*可能的*高信号 token 集合，以最大化期望结果的可能性。实践这一原则说起来容易做起来难，但在下文中，我们将概述这一指导原则在不同上下文组件中的实际含义。 **系统提示**应该极其清晰，使用简单直接的语言，以*恰当的高度*向智能体呈现想法。恰当的高度是处于两个常见失败模式之间的"刚刚好"地带。在一个极端，我们看到工程师在提示中硬编码复杂、脆弱的逻辑来引出精确的代理行为。这种方法会造成脆弱性，并随时间增加维护复杂性。在另一个极端，工程师有时提供模糊、高层次的指导，未能给 LLM 提供期望输出的具体信号，或错误地假设共享上下文。 最优高度取得平衡：足够具体以有效引导行为，又足够灵活以向模型提供强有力的启发式来指导行为。 *在上下文工程过程中校准系统提示。在一端，我们看到脆弱的条件判断硬编码提示；在另一端，我们看到过于笼统或错误假设共享上下文的提示。* 我们建议将提示组织成不同的部分（如 ``、``、`## Tool guidance`、`## Output description` 等），并使用 XML 标签或 Markdown 标题等技术来划分这些部分，尽管随着模型能力增强，提示的确切格式可能变得不那么重要。无论你决定如何构建系统提示，都应该追求以最少的信息完整概述期望行为。（注意，最少不一定意味着短；你仍然需要预先给智能体足够的信息以确保其遵循期望行为。） 最好从测试一个最小提示开始，使用可用的最佳模型，看看它在你的任务上表现如何，然后根据初始测试中发现的失败模式添加清晰的指令和示例来提升性能。 **工具**允许智能体与其环境交互，并在工作时引入新的、额外的上下文。由于工具定义了智能体与其信息/行动空间之间的契约，因此工具促进效率极为重要——既要通过返回 token 高效的信息，也要通过鼓励高效的智能体行为。 在 [Writing tools for AI agents – with AI agents](https://www.anthropic.com/engineering/writing-tools-for-agents) 中，我们讨论了构建 LLM 易于理解且功能重叠最小的工具。类似于设计良好的代码库中的函数，工具应该是自包含的、容错的，并且对其预期用途极其清晰。输入参数同样应该是描述性的、明确的，并发挥模型的固有优势。 我们最常见的失败模式之一是工具集臃肿，覆盖过多功能或导致使用哪个工具的决策点模糊。如果人类工程师无法明确说清在特定情况下应该使用哪个工具，就不能期望 AI 智能体做得更好。正如我们稍后讨论的，为智能体策展最小可用工具集也可以在长期交互中实现更可靠的上下文维护和修剪。 提供示例，即少样本提示（few-shot prompting），是一个广为人知的最佳实践，我们继续强烈建议。然而，团队常常会在提示中塞入一长串边缘案例，试图阐明 LLM 应该遵循的每一条可能规则。我们不建议这样做。相反，我们建议努力策展一组多样化的、典型的示例，有效展示智能体的期望行为。对于 LLM 来说，示例是"一图胜千言"的"图"。 我们对上下文不同组件（系统提示、工具、示例、消息历史等）的总体指导是：深思熟虑，保持上下文信息丰富但紧凑。现在让我们深入探讨运行时动态检索上下文。 ## 上下文检索与智能体搜索 在 [Building effective AI agents](https://www.anthropic.com/research/building-effective-agents) 中，我们强调了基于 LLM 的工作流与智能体之间的区别。自那篇文章发表以来，我们倾向于采用智能体的[简单定义](https://simonwillison.net/2025/Sep/18/agents/)：LLM 自主地在循环中使用工具。与客户合作过程中，我们看到该领域正在向这一简单范式收敛。 随着底层模型能力增强，智能体的自主水平可以扩展：更智能的模型使智能体能够独立驾驭细微的问题空间并从错误中恢复。我们现在看到工程师在设计智能体上下文的方式上发生了转变。 如今，许多 AI 原生应用采用某种形式的基于嵌入的推理前检索，为智能体提供重要的上下文进行推理。随着领域向更具代理性的方法过渡，我们越来越多地看到团队用"即时"（just in time）上下文策略来增强这些检索系统。 与预先处理所有相关数据不同，采用"即时"方法构建的智能体维护轻量级标识符（文件路径、存储的查询、网页链接等），并使用这些引用通过工具在运行时动态加载数据到上下文中。Anthropic 的智能体编码解决方案 [Claude Code](https://www.anthropic.com/claude-code) 使用这种方法对大型数据库执行复杂的数据分析。模型可以编写有针对性的查询、存储结果，并利用 head 和 tail 等 Bash 命令分析大量数据，而无需将完整的数据对象加载到上下文中。 这种方法类似于人类认知：我们通常不会记住整本信息集，而是引入外部组织和索引系统，如文件系统、收件箱和书签，按需检索相关信息。 除了存储效率之外，这些引用的元数据提供了一种高效精炼行为的机制，无论是显式提供的还是隐含的。对于在文件系统中操作的智能体来说，`tests` 文件夹中名为 `test_utils.py` 的文件与位于 `src/core_logic/` 中的同名文件暗示了不同的用途。文件夹层级、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何利用以及何时利用信息。 让智能体自主导航和检索数据还能实现渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每次交互产生的上下文会通知下一个决策：文件大小暗示复杂性；命名约定暗示用途；时间戳可以作为相关性的代理。智能体可以逐层构建理解，在工作记忆中只保留必要内容，并利用笔记策略实现额外的持久性。这种自我管理的上下文窗口使智能体专注于相关子集，而不是淹没在详尽但可能无关的信息中。 当然，这里存在权衡：运行时探索比检索预先计算的数据更慢。不仅如此，还需要有见地且周密的工程设计，以确保 LLM 拥有正确的工具和启发式方法来有效导航其信息环境。如果没有适当指导，智能体可能因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。在某些场景下，最有效的智能体可能采用混合策略：预先检索一些数据以提升速度，并酌情进行进一步的自主探索。 "正确"自主水平的决策边界取决于任务。Claude Code 是一个采用这种混合模式的智能体：[CLAUDE.md](http://claude.md/) 文件被朴素地预先放入上下文，而 glob 和 grep 等原语允许它导航环境并即时检索文件，有效规避了陈旧索引和复杂语法树的问题。混合策略可能更适合动态内容较少的上下文，如法律或财务工作。 随着模型能力提升，智能体设计将趋向于让智能模型智能地行动， progressively 减少人工策展。鉴于该领域的快速进展，"做最简单有效的事"可能仍然是我们对基于 Claude 构建智能体的团队的最佳建议。 ### 长时程任务的上下文工程 长时程任务要求智能体在 token 数量超过 LLM 上下文窗口的动作序列中保持连贯性、上下文和目标导向行为。对于持续数十分钟到数小时的连续工作任务，如大型代码库迁移或综合性研究项目，智能体需要专门的技术来应对上下文窗口大小的限制。 等待更大的上下文窗口似乎是一个明显的策略。但很可能在可预见的未来，所有大小的上下文窗口都会受到上下文污染和信息相关性问题的困扰——至少在需要最强智能体性能的情况下如此。 为使智能体能够在扩展的时间范围内有效工作，我们开发了几种直接应对这些上下文污染限制的技术：压缩、结构化笔记和多智能体架构。 **压缩** 压缩是指将接近上下文窗口限制的对话进行总结，并用该摘要重新初始化一个新的上下文窗口的做法。压缩通常作为上下文工程中驱动更好长期连贯性的首要杠杆。其核心在于以高保真度提炼上下文窗口的内容，使智能体能够以最小的性能退化继续。 在 Claude Code 中，例如，我们通过传递 me