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

来源: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents 抓取时间: 2026-07-21 16:19:25

在提示工程成为应用 AI 领域的关注焦点几年之后，一个新术语开始崭露头角：上下文工程。使用语言模型进行构建正越来越少地涉及为提示找到正确的单词和短语，而更多地是回答一个更广泛的问题："什么样的上下文配置最有可能产生我们模型的期望行为？"

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

在这篇文章中，我们将探索新兴的上下文工程艺术，并为构建可控制、有效的智能体提供一个精炼的思维模型。

上下文工程与提示工程

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

在使用 LLM 进行工程的早期，提示是 AI 工程工作的最大组成部分，因为日常聊天交互之外的大多数用例都需要为一次性分类或文本生成任务优化的提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，特别是系统提示。然而，随着我们转向构建更有能力的智能体，这些智能体需要在多轮推理和更长的时间范围内运行，我们需要策略来管理整个上下文状态（系统指令、工具、模型上下文协议 (MCP)、外部数据、消息历史等）。

循环运行的智能体会生成越来越多的数据，这些数据_可能_与下一轮推理相关，而这些信息必须循环更新。上下文工程是从不断演变的可能信息库中策划将进入有限上下文窗口的内容的艺术和科学。

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

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

尽管 LLM 速度很快，并且能够管理越来越多的数据量，但我们观察到，像人类一样，LLM 在某个点上会失去焦点或经历混乱。对大海捞针式基准测试的研究揭示了上下文腐烂的概念：随着上下文窗口中令牌数量的增加，模型准确回忆该上下文中信息的能力会下降。

虽然某些模型表现出比其他模型更温和的退化，但这种特征在所有模型中都会出现。因此，上下文必须被视为一种边际收益递减的有限资源。就像人类的工作记忆容量有限一样，LLM 有一个"注意力预算"，它们在解析大量上下文时会利用它。每个新引入的令牌都会在一定程度上消耗这个预算，这增加了仔细策划 LLM 可用令牌的必要性。

这种注意力稀缺源于 LLM 的架构约束。LLM 基于Transformer 架构，该架构使每个令牌能够在整个上下文中关注每个其他令牌。这导致 n 个令牌有 n² 个成对关系。

随着上下文长度的增加，模型捕获这些成对关系的能力会变得捉襟见肘，这在上下文大小和注意力焦点之间造成了自然的张力。此外，模型从训练数据分布中发展其注意力模式，其中较短的序列通常比较长的序列更常见。这意味着模型对上下文范围的依赖关系经验较少，专用参数也较少。

位置编码插值等技术允许模型通过将其适应最初训练的较小上下文来处理更长的序列，尽管令牌位置理解会有一些下降。这些因素创造了一个性能梯度，而不是一个陡峭的悬崖：模型在较长的上下文中仍然保持高度能力，但与较短的上下文相比，信息检索和长程推理的精度可能会降低。

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

有效上下文的剖析

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

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

在光谱的一端，我们看到脆弱的 if-else 硬编码提示，而在另一端，我们看到过于笼统或错误地假设共享上下文的提示。

我们建议将提示组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标记或 Markdown 标题等技术来划分这些部分，尽管随着模型变得更有能力，提示的确切格式可能变得不那么重要。

无论您决定如何构建系统提示，您都应该努力寻找能完整概述您期望行为的最小信息集。（请注意，最小并不一定意味着简短；您仍需要预先为智能体提供足够的信息，以确保其遵循期望的行为。）最好先使用可用的最佳模型测试最小提示，看看它在您的任务上表现如何，然后根据初始测试期间发现的失败模式，添加清晰的说明和示例以提高性能。

工具允许智能体与其环境一起运行，并在工作时引入新的额外上下文。因为工具定义了智能体与其信息/操作空间之间的契约，所以至关重要的是，工具通过返回令牌高效的信息和鼓励高效的智能体行为来提高效率。

