AI Agent 有效上下文工程
原文：Effective Context Engineering for AI Agents
来源：Anthropic Engineering Blog
翻译整理：2026-06-16
什么是上下文工程
上下文工程（Context Engineering） 是指在 LLM 推理过程中，对有限的 token 资源进行精细化管理的系统性方法。
Anthropic 的定义：
“在 LLM 推理期间，对最优 token 集合（信息）的策划与维护，包括落入上下文窗口的所有信息——不只是 prompt 本身。“
与 Prompt Engineering 的区别
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注范围 | 单次 prompt 的优化 | 多轮交互中整个上下文状态的管理 |
| 时间跨度 | 单次推理 | 整个 Agent 任务生命周期 |
| 核心问题 | 怎么写好 prompt？ | 在任意时刻，上下文里应该放什么？ |
| 适用场景 | 简单问答、单轮任务 | 长任务、多步骤 Agent、多轮对话 |
一句话区别：Prompt Engineering 是在写信，Context Engineering 是在管理整个通信档案室。
为什么上下文管理如此重要：Context Rot
LLM 存在「上下文衰减（Context Rot）」现象：随着上下文 token 数增加，模型性能会系统性下降。
技术根因：
- Transformer 的 n² 复杂度：注意力机制的计算复杂度随序列长度平方增长，导致长上下文推理代价更高
- 训练数据稀缺：超长序列的训练样本远少于短序列，模型在极长上下文下经验不足
实际表现：模型在长上下文下仍能维持基本能力，但在以下方面精度下降：
- 信息检索精度：从长上下文中找到特定信息的准确率下降
- 长程推理能力：跨越大量中间步骤的推理可靠性降低
这意味着塞入更多信息不等于获得更好结果，有时反而更差。
核心设计原则：最小高信号 Token 集
上下文工程的指导原则只有一条：
找到最小的高信号 token 集合，最大化期望结果的概率。
每一个进入上下文的 token 都应该问自己：「这个 token 是否让 Agent 更可能完成任务？」如果答案不确定，就不要放进去。
四个上下文来源的设计要点
1. System Prompt
System Prompt 需要在两个极端之间取得平衡：
- 太宽泛：Agent 行为难以预测，边缘情况处理混乱
- 太细致：变成脆弱的 if-else 逻辑，新情况出现时会失效
正确做法：提供行为启发式（heuristics），而非穷举规则。
❌ 脆弱的规则式写法：
如果用户说"取消"，则执行取消操作。
如果用户说"撤销"，则执行撤销操作。
如果用户说"别做了"，则停止操作。
✅ 弹性的启发式写法：
当用户表达想要停止或撤回当前操作的意图时（无论具体措辞），
优先停止并确认，而不是继续执行。
2. 工具集设计
工具集的上下文占用往往被低估。
三个设计要求：
- 最小化：只包含当前任务真正需要的工具
- 无重叠：任意两个工具的功能边界清晰，Agent 不会在两个工具间犹豫
- 目的明确：每个工具的 description 清楚说明「什么时候用」
量化参考：GitHub MCP server 将所有 API 端点暴露为工具后，仅工具定义就占用了 40,000-55,000 tokens——这几乎耗尽了大多数模型的常用上下文长度。
如果工程师自己都无法明确判断某场景该用哪个工具，Agent 也一定会选错。
3. 示例（Few-shot Examples）
示例的价值在于展示期望行为，而非穷举边缘情况。
原则：
- 几个高质量的典型示例 > 大量覆盖边缘情况的示例
- 示例应展示 Agent 「应该怎么做」，而非「不应该怎么做」
- 示例越接近真实工作流，效果越好
Token 效率视角：每个示例都在消耗上下文空间。一个示例如果只覆盖了极少出现的边缘情况，性价比极低。
4. 运行时动态上下文
这是上下文工程中最被忽视、也最有效的部分。
关键技术：Just-in-Time 检索
不要在任务开始时预加载所有可能用到的信息，而是：
- 上下文中只保留轻量标识符（文件路径、URL、ID）
- 当 Agent 真正需要某个数据时，通过工具调用动态获取
类比人类工作方式：
- ❌ 把所有文件都打印出来摆在桌上（上下文预加载）
- ✅ 知道文件在哪个文件夹，需要时去取（Just-in-Time 检索）
这种方式能让 Agent 根据任务进展逐步发现所需信息，而不是一开始就被海量信息淹没。
长任务的三种上下文解决方案
当任务足够长，无法在单个上下文窗口内完成时，有三种应对策略：
策略 1：上下文压缩（Compaction）
在上下文接近上限前，对已有对话进行摘要，然后用压缩后的摘要重新初始化上下文。
[原始上下文：50,000 tokens]
↓ 压缩摘要
[新上下文：5,000 token 摘要 + 后续任务]
适用场景：任务本身是线性的，早期步骤的细节在后续不再需要。
注意：压缩会丢失细节。摘要质量决定压缩效果，建议明确指导 Agent 摘要时保留哪些关键信息。
策略 2：结构化笔记（Structured Note-taking）
Agent 在执行任务过程中，主动将关键信息写入外部记忆文件，而不是依赖上下文记忆。
Agent 执行步骤 1
→ 将关键发现写入 notes.md
Agent 执行步骤 2
→ 读取 notes.md 获取上下文
→ 将新发现追加写入 notes.md
优势：关键信息持久化，不受上下文长度限制；Agent 可以在任意步骤回溯已知信息。
适用场景：需要在多步骤间传递中间结果的复杂任务（代码重构、文档生成、多阶段分析）。
策略 3：子 Agent 架构（Sub-agent Architecture）
将复杂任务分解给专注子任务的子 Agent，每个子 Agent 完成后返回压缩摘要给编排器（Orchestrator）。
编排器（Orchestrator）
├── 子 Agent A：专注子任务 X → 返回 1,000-2,000 token 摘要
├── 子 Agent B：专注子任务 Y → 返回 1,000-2,000 token 摘要
└── 子 Agent C：专注子任务 Z → 返回 1,000-2,000 token 摘要
↓
编排器汇总摘要，生成最终结果
关键设计点：子 Agent 返回的必须是凝练摘要，而非完整执行过程。
量化依据（来自 DACS 论文）：
- N=3 个子 Agent 不压缩输出 → 编排器准确率 60%
- N=10 个子 Agent 不压缩输出 → 编排器准确率 21%
子 Agent 的输出污染编排器上下文，是多 Agent 系统性能崩溃的主要原因。
上下文工程的底层逻辑
为什么即使模型能力不断增强，上下文工程仍然重要？
模型的上下文窗口在持续扩大（从 8K → 200K → 1M tokens），但这并不意味着上下文管理变得不重要，原因有三：
- 成本：更长的上下文 = 更高的推理成本，生产环境中 token 效率直接影响可行性
- 延迟：上下文越长，首 token 延迟越高，影响用户体验
- Context Rot 仍然存在：即使支持 1M tokens，在 800K 处埋入的关键信息检索精度也低于在 10K 处的情况
“即使模型能力持续进步，将上下文视为珍贵资源仍然是构建可靠、高效 Agent 的核心。“
实践总结
| 上下文来源 | 优化方向 | 常见错误 |
|---|---|---|
| System Prompt | 启发式规则，而非穷举 | 过于细化导致脆而易碎 |
| 工具集 | 最小化、无重叠 | 暴露所有 API 端点 |
| 示例 | 少而典型 | 堆砌边缘情况示例 |
| 运行时数据 | Just-in-Time 检索 | 任务开始时预加载所有数据 |
| 子 Agent 输出 | 只返回压缩摘要 | 返回完整执行日志 |
一句话记忆：上下文是 Agent 的工作记忆，它是有限且珍贵的——只放进去真正有用的东西。
与其他文章的关联
- 本文的工具设计部分与 Writing Tools for Agents 强关联：工具集精简是上下文效率的基础
- 子 Agent 摘要压缩的量化数据来自 DACS 论文（arxiv 2604.07911）