面向 AI 智能体的高效上下文工程

在提示工程作为应用 AI 关注焦点数年之后，一个新术语已崭露头角：上下文工程。基于语言模型的构建工作，正在从寻找合适的提示词和短语，转向回答一个更宏观的问题：”什么样的上下文配置最有可能产生模型所期望的行为？”

上下文指的是从大型语言模型（LLM）进行采样时所包含的 token 集合。当前的工程问题在于：在 LLM 固有约束条件下，优化这些 token 的利用价值，以持续实现预期目标。有效驾驭 LLM 往往需要_以上下文的视角思考_——换言之：综合考量 LLM 在任意时刻可用的整体状态，以及该状态可能产生哪些潜在行为。

本文将探讨上下文工程这一新兴领域，并提供一套经过提炼的心智模型，用于构建可控、高效的 Agent。

在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程是指编写和组织 LLM 指令以实现最优输出的方法（参见我们的文档，其中包含概述及实用的提示工程策略）。上下文工程是指在 LLM 推理过程中，策划和维护最优 token（信息）集合的一系列策略，涵盖所有可能出现在提示之外的其他信息。

在 LLM 工程的早期阶段，提示是 AI 工程工作中最重要的组成部分，因为日常聊天交互之外的绝大多数用例，都需要针对单次分类或文本生成任务进行优化的提示。顾名思义，提示工程的主要关注点在于如何编写有效的提示，尤其是系统提示。然而，随着我们逐步构建能够跨越多轮推理和更长时间跨度运行的更强大 Agent，我们需要能够管理整个上下文状态的策略（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）。

在循环运行的 Agent 中，每一轮推理都会产生越来越多_可能_与下一轮相关的数据，而这些信息必须被循环地加以精炼。上下文工程是从这个不断演变的信息宇宙中策划出将要进入有限上下文窗口内容的艺术与科学。

与编写提示这一离散任务不同，上下文工程是迭代式的，每次决定向模型传递什么内容时，都会进行策划阶段。

为什么上下文工程对于构建强大 Agent 至关重要

尽管 LLM 速度极快、且能够处理越来越大量的数据，但我们观察到，LLM 与人类一样，在超过某个临界点后会失去专注力或产生困惑。针对大海捞针式基准测试的研究揭示了上下文腐化这一概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确召回信息的能力会随之下降。

尽管不同模型表现出程度不一的性能下降，但这一特征在所有模型中普遍存在。因此，上下文必须被视为一种具有边际效益递减特性的有限资源。与工作记忆容量有限的人类一样，LLM 在解析大量上下文时，也有一个可供调用的”注意力预算”。每引入一个新 token，都会在一定程度上消耗这一预算，从而提高了精心策划提供给 LLM 的 token 的必要性。

这种注意力稀缺性源于 LLM 的架构约束。LLM 基于 Transformer 架构，该架构使每个 token 都能关注到整个上下文中的其他每个 token，由此产生 n 个 token 的 n² 对关系。

随着上下文长度的增加，模型捕获这些成对关系的能力逐渐被拉薄，在上下文规模与注意力焦点之间形成了天然张力。此外，模型的注意力模式来源于训练数据的分布，而训练数据中较短的序列通常比较长的序列更为常见。这意味着模型对于跨上下文的长程依赖关系经验较少，相关的专用参数也较为有限。

位置编码插值等技术可以通过将长序列适配到原始训练时的较小上下文，使模型能够处理更长的序列，尽管这会在 token 位置理解上有所损失。这些因素造成了性能的渐进式下降，而非陡峭的断崖：模型在较长上下文中依然保持高度能力，但与在较短上下文中的表现相比，在信息检索和长程推理的精确度上可能有所降低。

上述现实表明，深思熟虑的上下文工程对于构建强大的 Agent 至关重要。

有效上下文的构成要素

鉴于 LLM 受有限注意力预算的约束，_良好的_上下文工程意味着找到能够最大化某一预期结果可能性的_最小可能_高信号 token 集合。落实这一实践知易行难，但在下一节中，我们将阐述这一指导原则在上下文各组成部分中的具体含义。

