有效上下文工程：把智能体的注意力当作有限资源

精读对象：Effective context engineering for AI agents
作者：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield 等
发布机构：Anthropic
发布日期：2025 年 9 月 29 日
报告日期：2026 年 9 月 18 日
文章类型：智能体工程经验总结与设计指南
适合读者：LLM 应用开发者、智能体架构师、平台工程师、技术负责人

1.核心结论

这篇文章最重要的观点是：

1.上下文窗口不是一个越大越好的容器，而是智能体每一步都要重新分配的有限注意力预算。

2.工程目标不是尽量把已知信息全部塞给模型，而是在每次推理时，提供最小但足够的高信号信息集合。

“提示工程”和“上下文工程”的区别由此变得清楚：

• 提示工程主要优化指令怎么写；
• 上下文工程管理模型在当前一步究竟能看到什么，包括系统提示、工具定义、示例、消息历史、检索结果、环境状态和外部记忆；
• 对智能体而言，这个选择不是任务开始时做一次，而是在工具调用循环中持续发生。

文章的完整方法可以概括为三层：

层次	要解决的问题	主要方法
静态上下文	初始提示、工具和示例怎样保持高信号	合适抽象层级的系统提示、最小工具集、少量典型示例
运行时上下文	任务进行中怎样获取当前所需信息	即时检索、智能体搜索、渐进式披露、预取与按需探索的混合策略
长期任务状态	总信息量超过上下文窗口后怎样保持连贯	上下文压缩、结构化笔记、子智能体架构

三层共享同一个原则：

不要问“还能放进什么”，而要问：
当前决策需要哪些证据？
哪些信息只需保留索引？
哪些状态必须持久化？
哪些细节可以在完成局部任务后丢弃？

文章没有提供系统性的对照实验、成本曲线或公开评测集。它给出的是 Anthropic 的工程经验、设计启发和少量产品案例。因此，它适合作为设计框架，不足以证明“上下文越短，效果必然越好”，也不能证明压缩、记忆或多智能体在所有任务中都能带来净收益。

2.上下文工程到底管理什么

2.1 上下文不等于用户提示

原文把上下文定义为模型采样时包含的全部 Token。对一个工具型智能体，这通常包括：

• 系统指令和开发者约束；
• 用户请求与多轮消息；
• 工具名称、描述和参数 Schema；
• 工具调用及返回结果；
• 检索到的文档、网页或数据库记录；
• 示例、计划、临时笔记和任务状态；
• 压缩后的历史摘要；
• 可能被平台自动加入的元数据。

因此，一个写得很好的系统提示仍可能被糟糕的上下文破坏。大量无关检索结果会稀释关键证据；相似工具会增加选择歧义；旧的计划和失败结果可能让模型误判当前状态；压缩摘要遗漏一个未解决约束，也可能使后续工作沿错误方向继续。

2.2 上下文工程是一个循环控制问题

传统提示工程容易被理解为静态文本优化。智能体的上下文却会随着每一步改变：

当前上下文
→ 模型选择动作
→ 工具返回新信息
→ 系统筛选、压缩或持久化结果
→ 组装下一步上下文
→ 模型继续决策

这意味着上下文工程至少包含四种操作：选择、排序、压缩和外置。只讨论“提示词怎么写”，无法覆盖整个循环。

2.3 评价标准不是最短，而是决策效用

原文强调“最小的高信号 Token 集合”，但“最小”不能脱离任务解释。过度删减会造成信息不足，过度填充则会增加干扰。更准确的优化目标是：

在任务成功率、可靠性、延迟和成本约束下，提高进入上下文的信息对当前决策的边际价值。

因此，短提示不必然优于长提示。合规要求、复杂输出格式、领域边界和高风险操作可能需要较长说明。真正应删除的是重复、过时、无法影响当前决策或可以按需恢复的内容。

3.为什么更大的上下文窗口仍不够

3.1 可容纳不等于可稳定利用

文章引用“context rot（上下文腐化）”说明：随着上下文长度增加，模型从中准确召回和使用信息的能力往往下降。相关长上下文研究也观察到位置效应，例如关键信息位于长输入中部时，表现可能低于位于开头或结尾时。

这里要区分三个概念：

• 容量：接口允许输入多少 Token；
• 可检索性：模型能否找到相关信息；
• 可利用性：模型找到信息后，能否与其他约束一起正确推理。

