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

在提示词工程成为应用型 AI 领域关注焦点数年之后，一个新的术语开始受到重视：上下文工程（context engineering）。使用语言模型构建应用，正逐渐不再只是为提示词寻找正确的措辞，而是更多地回答一个更广泛的问题：“什么样的上下文配置，最有可能让模型产生我们期望的行为？”

上下文（Context）是指从大语言模型（LLM）进行采样时所包含的一组 token。这里的工程（engineering）问题，是在 LLM 固有约束之下，尽可能优化这些 token 的效用，从而持续获得期望的结果。要有效驾驭 LLM，往往需要从上下文的角度思考。换句话说，就是要考虑任意时刻 LLM 所能看到的整体状态，以及这种状态可能诱发哪些行为。

在本文中，我们将探讨正在兴起的上下文工程实践，并为如何构建可控且高效的智能体提供一种更精炼的思维模型。

上下文工程与提示词工程

在 Anthropic，我们把上下文工程视为提示词工程的自然演进。提示词工程指的是，为了获得最佳结果而编写和组织 LLM 指令的方法（有关概览和实用的提示词工程策略，可参阅我们的文档）。而上下文工程，则是指在 LLM 推理过程中筛选和维护最佳 token 集合（信息集合）的一系列策略，其中还包括所有可能进入上下文、但并不属于提示词本身的信息。

在使用 LLM 进行工程开发的早期阶段，提示词是 AI 工程工作的最大组成部分，因为除了日常聊天之外，大多数用例都需要针对一次性分类或文本生成任务优化提示词。顾名思义，提示词工程主要关注如何编写有效的提示词，尤其是系统提示词。然而，随着我们开始构建能力更强、需要跨多轮推理并在更长时间范围内运行的智能体，我们就需要用新的策略来管理完整的上下文状态，包括系统指令、工具、Model Context Protocol（MCP）、外部数据、消息历史等。

一个循环运行的智能体会生成越来越多可能与下一轮推理相关的数据，而这些信息必须不断进行周期性的提炼。上下文工程，就是从这个持续变化、潜在信息不断增长的空间中，筛选哪些内容应进入有限上下文窗口的艺术与科学。

与一次性完成“写好一个提示词”的任务不同，上下文工程是一个迭代过程；每当我们决定要向模型传入什么内容时，都会发生一次上下文筛选。

为什么上下文工程对构建高能力智能体如此重要

尽管 LLM 速度很快，也能够处理越来越庞大的数据量，但我们的观察表明，它们和人类一样，到了一定程度也会失去注意力，或者变得混乱。针对“大海捞针”类基准测试的研究发现了所谓的上下文腐化（context rot）：随着上下文窗口中的 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 智能体能做得更好。正如后文会提到的，为智能体维护一套“最小可用工具集”，也有助于在长时间交互中更可靠地维护和裁剪上下文。

提供示例，也就是 few-shot prompting，是一个众所周知的最佳实践，我们至今仍然强烈建议这样做。不过，团队经常会为了阐明某项任务中 LLM 可能需要遵守的每一条规则，而把一长串边缘案例塞进提示词。我们并不推荐这样做。相反，我们建议精心挑选一组多样化、典型且具有代表性的示例，准确展示智能体应有的行为。对于 LLM 来说，示例就是“一图胜千言”的那张图。

对于上下文的不同组成部分，包括系统提示词、工具、示例、消息历史等，我们总体上的建议是：要有意识地进行筛选，让上下文信息充分，但保持紧凑。接下来，我们将讨论如何在运行时动态检索上下文。

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

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

通过与客户合作，我们看到整个行业正在逐渐收敛到这一简单范式。随着底层模型能力增强，智能体的自主程度也能够随之提高：模型越聪明，智能体就越能独立应对细腻复杂的问题空间，并从错误中恢复。