系统提示应极为清晰，使用简洁直接的语言，以_恰当的粒度_向 Agent 呈现思路。恰当的粒度是介于两种常见失效模式之间的”黄金地带”。一个极端是，工程师在提示中硬编码复杂、脆弱的逻辑，以期引导精确的 Agent 行为。这种方式会带来脆弱性，并随着时间推移增加维护复杂度。另一个极端是，工程师有时提供模糊的、高层次的指导，未能为 LLM 提供期望输出的具体信号，或错误地假设存在共享上下文。最优的粒度在两者之间取得平衡：既足够具体以有效引导行为，又足够灵活以为模型提供强启发式规则来指引行为。

一端是脆弱的 if-else 硬编码提示，另一端是过于笼统或错误假设共享上下文的提示。

我们建议将提示组织成不同的章节（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题等技术来区分这些章节，尽管随着模型能力的提升，提示的精确格式可能变得越来越不重要。

无论您选择何种方式组织系统提示，都应追求能够完整描述预期行为的最小信息集。（注意，最小并不一定意味着简短；您仍需预先为 Agent 提供足够的信息，确保其遵循预期行为。）最佳实践是先用现有最强模型测试最简提示，观察其在任务上的表现，然后根据初始测试中发现的失效模式，添加清晰的指令和示例以提升性能。

工具使 Agent 能够与环境交互，并在工作过程中引入新的额外上下文。由于工具定义了 Agent 与其信息/行动空间之间的契约，工具促进效率至关重要——既要通过返回 token 高效的信息，也要通过鼓励 Agent 的高效行为。

在与 AI Agent 一起为 AI Agent 编写工具一文中，我们探讨了构建 LLM 易于理解、功能重叠最小的工具。与设计良好的代码库中的函数类似，工具应当是自包含的、对错误具有鲁棒性，并且在其预期用途上极为清晰。输入参数同样应具有描述性、无歧义，并能发挥模型固有的优势。

我们观察到最常见的失效模式之一，是工具集过于臃肿，覆盖了过多功能，或在该使用哪个工具这一问题上造成模糊的决策点。如果人类工程师无法明确判断在特定情境下应使用哪个工具，就不应期待 AI Agent 能做得更好。正如我们稍后将讨论的，为 Agent 策划一套最小可行工具集，也有助于在长时间交互中更可靠地维护和精简上下文。

提供示例（即少样本提示）是一项广为人知的最佳实践，我们仍然强烈建议采用。然而，团队往往会将大量边缘情况塞入提示中，试图阐明 LLM 在特定任务中应遵循的每一条规则。我们不建议这样做。相反，我们建议精心策划一组多样化的典型示例，能够有效展示 Agent 的预期行为。对于 LLM 而言，示例是那”一图胜千言”的存在。

我们在系统提示、工具、示例、消息历史等各类上下文组件中的总体指导原则是：保持思考，让上下文信息丰富而简练。现在让我们深入了解如何在运行时动态检索上下文。

上下文检索与智能体搜索

在构建高效 AI 智能体一文中，我们重点阐述了基于 LLM 的工作流与智能体之间的区别。自那篇文章发布以来，我们逐渐倾向于一个简洁的定义：智能体就是 LLM 在循环中自主使用工具。

在与客户并肩工作的过程中，我们看到整个领域正向这一简单范式汇聚。随着底层模型能力的不断提升，智能体的自主程度也可随之扩展：更智能的模型使智能体能够独立应对复杂问题并从错误中恢复。

我们正在见证工程师在为智能体设计上下文方面的思维转变。如今，许多 AI 原生应用采用某种形式的基于嵌入的推理前检索，以便将重要上下文呈现给智能体进行推理。随着领域向更具智能体特征的方式演进，我们越来越多地看到团队在这些检索系统中加入”恰到好处”的上下文策略。

这种”即时”策略不再在前期预处理所有相关数据，而是让智能体维护轻量级的标识符（文件路径、存储的查询、网页链接等），并在运行时借助工具动态将数据加载到上下文中。Anthropic 的智能体编程解决方案 Claude Code 正是采用这种方法对大型数据库执行复杂的数据分析。模型可以编写有针对性的查询、存储结果，并借助 head、tail 等 Bash 命令分析大量数据，而无需将完整数据对象加载到上下文中。这种方式与人类认知颇为相似：我们通常不会记忆整个知识语料库，而是借助文件系统、收件箱、书签等外部组织与索引系统按需检索相关信息。

