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

在提示工程成为应用 AI 关注焦点几年之后，一个新术语开始崭露头角：上下文工程。使用语言模型进行构建，正变得越来越不在于为你的提示找到合适的词语和短语，而更多在于回答一个更广泛的问题：“什么样的上下文配置最有可能生成我们模型期望的行为？”

上下文指的是从大型语言模型（LLM）采样时所包含的 token 集合。手头的工程问题是，在 LLM 固有约束下优化这些 token 的效用，以持续实现期望的结果。有效地驾驭 LLM 通常需要在上下文中思考——换句话说：考虑 LLM 在任何给定时刻可用的整体状态，以及该状态可能产生哪些潜在行为。

在这篇文章中，我们将探讨新兴的上下文工程艺术，并提供一个经过提炼的心智模型，用于构建可操控、有效的智能体。

在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程指的是编写和组织 LLM 指令以获得最佳结果的方法（参见我们的文档，了解概述和有用的提示工程策略）。上下文工程指的是在 LLM 推理期间策划和维护最佳 token（信息）集合的策略，包括提示之外可能进入其中的所有其他信息。

在 LLM 工程的早期，提示是 AI 工程工作中最大的组成部分，因为除日常聊天交互之外的大多数用例都需要针对一次性分类或文本生成任务优化的提示。正如该术语所暗示的，提示工程的主要关注点是如何编写有效的提示，尤其是系统提示。然而，随着我们朝着构建更强大的智能体迈进，这些智能体在多个推理轮次和更长的时间跨度上运行，我们需要管理整个上下文状态的策略（系统指令、工具、模型上下文协议（MCP）、外部数据、消息历史等）。

在循环中运行的智能体会生成越来越多的数据，这些数据可能与下一轮推理相关，而这些信息必须被循环地精炼。上下文工程是一门艺术与科学，它从不断演化的可能信息宇宙中，策划哪些内容将进入有限的上下文窗口。

为什么上下文工程对构建强大的智能体很重要

尽管 LLM 速度很快，并且能够管理越来越大的数据量，但我们观察到，它们和人类一样，会在某个时刻失去专注或感到困惑。关于大海捞针式基准测试的研究揭示了上下文腐化的概念：随着上下文窗口中 token 数量的增加，模型从该上下文中准确回忆信息的能力会下降。

虽然有些模型比其他模型表现出更温和的性能退化，但这一特征在所有模型中都会出现。因此，上下文必须被视为一种具有递减边际收益的有限资源。就像人类拥有有限的工作记忆容量一样，LLM 在解析大量上下文时也会动用一种“注意力预算”。每引入一个新 token 都会以某种程度消耗这一预算，从而增加了精心策划可供 LLM 使用的 token 的必要性。

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

随着上下文长度的增加，模型捕捉这些成对关系的能力会被拉伸到极限，从而在上下文大小与注意力聚焦之间形成一种天然的张力。此外，模型的注意力模式是从训练数据分布中发展而来的，而在这些分布中，较短的序列通常比较长的序列更为常见。这意味着模型对上下文范围的依赖关系经验更少，专门化的参数也更少。

像位置编码插值这样的技术，通过将更长的序列适配到最初训练的较小上下文，使模型能够处理更长的序列，尽管在 token 位置理解上会有一定程度的退化。这些因素造成的是性能上的渐变，而非断崖式下跌：模型在较长的上下文中仍保持很强的能力，但与在较短上下文中的表现相比，其在信息检索和长程推理方面的精度可能会有所下降。

这些现实意味着，深思熟虑的上下文工程对于构建有能力的智能体至关重要。

有效上下文的解剖

鉴于 LLM 受限于有限的注意力预算，好的上下文工程意味着找到尽可能小的高信号 token 集合，以最大化某种期望结果的可能性。实践这一做法说起来容易做起来难，但在下一节中，我们将概述这一指导原则在上下文的不同组成部分中实际意味着什么。

系统提示应当极其清晰，并使用简单、直接的语言，将想法以对智能体而言恰当的高度呈现出来。恰当的高度是两种常见失败模式之间的“金发姑娘”区间。在一个极端，我们看到工程师在提示中硬编码复杂、脆弱的逻辑，以引出精确的智能体行为。这种做法会造成脆弱性，并随着时间推移增加维护复杂性。在另一个极端，工程师有时提供模糊、高层次的指导，未能给 LLM 提供期望输出的具体信号，或错误地假设存在共享上下文。最佳的高度取得一种平衡：既足够具体以有效引导行为，又足够灵活以为模型提供强有力的启发式方法来指导行为。