如今，我们看到工程师对智能体上下文设计的思考方式正在发生变化。目前，许多 AI 原生应用会在推理开始之前，使用某种基于 embedding 的检索方式，把重要上下文提前取出，供智能体推理。随着整个领域逐步转向更加智能体化的方法，我们越来越多地看到团队在这些检索系统之上加入“即时（just in time）”上下文策略。

与其事先处理所有可能相关的数据，采用“即时”方法构建的智能体会保留轻量级标识符，例如文件路径、保存的查询、网页链接等，然后在运行时通过工具，根据这些引用动态把数据加载进上下文。Anthropic 的智能体式编程解决方案 Claude Code 就使用了这种方法，对大型数据库执行复杂的数据分析。模型可以编写有针对性的查询、保存结果，并使用 head、tail 等 Bash 命令分析大量数据，而无需把完整数据对象一次性装入上下文。这种方法与人类认知非常相似：我们通常不会把整个信息语料库都背下来，而是借助文件系统、收件箱、书签等外部组织和索引系统，在需要时检索相关信息。

除了节省存储和上下文空间之外，这些引用本身的元数据也能帮助智能体高效调整行为，无论这些信号是被显式提供的，还是可以被模型直觉理解的。对于一个在文件系统中工作的智能体来说，位于 tests 文件夹中的 test_utils.py，与位于 src/core_logic/ 中同名文件的用途显然不同。文件夹层级、命名规范和时间戳，都提供了重要信号，帮助人类和智能体理解信息应该在何时、以何种方式被使用。

让智能体自主浏览和检索数据，还能够实现渐进式披露（progressive disclosure）。也就是说，智能体可以通过探索，逐步发现相关上下文。每一次交互都会产生新上下文，并影响下一步决策：文件大小暗示复杂度，命名规范提示用途，时间戳可以作为相关性的代理信号。智能体可以一层一层建立理解，只把当前必要的信息保留在工作记忆中，再通过记笔记等策略获得额外的持久性。这种由智能体自行管理的上下文窗口，可以让它把注意力集中在相关子集上，而不是被全面但可能无关的信息淹没。

当然，这里存在权衡：运行时探索比读取预先计算好的数据更慢。不仅如此，为了确保 LLM 拥有正确的工具和启发式原则，能够有效导航自己的信息环境，还需要进行有明确取舍、经过深思熟虑的工程设计。如果缺乏恰当引导，智能体可能会因为误用工具、追逐死胡同，或者无法识别关键信息而浪费上下文。

在某些场景中，最有效的智能体可能会采用混合策略：为了速度，先提前检索一部分数据；然后再根据自身判断，决定是否进行进一步的自主探索。究竟应该给予多大的自主程度，取决于具体任务。Claude Code 就是一个采用这种混合模型的智能体：系统会在一开始直接把 CLAUDE.md 文件放入上下文，同时提供 glob、grep 等基础能力，让它可以导航环境并按需即时检索文件，从而有效绕开陈旧索引和复杂语法树等问题。

对于内容变化较少的场景，例如法律或金融工作，这种混合策略可能更加合适。随着模型能力提升，智能体设计会越来越倾向于让聪明的模型以聪明的方式行动，而人类手工筛选的信息会越来越少。鉴于这个领域的发展速度如此之快，“做最简单但能奏效的方案”很可能仍然是我们给使用 Claude 构建智能体的团队最好的建议。

面向长时程任务的上下文工程

长时程任务要求智能体在一系列行动中保持一致性、上下文连续性和目标导向行为，而这些行动累积的 token 数量往往会超过 LLM 的上下文窗口。对于持续几十分钟乃至数小时的任务，例如大型代码库迁移或全面研究项目，智能体必须使用专门的技术来绕过上下文窗口大小限制。

等待未来出现更大的上下文窗口，看起来可能是一种显而易见的做法。但在可预见的未来，无论上下文窗口有多大，只要我们追求最强的智能体性能，就很可能仍然会受到上下文污染和信息相关性问题的影响。为了让智能体能够在更长时间范围内持续有效工作，我们开发了几种直接应对上下文污染限制的技术：压缩、结构化笔记和多智能体架构。

