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

2025年9月29日

Anthropic

概览

要构建有效、可靠的 AI 智能体（Agent），关键在于将“上下文”（Context）视为一种有限且宝贵的资源，并对其进行精心的管理和优化。

1. 从“提示工程”到“上下文工程”的演进

提示工程：主要关注如何编写和组织 LLM 的指令（尤其是系统提示）以获得最佳单次输出。
上下文工程：是一个更宏观的概念，它关注在 LLM 的整个运行周期中，如何管理和维护进入其“上下文窗口”的所有信息，包括系统提示、工具、外部数据、历史对话等。这是一个持续、迭代的优化过程。

2. 上下文是有限的关键资源

LLM 和人类一样，拥有有限的 “注意力预算” （attention budget）。
当上下文窗口中的信息（tokens）过多时，模型的性能会下降，出现 “上下文衰减”（context rot） 现象，即模型难以准确回忆或利用其中的信息。
因此，必须精心筛选进入上下文的信息，目标是：用最少、最高效的信息（high-signal tokens）来最大化达成预期结果的可能性。

3.有效上下文的结构

原则：在任何时刻，放入“最小但高信号”的 token 集合，以最大化达成目标的概率。
系统提示：把握“合适高度”——足够具体以引导行为，不要用脆弱的硬编码逻辑；结构化分区（背景、指令、工具指引、输出格式）；先最小可行，再基于失效模式增补。
工具设计：少而精、边界清晰、参数明确、返回信息token高效；避免功能重叠与选择歧义。
示例选择：少量、多样、典型的 few-shot 胜过塞满规则与边角案例；示例即高效“行为图片”。

4. 动态与混合式上下文检索

文章倡导从“预先加载所有信息”转向 “即时”（just-in-time） 的上下文检索策略。
智能体不应一次性将所有可能相关的数据都加载到上下文中，而是应该利用工具（如文件系统、数据库查询）在需要时动态地、自主地检索信息。
这种方法模仿了人类的认知方式（我们不会记住所有事，而是知道去哪里查找），可以实现 “渐进式信息披露”，让智能体更专注、更高效。在实践中，将预加载与即时检索相结合的 混合策略 通常效果最佳。

5. 处理长时程任务的三大策略

对于超出单个上下文窗口容量的复杂、长期任务，文章提出了三种关键技术：

压缩（Compaction）：
- 做法：在对话历史接近上下文窗口极限时，让模型对其进行总结和压缩，然后用这个精简的摘要开启一个新的对话窗口。
- 目的：在保留核心信息（如决策、未解决的问题）的同时，丢弃冗余内容，从而实现任务的连贯性。
结构化笔记/记忆（Structured Note-taking / Agentic Memory）：
- 做法：让智能体在执行任务时，定期将关键信息、待办事项、进度等写入一个外部“记忆体”（如一个NOTES.md文件），并在需要时读取。
- 目的：为智能体提供持久化记忆，使其能够在多次上下文重置后依然保持对任务的长期追踪和规划能力。
子代理架构（Sub-agent Architectures）：
- 做法：将一个复杂任务分解，由一个主代理负责宏观规划和协调，并将具体的、深入的子任务分配给多个专门的子代理去完成。每个子代理在自己的独立上下文中工作，完成后仅向主代理返回一个精炼的总结。
- 目的：实现“关注点分离”，避免主代理的上下文被海量细节淹没，从而高效处理复杂的研究和分析任务。

正文

上下文是 AI 智能体的关键但有限的资源。本文将探讨如何有效策划和管理驱动它们的上下文。

在过去几年里，提示词工程（prompt engineering） 一直是应用 AI 的焦点，而如今一个新术语开始受到关注：上下文工程（context engineering）。构建基于语言模型的系统，已经不再只是寻找正确的提示词和短语，而是要回答一个更广泛的问题：“哪种上下文配置最有可能让模型生成我们期望的行为？”

上下文（Context） 是指在从大型语言模型（LLM）中采样时包含的一组 token。所谓工程问题，就是要在 LLM 固有的限制下，优化这些 token 的效用，从而持续获得理想的结果。要想有效驾驭 LLM，往往需要在上下文中思考——换句话说：考虑在任意时刻 LLM 可用的整体状态，以及该状态可能带来的行为结果。本文将探讨新兴的上下文工程艺术，并提供一种更精细的思维模型，用于构建可引导、有效的智能体。

上下文工程 vs 提示词工程

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

在早期，提示词是 LLM 工程工作中最大的组成部分，因为大多数超出日常聊天的应用场景都需要针对一次性分类或文本生成任务优化提示词。顾名思义，提示词工程主要关注如何编写有效的提示词，尤其是系统提示词。但随着我们逐渐转向构建能够跨多个推理回合、长期运行的更强大智能体，我们需要能够管理整个上下文状态的策略（系统指令、工具、模型上下文协议 MCP、外部数据、消息历史等）。

