Anthropic 官方：AI Agents 有效上下文工程最佳实践

上下文工程 vs. 提示工程

经过几年在应用 AI 中专注于提示工程，一个新的术语已经引起关注：上下文工程。使用语言模型进行构建不再仅仅是为提示寻找正确的词汇和短语，而是更多地回答一个更广泛的问题："什么样的上下文配置最有可能生成我们模型期望的行为？"

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

在这篇文章中，我们将探讨上下文工程这一新兴艺术，并为构建可引导、高效的 AI 智能体提供一个完善的心智模型。

上下文工程 vs. 提示工程

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

在使用 LLM 进行工程的早期阶段，提示编写是 AI 工程工作中最重要的组成部分，因为在日常聊天交互之外的大多数用例都需要针对单次分类或文本生成任务优化的提示。顾名思义，提示工程的主要关注点是如何编写有效的提示，特别是系统提示。然而，当我们朝着开发能够跨多个推理轮次和更长时间跨度运作的更强大的 AI 智能体迈进时，我们需要用于管理整个上下文状态的策略（系统指令、工具、Model Context Protocol (MCP)、外部数据、消息历史等）。

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

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

尽管 LLM 的速度和管理越来越大的数据量的能力，我们观察到 LLM 像人类一样，在某个点会失去焦点或经历混淆。对"大海捞针"风格基准测试的研究发现了上下文衰退的概念：随着上下文窗口中的令牌数量增加，模型从该上下文中准确回忆信息的能力会下降。

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

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

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

位置编码插值等技术通过将较长序列适应到原始训练的较小上下文，允许模型处理较长序列，尽管令牌位置理解会有所下降。这些因素创造了一个性能梯度而不是硬崖：模型在较长的上下文中仍然高度强大，但与在较短上下文上的性能相比，信息检索和长期推理的精度可能会降低。

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

有效上下文的解剖学

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

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

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

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

工具允许 AI 智能体与其环境进行操作，并在工作时拉入新的、额外的上下文。因为工具定义了 AI 智能体和它们的信息/行动空间之间的合约，工具促进效率是极其重要的，无论是通过返回令牌高效的信息，还是通过鼓励高效的 AI 智能体行为。在为 AI 智能体编写工具中，我们讨论了构建 LLM 能很好理解并且功能重叠最少的工具。与设计良好的代码库的功能类似，工具应该是自包含的、对错误稳健的，并且对其预期用途非常清楚。输入参数应该同样具有描述性、明确无误，并利用模型的固有优势。

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

提供示例，又称为少样本提示，是一种众所周知的最佳实践，我们继续强烈建议。然而，团队通常会将一长串边界情况塞进提示中，试图阐明 LLM 应该遵循的每一条可能的规则以完成特定任务。我们不建议这样做。相反，我们建议努力策划一套多样、规范的示例，有效地展示 AI 智能体的期望行为。对于 LLM，示例是价值千言万语的"图片"。

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

在《构建有效的 AI 智能体》一文中，我们突出了基于 LLM 的工作流和 AI 智能体之间的区别。自那篇文章发表以来，我们逐渐形成了对 AI 智能体的简单定义：LLM 在循环中自主使用工具。

与客户合作的过程中，我们看到整个行业正朝这一简单范式收敛。随着基础模型变得更加强大，AI 智能体的自主程度也能相应扩展：更聪明的模型使 AI 智能体能够独立地在复杂的问题空间中导航并从错误中恢复。

我们现在看到工程师在如何为 AI 智能体设计上下文方面出现了转变。如今，许多 AI 原生应用采用某种形式的基于嵌入的推理前检索，为 AI 智能体提供重要的推理上下文。随着行业向更加智能体化的方法转变，我们越来越多地看到团队在这些检索系统中增加"即时"上下文策略。

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

除了存储效率外，这些引用的元数据提供了一种有效细化行为的机制，无论是明确提供还是直观应用。对于在文件系统中操作的 AI 智能体，位于 tests 文件夹中的名为 test_utils.py 的文件所暗示的目的，与位于 src/core_logic/ 文件夹中同名文件的目的不同。文件夹层级、命名惯例和时间戳都提供了重要信号，帮助人类和 AI 智能体理解如何以及何时利用这些信息。

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

