AI Agent 的高效上下文工程¶

发表于 2025 年 9 月 29 日，Anthropic

上下文是 AI Agent 的关键资源，但它是有限的。 本文探讨如何为 Agent 有效策划和管理上下文。

上下文工程 vs. 提示工程¶

提示工程正在演进为一门更广泛的学科——上下文工程。 在应用 AI 领域，经过几年以提示工程为主导的发展之后，一个新术语出现了：上下文工程（context engineering）。用语言模型构建应用的重心，正在从"找到恰当的词句"转向一个更宏观的问题——什么样的上下文配置最有可能触发模型的期望行为。

上下文（Context） 指的是在对 LLM 进行采样时传入的全部 token 集合。工程（Engineering） 的问题则是：在 LLM 固有的限制下，如何优化 token 的效用，从而稳定地达成期望结果。高效使用 LLM 通常需要"以上下文的视角思考"——考虑任意时刻 LLM 可用的整体状态，以及这种状态可能产生什么行为。

在 Anthropic，我们将上下文工程视为提示工程的自然演进。提示工程关注如何撰写和组织 LLM 指令以获得最优结果。上下文工程 则关注如何在 LLM 推理过程中策划和维护最优的 token 集合——包括提示之外所有可能进入上下文的信息。

在早期 LLM 工程中，提示编写是 AI 工程工作的最大组成部分，因为大多数场景只需要为一次性分类或文本生成任务优化提示。提示工程的主要关注点是如何写出有效的提示——特别是系统提示。然而，随着我们构建跨越多轮交互、更长时间范围的更强 Agent，就需要管理整个上下文状态的策略（系统指令、工具、Model Context Protocol (MCP)、外部数据、消息历史等）。

Agent 在循环运行时会生成越来越多可能与下一轮推理相关的数据，这些信息必须被周期性地精炼。上下文工程是一门艺术和科学——从不断演化的可用信息宇宙中，策划出什么应该进入有限的上下文窗口。

与编写提示这个离散任务不同，上下文工程是迭代进行的——每次决定向模型传入什么内容时，都需要进行一次策划。

为什么上下文工程对构建强大 Agent 至关重要¶

上下文窗口存在"注意力预算"——token 越多，模型的信息回忆能力越差。 尽管 LLM 在速度和管理大量数据方面优于人类，它们在某个临界点同样会失去焦点或产生混淆。对"大海捞针"（needle-in-a-haystack）基准测试的研究揭示了上下文腐化（context rot） 的概念：随着上下文窗口中 token 数量增加，模型从上下文中准确回忆信息的能力会下降。

虽然不同模型的衰减程度不同，但这一特性在所有模型中都会出现。因此，上下文必须被视为一种边际收益递减的有限资源。就像人类有限的工作记忆容量一样，LLM 有一个"注意力预算"——在解析大量上下文时会被消耗。每个新增 token 都会在某种程度上消耗这一预算，增加了精心策划可用 token 的必要性。

这种注意力稀缺源于架构层面的限制。LLM 基于 Transformer 架构，该架构使得每个 token 都能关注整个上下文中的其他所有 token。对于 n 个 token，这产生了 n² 的两两关系。

随着上下文长度增加，模型捕捉这些两两关系的能力被摊薄，在上下文大小和注意力聚焦之间产生了天然的张力。此外，模型从训练数据分布中形成注意力模式——而训练数据中短序列更为常见。这意味着模型对于上下文范围内的长距离依赖关系，拥有更少的经验和更少的专用参数。

位置编码插值等技术允许模型通过将较长序列适配到原始训练的较短上下文来处理更长序列，但在 token 位置理解方面会有一定程度的退化。这些因素创造了一个性能梯度，而非硬性悬崖：模型在较长上下文中仍然高度能干，但与较短上下文相比，在信息检索和长距离推理方面的精确度可能有所下降。

这些现实意味着，深思熟虑的上下文工程对于构建强大的 Agent 是不可或缺的。

有效上下文的构成¶

好的上下文工程 = 找到最小化的高信号 token 集合，最大化期望结果的概率。 鉴于 LLM 受限于有限的注意力预算，好的上下文工程意味着找到尽可能最小的高信号 token 集合，使期望结果的概率最大化。实施起来说易行难，但以下内容阐述了这一指导原则在不同上下文组件中的实践含义。

系统提示¶

系统提示需要在"过于具体"和"过于笼统"之间找到恰当的抽象高度。 系统提示应当极其清晰，使用简洁直接的语言，在恰当的抽象高度（right altitude） 为 Agent 呈现思路。恰当的高度是两种常见失败模式之间的"金发女孩区间"。一个极端是：工程师硬编码复杂、脆弱的逻辑来引出精确的 Agent 行为——这会造成脆弱性并增加维护复杂度。另一个极端是：工程师提供模糊、高层级的指导，未能给出具体信号，或者错误地假设共享上下文。最优高度在两者之间取得平衡：足够具体以有效引导行为，又足够灵活以提供强有力的启发式规则。

