AI Agent的有效上下文工程

发布于 2025 年 9 月 29 日

上下文对 AI Agent 而言是关键但有限的资源。本文将探讨有效策划和管理为其提供支持的上下文的策略。

经过几年提示工程成为应用 AI 领域关注的焦点后，一个术语崭露头角：上下文工程。使用语言模型构建已越来越不关乎为提示找到合适的词语和短语，而更多是关于回答一个更宽泛的问题：“怎样的上下文配置最有可能让模型生成我们期望的行为？”

上下文指的是从大语言模型（LLM）采样时包含的 token 集合。而当前的工程问题是在 LLM 固有限制下，优化这些 token 的效用，以持续达成期望结果。有效驾驭 LLM 通常需要从上下文角度思考——即考虑 LLM 在任意时刻可用的整体状态，以及该状态可能产生的潜在行为。

在本文中，我们将探讨新兴的上下文工程艺术，并提供一套更完善的思维模型来构建可引导、高效的智能体。

上下文工程 vs. 提示工程

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

在 LLM 工程早期，提示是 AI 工程工作的最大组成部分，因为除日常聊天交互外，大多数用例都需要为一次性分类或文本生成任务优化提示。顾名思义，提示工程的主要焦点是如何编写有效的提示，特别是系统提示。然而，随着我们转向工程化更强大的智能体，这些智能体需要在多次推理和更长时间跨度中运行，我们需要管理整个上下文状态（系统指令、工具、Model Context Protocol（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 高效的信息，也要鼓励高效的智能体行为。

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

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

提供示例（又称少样本提示）是一个众所周知的实践，我们继续强烈建议使用。然而，团队常常会将一长串边缘情况塞入提示中，试图阐述 LLM 应遵循的每个可能的规则。我们不推荐这样做。相反，我们建议努力策划一组多样化、典范性的示例，以有效传达智能体的期望行为。对 LLM 而言，示例就是“一图胜千言”的“图”。

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

上下文检索与智能体搜索

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

在与客户合作过程中，我们看到业界正在趋同于这一简单范式。随着底层模型能力增强，智能体的自主性水平可以扩展：更智能的模型使智能体能够独立导航微妙的问题空间并从错误中恢复。

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

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

除了存储效率外，这些引用的元数据还提供了一种有效精炼行为的机制，无论是显式提供还是隐式。对于一个在文件系统中操作的智能体，一个名为 test_utils.py 的文件位于 tests 文件夹中，其用途暗示与位于 src/core_logic/ 文件夹中的同名文件不同。文件夹层次结构、命名约定和时间戳都提供了重要信号，帮助人类和智能体理解如何以及何时使用信息。

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

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

在某些场景下，最高效的智能体可能采用混合策略：预先检索一些数据以提高速度，然后自行决定进一步自主探索。选择“正确”自主程度的分界点取决于任务。Claude Code 是一个采用此混合模型的智能体：CLAUDE.md 文件被朴素地预先放入上下文，而 glob 和 grep 等原语使其能够导航环境并即时检索文件，有效避免了过时索引和复杂语法树的问题。

混合策略可能更适合内容变化较少的上下文，例如法律或财务工作。随着模型能力的提升，智能体设计将趋于让智能模型自主行动，人类策划逐渐减少。鉴于该领域的快速进步，“做最简单的有效方法”可能仍是我们给在 Claude 上构建智能体的团队的最佳建议。

面向长周期任务的上下文工程

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

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

压缩

压缩是一种实践：将接近上下文窗口限制的对话内容进行总结，然后用总结重新初始化一个新的上下文窗口。压缩通常是上下文工程中驱动更好长期连贯性的第一招。其核心是以高保真方式提炼上下文窗口的内容，使智能体能够以最小的性能衰减继续工作。

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

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

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

结构化笔记

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

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

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

上下文重置后，智能体会读取自己的笔记，并继续长达数小时的训练序列或地下城探索。这种跨摘要步骤的连贯性使得长周期策略成为可能，而如果将所有信息都保留在 LLM 的上下文窗口中，这些策略是不可能实现的。

作为 Sonnet 4.5 发布的一部分，我们在 Claude 开发者平台上公开发布了一个记忆工具的公开测试版，通过基于文件的系统使存储和查阅上下文窗口之外的信息变得更加容易。这允许智能体随时间积累知识库，跨会话维护项目状态，并在不将所有内容保留在上下文中的情况下参考先前的工作。

子智能体架构

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

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

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

• 压缩维护对话流程，适用于需要大量来回交互的任务；
• 笔记擅长迭代开发，有明确的里程碑；
• 多智能体架构处理复杂研究和分析，其中并行探索能带来更大收益。

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

结论

上下文工程代表了我们在 LLM 上构建方式的根本转变。随着模型能力增强，挑战不仅仅在于构思完美的提示——更在于深思熟虑地策划在每个步骤中哪些信息进入模型有限的注意力预算。无论你是在为长周期任务实现压缩、设计 token 高效的工具，还是让智能体能够即时探索其环境，指导原则始终如一：找到最小的高信号 token 集合，以最大化期望结果的可能性。

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

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

• 原文链接： anthropic.com/engineerin...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～