我们建议将提示组织成不同的部分（如 <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 来说，示例就是“一图胜千言”。

我们对上下文各个组成部分（系统提示、工具、示例、消息历史等）的总体指导是：深思熟虑，让上下文既有信息量，又保持紧凑。现在让我们深入探讨运行时动态检索上下文。

上下文检索与 agent 式搜索

在构建有效的 AI agent一文中，我们强调了基于 LLM 的工作流与 agent 之间的差异。自我们撰写那篇文章以来，我们逐渐倾向于一个简单定义：agent 就是 LLM 在循环中自主使用工具。

在与客户合作的过程中，我们看到该领域正逐渐 convergence 于这一简单范式。随着底层模型能力增强，agent 的自主程度也可以随之扩展：更聪明的模型让 agent 能够独立应对微妙的问题空间并从错误中恢复。

我们现在看到工程师在设计智能体上下文的方式上正在发生转变。如今，许多 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 中，我们通过将消息历史传递给模型来总结并压缩最关键细节来实现这一点。模型会保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。智能体随后可以基于这个压缩后的上下文以及最近访问的五个文件继续工作。用户获得了连续性，而无需担心上下文窗口的限制。

压缩的艺术在于选择保留什么与丢弃什么，因为过于激进的压缩可能导致丢失那些微妙但关键的上下文，而这些上下文的重要性往往在之后才会显现。对于实现压缩系统的工程师，我们建议在复杂的智能体轨迹上仔细调整你的提示词。首先最大化召回率，确保你的压缩提示词捕获轨迹中每一条相关信息，然后通过消除多余内容来迭代提升精确率。

一个显而易见的多余内容示例是清除工具调用和结果——一旦某个工具在消息历史深处被调用过，智能体为什么还需要再次看到原始结果呢？最安全、最轻量的压缩形式之一是工具结果清除，最近已作为Claude 开发者平台上的功能推出。

结构化笔记

结构化笔记，或称智能体记忆，是一种智能体定期将笔记持久化到上下文窗口之外的内存中的技术。这些笔记会在之后被重新拉回上下文窗口中。

这一策略以极小的开销提供了持久记忆。就像 Claude Code 创建待办事项列表，或你的自定义智能体维护一个 NOTES.md 文件一样，这种简单的模式让智能体能够在复杂任务中跟踪进度，保留关键的上下文和依赖关系，否则这些信息会在数十次工具调用中丢失。

Claude 玩 Pokémon 展示了记忆如何在非编程领域改变智能体的能力。该智能体在数千个游戏步骤中保持精确的记录——跟踪诸如“在过去 1,234 步中我一直在 1 号道路训练我的 Pokémon，皮卡丘已升了 8 级，目标是 10 级”这样的目标。在没有任何关于记忆结构的提示下，它绘制出已探索区域的地图，记住自己解锁了哪些关键成就，并维护战斗策略的战略笔记，帮助它了解哪些攻击对不同对手最有效。

在上下文重置后，智能体读取自己的笔记，继续长达数小时训练序列或地下城探索。这种跨摘要步骤的一致性使得长时程策略成为可能，而如果仅将所有信息保留在 LLM 的上下文窗口中，这是不可能实现的。

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

子智能体架构

子智能体架构提供了另一种绕过上下文限制的方法。与其让一个智能体试图在整个项目中维护状态，不如让专门的子智能体以干净的上下文窗口处理聚焦的任务。主智能体以高层计划进行协调，而子智能体则执行深入的技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛探索，使用数万或更多 token，但只返回其工作的精简、提炼后的摘要（通常为 1,000-2,000 token）。

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

在这些方法之间做选择取决于任务特征。例如：

• 压缩为需要大量来回交互的任务保持对话流畅性；
• 笔记记录在具有明确里程碑的迭代开发中表现出色；
• 多智能体架构处理复杂的研究和分析，在这些场景中并行探索能带来回报。

即使模型持续改进，在扩展交互中保持一致性这一挑战仍将是构建更有效智能体的核心。

结论

上下文工程代表了我们在使用 LLM 构建应用方式上的一次根本性转变。随着模型能力越来越强，挑战不再只是精心设计完美的提示词——而是要在每一步都深思熟虑地筛选哪些信息进入模型有限的注意力预算。无论你是在为长周期任务实现压缩、设计 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 的支持。