AI 智能体的有效上下文工程
发布日期：2025 年 9 月 29 日
简介
"上下文是 AI 智能体的关键但有限资源。"本文探讨了有效策划和管理驱动智能体的上下文的策略。
经过几年的提示工程在应用 AI 中成为关注焦点后，一个新术语已经崭露头角：上下文工程。使用语言模型进行构建越来越少地关乎寻找提示的正确措辞，而更多地关乎回答这个更宽泛的问题："什么样的上下文配置最有可能产生我们模型的期望行为？"
上下文指从大型语言模型 (LLM) 进行采样时包含的令牌集合。工程问题在于针对 LLM 的固有约束优化这些令牌的实用性，以便始终如一地实现期望结果。有效地驾驭 LLM 通常需要在上下文中思考——换句话说：考虑 LLM 在任何给定时刻可用的整体状态，以及该状态可能产生的潜在行为。
本文探讨了上下文工程这门新兴学科，并为构建可控、高效的智能体提供了精细化的思维模型。
上下文工程 vs. 提示工程
在 Anthropic，我们将上下文工程视为提示工程的自然延伸。提示工程指为优化 LLM 结果而编写和组织指令的方法。上下文工程指的是在 LLM 推理期间策划和维护最优令牌集合的一套策略，包括可能出现在提示之外的所有其他信息。
在使用 LLM 的早期，提示编写是 AI 工程工作的最大组成部分，因为日常聊天之外的大多数用例都需要为一次性分类或文本生成任务优化的提示。正如术语所暗示的，提示工程的主要焦点是如何编写有效提示，特别是系统提示。然而，随着我们朝着更强大的智能体工程迈进，这些智能体在多个推理轮次和更长时间范围内运作，我们需要管理整个上下文状态的策略（系统指令、工具、Model Context Protocol (MCP)、外部数据、消息历史等）。
在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据，这些信息必须循环精炼。上下文工程是从不断演变的可能信息宇宙中，"艺术和科学地"策划哪些内容将进入有限上下文窗口的过程。
与编写提示的离散任务不同，上下文工程是迭代的，每次我们决定向模型传递什么时都会进行策划。
为什么上下文工程对构建强大的智能体很重要
尽管 LLM 速度快且能处理越来越多的数据，但我们观察到 LLM 与人类一样，在某一点会失去焦点或经历混淆。针对"干草堆中寻针"样式基准的研究发现了上下文衰减的概念：随着上下文窗口中的令牌数增加，模型从该上下文准确回忆信息的能力会降低。
虽然某些模型表现出比其他模型更温和的性能下降，但这种特征在所有模型中出现。因此，上下文必须被视为具有收益递减的有限资源。如人类一样，LLM 拥有有限的"注意力预算"，在解析大量上下文时会消耗这个预算。引入的每个新令牌都会按某种程度消耗这个预算，增加了仔细策划可用于 LLM 的令牌的必要性。
这种注意力稀缺源于 LLM 的架构约束。LLM 基于transformer 架构，该架构使每个令牌能够"注意到"整个上下文中的每个其他令牌。这导致 n 个令牌产生 n² 对对关系。
随着上下文长度增加，模型捕获这些对对关系的能力变得捉襟见肘，在上下文大小和注意力焦点之间产生自然张力。此外，模型从训练数据分布发展其注意力模式，其中较短的序列通常比较长的序列更常见。这意味着模型对上下文范围依赖性的经验较少，参数也较专业。
位置编码插值等技术允许模型通过适应原始训练的较小上下文来处理更长的序列，尽管令牌位置理解会有一定衰减。这些因素造成了性能梯度而非硬崖：模型在较长上下文中保持高度能力，但在信息检索和长距离推理中的精度可能低于较短上下文的性能。
这些现实情况意味着深思熟虑的上下文工程对构建强大的智能体至关重要。
有效上下文的构成
鉴于 LLM 受有限注意力预算的限制，好的上下文工程意味着找到最小的可能的高信号令牌集合，最大化某种期望结果的可能性。实施这一实践说起来容易，做起来难，但在以下部分中，我们概述了这一指导原则在上下文不同组成部分的实际含义。
系统提示
系统提示应非常清晰，使用简洁、直接的语言以正确的高度呈现思想。正确的高度是两种常见失败模式之间的"金发姑娘"区域。在一个极端，我们看到工程师在提示中硬编码复杂、脆弱的逻辑以引发精确的智能体行为。这种方法会造成脆弱性并随时间增加维护复杂性。在另一个极端，工程师有时提供模糊的高层级指导，未能为 LLM 提供所需输出的具体信号或错误地假设共享上下文。最优高度实现平衡：足够具体以有效指导行为，但足够灵活以为模型提供强有力的启发式。
在频谱的一端，我们看到脆弱的 if-else 硬编码提示，在另一端是过于笼统或错误地假设共享上下文的提示。
我们建议将提示组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 头等技术来划分这些部分，尽管随着模型变得更强大，提示的确切格式可能变得不那么重要。
无论如何构构系统提示，你应该力求找到完全概述期望行为的最少信息。（注意最少并不一定意味着简短；你仍需提前向智能体提供充分信息以确保其坚持期望行为。）最好从用最好可用的模型测试最少提示开始，以了解它在你的任务上的性能，然后根据初始测试中发现的失败模式添加清晰的指令和例子以改进性能。
工具
工具允许智能体与其环境互动并在工作过程中拉入新增上下文。因为工具定义了智能体与其信息/行为空间之间的契约，工具促进效率至关重要，既要返回令牌高效的信息，又要鼓励高效的智能体行为。
在《为 AI 智能体编写工具》一文中，我们讨论了构建 LLM 理解且功能重叠最少的工具。类似于设计良好的代码库的函数，工具应自包含、鲁棒应对错误，并对其预期用途极其清晰。输入参数同样应描述性强、无歧义，并符合模型的固有优势。
我们看到的最常见失败模式之一是过度膨胀的工具集，覆盖太多功能或导致关于应使用哪个工具的模糊决策点。如果人类工程师不能明确说出在给定情况下应使用哪个工具，AI 智能体也不能被期望做得更好。如我们稍后讨论的，为智能体策划最少可行工具集也可导致更可靠的维护和长期交互的上下文修剪。
提供例子，即所谓的少样本提示，是一种众所周知的最佳实践，我们继续强烈建议。然而，团队经常将大量边界情况塞入提示中，试图阐明 LLM 对特定任务应遵循的每项可能规则。我们不建议这样做。相反，我们建议努力策划一套多样、规范的例子，有效传达智能体的期望行为。对于 LLM，例子是"一图胜千言"。
我们对上下文的不同组成部分（系统提示、工具、例子、消息历史等）的总体指导是深思熟虑且保持上下文信息充分但紧凑。现在让我们深入了解在运行时动态检索上下文。
上下文检索和智能体搜索
在《构建有效的 AI 智能体》中，我们强调了基于 LLM 的工作流与智能体之间的差异。自那篇文章发布后，我们倾向于对智能体的一个简单定义：LLM 在循环中自主使用工具。
与客户合作，我们看到该领域趋向于这一简单范式。随着底层模型变得更强大，智能体的自主程度可以扩展：更智能的模型允许智能体独立导航微妙问题空间并从错误中恢复。
我们现在看到工程师思考智能体上下文设计方式的转变。如今，许多 AI 原生应用采用某种形式的基于嵌入的推理前检索，以为智能体要推理的内容呈现重要上下文。随着该领域过渡到更多智能体方法，我们越来越看到团队使用"即时"上下文策略增强这些检索系统。
与其预先处理所有相关数据，以"即时"方法构建的智能体维护轻量标识符（文件路径、存储查询、网络链接等），并使用这些引用在运行时通过工具动态将数据加载到上下文中。Anthropic 的智能体编码解决方案 Claude Code 使用这种方法对大型数据库执行复杂数据分析。该模型可编写有针对性的查询、存储结果，并利用 Bash 命令如 head 和 tail 来分析大量数据，而无需将完整数据对象加载到上下文中。这种方法镜像人类认知：我们通常不记忆整个信息集，而是引入文件系统、收件箱和书签等外部组织和索引系统来按需检索相关信息。
超越存储效率，这些引用的元数据提供了一种机制来有效精炼行为，无论是明确提供还是直观的。对于在文件系统中运行的智能体，名为 test_utils.py 的文件在 tests 文件夹中的出现暗示了与位于 src/core_logic/ 文件夹中同名文件的不同目的。文件夹层级、命名约定和时间戳都提供了重要信号，帮助人类和智能体理解如何和何时利用信息。
让智能体自主导航和检索数据也启用了渐进式披露——换句话说，允许智能体通过探索逐步发现相关上下文。每次交互产生通知下一决策的上下文：文件大小暗示复杂性；命名约定暗示目的；时间戳可作为相关性的代理。智能体可逐层组合理解，仅在工作记忆中维持必要的内容，并利用笔记策略以获得额外持久性。这种自管理上下文窗口使智能体专注于相关子集，而非溺水于详尽但可能无关的信息。
当然，存在权衡：运行时探索比检索预先计算的数据慢。不仅如此，还需要有见地且深思熟虑的工程，确保 LLM 拥有正确的工具和启发式方法以有效导航其信息景观。没有适当指导，智能体可能因误用工具、追寻死胡同或未能识别关键信息而浪费上下文。
在某些设置中，最有效的智能体可能采用混合策略，为速度预先检索某些数据，并自行选择进一步自主探索。"正确"自主程度的决策边界取决于任务。Claude Code 是采用这种混合模型的智能体：CLAUDE.md 文件被天真地放入前期上下文，而 glob 和 grep 等原语允许它导航其环境并即时检索文件，有效绕过了陈旧索引和复杂语法树的问题。
混合策略可能更适合内容动态性较低的上下文，如法律或财务工作。随着模型能力改进，智能体设计将趋向于让智能模型智能地行动，逐步减少人工策划。鉴于该领域进展迅速，"做能工作的最简单事情"可能仍是我们对基于 Claude 构建智能体的团队最好的建议。
长期任务的上下文工程
长期任务要求智能体在令牌计数超过 LLM 上下文窗口的一系列行为中维护连贯性、上下文和目标导向行为。对于跨越数十分钟到数小时连续工作的任务，如大型代码库迁移或全面研究项目，智能体需要专门技术来解决上下文窗口大小限制。
等待更大的上下文窗口似乎是明显的策略。但在可预见的未来，所有大小的上下文窗口可能会受到上下文污染和信息相关性问题的约束——至少对于需要最强智能体性能的情况。为使智能体能够在扩展时间范围内有效工作，我们开发了几种直接应对这些上下文污染约束的技术：压缩、结构化笔记和多智能体架构。
压缩
压缩是指采用接近上下文窗口限制的对话，总结其内容，并用摘要重新启动新上下文窗口的实践。压缩通常充当上下文工程的第一个杠杆，以驱动更好的长期连贯性。从本质上说，压缩以高保真方式蒸馏上下文窗口的内容，使智能体能够以最少性能衰减继续。
例如，在 Claude Code 中，我们通过将消息历史传递给模型以总结和压缩最关键细节来实现这一点。模型保留架构决策、未解决的错误和实现细节，同时丢弃冗余工具输出或消息。智能体随后可继续这个压缩上下文加最近访问的五个文件。用户获得连贯性，无需担心上下文窗口限制。
压缩的艺术在于选择保留什么对比舍弃什么，因为过度激进的压缩可导致丧失微妙但关键的上下文，其重要性仅在稍后变得明显。对于实施压缩系统的工程师，我们建议在复杂智能体跟踪上仔细调整你的提示。首先通过最大化回忆来确保你的压缩提示从跟踪中捕获每个相关信息片段，然后通过消除多余内容迭代改进精度。
低垂的多余内容的一个例子是清除工具调用和结果——一旦工具在消息历史深处被调用，智能体为什么需要再看一遍原始结果？最安全、最轻触形式的压缩之一是工具结果清除，最近在 Claude 开发者平台上推出为一项功能。
结构化笔记
结构化笔记或智能体记忆是一种技术，其中智能体定期编写持久化到上下文窗口外部记忆的笔记。这些笔记稍后被拉回到上下文窗口中。
这种策略以最小开销提供持久记忆。如 Claude Code 创建待做事项清单，或你的自定义智能体维护 NOTES.md 文件，这个简单模式允许智能体跨复杂任务追踪进度，维护否则会在数十次工具调用中丢失的关键上下文和依赖项。
Claude 玩 Pokémon 展示了记忆如何在非编码领域转变智能体能力。智能体维护了数千个游戏步骤的精确计数——追踪目标如"在过去 1,234 步中，我一直在路线 1 训练我的 Pokémon，Pikachu 朝着 10 级的目标获得了 8 级"。无需任何关于记忆结构的提示，它开发了已探索区域的地图，记住了它已解锁的关键成就，并维护了战斗策略的战略笔记，帮助它了解哪些招式对不同对手最有效。
在上下文重置后，智能体阅读自己的笔记并继续数小时长的训练序列或地牢探索。这种跨总结步骤的连贯性启用了在仅将所有信息保存在 LLM 上下文窗口中时不可能的长期策略。
作为 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上的公开测试中发布了一个记忆工具，使通过基于文件的系统在上下文窗口外存储和查阅信息变得更容易。这允许智能体随时间构建知识库、跨会话维护项目状态，并引用之前的工作而无需将一切保持在上下文中。
子智能体架构
子智能体架构提供了绕过上下文限制的另一种方式。与其一个智能体试图维护整个项目的状态，专业化的子智能体可处理具有干净上下文窗口的聚焦任务。主智能体使用高级计划协调，同时子智能体执行深度技术工作或使用工具寻找相关信息。每个子智能体可广泛探索，使用数万个或更多令牌，但仅返回其工作的精缩、蒸馏摘要（通常 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 的支持。