核验日期：2026-07-08

内容来源：Anthropic Engineering 官方技术博客。本文先作为 Claude Code 专区后台草稿入库，发布前应由内容人员复核标题、摘要、图片、来源链接与是否需要补充本站实践说明。

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

上下文是 AI 智能体的一项关键但有限的资源。在本文中，我们探讨如何有效筛选和管理驱动智能体运作的上下文。

来源：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
发布日期：2025-09-29

在过去几年里，提示工程一直是应用 AI 领域关注的焦点，如今一个新的术语开始受到重视：上下文工程。使用语言模型构建应用，正逐渐不再只是为提示词寻找合适的措辞，而是要回答一个更宽泛的问题：“怎样配置上下文，最有可能让模型产生我们期望的行为？”

上下文指的是从大语言模型（LLM）采样时所包含的一组 token。当前的工程问题，是在 LLM 固有约束下优化这些 token 的效用，从而稳定地达成某个期望结果。要有效驾驭 LLM，常常需要从上下文的角度思考，换句话说：考虑 LLM 在任意时刻可见的整体状态，以及这种状态可能带来的潜在行为。

在本文中，我们将探讨上下文工程这门正在兴起的技艺，并提供一个更精细的心智模型，用于构建可引导、有效的智能体。

上下文工程 vs. 提示工程

在 Anthropic，我们认为上下文工程是提示工程的自然演进。提示工程指的是为获得最佳结果而编写和组织 LLM 指令的方法（可参阅我们的文档，其中概述了实用的提示工程策略）。上下文工程指的是在 LLM 推理期间筛选和维护最优 token（信息）集合的一系列策略，其中也包括提示词之外可能进入上下文的所有其他信息。

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

在循环中运行的智能体会生成越来越多可能与下一轮推理相关的数据，而这些信息必须被周期性地精炼。上下文工程就是从这个不断变化、可能相关的信息宇宙中，筛选出应该进入有限上下文窗口的内容，这既是艺术也是科学。

与编写提示词这一离散任务不同，上下文工程是迭代式的；每当我们决定向模型传入什么内容时，筛选阶段都会发生。

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

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

虽然某些模型的退化更平缓，但这一特征在所有模型上都会出现。因此，必须把上下文视为一种边际收益递减的有限资源。人类拥有有限的工作记忆容量，LLM 也类似，在解析大量上下文时会动用自身的“注意力预算”。每引入一个新的 token，都会在某种程度上消耗这份预算，因此更需要谨慎筛选 LLM 可用的 token。

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

随着上下文长度增加，模型捕捉这些成对关系的能力会被摊薄，在上下文规模和注意力焦点之间形成天然张力。此外，模型的注意力模式来自训练数据分布，而在这些分布中，短序列通常比长序列更常见。这意味着模型对贯穿整个上下文的依赖关系经验更少，专门用于处理这类依赖的参数也更少。

像位置编码插值这样的技术，可以通过让模型适配原本训练时较小的上下文，使其处理更长序列，不过这也会带来一定的 token 位置理解退化。这些因素共同形成的是一条性能梯度，而不是一道硬悬崖：模型在较长上下文中仍然非常有能力，但与其在较短上下文中的表现相比，信息检索和长程推理的精度可能会下降。

这些现实意味着，周到的上下文工程是构建有能力智能体的必要条件。

有效上下文的构成

既然 LLM 受限于有限的注意力预算，好的上下文工程就意味着找到尽可能小的一组高信号 token，以最大化达成某个期望结果的可能性。真正做到这一点远比说起来难，但在下面这一节，我们会概述这条指导原则在上下文不同组成部分上的实践含义。

系统提示词应该极其清晰，并使用简单、直接的语言，在适合智能体的正确高度上呈现想法。正确高度位于两种常见失败模式之间的“恰到好处”区间。在一个极端，我们会看到工程师在提示词中硬编码复杂、脆弱的逻辑，以诱导出精确的智能体行为。这种方法会造成脆弱性，并随着时间推移增加维护复杂度。在另一个极端，工程师有时会给出含糊的高层指导，既无法为 LLM 提供关于期望输出的具体信号，又错误地假设双方共享某些上下文。最佳高度是在两者之间取得平衡：足够具体，可以有效引导行为；也足够灵活，可以为模型提供强有力的启发式准则来指导行为。

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

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