当智能体在循环中运行时，它会生成越来越多可能与下一步推理相关的数据，这些信息必须被不断提炼。上下文工程就是在不断演化的庞大信息宇宙中，艺术与科学地挑选进入有限上下文窗口的内容。

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

为什么上下文工程对构建强大智能体很重要

尽管 LLM 的速度和处理大规模数据的能力不断提升，但我们观察到 LLM 和人类一样，在一定程度上会失去专注或产生混乱。研究表明，随着上下文窗口中的 token 数量增加，模型从中准确提取信息的能力会下降，这被称为上下文衰减（context rot）。

虽然不同模型的退化程度有所差异，但这一现象普遍存在。因此，上下文必须被视为一种有限资源，且存在边际收益递减。就像人类有有限的工作记忆容量，LLM 也有“注意力预算”，每引入一个新的 token，都会消耗一部分预算，从而增加了对精心策划的必要性。

这种注意力稀缺性来自 LLM 的架构限制。LLM 基于Transformer 架构，其机制使得每个 token 都可以与上下文中的其他所有 token 建立联系。这导致当 token 数为 n 时，会产生 n² 对关系。

随着上下文长度增加，模型捕捉这些关系的能力被稀释，形成上下文大小与注意力集中度之间的天然张力。此外，模型的注意力模式主要来源于训练数据分布，而训练数据中短序列比长序列更常见。这意味着模型在处理全局依赖时经验不足、专用参数更少。

像位置编码插值这样的技术可以帮助模型处理更长序列，但也会导致 token 位置理解的退化。这些因素并不会导致模型性能的“悬崖式”下降，而是呈现渐进式衰减：模型在长上下文中依然有较强能力，但在信息检索和长程推理上，精确度会低于处理短上下文时的表现。

因此，深思熟虑的上下文工程对于构建强大智能体至关重要。

有效上下文的结构

鉴于 LLM 的注意力预算是有限的，良好的上下文工程意味着要找到尽可能少的高价值 token 集合，以最大化获得期望结果的可能性。实践起来远比说起来困难，但下面我们将逐一说明这一原则在不同上下文组件中的体现。

系统提示词（System prompts） 应当非常清晰，使用简洁、直接的语言，并以合适的“高度”呈现信息。所谓合适的高度，处于两个常见失败模式之间：

一种极端是工程师在提示词中硬编码复杂、脆弱的逻辑，以迫使模型产生精确的行为。这种方式会导致长期的脆弱性和维护复杂度增加。
另一种极端是提示词过于模糊和高层，无法给模型提供具体信号，或者错误地假设了共享上下文。

最优的提示词应当在这两者之间取得平衡：足够具体以有效引导行为，但同时保持灵活性，提供强有力的启发式线索。

系统提示词的校准 一端是脆弱的 if-else 硬编码提示词，另一端是过于笼统或假设共享上下文的提示词。

我们建议将提示词组织为不同部分（例如 <background_information>、<instructions>、## 工具使用指导、## 输出描述 等），并使用 XML 标签或 Markdown 标题来区分这些部分。虽然随着模型能力增强，提示词的具体格式可能逐渐变得不那么重要，但清晰的结构依然有帮助。

无论采用何种结构，你都应当追求最小化但完整的信息集。注意，“最小化”并不一定意味着“简短”；你仍需要在一开始就提供足够的信息来确保模型遵循预期行为。一个好方法是：先用最小化提示词测试最好的模型，看它在任务中的表现，然后基于失败点逐步补充清晰的指令和示例。

工具（Tools） 让智能体能与环境交互，并在工作中获取新的上下文。由于工具定义了智能体与其信息/操作空间之间的契约，因此工具必须促进高效性：既要返回 token 高效的信息，也要鼓励高效的智能体行为。

在为 AI 智能体编写工具一文中，我们强调了工具设计要便于 LLM 理解，并尽量避免功能重叠。就像设计良好的代码库函数一样，工具应当自包含、抗错误、并且用途明确。输入参数应当具有描述性、毫不含糊，并契合模型的固有优势。

常见失败模式之一是工具集过于庞大，覆盖过多功能，或导致在选择使用哪个工具时存在歧义。如果人类工程师都无法明确选择工具，那么 AI 智能体也不可能做得更好。相反，策划出最小可行的工具集，更利于长期维护和上下文精简。

示例（Examples） ——即少样本提示（few-shot prompting），依旧是最佳实践。但我们不建议将所有边缘情况塞进提示词中，而应当策划一组多样化的典型示例，有效展现期望行为。对于 LLM 来说，示例就像“胜过千言万语的图画”。

整体而言，我们的指导原则是：在系统提示词、工具、示例、消息历史等各个组件中，保持信息充实但紧凑。

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

在构建高效 AI 智能体一文中，我们曾强调基于 LLM 的工作流与智能体的区别。如今我们采用了一个更简单的定义：智能体 = LLM 在循环中自主使用工具。

随着底层模型变得更强大，智能体的自主性可以不断提升：更智能的模型能够独立探索复杂问题空间，并从错误中恢复。