上下文窗口扩大会改善容量，却不保证后两项同步改善。任务中的矛盾信息、重复记录、过期状态和位置偏差仍然存在。

3.2 “注意力预算”是工程隐喻，不是精确计量单位

原文用“attention budget”解释为什么每个新增 Token 都可能分散模型注意力。这个比喻有用，但不应按字面理解为每个 Token 都消耗相同、可测量的预算。

文章还提到标准 Transformer 的自注意力会形成约为 n² 的 Token 对关系。这说明常规全注意力的计算和内存成本随序列长度快速增长，但计算复杂度本身不能单独证明模型为何遗漏某条信息。长上下文性能还受训练数据长度分布、位置编码、注意力模式、任务形式、模型规模和推理方法影响。

因此，文章在这一部分提供的是合理的工程解释，不是完整的因果理论。

3.3 信息相关性仍然是根本限制

即使未来模型能稳定处理更长序列，也不能消除“哪些信息与当前步骤有关”的问题。把全部历史永久保留，会使过时计划、已解决错误和重复工具输出继续竞争注意力。更大的窗口会推迟清理时点，却不会替代状态管理。

4.静态上下文：提示、工具和示例

4.1 系统提示要处在合适的抽象层级

文章把系统提示的两种失败极端概括为：

• 过度具体：把复杂行为硬编码成大量条件分支，提示脆弱且难维护；
• 过度抽象：只给宽泛目标，缺少可执行边界，并错误假设模型知道共享背景。

合适的“高度”应同时满足两个条件：规则足以约束关键行为，启发式又能覆盖未枚举情形。例如，与其列出几十条“遇到某个文件就做某个动作”，不如说明任务目标、证据优先级、允许的工具、风险边界、验证标准和何时请求用户判断。

文章建议用 Markdown 标题或 XML 标签分隔背景、指令、工具说明和输出格式。这种结构有助于人和模型识别边界，但作者也明确认为，模型能力提高后，具体格式的重要性可能下降。结构化不是目的；信息边界清楚才是目的。

4.2 最小提示要从失败样本中长出来

原文建议先用能力最强的可用模型测试一个最小提示，再针对观察到的失败增加指令和示例。这种顺序有两个好处：

1. 能区分模型本身已经会做的事情与必须显式规定的事情；
2. 每条新增规则都对应已知失败模式，避免提示逐渐变成无人敢删的历史补丁集合。

这也意味着提示维护需要回归评测。模型、工具和业务规则变化后，旧规则可能失去作用，甚至与新能力冲突。

4.3 工具定义也是上下文设计

工具不仅提供行动能力，也定义智能体理解环境的方式。文章要求工具做到：

• 功能边界清楚，彼此尽量少重叠；
• 参数名称和描述明确；
• 返回结果紧凑，并突出后续决策所需信息；
• 出错时提供可恢复、可行动的反馈；
• 工具集合保持最小可用规模。

如果人类工程师无法稳定判断两个工具何时分别使用，模型通常也不会表现得更好。工具歧义不应主要靠增加提示补救，而应优先通过重新划分功能、改名、收紧参数或统一接口来消除。

4.4 示例应覆盖典型行为，不应枚举所有边界

少样本示例能够同时展示输入解释、操作路径和输出风格。文章主张选择“多样且典型”的示例，而不是把所有特殊情况堆进提示。

示例的价值在于高密度表达行为模式，但它也会制造偏差。模型可能机械模仿示例中的字段、地区、长度或处理顺序。因此应测量示例对未见输入的泛化效果，并定期删除重复或已经被明确规则覆盖的示例。

5.运行时上下文：从预加载转向即时检索

5.1 预推理检索的局限

常见 RAG 系统会在模型开始回答前，通过嵌入检索一次性找出相关资料。这种方式延迟较低、行为较容易预测，但它要求系统在任务尚未展开时就判断“什么是相关的”。对于需要多步探索的问题，后续步骤所需信息往往只有在读取前一条证据后才会显现。

5.2 即时上下文保留索引，不预先搬运全部内容

文章提倡让智能体先持有轻量引用，例如文件路径、网页链接、已保存查询或对象 ID，再通过工具按需加载内容。Claude Code 的例子说明，智能体可以编写定向查询，用 head、tail 等命令检查大型数据，而不把完整对象全部放进上下文。