无论你决定如何组织系统提示词，都应该努力用最小的信息集合完整勾勒出你期望的行为。（注意，最小不一定意味着短；你仍然需要预先向智能体提供足够信息，确保它遵循期望行为。）最佳做法是先用可用的最佳模型测试一个最小提示词，观察它在你的任务上的表现，然后根据初始测试中发现的失败模式，加入清晰的指令和示例来改善性能。

工具让智能体能够作用于环境，并在工作过程中拉取新的额外上下文。因为工具定义了智能体与其信息/行动空间之间的契约，所以工具促进效率极其重要：既要返回 token 高效的信息，也要鼓励智能体采取高效行为。

在《Writing tools for AI agents – with AI agents》中，我们讨论过如何构建 LLM 容易理解、功能重叠最少的工具。类似于设计良好的代码库中的函数，工具应该自包含、对错误具备稳健性，并且在预期用途上极其清晰。输入参数也同样应该描述性强、无歧义，并且发挥模型的固有优势。

我们看到的最常见失败模式之一，是工具集臃肿，覆盖了过多功能，或导致智能体在选择该使用哪个工具时面对模糊的决策点。如果人类工程师都无法明确说出某个场景下应该使用哪个工具，就不能期待 AI 智能体做得更好。正如后文将讨论的，为智能体筛选出一个最小可行工具集，也能让长交互中的上下文维护和修剪更加可靠。

提供示例，也就是 few-shot prompting，是一个众所周知的最佳实践，我们仍然强烈建议采用。不过，团队经常会把一长串边界情况塞进提示词，试图阐明 LLM 在特定任务中应遵循的每一种可能规则。我们不建议这样做。相反，我们建议用心筛选一组多样且典型的示例，有效呈现智能体的期望行为。对于 LLM 来说，示例就是“胜过千言万语的图像”。

我们对上下文不同组成部分（系统提示词、工具、示例、消息历史等）的总体建议是：保持审慎，让上下文信息充分但紧凑。现在让我们深入讨论如何在运行时动态检索上下文。

上下文检索与智能体式搜索

在《Building effective AI agents》中，我们强调了基于 LLM 的工作流与智能体之间的区别。自那篇文章发布以来，我们越来越倾向于使用一个简单定义来描述智能体：LLM 在循环中自主使用工具。

在与客户合作的过程中，我们看到整个领域正在朝这个简单范式收敛。随着底层模型变得更有能力，智能体的自治水平也可以扩展：更聪明的模型让智能体能够独立穿越细微复杂的问题空间，并从错误中恢复。

我们现在看到，工程师对智能体上下文设计的思考方式正在发生转变。如今，许多 AI 原生应用会采用某种基于嵌入的推理前检索，在模型推理之前浮现重要上下文供智能体推理。随着领域转向更智能体化的方法，我们越来越常看到团队用“即时”上下文策略增强这些检索系统。

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

除了存储效率之外，这些引用的元数据也提供了一种高效细化行为的机制，无论这些元数据是被显式提供的，还是可以凭直觉推断出来的。对于一个在文件系统中运行的智能体来说，tests 文件夹中名为 test_utils.py 的文件，与位于 src/core_logic/ 中同名文件所暗示的用途不同。文件夹层级、命名约定和时间戳都会提供重要信号，帮助人类和智能体理解应该如何以及何时使用信息。

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

当然，这里存在取舍：运行时探索比检索预先计算的数据更慢。不仅如此，还需要有主见且周到的工程设计，确保 LLM 具备正确的工具和启发式准则，能够有效导航其信息景观。如果缺乏适当指导，智能体可能会误用工具、追逐死胡同，或无法识别关键信息，从而浪费上下文。

