AI 代理上下文工程指南
本文翻译自 Anthropic Engineering: Effective Context Engineering for AI Agents
上下文工程是在 LLM 推理过程中战略性地管理和维护最优 token 集合的艺术，超越了传统的提示工程，涉及跨多轮交互的整个上下文状态管理。
核心定义
上下文工程 (Context Engineering) 不仅仅是编写好的提示词，而是：
- 战略性地选择进入模型的信息
- 管理有限的注意力预算
- 在多轮对话中维护关键状态
- 优化 token 使用效率
设计原则
1. 将上下文视为有限资源
LLM 会经历上下文腐烂 (Context Rot)——随着 token 量增加，性能会下降。
性能
↑
│ ●●●●
│ ●●●
│ ●●
│ ●●
│ ●●●
└─────────────────────→ Token 数量关键认识：
- 模型的注意力预算是有限的
- 需要精心筛选而非穷举信息
- 质量胜过数量
2. 系统提示的正确高度
最佳系统提示需要在具体性和灵活性之间取得平衡：
太具体 ◄─────────────────────► 太模糊
↓ ↓
脆弱、硬编码逻辑 模糊、无方向指导目标：金发女孩区域 (Goldilocks Zone)
- 提供足够的具体方向
- 同时允许模型自主性
关键技巧
1. 即时检索 (Just-in-Time Retrieval)
不要预加载所有数据，而是：
传统方法：
┌─────────────────────────────────┐
│ 预加载所有可能需要的数据到上下文 │
└─────────────────────────────────┘
即时检索方法：
┌──────────────┐ 需要时 ┌──────────────┐
│ 轻量级标识符 │ ──────────→ │ 动态检索数据 │
└──────────────┘ └──────────────┘这模仿了人类认知——使用外部索引系统而不是记忆整个语料库。
2. 压缩 (Compaction)
当接近上下文限制时总结对话历史：
保留：
- 架构决策
- 关键细节
- 重要结论
丢弃：
- 冗余工具输出
- 中间推理步骤
- 重复信息
python
# 伪代码示例
def compact_context(conversation):
summary = summarize(
conversation,
preserve=["decisions", "key_facts", "conclusions"],
discard=["tool_outputs", "intermediate_steps"]
)
return summary3. 结构化笔记 (Structured Note-Taking)
让代理维护持久的外部记忆：
markdown
# progress.txt
## 会话 3 进度
- ✅ 修复了认证令牌验证
- ✅ 更新用户模型以处理边缘情况
- 🔄 下一步：调查 user_management 测试失败
- ⚠️ 注意：不要删除测试，可能导致功能缺失
## 关键决策
- 选择使用 JWT 而非会话认证
- 数据库使用 PostgreSQL这对于跨越多小时的任务特别有用，能够在上下文重置后保持连续性。
4. 子代理架构 (Sub-Agent Architectures)
专门的代理处理聚焦的任务，返回精简摘要：
┌─────────────────────────────────────────┐
│ 主代理 │
│ (管理整体任务，保持精简上下文) │
└─────────────┬───────────────────────────┘
│
┌─────────┼─────────┐
↓ ↓ ↓
┌───────┐ ┌───────┐ ┌───────┐
│子代理1│ │子代理2│ │子代理3│
│(搜索) │ │(分析) │ │(编码) │
└───┬───┘ └───┬───┘ └───┬───┘
│ │ │
└────→ 精简摘要 ←────┘
│
↓
返回主代理优势：
- 每个子代理有干净的上下文
- 只返回精华信息
- 避免主上下文污染
工具设计最佳实践
| 原则 | 说明 |
|---|---|
| 最小化工具重叠 | 避免功能相似的工具造成歧义 |
| 确保 token 高效返回 | 工具返回精简、有用的信息 |
| 参数描述清晰 | 使输入参数明确无歧义 |
| 使用多样化示例 | 提供不同场景的典型示例，而非穷举边缘情况 |
长时任务策略选择
| 策略 | 最适合场景 |
|---|---|
| 压缩 (Compaction) | 需要保持对话流的长时间来回交互 |
| 笔记 (Note-taking) | 有明确里程碑的迭代开发 |
| 多代理 (Multi-agent) | 并行探索有价值的复杂研究任务 |
实践示例
示例 1：代码重构任务
text
系统提示（优化上下文）：
你是一个代码重构助手。
工作方式：
1. 首先只读取直接相关的文件
2. 将发现记录到 notes.md
3. 每完成一个小任务就更新进度
4. 使用 git 跟踪所有更改
上下文管理：
- 不要一次读取超过 3 个文件
- 完成模块后清理工作记忆
- 保持 notes.md 作为持久状态示例 2：研究任务
text
系统提示（子代理协调）：
你是一个研究协调员。
可用子代理：
- search_agent: 网络搜索
- analysis_agent: 数据分析
- summary_agent: 内容总结
工作方式：
1. 将研究分解为子任务
2. 委派给适当的子代理
3. 收集精简摘要
4. 综合最终报告
只在主上下文保留关键发现。核心要点
随着模型能力增强，挑战不再只是编写完美的提示——而是深思熟虑地管理进入模型有限注意力预算的信息。
指导原则
无论你是：
- 为长时任务实施压缩
- 设计 token 高效的工具
- 让代理即时探索环境
始终记住：找到最小的高信号 token 集合，最大化期望结果的可能性。
相关资源
最后更新：2025年12月 | 来源：Anthropic Engineering