这个设计把信息分成两层：

导航层：名称、路径、目录、时间戳、大小、链接、查询句柄
内容层：只有当前推理需要的原文、记录、代码或聚合结果

导航层本身也携带语义。文件所在目录、命名方式、修改时间和大小可以帮助智能体判断用途与相关性。

5.3 渐进式披露让检索成为推理的一部分

在渐进式披露中，每次探索结果都会改变下一次检索：文件名提示可能的模块，文件大小决定先读摘要还是局部，时间戳帮助判断新旧，搜索命中揭示新的术语。这不同于一次性 RAG，因为检索查询由任务过程动态生成。

它的优势是减少无关信息，并允许模型根据环境反馈调整方向；代价则是更多工具调用、更高延迟，以及走入死胡同的风险。

5.4 实际系统通常需要混合策略

文章以 Claude Code 为例：项目级指导文件预先进入上下文，具体代码再通过 glob、grep 等工具按需查找。这个混合模式可以推广为：

• 稳定、短小、每次都需要的规则预加载；
• 体积大、变化快、只在部分任务中需要的内容按需检索；
• 高召回要求的关键证据可先粗检索，再允许智能体深挖；
• 高延迟数据可预取摘要，同时保留访问原文的路径。

选择边界取决于任务。即时探索并不天然优于预计算检索；它用灵活性换取时间和搜索成本。

6.长任务的三种状态管理机制

6.1 上下文压缩：延续当前工作流

压缩是在上下文接近上限时，把历史提炼成摘要，再用摘要启动新的上下文窗口。它适合需要保持连续对话和工作轨迹的任务。

高质量压缩应保留：

• 用户目标、硬性约束和完成标准；
• 已确认的事实及其来源；
• 已作出的设计决定和理由；
• 当前状态、未完成项和阻塞问题；
• 失败尝试中仍会影响后续的教训；
• 重新获取细节所需的文件路径、查询或标识符。

可以优先删除重复消息、过时计划、已经消化的原始工具输出和可由稳定来源重新读取的内容。

文章建议压缩调优先追求召回率，再逐步提高精确率。原因是早期删掉一个以后才显得关键的约束，通常比暂时多保留一点冗余更难恢复。

6.2 结构化笔记：把状态持久化到上下文之外

结构化笔记或智能体记忆让模型把重要状态写入文件或其他外部存储，并在需要时重新读取。它适合里程碑明确、状态需要跨会话保留的开发与运营任务。

笔记不能只是对话摘要。可执行的状态记录通常需要固定字段，例如：

目标与成功标准
当前阶段
已完成事项及验证证据
关键决定和原因
未解决问题
下一步动作
相关文件、对象和查询标识符

外部记忆的主要风险是写入错误、陈旧信息继续被信任、不同会话并发修改，以及笔记无限增长。生产系统需要来源、更新时间、作用域、版本和清理策略。

6.3 子智能体：隔离局部搜索上下文

子智能体架构让多个专门智能体在各自干净的上下文中完成局部任务，主智能体只接收压缩结果。它特别适合可以并行探索、每个分支都可能产生大量中间材料的研究任务。

这种方式真正节省的不是系统总 Token，而是主智能体的上下文。子智能体可能各自使用大量 Token，系统总成本甚至会上升。收益来自关注点分离：局部工具输出不再污染主协调上下文。

有效的子任务返回不应只有结论，还应包含：

• 调查范围和未覆盖范围；
• 关键证据及来源；
• 不确定性和冲突；
• 失败的检索路径；
• 对主任务有影响的后续建议。

否则，压缩后的“答案”会隐藏证据质量，主智能体也无法判断多个子结果是否互相矛盾。

6.4 三种机制不是互斥选项

机制	最适合的任务	主要收益	主要风险
上下文压缩	连续对话、长工具链、需要保留近期轨迹	延续同一任务流，改造成本较低	摘要不可逆地遗漏细节
结构化笔记	跨会话、里程碑清楚、状态需要复用	持久、可编辑、可按需读取	错误或过时记忆被反复使用
子智能体	可分解、可并行、局部探索量大	隔离搜索噪声，主上下文更聚焦	总成本上升、委派或汇总失真

长任务通常会组合三者：子智能体完成局部探索，结构化笔记保存项目状态，主对话在必要时压缩。

7.统一理解：上下文的四种存储层

