上下文工程深度解析：从提示词优化到注意力预算管理
学习来源：Anthropic - Effective Context Engineering for AI Agents
阅读时间：2026-04-12
标签：#上下文工程 #AI-Agent #注意力机制 #Claude
一、核心认知升级：从"写好提示词"到"管理注意力预算"
1.1 范式转移的本质
传统的**提示工程（Prompt Engineering）关注的是"如何写好提示词的词汇和短语"，而上下文工程（Context Engineering）**要回答的是更根本的问题：
"什么样的上下文配置最有可能引导模型产生期望的行为？"
这个转变背后的驱动力是 Agent 系统的兴起。当 LLM 从单轮问答演进到多轮推理、从独立任务延伸到长时域操作时，工程师面对的不再是"写一个好提示"，而是"在不断演化的信息宇宙中，持续筛选和优化进入 context window 的 token 集合"。
1.2 上下文工程的定义
上下文 = LLM 采样时包含的所有 token 集合
上下文工程的目标：在 LLM 固有约束条件下，最大化这些 token 的效用，以持续达成期望结果。
关键洞察：上下文工程是迭代的——每次决定向模型传递什么信息时，都会发生一次上下文 curation phase，这与写一个静态提示词有本质区别。
二、注意力预算：LLM 的稀缺资源
2.1 为什么上下文是有限资源
Anthropic 明确指出了一个反直觉但极其重要的观察：LLM 和人类一样，在某个临界点后会失去焦点或产生困惑。
这源于两个技术原因：
Transformer 架构的 n² 复杂度
LLM 基于 Transformer 架构，每个 token 可以attend到上下文中的所有其他 token。对于 n 个token，存在 n² 个成对关系。随着上下文增长，模型捕捉这些成对关系的能力被"摊薄"。
训练数据分布偏差
模型在训练数据中，短序列的出现频率远高于长序列。这意味着：
- 模型在处理长上下文时经验不足
- 专门处理上下文级依赖的参数使用不够充分
2.2 上下文腐烂（Context Rot）现象
研究中的"大海捞针"（needle-in-a-haystack）基准测试揭示了上下文腐烂现象：随着 context window 中 token 数量的增加，模型准确回忆上下文中信息的能力下降。
虽然不同模型的衰减程度不同，但这个特征在所有模型中都会出现。
2.3 核心原则
上下文必须被视为一种有限资源，具有边际效益递减的特性。
每个新引入的 token 都会以某种程度消耗注意力预算。因此，需要精心 curation 可用于 LLM 的 token 集合。
类比人类工作记忆：人类有有限的工作记忆容量，LLM 同样有"注意力预算"。这不仅是技术约束，更是设计原则——你需要像管理人类认知负荷一样管理模型的上下文。
三、有效上下文的组成解剖
3.1 系统提示词（System Prompts）
系统提示词应极度清晰，使用简单、直接的语言，并在"正确的高度"呈现 ideas。
两种常见的失败模式
| 极端 | 表现 | 问题 |
|---|---|---|
| 过度具体 | 在 prompt 中硬编码复杂的 if-else 逻辑 | 脆弱性增加，维护复杂度随时间增长 |
| 过度抽象 | 提供模糊、高层次的指导，假设存在"共享上下文" | 无法给 LLM 提供具体的行为信号 |
"正确高度"的平衡点
最佳实践：足够具体以有效引导行为，同时足够灵活以提供强有力的启发式规则。
不是告诉 Agent "在这种情况下怎么做"，而是告诉它"遇到问题时如何思考"。
结构化建议
Anthropic 推荐将系统提示词组织成清晰的部分：
<background_information>- 背景信息<instructions>- 指令## Tool guidance- 工具指导## Output description- 输出描述
使用 XML 标签或 Markdown 标题来分隔这些部分。不过，随着模型能力提升，具体的格式要求可能变得越来越不重要。
最小化原则
核心原则：找到完整描述期望行为所需的最小信息集。
"minimal does not necessarily mean short" — 最小化不意味着简短
推荐方法：先用最小化提示测试最好的模型，然后根据发现的失败模式逐步添加示例和指令。
3.2 工具（Tools）
工具定义了 Agent 与其信息/行动空间的契约，因此极其重要。
工具设计的核心原则
- Token 高效 — 返回的信息应在 token 使用上高效
- 行为引导高效 — 鼓励高效的 Agent 行为模式
- 自包含 — 类似良好设计的代码库，工具应该是自包含的
- 错误鲁棒 — 对错误有良好的处理
- 用途清晰 — 工具的预期用途必须极其清晰
最常见的失败模式
工具集合过于臃肿 — 覆盖过多功能或导致关于"使用哪个工具"的模糊决策点。
如果一个人类工程师无法明确说出在给定情况下应该使用哪个工具，就不能期望 AI Agent 做得更好。
最小可行工具集
精简工具集不仅提高决策清晰度，还带来更可靠的长期维护和长交互中的上下文修剪。
3.3 示例（Few-shot Prompting）
示例是 AI 工程中经久不衰的最佳实践，但常见错误是：
不推荐：在 prompt 中塞入大量边缘案例，试图穷举所有规则
推荐：精心 curation 一组多样化、典范的示例（canonical examples），有效展示 Agent 的期望行为
对于 LLM，示例是"价值千言的图片"（Examples are the "pictures" worth a thousand words for an LLM）
四、上下文检索策略：Just-in-Time vs 预推理检索
4.1 两种范式的对比
| 策略 | 方式 | 优势 | 劣势 |
|---|---|---|---|
| 预推理时间检索 | 在推理前预处理所有相关数据 | 速度快 | 可能包含不相关信息，造成上下文污染 |
| Just-in-Time | 维护轻量级标识符，运行时动态加载数据 | 上下文更精准，避免过时索引 | 运行时探索较慢 |
4.2 Just-in-Time 的认知映射
这种模式实际上是在模仿人类认知：
人类不会记住整个语料库，而是引入外部组织和索引系统（文件系统、收件箱、书签）来按需检索相关信息。
Just-in-Time 策略的核心元素：
- 维护轻量级标识符（文件路径、存储查询、网页链接等）
- 通过工具在运行时动态加载数据到上下文
4.3 元数据的价值
文件路径、文件夹层次结构、命名约定、时间戳——这些元数据都为 Agent 提供了重要信号，帮助理解如何使用信息。
示例：在文件系统中：
tests/test_utils.py中的test_utils.py与src/core_logic/test_utils.py传达了不同的用途- 文件大小暗示复杂度
- 时间戳可以作为相关性的代理
4.4 渐进式发现（Progressive Disclosure）
让 Agent 自主导航和检索数据也实现了渐进式发现——通过探索逐步发现相关上下文。
每一轮交互产生指导下一决策的上下文：
- 文件大小 → 复杂度
- 命名约定 → 用途
- 时间戳 → 相关性
Agent 可以层层构建理解，只在 Working Memory 中维护必要的信息，并利用笔记策略进行额外持久化。
4.5 混合策略
最有效的 Agent 可能采用混合策略：
- 某些数据预先检索以提高速度
- 在需要时进行自主探索
典型案例：Claude Code
CLAUDE.md文件被预先放入上下文glob和grep等原语允许 Agent 实时导航环境并按需检索文件
对于动态内容较少的场景（如法律或财务工作），混合策略可能更适用。
五、长时域任务的上下文工程
当任务横跨数十分钟到数小时的连续工作时（如大型代码库迁移或综合研究项目），Agent 需要专门技术来绕过 context window 限制。
5.1 压缩（Compaction）
压缩 = 将接近 context window 限制的对话总结，用摘要重新初始化新的上下文窗口。
核心机制
在 Claude Code 中实现方式：
- 将消息历史传给模型进行总结和压缩
- 模型保留：架构决策、未解决的 bug、实现细节
- 模型丢弃：冗余的工具输出或消息
Agent 然后用这个压缩后的上下文继续工作，加上最近访问的 5 个文件。
压缩的艺术
压缩的艺术在于选择保留什么、丢弃什么——过度激进的压缩可能导致微妙但关键上下文的丢失。
最安全的轻量级压缩形式之一：清除工具调用和结果。一旦工具在消息历史深处被调用，Agent 为什么需要再次看到原始结果？
实施建议
- 先最大化召回率，确保压缩提示捕获轨迹中的每条相关信息
- 然后迭代提高精确度，消除多余内容
5.2 结构化笔记（Structured Note-taking / Agentic Memory）
核心思想：Agent 定期将笔记写入持久化内存（context window 之外），后续再拉回上下文。
典型应用
- Claude Code 创建待办列表
- 自定义 Agent 维护
NOTES.md文件
超越编码的案例
Claude 玩宝可梦 展示了记忆如何转变 Agent 能力：
- 跨数千游戏步骤维护精确计数（"过去 1234 步我一直在 Route 1 训练宝可梦，Pikachu 已获得 8 级，目标是 10 级"）
- 无需提示，自行开发探索区域地图
- 记住已解锁的关键成就
- 维护战斗策略笔记
上下文重置后，Agent 读取自己的笔记，继续数小时训练或地牢探索。
Anthropic 的 Memory Tool
作为 Sonnet 4.5 发布的一部分，Anthropic 发布了基于文件的 Memory Tool（公开 beta），使 Agent 更容易通过文件系存储和查询 context window 之外的信息。
5.3 子 Agent 架构（Sub-agent Architectures）
核心思想：不再让一个 Agent 维护整个项目的状态，而是使用专用子 Agent 处理专注任务。
架构模式
主 Agent（协调者）
├── 子 Agent 1（深度技术工作）→ 返回 ~1000-2000 token 的蒸馏摘要
├── 子 Agent 2（信息检索）→ 返回 ~1000-2000 token 的蒸馏摘要
└── 子 Agent 3（信息检索）→ 返回 ~1000-2000 token 的蒸馏摘要每个子 Agent 可能探索大量内容（数万个 token 或更多），但只返回压缩的蒸馏摘要（通常 1000-2000 token）。
分离关注点
这种模式实现了清晰的关注点分离：
- 详细搜索上下文保留在子 Agent 内部
- 主 Agent 专注于综合和分析结果
5.4 三种技术的选择指南
| 任务特征 | 推荐技术 |
|---|---|
| 需要大量来回对话 | Compaction（保持对话流程） |
| 有清晰里程碑的迭代开发 | Note-taking（追踪进度和依赖） |
| 复杂研究和分析，平行探索有回报 | Multi-agent（并行探索） |
六、核心设计原则
6.1 元原则
找到最小的高信号 token 集合，以最大化期望结果的概率。
这是贯穿全文的元原则，无论处理系统提示、工具、示例还是长时域任务。
6.2 上下文工程的关键洞察
- 上下文是迭代 curation，不是一次性编写
- 注意力是有限预算，需要精心管理
- 更聪明的模型 = 更少的规定性工程，更多自主性
- 最简单的可行方案通常最优（Do the simplest thing that works）
6.3 与传统软件工程的对比
| 传统软件工程 | 上下文工程 |
|---|---|
| 优化代码逻辑 | 优化信息选择 |
| 关注控制流 | 关注注意力分配 |
| 确定性执行 | 概率性引导 |
| 静态分析 | 动态适应 |
七、对 AI-Native 开发的启示
7.1 从规则驱动到原则驱动
随着模型能力提升，Agent 设计趋势是：
- 减少规定性规则
- 增加启发式原则
- 让智能模型更自主地行动
7.2 信息设计的重要性
上下文工程的兴起意味着 AI 工程师需要越来越像信息架构师：
- 思考什么信息应该在什么时候可用
- 设计信息的索引和检索机制
- 权衡信息的完整性和认知负荷
7.3 与 Model Context Protocol (MCP) 的协同
Anthropic 在文中提到 MCP（Model Context Protocol），这表明行业正在建立标准化的上下文管理协议。上下文工程不仅是个人实践，也正在成为系统级标准。
八、总结：上下文工程的核心框架
┌─────────────────────────────────────────────────────────────────┐
│ 上下文工程核心框架 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 问题: 如何在有限注意力预算下最大化期望行为概率？ │
│ │
│ 方法: │
│ ├── 最小化: 用最小高信号 token 集 │
│ ├── 结构化: 清晰分隔上下文的各组成部分 │
│ ├── 动态化: Just-in-time 替代全量预加载 │
│ ├── 持久化: 通过 compaction/note-taking 跨会话保持连贯性 │
│ └── 分层化: 多 Agent 架构分离关注点 │
│ │
│ 权衡: │
│ ├── 速度 vs 精度 (预检索 vs 运行时探索) │
│ ├── 完整性 vs 专注度 (全量 vs 精炼上下文) │
│ └── 自主性 vs 可控性 (探索 vs 规定) │
│ │
└─────────────────────────────────────────────────────────────────┘九、延伸思考
9.1 为什么现在才提出上下文工程？
提示工程已经火热了几年，为什么上下文工程在当下这个时间点被明确提出？
答案：Agent 范式的成熟。当 AI 应用从单轮任务转向多轮、长时域、工具使用的 Agent 系统时，上下文管理才成为核心挑战。
9.2 上下文工程 vs RAG
RAG（Retrieval-Augmented Generation）是预推理检索的一种实现，而上下文工程包含更广泛的策略：
- 包括 Just-in-Time 检索
- 包括 Compaction、Note-taking 等非检索策略
- 包括如何组织、压缩、维护上下文
RAG 是上下文工程的子集。
9.3 注意力预算的量化挑战
虽然文章指出了注意力是有限预算，但目前我们还缺乏：
- 量化特定信息"消耗"多少注意力预算的方法
- 预测上下文腐烂临界点的工具
- 自动优化上下文组成的系统
这是一个值得深入研究的方向。
十、参考资料
- Anthropic - Effective Context Engineering for AI Agents
- Anthropic - Building effective AI agents
- Anthropic - Writing tools for AI agents
- Context Rot Research
- Model Context Protocol
- Simon Willison - Agents Definition
更新日志
- 2026-04-12: 创建文档，完成深度分析