在某些场景中，最有效的智能体可能会采用混合策略：为了速度预先检索一部分数据，同时在其自行判断下继续进行进一步的自主探索。什么是“正确”的自治水平，其决策边界取决于任务。Claude Code 就是采用这种混合模型的智能体：CLAUDE.md 文件会被直接预先放入上下文，而 glob 和 grep 这类原语则允许它导航环境并即时检索文件，从而有效绕过陈旧索引和复杂语法树带来的问题。

对于内容动态性较低的场景，例如法律或金融工作，混合策略可能更适合。随着模型能力提高，智能体式设计会逐渐走向让智能模型以智能方式行动，并逐步减少人工筛选。鉴于该领域进展迅速，“做能奏效的最简单的事”很可能仍是我们给基于 Claude 构建智能体的团队的最佳建议。

长周期任务的上下文工程

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

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

压缩

压缩是指将一段接近上下文窗口上限的对话进行摘要，然后用该摘要重新启动一个新的上下文窗口。压缩通常是上下文工程中用于提升长期连贯性的第一根杠杆。其核心在于以高保真方式提炼上下文窗口中的内容，让智能体能够以最小的性能退化继续工作。

例如，在 Claude Code 中，我们的实现方式是把消息历史传给模型，让模型摘要并压缩其中最关键的细节。模型会保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。随后，智能体可以基于这个压缩后的上下文，以及最近访问的五个文件继续工作。用户能获得连续性，而不必担心上下文窗口限制。

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

一个容易处理的多余内容例子是清理工具调用及其结果。一旦某个工具调用已经位于消息历史深处，智能体为什么还需要再次看到原始结果？最安全、最轻量的压缩形式之一就是工具结果清理，它最近已作为 Claude Developer Platform 的一项功能发布。

结构化笔记

结构化笔记，也称智能体记忆，是一种让智能体定期把笔记写入上下文窗口之外的持久化记忆中的技术。这些笔记会在之后某些时刻被重新拉回上下文窗口。

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

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

在上下文重置之后，智能体会读取自己的笔记，并继续多小时的训练序列或地牢探索。这种跨摘要步骤的连贯性，使长周期策略成为可能；如果仅把所有信息保留在 LLM 的上下文窗口中，这是无法实现的。

作为 Sonnet 4.5 发布的一部分，我们在 Claude Developer Platform 上以公开测试版形式发布了一个记忆工具，让智能体更容易通过基于文件的系统，在上下文窗口之外存储和查询信息。这允许智能体随着时间积累知识库、跨会话维护项目状态，并引用过去的工作，而无需把所有东西都保留在上下文里。

子智能体架构

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

这种方法实现了清晰的关注点分离：详细的搜索上下文被隔离在子智能体内部，而主导智能体专注于综合和分析结果。这个模式在《How we built our multi-agent research system》中有所讨论，它在复杂研究任务上相比单智能体系统显示出显著改进。

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

• 压缩可以为需要大量来回交互的任务维持对话流；
• 记笔记擅长处理具有清晰里程碑的迭代开发；
• 多智能体架构适合复杂研究和分析，在这类任务中，并行探索会带来回报。

即使模型继续改进，如何在长时间交互中维持连贯性，仍将是构建更有效智能体的核心挑战。

结论

上下文工程代表了我们使用 LLM 构建应用方式的一次根本转变。随着模型变得更有能力，挑战不再只是精心编写完美提示词，而是要在每一步都审慎筛选哪些信息进入模型有限的注意力预算。无论你是在为长周期任务实现压缩、设计 token 高效的工具，还是让智能体能够即时探索环境，指导原则始终相同：找到最小的一组高信号 token，使其最大化达成期望结果的可能性。

随着模型改进，我们概述的技术也会继续演进。我们已经看到，更聪明的模型需要更少规定式工程，让智能体能以更高自治度运行。但即使能力继续扩展，把上下文视为珍贵且有限的资源，仍将是构建可靠、有效智能体的核心。

立即在 Claude Developer Platform 中开始使用上下文工程，并通过我们的记忆与上下文管理 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 的支持。