文章的建议可以进一步整理为四层存储模型：

层	保存内容	生命周期	典型载体
当前工作集	当前决策必须直接看到的信息	一次或少数几次推理	当前上下文
近期任务状态	当前阶段仍可能使用的计划、发现和约束	一个任务或阶段	压缩摘要、任务清单
可寻址外部知识	可按需重新读取的大型事实和原始材料	多任务或长期	文件、数据库、网页、对象存储
并行局部工作区	某个子问题的详细探索轨迹	一个子任务	子智能体上下文、隔离执行环境

设计重点不是把所有信息放进同一层，而是定义迁移规则：什么时候从当前工作集压缩到近期状态，什么时候只保留外部引用，什么时候需要把外部内容重新加载，以及谁负责判断信息已经过时。

8.文章最有价值的工程启示

8.1 上下文管理应围绕决策边界设计

同一份信息对不同步骤的价值不同。工具列表在选择工具时重要，原始日志在定位异常时重要，最终汇报阶段则可能只需要已验证结论和证据链接。上下文不应按“任务相关”这一粗粒度标准一次性组装，而应按当前决策点动态组装。

8.2 可重新获取的信息不必长期占据上下文

如果原始数据有稳定地址，并且读取成本可接受，就可以在上下文里保留路径、查询或 ID，而不是保留全文。这要求外部环境具有良好的可寻址性；命名、目录和元数据因此成为智能体基础设施的一部分。

8.3 工具返回应为下一步决策服务

工具通常按人类 API 或数据库结构返回数据，但模型真正需要的可能只是匹配数量、错误摘要、关键字段和进一步展开的句柄。可以用分页、字段选择、过滤、聚合和摘要降低上下文占用，同时保留访问原始证据的能力。

8.4 状态与证据应分开保存

“当前做到哪里”属于状态；“为什么得出这个结论”属于证据。只保存状态会失去可审计性，只保存原始证据会使恢复成本过高。压缩摘要和结构化笔记应记录状态，同时指向可重新检查的原始来源。

9.文章没有充分展开的问题

9.1 缺少可复算的收益数据

文章声称多智能体研究系统相对单智能体有显著改善，也用 Claude Code 和游戏智能体说明压缩与记忆的价值，但没有在本文给出任务集、基线、Token 成本、延迟、方差和失败分布。读者无法仅凭这篇文章计算某种机制的净收益。

采用这些方法时，应建立自己的基线：成功率、总 Token、墙钟时间、工具调用数、恢复率、人工接管率和错误类型，而不是直接套用案例结论。

9.2 压缩会制造信息瓶颈

摘要一旦替代原始历史，后续模型看到的是压缩器对“什么重要”的判断。未来步骤可能需要当时被认为无关的细节。可靠系统应保留原始事件日志或可重新读取的工件，使压缩是工作视图，不是唯一真相来源。

9.3 记忆需要治理，而不只是读写工具

文章强调文件式记忆的简洁，却没有深入讨论真实性、权限、生命周期和冲突解决。记忆可能来自模型推测，而不是外部事实；恶意工具输出也可能诱导智能体写入长期指令。应区分事实、推测、用户偏好、任务状态和程序规则，并为不同类别设置来源与失效机制。

9.4 即时检索扩大了搜索路径依赖

智能体根据早期发现决定下一步搜索。如果第一步误判，它可能不断沿错误方向收集“支持性”信息。系统需要搜索预算、覆盖检查、替代假设和回退到广召回检索的机制。

9.5 多智能体的协调成本没有展开

子智能体会带来任务分解、重复探索、冲突汇总、权限隔离和预算分配问题。并行只有在子任务足够独立、汇总标准清楚时才可能降低墙钟时间；它不会自动提高正确性。

9.6 安全问题讨论不足

外部网页、文件和工具结果都可能包含提示注入。即时检索让更多不受信任内容动态进入上下文；结构化记忆又可能把攻击持久化。生产系统必须把外部内容当作数据而不是高优先级指令，并限制工具权限、写入范围和高风险动作。

10.把文章原则转化为设计流程

10.1 先画出上下文清单

记录每次模型调用实际包含什么：系统提示、工具定义、历史消息、检索块、工具返回和平台元数据。分别计算 Token，并标出来源、更新时间和是否可重新获取。

10.2 用失败样本判断瓶颈