建议将提示组织为不同的章节（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），使用 XML 标签或 Markdown 标题来分隔各部分——尽管随着模型能力增强，精确的格式可能变得不那么重要。

无论结构如何，目标是用最少的信息完整勾勒期望行为。（注意：最少并不一定意味着简短；必须预先提供足够的信息以确保模型遵循期望行为。）最佳做法是先用最好的模型测试一个最小化的提示，然后根据初始测试中发现的失败模式，添加清晰的指令和示例来提升性能。

工具¶

工具定义了 Agent 与其信息/行动空间的契约——必须促进效率。 工具允许 Agent 与环境交互，并在工作时拉取新的上下文。因为工具定义了 Agent 与其信息/行动空间之间的契约，工具促进效率极其重要——既要返回 token 高效的信息，又要鼓励高效的 Agent 行为。

正如《为 AI Agent 编写工具》中讨论的，工具应该被 LLM 充分理解，并且功能之间的重叠最小化。类似于设计良好的代码库中的函数，工具应当自包含、对错误健壮，并且对其预期用途极其清晰。输入参数应当描述性强、无歧义，并且发挥模型的固有优势。

最常见的失败模式之一是工具集臃肿——覆盖过多功能，或在该使用哪个工具的决策点上造成模糊。"如果一个人类工程师都无法明确说出某个场景该用哪个工具"，AI Agent 也不能指望做得更好。策划一个最小可行工具集也能在长时间交互中更可靠地维护和精简上下文。

示例¶

示例（few-shot）依然是最有效的实践之一——但要精选经典示例，而非堆砌边缘案例。 提供示例（few-shot prompting）是一项众所周知的最佳实践，Anthropic 继续强烈推荐。然而，团队经常在提示中塞入一长串边缘案例，试图表达每一条可能的规则。我们不推荐这样做。相反，建议策划一组多样化的、具有代表性的示例，有效展现期望行为。"对于 LLM 来说，示例就是'一图胜千言'中的那张图。"

跨不同上下文组件（系统提示、工具、示例、消息历史等）的总体指导是：深思熟虑，保持上下文既有信息量又足够紧凑。

上下文检索与 Agent 搜索¶

从预加载式检索向"即时"（just-in-time）Agent 搜索策略演进。 在《构建有效的 AI Agent》中，我们强调了基于 LLM 的工作流与 Agent 之间的区别。此后，Anthropic 倾向于一个简单定义：Agent 就是 LLM 在循环中自主使用工具。

与客户合作的过程中，行业正在向这一简单范式趋同。随着底层模型变得更强，Agent 的自主性可以扩展：更聪明的模型使 Agent 能够独立应对复杂的问题空间并从错误中恢复。

如今，工程师对 Agent 上下文设计的思维方式正在转变。当前许多 AI 原生应用采用基于嵌入的推理前检索来呈现重要上下文。随着向更 Agent 化方案的过渡，团队越来越多地用"即时"（just in time）上下文策略来增强这些检索系统。

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

除了存储效率，这些引用的元数据提供了一种高效精炼行为的机制。对于在文件系统中操作的 Agent，tests 文件夹中名为 test_utils.py 的文件暗示着与 src/core_logic/ 中的文件不同的用途。文件夹层级、命名约定和时间戳都提供了重要信号，帮助人类和 Agent 理解如何以及何时使用信息。

让 Agent 自主导航和检索数据实现了渐进式披露（progressive disclosure）——允许 Agent 通过探索逐步发现相关上下文。每次交互都产生为下一个决策提供信息的上下文：文件大小暗示复杂度；命名约定暗示用途；时间戳可以作为相关性的代理。Agent 逐层构建理解，仅在工作记忆中保留必要内容，并利用笔记策略实现额外的持久化。这种自管理的上下文窗口使 Agent 聚焦于相关子集，而非淹没在详尽但可能无关的信息中。

这里有一个权衡：运行时探索比检索预计算数据更慢。需要有见解且深思熟虑的工程设计，以确保 LLM 拥有正确的工具和启发式规则来有效导航其信息景观。缺乏适当的引导时，Agent 可能因误用工具、追逐死胡同或未能识别关键信息而浪费上下文。

在某些场景下，最有效的 Agent 可能采用混合策略（hybrid strategy）——预先检索部分数据以提高速度，同时根据判断进行进一步的自主探索。"恰当"的自主程度边界取决于任务。Claude Code 采用这种混合模型：CLAUDE.md 文件被直接放入上下文，而 glob 和 grep 等基础工具允许它即时导航环境和检索文件，绕过了过时索引和复杂语法树的问题。