当然，这里存在一个权衡：运行时探索比检索预先计算的数据更慢。不仅如此，还需要有主见的、经过深思熟虑的工程设计来确保 LLM 拥有合适的工具和启发式方法，以便有效地在其信息景观中导航。在没有恰当指导的情况下，AI 智能体可能会通过误用工具、追逐死路或未能识别关键信息而浪费上下文。

在某些情况下，最有效的 AI 智能体可能采用混合策略，预先检索一些数据以加快速度，然后根据自身判断进行进一步的自主探索。"正确"自主程度的决策边界取决于任务。Claude Code 就是采用这种混合模型的 AI 智能体：CLAUDE.md 文件被直接加载到初始上下文中，而 glob 和 grep 等基本工具则允许它导航其环境并即时检索文件，有效地规避了过时索引和复杂语法树的问题。

混合策略可能更适合内容变化不那么频繁的场景，如法律或金融领域的工作。随着模型能力的提高，AI 智能体设计将趋向于让聪慧的模型聪慧地行动，需要人工策划的干预越来越少。考虑到该领域快速的发展步伐，"做能用的最简单的事"可能仍然是我们对在 Claude 上构建 AI 智能体的团队最好的建议。

长期任务的上下文工程

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

等待更大的上下文窗口似乎是一个显而易见的策略。但在可预见的未来，各种大小的上下文窗口都将面临上下文污染和信息相关性问题——至少在需要 AI 智能体表现最优的情况下是如此。为了使 AI 智能体能够在更长的时间跨度内有效工作，我们开发了几种直接解决这些上下文污染问题的技术：压缩、结构化笔记和多 AI 智能体架构。

压缩

压缩是指将接近上下文窗口限制的对话进行总结，然后用摘要重新启动一个新上下文窗口的做法。压缩通常是上下文工程的第一个杠杆，来推动更好的长期连贯性。压缩的核心是以高保真方式精炼上下文窗口的内容，使 AI 智能体能够继续进行，性能下降最小。

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

压缩的艺术在于如何选择保留和舍弃的内容，因为过度激进的压缩可能导致丢失微妙但关键的上下文，这些上下文的重要性往往在之后才显现。对于实现压缩系统的工程师，我们建议根据复杂的 AI 智能体跟踪仔细调整提示。首先最大化召回率，确保压缩提示从跟踪中捕获每一个相关信息，然后迭代以改进精度，消除冗余内容。

一个容易处理的冗余内容的例子是清除工具调用和结果——一旦工具在消息历史的深处被调用过，AI 智能体为什么还需要再次查看原始结果呢？最安全、最温和的压缩形式之一是工具结果清除，最近作为 Claude Developer Platform 上的功能发布。

结构化笔记

结构化笔记，也称为 AI 智能体记忆，是一种技术，其中 AI 智能体定期将笔记写入并持久化保存在上下文窗口外的存储中。这些笔记随后会被重新拉回到上下文窗口中。

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

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

在上下文重置后，AI 智能体读取自己的笔记，继续进行多小时的训练序列或地牢探索。这种跨越总结步骤的连贯性使其能够实现只在 LLM 的上下文窗口中保留所有信息时不可能实现的长期策略。

作为 Sonnet 4.5 发布的一部分，我们在 Claude Developer Platform 上公开发布了一个记忆工具的公开测试版，通过基于文件的系统使存储和查询上下文窗口外的信息变得更容易。这使 AI 智能体能够随着时间的推移构建知识库，在会话之间保持项目状态，并参考以前的工作，而无需将所有内容保留在上下文中。

子 AI 智能体架构

子智能体架构

子智能体架构提供了另一种解决上下文限制的方法。与其让一个智能体在整个项目中维持状态，不如让专门的子智能体用清晰的上下文窗口处理聚焦的任务。主智能体用高层计划进行协调，而子智能体执行深度技术工作或使用工具找到相关信息。每个子智能体可能会进行广泛的探索，消耗数万个令牌或更多，但只返回其工作的一份浓缩、精炼的摘要（通常 1,000-2,000 个令牌）。

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

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

• 压缩法保持对话流，适合需要广泛来回交互的任务；
• 笔记法适合有明确里程碑的迭代开发；
• 多智能体架构处理复杂的研究和分析，其中并行探索能带来收益。

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

上下文工程：根本转变

上下文工程代表了我们使用 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 的支持。