• 找不到已提供的信息：检查长度、位置、冲突和检索排序；
• 选错工具：检查工具重叠、命名和定义规模；
• 多轮后偏离目标：检查任务状态和已决事项是否持久化；
• 长任务压缩后重复工作：检查摘要是否保留决定、验证和未完成项；
• 调用成本过高：检查完整工具结果是否反复进入上下文；
• 研究覆盖不足：检查即时搜索是否过早收敛。

10.3 选择最小补偿机制

固定说明反复缺失
→ 改进系统提示或提供典型示例

大型材料只在部分步骤需要
→ 保存索引，按需检索

工具结果很大但只需局部字段
→ 在工具层过滤、分页或聚合

任务跨越上下文窗口
→ 先压缩，再视需要加入结构化笔记

多个局部探索相互独立且各自产生大量材料
→ 考虑子智能体隔离上下文

10.4 同时评测效果与资源

至少记录：

• 端到端任务成功率；
• 关键事实召回率和错误引用率；
• 上下文总 Token 与各组成部分占比；
• 工具调用次数、失败率和重复率；
• 总延迟与模型成本；
• 压缩前后任务连续性；
• 记忆中的错误、过期和冲突条目；
• 子智能体的重复工作与汇总遗漏。

只看上下文长度会鼓励过度压缩；只看成功率则可能接受不可控的成本。

11.生产检查清单

11.1 系统提示与示例

• 每条规则是否对应真实风险或失败样本？
• 是否混入了可以由代码、Schema 或权限层保证的规则？
• 指令是否既有具体边界，又能覆盖未枚举情形？
• 示例是否少量、多样、典型，并测试过未见输入？
• 模型升级后是否重新验证旧提示的必要性？

11.2 工具与检索

• 工具之间是否存在功能重叠或命名歧义？
• 返回值能否选择字段、分页、过滤或聚合？
• 大型内容是否有稳定路径、ID 或查询句柄可供再次读取？
• 即时搜索是否有预算、停止条件和广召回回退？
• 最终结论能否追溯到未经摘要的原始证据？

11.3 压缩与记忆

• 压缩摘要是否保留目标、约束、决定、验证、未完成项和来源？
• 原始事件或工件是否仍可恢复？
• 记忆条目是否记录来源、时间、作用域和置信状态？
• 是否区分用户事实、模型推断、任务状态与系统指令？
• 是否存在过期、冲突、删除和并发写入策略？

11.4 子智能体

• 子任务是否足够独立，委派边界是否清楚？
• 每个子智能体是否知道交付格式和完成标准？
• 汇总是否保留证据、冲突、不确定性和未覆盖范围？
• 是否测量总 Token，而不只看主智能体上下文？
• 读写权限和高风险动作是否按子任务最小化？

12.总体评价

《Effective context engineering for AI agents》的贡献，是把提示、工具、检索、记忆和多智能体这些常被分开讨论的主题，统一到“有限注意力预算”这一工程模型下。它提醒开发者，智能体性能不仅取决于模型能力和提示措辞，还取决于每一步如何选择、组织、淘汰和外置信息。

文章最可迁移的原则有三条：

1. 当前上下文只保留当前决策真正需要的高信号信息；
2. 大型、可寻址的材料留在外部，通过工具渐进式获取；
3. 长任务把连续性拆成压缩摘要、持久状态和隔离的局部工作区，而不是依赖无限增长的对话历史。

它的局限在于证据主要来自经验和产品案例，对压缩损失、记忆治理、检索路径依赖、多智能体成本和安全边界讨论不足。尤其需要避免把“最小上下文”误读成“越短越好”，或把 n² 注意力复杂度当作长上下文失效的完整因果解释。

更准确的实践结论是：

上下文工程不是删除信息，而是为信息选择合适的存储层、进入时机和退出条件；最终目标不是最少 Token，而是在可接受的成本和风险下，让模型在每个决策点看到足够且可信的证据。

13.参考资料

1. Anthropic：Effective context engineering for AI agents
2. Anthropic：Building effective agents
3. Anthropic：Writing effective tools for AI agents—using AI agents
4. Anthropic：How we built our multi-agent research system
5. Nelson F. Liu 等：Lost in the Middle: How Language Models Use Long Contexts
6. Chroma Research：Context Rot: How Increasing Input Tokens Impacts LLM Performance