压缩（Compaction）

压缩，是指当一段对话接近上下文窗口上限时，对其中内容进行总结，然后利用这份总结重新启动一个新的上下文窗口。压缩通常是上下文工程中用于提升长期一致性的第一项手段。从本质上说，压缩就是以尽可能高的保真度提炼一个上下文窗口中的内容，让智能体能够在性能尽量少受影响的情况下继续工作。

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

压缩的艺术就在于决定什么该保留、什么该丢弃，因为过于激进的压缩可能会丢失一些细微但关键的上下文，而这些信息的重要性可能只有到后面才会显现。对于正在实现压缩系统的工程师，我们建议基于复杂的智能体轨迹认真调优压缩提示词。首先优先最大化召回率，确保压缩提示词能够捕捉轨迹中每一项相关信息；然后再通过迭代提高精确率，逐步剔除多余内容。

一种最容易先清理掉的冗余内容，就是历史中的工具调用和工具结果。既然某个工具调用已经发生在很久以前的消息历史中，智能体为什么还需要再次看到它当时的原始结果？最安全、改动最轻的一种压缩方式，就是清理工具结果；这一能力最近也作为 Claude Developer Platform 的一项功能发布。

结构化笔记（Structured note-taking）

结构化笔记，也可以称为智能体记忆，是一种让智能体定期写下笔记，并把这些笔记持久化保存到上下文窗口之外的技术。之后在需要时，再把这些笔记重新加载回上下文窗口。

这种策略只需要很小的额外开销，就能提供持久记忆。例如 Claude Code 会创建待办事项列表，或者你的自定义智能体维护一个 NOTES.md 文件。这个简单模式可以让智能体在复杂任务中持续跟踪进度，并保留那些否则可能在数十次工具调用后丢失的关键上下文和依赖关系。

子智能体架构（Sub-agent architectures）

子智能体架构是另一种绕过上下文限制的方法。与其让单个智能体尝试在整个项目期间维持全部状态，不如让多个专业化的子智能体各自处理聚焦任务，并拥有干净的上下文窗口。主智能体负责依据高层计划进行协调，而子智能体则执行深入的技术工作，或者使用工具寻找相关信息。每个子智能体可能会进行大量探索，消耗数万甚至更多 token，但最终只返回一份经过压缩和提炼的工作摘要，通常只有 1,000 到 2,000 个 token。

这种方法实现了清晰的关注点分离：详细的搜索上下文被隔离在各个子智能体内部，而主智能体则专注于综合和分析结果。我们在《我们如何构建多智能体研究系统》中讨论过这一模式；在复杂研究任务上，它相比单智能体系统带来了显著提升。

究竟该选择哪种方法，要取决于任务特征。例如：

压缩适合需要大量来回交互、又必须保持对话连续性的任务；

结构化笔记适合具有明确里程碑的迭代式开发；

多智能体架构适合复杂研究和分析任务，因为在这类任务中，并行探索能够带来显著收益。

即便模型还会继续进步，如何在长时间交互中保持一致性，依然会是构建更高效智能体的核心挑战。

结论

上下文工程代表了我们使用 LLM 构建系统时的一次根本性转变。随着模型能力增强，挑战已经不再只是写出一个完美提示词，而是在每一步都认真筛选：究竟哪些信息值得进入模型有限的注意力预算。无论你是在为长时程任务实现压缩，设计 token 效率更高的工具，还是让智能体能够即时探索环境，背后的指导原则始终相同：找到最小的一组高信号 token，并最大化获得目标结果的概率。

随着模型进步，我们在本文中介绍的这些技术还会继续演化。我们已经看到，越聪明的模型越不需要强约束、强规定式的工程设计，从而让智能体能够以更高自主性运行。但即便模型能力持续扩展，把上下文当作一种珍贵而有限的资源，仍然会是构建可靠、高效智能体的核心原则。