Context Engineering（上下文工程）
为 AI Agent 筛选最优 Token 集合的最佳实践 ([docs.claude-mem.ai][1])
AI Agent 的上下文工程
核心原则
找到最小但高信号的 token 集合，以最大化达成目标结果的概率。 ([docs.claude-mem.ai][1])
上下文工程 vs Prompt 工程
Prompt 工程： 编写和组织 LLM 指令，以获得最佳结果（一次性任务）
上下文工程： 在多轮推理过程中，持续整理和维护最优 token 集合（迭代过程）
上下文工程管理的内容包括：
- 系统指令（System instructions）
- 工具（Tools）
- Model Context Protocol（MCP）
- 外部数据（External data）
- 消息历史（Message history）
- 运行时数据检索（Runtime data retrieval） ([docs.claude-mem.ai][1])
问题：上下文腐化（Context Rot）
关键洞察： LLM 拥有一个“注意力预算”（attention budget），随着上下文增长会逐渐耗尽。
- 每个 token 都会关注其他所有 token（n² 关系）
- 上下文越长，模型准确性越低
- 模型对长序列的训练经验更少
- 上下文必须被视为一种有限资源，且边际收益递减
系统提示（System Prompts）：找到“合适的抽象层级”
Goldilocks 区间（刚刚好原则）
过于具体 ❌
- 写死的 if-else 逻辑
- 脆弱且易出错
- 维护成本高
过于模糊 ❌
- 只有高层指导，没有具体信号
- 错误地假设存在共享上下文
- 缺乏可执行指引
刚刚好 ✅
- 足够具体以有效引导行为
- 足够灵活以提供强启发
- 用最少信息完整描述期望行为
最佳实践
- 使用简单、直接的语言
- 组织为清晰结构（如
<background_information>、<instructions>、## Tool guidance等） - 使用 XML 标签或 Markdown 标题结构化
- 从最小 prompt 开始，根据失败案例逐步补充
- 注意：最小 ≠ 简短（需要提供足够信息）
工具（Tools）：最小且清晰
设计原则
- 自包含：每个工具只做一件事
- 鲁棒性：能处理边界情况
- 极度清晰：用途无歧义
- Token 高效：只返回必要信息
- 参数清晰：如
user_id而不是user
关键规则
如果一个人类工程师都无法明确判断在某个场景下应该使用哪个工具，那么 AI agent 也不可能做得更好。
常见失败模式（需要避免）
- 工具集合过于臃肿
- 工具功能重叠
- 工具选择存在歧义
示例（Examples）：多样化，而非穷举
应该做 ✅
- 筛选一组多样但典型的示例
- 有效展示预期行为
- “一图胜千言”的效果
不应该做 ❌
- 堆砌大量边界案例
- 尝试覆盖所有规则
- 用穷举场景压垮上下文
上下文检索策略
即时加载上下文（Just-In-Time Context）（推荐）
方法： 维护轻量级标识（文件路径、查询、链接），在运行时动态加载数据
优势：
- 避免上下文污染
- 支持渐进式信息披露
- 更符合人类认知（不会记住一切）
- 利用元数据（文件名、目录结构、时间戳）
- agent 可逐步发现上下文
权衡：
- 比预计算检索更慢
- 需要良好的工具设计避免死路
推理前检索（Pre-Inference Retrieval）（传统 RAG）
方法： 通过 embedding 在推理前检索上下文
适用场景：
- 交互过程中不会变化的静态内容
混合策略（最佳实践）
方法：
- 先加载部分数据
- 再按需自主探索
示例：
- Claude Code 预加载
CLAUDE.md - 使用 glob / grep 做即时检索
经验法则：
做最简单可行的方案
长周期任务（Long-Horizon Tasks）：三种技术
1. 压缩（Compaction）
做什么： 当接近上下文上限时，总结对话并重新开始
实现方式：
- 将历史消息传入模型进行压缩
- 保留关键细节（架构、bug、实现）
- 删除冗余输出
- 用“压缩上下文 + 最近文件”继续
调优流程：
- 先保证召回（尽可能保留信息）
- 再优化精度（去掉冗余）
简单优化点：
- 清理旧的 tool 调用和结果
适用场景：
- 长时间多轮交互任务
2. 结构化笔记（Structured Note-Taking / Agent Memory）
做什么： agent 将信息写入上下文之外的持久存储
示例：
- To-do 列表
NOTES.md- 游戏状态记录
- 项目进度日志
优势：
- 低开销持久记忆
- 在工具调用之间保持上下文
- 支持多小时连续任务
适用场景：
- 有明确阶段的迭代开发
3. 子 Agent 架构（Sub-Agent Architectures）
做什么： 用多个专用 agent 处理不同任务
工作方式：
- 主 agent 负责规划
- 子 agent 做深入执行
- 子 agent 使用大量上下文（数万 tokens）
- 返回压缩摘要（1000–2000 tokens）
优势：
- 关注点分离
- 支持并行探索
- 细节上下文被隔离
适用场景：
- 复杂研究和分析任务
快速决策框架
| 场景 | 推荐方案 |
|---|---|
| 静态内容 | 预检索或混合 |
| 动态探索 | 即时上下文 |
| 长对话 | 压缩 |
| 迭代开发 | 结构化笔记 |
| 复杂研究 | 子 agent |
| 快速验证 | 最简单方案 |
核心总结
- 上下文是有限资源（注意力预算）
- 要整体思考 LLM 可见的全部状态
- 保持最小化（越多不一定越好）
- 每次调用都要重新整理上下文
- 为模型自主能力设计
- 从简单开始，根据失败逐步增强
反模式（Anti-Patterns）
- ❌ 把所有内容塞进 prompt
- ❌ 写死 if-else 逻辑
- ❌ 工具过多
- ❌ 示例穷举
- ❌ 迷信大上下文窗口
- ❌ 忽视长期上下文污染
记住
即使模型持续进化，在长时间交互中保持一致性，仍然是核心挑战。
上下文工程的本质不会改变：
👉 优化 token 预算中的信噪比