混合策略可能更适合内容不太动态的场景，如法律或金融工作。随着模型能力提升，Agent 设计将趋向于让智能模型自主行动，逐步减少人工策划。鉴于快速的进步，"做最简单的能用的事"可能仍然是构建基于 Claude 的 Agent 的最佳建议。

长时间任务的上下文工程¶

当 token 数量超过上下文窗口时，需要压缩、笔记和多 Agent 架构等专门技术。 长时间任务要求 Agent 在动作序列中保持连贯性、上下文和目标导向行为——当 token 数量超过 LLM 的上下文窗口时尤为如此。对于持续数十分钟到数小时的连续工作——如大型代码库迁移或全面研究项目——Agent 需要专门的技术来克服上下文窗口大小的限制。

等待更大的上下文窗口似乎是显而易见的方案。但可以预见的是，在可预见的未来，所有大小的上下文窗口都会面临上下文污染和信息相关性问题——至少在追求最强 Agent 性能的场景下如此。为了让 Agent 在延长的时间范围内有效工作，以下几种技术直接应对这些限制：压缩、结构化笔记和多 Agent 架构。

压缩（Compaction）¶

压缩是第一道防线——对接近上限的对话进行总结后重新开始。 压缩是将接近上下文窗口限制的对话内容进行总结，然后用总结初始化新的上下文窗口的做法。压缩通常是上下文工程中驱动更好长期连贯性的第一个杠杆。其核心是以高保真方式蒸馏上下文窗口内容，使 Agent 能够以最小的性能退化继续工作。

在 Claude Code 中，这通过将消息历史传递给模型进行总结和压缩来实现。模型保留架构决策、未解决的 bug 和实现细节，同时丢弃冗余的工具输出或消息。Agent 带着这些压缩后的上下文加上最近访问的五个文件继续工作。用户获得了连续性，无需担心上下文窗口限制。

压缩的艺术在于选择保留什么、丢弃什么——过于激进的压缩可能丢失微妙但关键的上下文，其重要性可能在后来才显现。对于实现压缩系统的工程师，建议在复杂的 Agent 追踪上仔细调优提示。从最大化召回率开始——确保压缩提示捕获每一条相关信息，然后迭代改进精确率——去除多余内容。

一个唾手可得的优化是清除工具调用和结果——一旦工具在历史深处被调用过，Agent 为什么还需要看到原始结果？最安全、最轻量的压缩形式之一是工具结果清除，最近已作为 Claude 开发者平台的功能推出。

结构化笔记（Structured Note-Taking）¶

让 Agent 将笔记持久化到上下文窗口之外，在需要时再拉回来。 结构化笔记（或称 Agent 记忆）是一种技术——Agent 定期将笔记写入上下文窗口之外的持久化存储中，这些笔记在后续被拉回上下文窗口。

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

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

上下文重置后，Agent 读取自己的笔记并继续多小时的训练序列或地下城探索。这种跨总结步骤的连贯性，使得仅在 LLM 上下文窗口中保存所有信息时不可能实现的长期策略成为可能。

作为 Sonnet 4.5 发布的一部分，Anthropic 在 Claude 开发者平台推出了公开测试版的记忆工具，通过文件系统使存储和查阅上下文窗口外信息变得更容易。这允许 Agent 随时间建立知识库、跨会话维护项目状态、并引用之前的工作而无需将一切保持在上下文中。

子 Agent 架构（Sub-Agent Architectures）¶

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

这实现了清晰的关注点分离——详细的搜索上下文保持隔离在子 Agent 内，而主 Agent 专注于综合和分析结果。这一模式在《我们如何构建多 Agent 研究系统》中有讨论，在复杂研究任务上相比单 Agent 系统展现了显著改善。

这些方法的选择取决于任务特征：

即使模型持续改进，在延长的交互中维持连贯性仍将是构建更有效 Agent 的核心问题。

结论¶

上下文工程代表了我们使用 LLM 构建应用的根本性转变。 随着模型变得更强，挑战不再仅仅是精心制作完美的提示——而是在每一步深思熟虑地策划什么信息进入模型有限的注意力预算。无论是为长时间任务实现压缩、设计 token 高效的工具，还是让 Agent 即时探索环境，指导原则始终不变：找到最小化的高信号 token 集合，最大化期望结果的概率。

这里概述的技术将随着模型改进而持续演进。更聪明的模型已经需要更少的规定性工程，允许 Agent 以更大的自主性运行。但即使能力持续扩展，将上下文视为宝贵的有限资源，仍将是构建可靠、有效 Agent 的核心原则。

在 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 的支持。