除了存储效率之外，这些引用的元数据还提供了一种高效优化行为的机制——无论是显式提供的还是直觉性的。对于在文件系统中运行的智能体而言，tests 文件夹中名为 test_utils.py 的文件，与位于 src/core_logic/ 下同名文件所暗示的用途截然不同。文件夹层级、命名规范和时间戳都提供了重要信号，帮助人类和智能体了解如何以及何时使用这些信息。

让智能体自主导航和检索数据，还能实现渐进式披露——也就是说，允许智能体通过探索逐步发现相关上下文。每一次交互都会产生指引下一步决策的上下文：文件大小暗示复杂程度；命名规范提示用途；时间戳可作为相关性的代理指标。智能体可以逐层构建理解，在工作记忆中只保留必要内容，并利用笔记策略实现额外的持久化。这种自主管理的上下文窗口让智能体专注于相关子集，而不会被繁杂却可能无关的信息所淹没。

当然，这种方式也存在权衡：运行时探索比检索预计算数据要慢。不仅如此，还需要有主见且经过深思熟虑的工程实现，以确保 LLM 拥有正确的工具和启发式方法来有效导航其信息环境。若缺乏适当的引导，智能体可能因滥用工具、追逐死胡同或无法识别关键信息而浪费上下文。

在某些场景下，最高效的智能体可能采用混合策略：预先检索部分数据以提升速度，同时在自行判断时进行进一步的自主探索。”合适”自主程度的决策边界取决于具体任务。Claude Code 正是采用这种混合模型的智能体：CLAUDE.md 文件在前期被直接载入上下文，而 glob 和 grep 等原语则允许它导航环境并即时检索文件，从而有效规避了索引过期和复杂语法树的问题。

混合策略可能更适合内容动态性较低的场景，例如法律或金融工作。随着模型能力的持续提升，智能体设计将趋向于让智能模型自主发挥，人工策划的程度逐渐降低。鉴于该领域的快速发展节奏，”做能解决问题的最简单方案”很可能仍将是我们给在 Claude 上构建智能体的团队的最佳建议。

面向长时域任务的上下文工程

长时域任务要求智能体在一系列动作中保持连贯性、上下文和目标导向行为，而这些动作的 token 数量会超过 LLM 的上下文窗口。对于持续数十分钟乃至数小时的工作（如大型代码库迁移或全面的研究项目），智能体需要专门的技术来绕过上下文窗口大小的限制。

等待更大的上下文窗口似乎是显而易见的策略。但在可预见的未来，各种规模的上下文窗口都很可能面临上下文污染和信息相关性问题——至少在追求最强智能体表现的场景下如此。为使智能体能够在更长的时间跨度内高效工作，我们开发了几种直接应对这些上下文污染约束的技术：压缩、结构化笔记和多智能体架构。

压缩

压缩是指将接近上下文窗口上限的对话进行摘要，并以该摘要重新启动新的上下文窗口的实践。压缩通常是上下文工程中推动长期连贯性的第一道杠杆。从本质上讲，压缩以高保真的方式提炼上下文窗口的内容，使智能体能够以最小的性能损耗继续运行。

以 Claude Code 为例，我们通过将消息历史传递给模型来实现压缩，让模型对最关键的细节进行摘要和压缩。模型会保留架构决策、未解决的缺陷和实现细节，同时丢弃冗余的工具输出或消息。智能体随后可以基于这份压缩后的上下文加上最近访问的五个文件继续工作。用户无需担心上下文窗口限制，即可获得连续性体验。

压缩的艺术在于选择保留什么、舍弃什么，因为过于激进的压缩可能导致细微但关键的上下文丢失，而其重要性往往要到后来才会显现。对于实现压缩系统的工程师，我们建议在复杂的智能体追踪上仔细调整提示词。先最大化召回率，确保压缩提示词能捕获追踪中的每一条相关信息，再逐步迭代以提升精确率、剔除无关内容。

