译者说明：本文译自 Anthropic 官方工程博客。原文面向 agent 开发者，但其中关于「上下文是有限资源」的判断和三种长任务处理技术，对任何长时间使用 AI 的人都适用。文末附研究咨询场景的对照。

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

概述

上下文工程代表了对传统提示词工程的一次转向。它关注的问题是：「什么样的上下文配置，最有可能产生我们想要的模型行为？」

工程师不再执着于打磨单条提示词，而是优化推理时可用的整套 token——包括系统指令、工具、外部数据和对话历史。

上下文工程 vs 提示词工程

提示词工程强调如何最优地撰写和组织给模型的指令。

上下文工程管理的是推理期间的整个 token 生态。用 Anthropic 的说法：

上下文工程指的是「在大模型推理过程中，策展并维持最优 token（信息）集合」的一整套策略。

这个区别对跨越长时程的多轮智能体尤其重要。单个智能体会不断产生可能影响后续推理的数据，因此需要周期性地精炼哪些内容进入有限的上下文窗口。

为什么上下文是有限资源

大语言模型存在**「上下文腐化」（context rot）**现象——随着上下文窗口变大，性能会下降。

这源于架构上的约束：基于 Transformer 的模型会构建 n² 量级的 token 两两关系，序列越长，注意力容量被摊得越薄。此外，模型的训练数据以较短序列为主，因此在处理长距离依赖时准备不足。

这个现实决定了必须仔细策展。模型在长上下文下仍然有能力，但会表现出：

相比在短上下文下的表现，信息检索的精确度和长距离推理能力都会下降。

---

有效上下文的解剖

系统提示词

有效的系统提示词要在具体与灵活之间取得平衡——处在「硬编码的脆弱逻辑」与「含糊、想当然的指引」之间的**「金发姑娘区间」**。

它应当**「以恰当的海拔高度呈现给智能体」**：既给出具体的行为信号，又不过度简化。

推荐的结构是用 XML 标签或 Markdown 标题划分出清晰的区块，例如 <background_information>、<instructions>、## Tool guidance。

原则是：

能完整勾勒出你期望行为的、最小的信息集合。

工具

工具定义了智能体与其环境之间的契约。有效的工具应当：

• 返回 token 高效的信息
• 鼓励高效的智能体行为
• 避免功能重叠
• 呈现清晰、无歧义的使用场景

如果一个人类工程师都无法明确说出某种情况下该用哪个工具，就不能指望 AI 智能体做得更好。

臃肿的工具集会制造混乱与不可靠。

示例（少样本提示）

与其详尽地记录每一种边缘情况，不如策展一组多样化的典型示例来刻画期望行为。

对大模型而言，示例就是那些「胜过千言万语」的图片。

高质量的示例胜过数量。

---

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

现代智能体越来越多地采用**「即时」（just in time）上下文策略**：保留轻量的标识符（文件路径、URL、查询引用），在运行时通过工具动态加载数据。

这与人类的认知方式相似——我们不会背下整个资料库，而是按需检索。

这种方式实现了渐进式披露（progressive disclosure）：智能体通过探索逐步发现相关上下文。每一次交互产出的信息，指引下一步决策；工作记忆保持聚焦，而把组织工作交给外部。

代价：运行时探索比预先计算好的检索要慢。有效的引导，能确保智能体高效导航，而不是把上下文浪费在追逐死胡同上。

---

长时程任务的三种技术

一、压缩（Compaction）

在接近上下文上限时，对对话内容做摘要，然后用压缩后的要点重新开始。

拿一段接近上下文窗口上限的对话，对其内容做摘要，然后用这份摘要重新初始化一个新的上下文窗口。

成功的关键在于平衡召回（捕捉全部相关细节）与精确（剔除冗余）。

一个唾手可得的优化：一旦工具的返回结果已被存到别处，就把它从上下文里清掉。

二、结构化笔记

智能体在上下文窗口之外维护持久的笔记，之后再取回。这提供了**「开销极小的持久记忆」**。

例子包括 Claude Code 维护任务清单，或智能体在 NOTES.md 文件里追踪项目进展。

原文提到那个玩宝可梦的 Claude 智能体作为演示——它在数千个游戏步骤中维持精确的计数，并跨越数小时的会话保留策略笔记，使其在上下文重置之后仍能保持连贯。

三、子智能体架构

专门的子智能体在干净的上下文窗口中处理聚焦的任务，同时由一个协调者智能体负责高层规划。

每个子智能体广泛探索，但只返回压缩后的摘要（通常 1,000–2,000 token）。

这实现了：

清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主智能体专注于综合与分析结果。

---

结论

上下文工程的指导原则：

找到能最大化「达成你期望结果」概率的、最小的高信号 token 集合。

随着模型能力提升，更少的规定性工程会带来更大的自主性；但把上下文当作有限资源来对待，始终是构建可靠智能体的关键。

---

译后附记：换成研究咨询的说法

原文是写给 agent 开发者的，但每一条都有日常对应。

「上下文腐化」解释了一个你早就感觉到的现象

对话越长，它越容易丢细节、越容易忘记你开头定的规矩——这不是错觉，是有架构原因的。

推论：别把一个对话用到底。 感觉到它开始飘的时候，就是该开新对话的时候。

三种技术的日常版本

结构化笔记那条最容易被忽略，收益却最大。 处理一批材料时，让它每处理完一份就把结果追加到一个 Markdown 文件里——上下文里只留当前这份，历史都在磁盘上。这样跑一百份和跑五份，上下文占用是一样的。

「最小的高信号 token 集合」怎么落地

最实际的一条推论：给它的背景资料不是越多越好。

一份 200 页的客户历史报告，如果这次任务只用得上其中的第三章，那就只给第三章。多给的部分不是「有备无患」，是在稀释它对真正重要内容的注意力。

判断标准：这份材料里，有多少是这次任务真正需要的？ 低于一半，就该先裁剪再喂。