在为 AI 智能体编写工具——使用 AI 智能体中，我们讨论了构建 LLM 能够很好理解且功能重叠最小的工具。与精心设计的代码库的功能类似，工具应该是自包含的、对错误具有鲁棒性，并且在预期用途方面极其清晰。输入参数同样应该是描述性的、明确的，并发挥模型的固有优势。

我们看到的最常见失败模式之一是工具集过于臃肿，涵盖了太多功能或导致使用哪个工具的决策点不明确。如果人类工程师不能明确说出在特定情况下应该使用哪个工具，那么我们就不能指望 AI 智能体做得更好。正如我们稍后将讨论的，为智能体策划一个最小可行的工具集还可以在长交互过程中更可靠地维护和修剪上下文。

提供示例，也就是少样本提示，是一个众所周知的最佳实践，我们继续强烈建议这样做。然而，团队通常会将一长串边缘案例塞进提示中，试图阐明 LLM 在特定任务中应该遵循的每一条可能规则。我们不建议这样做。相反，我们建议努力策划一组多样化的、典型的示例，这些示例能有效描述智能体的预期行为。对于 LLM 来说，示例就是价值千言万语的"图片"。

我们对上下文的不同组成部分（系统提示**、工具、示例、**消息历史等）的总体指导是，要深思熟虑，并保持您的上下文信息丰富但紧凑。现在让我们深入探讨在运行时动态检索上下文。

上下文检索与智能体搜索

在构建有效的 AI 智能体中，我们强调了基于 LLM 的工作流程与智能体之间的差异。自从我们写了那篇文章以来，我们已经倾向于一个简单的智能体定义：LLM 在循环中自主使用工具。

与我们的客户合作，我们看到该领域正在收敛到这个简单的范式。随着基础模型变得更有能力，智能体的自主性水平可以扩大：更智能的模型允许智能体独立导航复杂的问题空间并从错误中恢复。

我们现在看到工程师在为智能体设计上下文方面的思维转变。今天，许多 AI 原生应用程序采用某种形式的基于嵌入的推理前检索，为智能体提供重要的上下文进行推理。随着该领域向更智能体化的方法转变，我们越来越多地看到团队使用"及时"上下文策略来增强这些检索系统。

不是预先处理所有相关数据，而是使用"及时"方法构建的智能体维护轻量级标识符（文件路径、存储的查询、Web 链接等），并使用这些引用在运行时使用工具动态地将数据加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 使用这种方法对大型数据库执行复杂的数据分析。该模型可以编写有针对性的查询、存储结果，并利用 head 和 tail 等 Bash 命令分析大量数据，而无需将完整数据对象加载到上下文中。这种方法反映了人类认知：我们通常不记住整个语料库的信息，而是引入文件系统、收件箱和书签等外部组织和索引系统来按需检索相关信息。

除了存储效率之外，这些引用的元数据还提供了一种机制来有效地改进行为，无论这些元数据是明确提供的还是直观的。对于在文件系统中运行的智能体来说，tests 文件夹中名为 test_utils.py 的文件的存在意味着与位于 src/core_logic/ 中的同名文件具有不同的用途。文件夹层次结构、命名约定和时间戳都提供了重要的信号，帮助人类和智能体理解如何以及何时利用信息。

让智能体自主导航和检索数据还可以实现渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每次交互都会产生指导下一个决策的上下文：文件大小暗示复杂性；命名约定暗示目的；时间戳可以作为相关性的代理。智能体可以逐层组装理解，只在工作内存中维护必要的内容，并利用笔记策略实现额外的持久性。这种自我管理的上下文窗口使智能体专注于相关子集，而不是淹没在详尽但可能不相关的信息中。

当然，这是一种权衡：运行时探索比检索预先计算的数据慢。不仅如此，还需要有主见和深思熟虑的工程来确保 LLM 拥有正确的工具和启发式方法，以有效地导航其信息格局。如果没有适当的指导，智能体可能会因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。