一个容易摘取的”低垂果实”是清除工具调用及其结果——当一个工具在消息历史深处已被调用过，智能体为何还需要再次查看原始结果？最轻量、最安全的压缩形式之一是清除工具结果，这一功能最近已作为 Claude 开发者平台的特性正式上线。

结构化笔记

结构化笔记，即智能体记忆，是一种让智能体定期将笔记持久化写入上下文窗口之外的存储，并在后续适时将其拉回上下文窗口的技术。

这一策略以极低的开销实现了持久记忆。就像 Claude Code 创建待办事项列表，或你的自定义智能体维护一个 NOTES.md 文件一样，这个简单的模式让智能体能够在复杂任务中追踪进度，在数十次工具调用过程中维护关键的上下文和依赖关系，而不至于丢失它们。

Claude 玩宝可梦展示了记忆如何在非编程领域改变智能体的能力。该智能体在数千个游戏步骤中维护精确的计数——追踪如”在过去 1,234 步中，我一直在 1 号道路上训练宝可梦，皮卡丘已向目标 10 级提升了 8 级”这样的目标。在没有任何关于记忆结构提示的情况下，它自主开发出已探索区域的地图，记住已解锁的关键成就，并维护战斗策略笔记，帮助它学习哪些技能对不同对手最为有效。

在上下文重置后，智能体读取自己的笔记，继续进行数小时的训练序列或地下城探索。这种跨摘要步骤的连贯性使得长时域策略成为可能，而这在仅依靠 LLM 上下文窗口保存所有信息时是无法实现的。

作为我们 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上发布了一款记忆工具的公开测试版，通过基于文件的系统让智能体更轻松地在上下文窗口之外存储和查阅信息。这使得智能体能够随时间积累知识库、跨会话维护项目状态，并在无需将所有内容保留在上下文中的情况下引用以往的工作。

子智能体架构

子智能体架构提供了另一种绕过上下文限制的方式。相比由单一智能体尝试在整个项目中维护状态，专门化的子智能体可以在干净的上下文窗口中处理聚焦的任务。主智能体以高层计划进行协调，而子智能体则执行深度技术工作或使用工具查找相关信息。每个子智能体可能进行大量探索，使用数万个甚至更多的 token，但最终只返回其工作的精炼摘要（通常为 1,000 至 2,000 个 token）。

这种方法实现了清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主智能体则专注于综合和分析结果。这一模式在我们如何构建多智能体研究系统中有所探讨，在复杂研究任务上相较单智能体系统取得了显著提升。

这些方法之间的选择取决于任务特性。例如：

• 压缩方式能为需要大量来回交互的任务保持对话流畅性；
• 笔记方式擅长处理具有清晰里程碑的迭代开发；
• 多智能体架构适用于并行探索能带来收益的复杂研究与分析场景。

即便模型持续进步，在长时间交互中保持连贯性的挑战，仍将是构建更高效智能体的核心议题。

结论

上下文工程代表了我们使用大语言模型方式的根本性转变。随着模型能力不断增强，挑战不再仅仅是设计完美的提示词——而是在每一步中深思熟虑地筛选哪些信息进入模型有限的注意力预算。无论是为长时任务实现压缩、设计高效的工具，还是让智能体能够即时探索环境，指导原则始终如一：找到能最大化实现预期结果的最小高信噪比 token 集合。

我们所概述的这些技术将随着模型的进步持续演进。我们已经看到，更智能的模型需要更少的规范性工程，使智能体能够以更高的自主性运作。但即便能力不断扩展，将上下文视为宝贵的有限资源，仍将是构建可靠、高效智能体的核心所在。

立即在 Claude 开发者平台上开始上下文工程实践，并通过我们的内存与上下文管理 cookbook 获取实用技巧与最佳实践。

致谢

本文由 Anthropic 应用 AI 团队撰写：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan 和 Jeremy Hadfield，并得到团队成员 Rafi Ayub、Hannah Moran、Cal Rueb 和 Connor Jennings 的贡献。特别感谢 Molly Vorwerck、Stuart Ritchie 和 Maggie Vo 的大力支持。