AI代理的上下文工程
核心原则
找到能够最大化所期望结果可能性的最小高信号标记集。
上下文工程 vs 提示工程
提示工程：编写和组织大语言模型指令以获得最佳结果（一次性任务）
上下文工程：在多轮推理过程中策划和维护最优的 token 集合（迭代过程）
上下文工程管理：
- 系统指令
- 工具
- 模型上下文协议 (MCP)
- 外部数据
- 消息历史
- 运行时数据检索
问题：语境衰变
关键见解：大型语言模型（LLM）有一个“注意力预算”，随着上下文的增加而被消耗
- 每个标记都会关注每个其他标记（n² 关系）
- 随着上下文长度增加，模型准确性下降
- 模型在处理较长序列时的训练经验较少
- 上下文必须被视为一种边际收益递减的有限资源
系统提示：找到“正确高度”
适居带
过于规定性 ❌
- 硬编码的 if-else 逻辑
- 易碎和脆弱
- 维护复杂度高
太模糊 ❌
- 没有具体信号的高层指导
- 错误地假设共享的上下文
- 缺乏可行的方向
刚好 ✅
- 足够具体以有效指导行为
- 足够灵活以提供强有力的启发式方法
- 完整概述预期行为的最少信息集
最佳实践
- 使用简单、直接的语言
- 组织成不同的部分（
<background_information>、<instructions>、## Tool guidance等） - 使用 XML 标签或 Markdown 标题来组织结构
- 从最小的提示开始，根据失败模式进行补充
- 注意：简约 ≠ 简短（请在一开始提供足够的信息）
工具：简约而清晰
设计原则
- 自包含：每个工具都有一个明确的单一用途
- 对错误具有鲁棒性：优雅地处理边缘情况
- 非常清楚：预期用途明确无误
- token 高效：返回相关信息而无冗余
- 描述性参数：明确的输入名称（例如，
user_id而不是user）
关键规则
如果一个人类工程师无法明确地说在特定情境下应该使用哪种工具，那么不能指望人工智能代理能做得更好。
常见故障模式及避免方法
- 臃肿的工具集涵盖了过多功能
- 用途重叠的工具
- 关于使用哪种工具的模糊决策点
示例：多样，不完全
做 ✅
- 策划一组多样的、经典的例子
- 有效地显示预期行为
- 想想“图片胜过千言”
不要 ❌
- 列在大量边缘情况中的东西
- 尽量阐明每一条可能的规则
- 用详尽的场景压倒
上下文检索策略
即时上下文（推荐给代理）
方法：保持轻量级标识符（文件路径、查询、链接）并在运行时动态加载数据
好处：
- 避免上下文污染
- 启用渐进式显示
- 模拟人类认知（我们不会记住所有东西）
- 利用元数据（文件名、文件夹结构、时间戳）
- 代理逐步发现上下文
权衡：
- 比预先计算的检索慢
- 需要适当的工具指导以避免走入死胡同
推理前检索（传统RAG）
方法：在推理之前使用基于嵌入的检索来呈现上下文
使用时机：在互动过程中不会改变的静态内容
混合策略（两者兼顾）
方法：预先获取一些数据，在需要时启用自主探索
示例：Claude Code 预先加载 CLAUDE.md 文件，使用 glob/grep 进行即时检索
经验法则: “做最简单可行的事情”
长期任务：三种技术
1. 压实
什么：总结接近上下文限制的对话，并用总结重新开始
实施：
- 将消息历史传递给模型进行压缩
- 保留关键细节（架构决策、漏洞、实现）
- 丢弃多余的输出
- 继续使用压缩上下文 最近访问的文件
调音过程：
- 第一：最大化召回（捕获所有相关信息）
- 然后：提高精确度（去掉多余内容）
低垂的果实：清理旧的工具调用和结果
最佳适用：需要大量来回交流的任务
2. 结构化笔记（能动记忆）
什么：代理写的笔记保存在上下文窗口之外，稍后可以检索
例子：
- 待办事项列表
- NOTES.md 文件
- 游戏状态跟踪（宝可梦例子：跟踪1,234步训练）
- 项目进度日志
好处：
- 具有最小开销的持久内存
- 在工具调用中保持关键上下文
- 启用多小时的连贯策略
最佳适用：具有明确里程碑的迭代开发
3. 子代理架构
什么：专门的子代理处理具有清晰上下文窗口的专注任务
工作原理：
- 主要代理协调高级计划
- 子代理执行深入的技术工作
- 子代理进行广泛探索（数万个 token）
- 返回简明摘要（1,000-2,000 token）
好处：
- 关注点明确分离
- 平行探索
- 详细的上下文仍然是孤立的
适合：复杂的研究和分析任务
快速决策框架
| 场景 | 推荐方法 |
|---|---|
| 静态内容 | 推理前检索或混合 |
| 需要动态探索 | 即时上下文 |
| 延长的来回 | 压缩 |
| 迭代开发 | 结构化笔记 |
| 复杂研究 | 子代理架构 |
| 快速模型改进 | “做最简单可行的事情” |
关键要点
- 上下文是有限的：把它当作一种珍贵的资源来管理注意力预算
- 整体思考：考虑 LLM 可用的整个状态
- 保持简约：更多的上下文并不总是更好
- 要迭代：每次传递给模型时都会进行上下文整理
- 自主设计：随着模型的改进，让它们智能地行动
- 从简单开始：以最少的设置进行测试，根据失败模式进行添加
应避免的反模式
- ❌ 把所有内容都塞进提示里
- ❌ 创建脆弱的 if-else 逻辑
- ❌ 构建臃肿的工具集
- ❌ 将详尽的边缘情况塞作示例
- ❌ 认为更大的上下文窗口可以解决一切问题
- ❌ 在长时间互动中忽略上下文污染
记住
即使模型不断改进，在更长时间的互动中保持连贯性的挑战仍将是构建更高效智能体的核心问题。
上下文工程将会发展，但核心原则保持不变：在你的 token 预算中优化信噪比。
基于 Anthropic 的《AI 代理的有效上下文工程》（2025 年 9 月）