目前我们看到的趋势是：许多 AI 原生应用仍使用嵌入检索在推理前提取相关上下文。但随着智能体方法的普及，越来越多团队开始使用“即时（just in time）上下文”策略。

这种方法不是预处理所有数据，而是通过轻量化的引用（文件路径、存储查询、网页链接等），在运行时使用工具动态加载数据。Anthropic 的智能体编程解决方案 Claude Code 就采用了这种方式，它通过写查询语句、存储结果、使用 Bash 命令（如 head 和 tail）来处理大规模数据，而无需一次性加载完整数据对象。这种方法类似于人类认知：我们不会死记所有信息，而是借助外部组织和索引系统（文件系统、收件箱、书签）按需获取。

此外，引用的元数据还能提供行为引导信号。例如，在文件系统中，tests 文件夹里的 test_utils.py 与 src/core_logic.py 下的同名文件用途就截然不同。文件夹层级、命名约定和时间戳，都会为人类和智能体提供重要线索。

这种自主导航和检索也让智能体能够渐进式地发现相关上下文。每次交互都会生成新的上下文，进而指导下一次决策：文件大小暗示复杂度；命名方式提示用途；时间戳则能作为相关性的代理。这样，智能体逐层构建理解，只保留必要的工作记忆，并通过“笔记”实现持久存储。

当然，代价是运行时探索比预先检索更慢；同时需要工程师进行深思熟虑的设计，否则智能体可能浪费上下文，误用工具，走入死胡同，或忽略关键信息。

某些场景下，最有效的策略可能是混合模式：部分数据提前加载以保证速度，而其他数据则由智能体按需探索。Claude Code 就是这样，它会在上下文中直接放入 CLAUDE.md 文件，但也能使用 glob 和 grep 即时检索文件，从而避免索引过时和语法树复杂度问题。

混合策略特别适用于内容相对静态的领域，如法律或金融。随着模型能力提升，智能体设计趋势将是让更智能的模型发挥更大自主性。

长期任务的上下文工程

长期任务要求智能体在长时间内保持连贯性、上下文和目标导向行为，这通常会超过 LLM 的上下文窗口限制。例如代码库迁移、综合研究项目等，可能持续数十分钟甚至数小时。

等待更大上下文窗口似乎是一个方案，但实际上，无论多大窗口都可能受到上下文污染和信息相关性问题的影响。因此我们研发了一些技术来解决：压缩（compaction）、结构化笔记（structured note-taking）、子智能体架构（sub-agent architectures）。

压缩（Compaction）

压缩是指在接近上下文窗口极限时，对内容进行总结，并以该总结开启新的上下文窗口。这通常是保持长期连贯性的首要方法。

在 Claude Code 中，我们会让模型总结消息历史，提炼出关键细节（架构决策、未解决 bug、实现细节），并丢弃冗余的工具输出。然后继续在压缩后的上下文中工作，同时保留最近访问的几个文件。这让用户获得连续性，而不用担心窗口大小。

压缩的关键在于选择保留什么，丢弃什么。过度压缩可能导致丢失关键上下文。工程师在实现压缩时，建议先追求召回率，再逐步提升精确度。

典型的冗余内容就是工具调用的原始结果——一旦调用完成，智能体通常无需再次看到原始输出。Anthropic 也在 Claude 开发者平台中推出了工具结果清理功能。

结构化笔记（Structured note-taking）

结构化笔记（或称智能体记忆）是指智能体定期将笔记保存到上下文窗口之外，并在需要时重新调入。这种方式成本低但能提供持久记忆。

例如 Claude Code 会生成待办事项清单，或用户自定义智能体维护 NOTES.md 文件。这让智能体能跟踪进度，保持关键依赖，而不会因多次工具调用丢失上下文。

比如 Claude 玩宝可梦的实验，智能体能在数千步游戏中持续跟踪目标和进展：记录训练进度、地图探索、战斗策略，并在重置上下文后依旧能继续。

随着 Sonnet 4.5 发布，Anthropic 推出了记忆工具，支持文件式存储，方便跨会话维护项目状态、建立知识库。

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

子智能体架构通过将复杂任务拆分给不同子智能体解决上下文限制问题。主智能体负责整体计划，子智能体专注于技术细节，每个子智能体在自己窗口中探索，然后输出压缩总结。

这种方式实现了关注点分离：子智能体处理细节，主智能体综合结果。实践表明，这种方式在复杂研究任务中优于单智能体系统。

不同方法适用于不同任务：

压缩：适合需要持续对话的任务；
笔记：适合迭代开发，目标清晰；
子智能体：适合复杂研究与并行探索。

即便模型继续进步，如何保持长期连贯性仍是关键挑战。

结论

上下文工程代表了我们与 LLM 协作方式的根本转变。随着模型能力增强，挑战已不只是编写完美提示词，而是如何在每一步精心策划进入模型有限注意力预算的信息。

无论是为长期任务实现压缩、设计高效工具，还是让智能体按需探索，核心原则始终如一：找到最小的高信号 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 的支持。

原文: Effective context engineering for AI agents