在某些情况下，最有效的智能体可能会采用混合策略，预先检索一些数据以提高速度，并酌情进行进一步的自主探索。"正确"自主权水平的决策边界取决于任务。Claude Code 是一个采用这种混合模型的智能体：CLAUDE.md 文件被预先朴素地放入上下文中，而 glob 和 grep 等原语允许它导航其环境并及时检索文件，有效地绕过了索引过时和复杂语法树的问题。

混合策略可能更适合内容动态性较低的上下文，例如法律或金融工作。随着模型能力的提高，智能体设计将趋向于让智能模型智能地行动，而人工策划逐渐减少。鉴于该领域的快速进步，"做最简单的有效事情"可能仍然是我们对在 Claude 之上构建智能体的团队的最佳建议。

长期任务的上下文工程

长期任务要求智能体在令牌计数超过 LLM 上下文窗口的动作序列中保持连贯性、上下文和目标导向行为。对于跨越数十分钟到数小时连续工作的任务，如大型代码库迁移或综合研究项目，智能体需要专门的技术来解决上下文窗口大小的限制。

等待更大的上下文窗口似乎是一个明显的策略。但在可预见的未来，所有大小的上下文窗口都可能受到上下文污染和信息相关性问题的影响——至少在需要最强智能体性能的情况下是如此。为了使智能体能够在延长的时间范围内有效工作，我们开发了几种直接解决这些上下文污染约束的技术：压缩、结构化笔记和多智能体架构。

压缩

压缩是指对接近上下文窗口限制的对话进行处理，总结其内容，并使用摘要重新启动新的上下文窗口。压缩通常用作上下文工程中的第一个杠杆，以提高长期连贯性。从本质上讲，压缩以高保真方式提炼上下文窗口的内容，使智能体能够以最小的性能下降继续工作。

例如，在 Claude Code 中，我们通过将消息历史传递给模型来总结和压缩最重要的细节来实现这一点。模型保留了架构决策、未解决的错误和实现细节，同时丢弃了冗余的工具输出或消息。然后，智能体可以继续使用这个压缩的上下文加上五个最近访问的文件。用户获得连续性，而无需担心上下文窗口限制。

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

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

结构化笔记

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

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

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

在上下文重置后，智能体读取自己的笔记并继续数小时的训练序列或地牢探索。这种跨摘要步骤的连贯性实现了仅在 LLM 上下文窗口中保留所有信息时不可能实现的长期策略。

作为 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上发布了一个公开测试版的记忆工具，它通过基于文件的系统更轻松地存储和查阅上下文窗口之外的信息。这允许智能体随着时间的推移构建知识库，跨会话维护项目状态，并引用以前的工作，而无需将所有内容保留在上下文中。

子智能体架构

子智能体架构提供了另一种解决上下文限制的方法。不是一个智能体尝试在整个项目中维护状态，而是专门的子智能体可以使用干净的上下文窗口处理专注的任务。主智能体通过高级计划进行协调，而子智能体执行深度技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛探索，使用数万个令牌或更多，但只返回其工作的浓缩摘要（通常为 1000-2000 个令牌）。

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

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

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

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

结论

上下文工程代表了我们如何使用 LLM 进行构建的根本转变。随着模型变得更有能力，挑战不仅仅是制作完美的提示——而是在每一步精心策划哪些信息进入模型有限的注意力预算。无论您是为长期任务实施压缩、设计令牌高效的工具，还是使智能体能够及时探索其环境，指导原则保持不变：找到最小的高信号令牌集合，以最大化您期望结果的可能性。

我们概述的技术将随着模型的改进而继续发展。我们已经看到，更智能的模型需要更少的规范性工程，允许智能体以更大的自主性运行。但即使能力扩展，将上下文视为宝贵的有限资源，仍将是构建可靠、有效智能体的核心。

立即开始在 Claude 开发者平台上进行上下文工程，并通过我们的记忆和上下文管理食谱访问有用的提示和最佳实践。

致谢

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