最佳实践：上下文工程四策略
上下文窗口是具有机会成本的经济资源。与其被动应对窗口耗尽，不如建立主动防御体系。本节介绍四种递进策略，从预防到应急，构建完整的上下文管理方案。
6.8.1 四策略框架概述
四种策略形成层层防御：
策略 1: 缓存优化（预防）
↓ 最大化缓存命中，10 倍成本差异
↓ 设计缓存友好的提示结构
策略 2: 观察遮蔽（早期干预）
↓ 工具输出 = 83.9% tokens，最大杠杆
↓ 固定遮蔽可匹配 LLM 摘要效果
策略 3: 压缩策略（主动管理）
↓ 70-80% 利用率时触发
↓ 结构化摘要保留信号，丢弃噪音
策略 4: 分区策略（架构解决方案）
↓ 子智能体隔离上下文
↓ 文件交接策略，避免信息传递损耗选择策略的决策框架：
| 上下文状态 | 首选策略 | 理由 |
|---|---|---|
| 利用率 < 50% | 缓存优化 | 预防胜于治疗 |
| 工具输出占比 > 50% | 观察遮蔽 | 瞄准最大消耗源 |
| 利用率 70-80% | 压缩策略 | 主动释放空间 |
| 任务可拆分 | 分区策略 | 从架构层面解决 |
不要等到上下文耗尽才行动。研究表明，在 70-80% 利用率时主动优化，比等到质量下降信号再处理，效果好得多。
6.8.2 缓存优化：10 倍成本差异
API 服务商对缓存命中的输入 token 提供大幅折扣。以 Claude Sonnet 4 为例：
| Token 类型 | 成本 |
|---|---|
| 未缓存输入 | $3.00/MTok |
| 缓存输入 | $0.30/MTok |
| 差异 | 10 倍 |
这意味着设计缓存友好的提示结构能带来显著成本节省。
缓存友好的内容排序原则：
[稳定内容优先] ← 可缓存（系统提示、工具定义）
[常用模板次之] ← 部分可缓存（格式要求、常用指令）
[动态内容最后] ← 无法缓存（当前查询、实时数据）什么会破坏缓存：
- 在系统提示中加入时间戳（每次请求都不同）
- 格式不一致（同一类请求结构不同）
- 频繁调整系统提示措辞
金融应用示例：
假设你的金融分析系统有 4 万 tokens 的稳定前缀（系统提示 + 工具定义 + 分析框架）。每天处理 100 个请求：
无缓存成本：40,000 × 100 × $3/MTok = $12/天 = $360/月
缓存命中成本：40,000 × 100 × $0.3/MTok = $1.2/天 = $36/月
月节省 = $360 - $36 = $324（90%）AGENTS.md 的内容应保持稳定，不要频繁修改。稳定的系统提示是缓存优化的基础。
6.8.3 观察遮蔽：零开销的高杠杆策略
研究发现，在典型的智能体工作流中，工具输出占据 83.9% 的 tokens。这是优化的最大杠杆点。
观察遮蔽（Observation Masking） 的核心思想是：工具输出在使用后往往不再需要完整保留。可以用简短的占位符替换冗长的原始输出。
原始工具输出（2000 tokens）：
{
"date": "2026-01-27",
"results": [
{"symbol": "AAPL", "price": 185.23, "volume": 52341000, ...},
{"symbol": "MSFT", "price": 412.56, "volume": 28765000, ...},
... 更多数据 ...
]
}
遮蔽后（50 tokens）：
[工具输出已处理：获取了 10 只股票的实时行情数据，已提取关键指标]关键发现：
研究表明，固定遮蔽（如”前 X 行已省略”）的效果可以匹配甚至超过 LLM 生成的摘要，同时零 token 开销（LLM 摘要通常消耗 5-7% 额外 tokens）。
遮蔽策略选择：
| 内容类型 | 策略 | 理由 |
|---|---|---|
| 最近一轮工具输出 | 保留完整 | 当前任务可能需要 |
| 3 轮以上的工具输出 | 选择性遮蔽 | 提取关键点，隐藏细节 |
| 重复格式的数据 | 立即遮蔽 | 格式已知，只需保留结论 |
| 已完成处理的中间结果 | 完全遮蔽 | 任务已完成，不再需要 |
6.8.4 压缩策略：结构化摘要
当上下文利用率达到 70-80% 时，应主动触发压缩。但压缩有代价——研究显示，递归摘要会丢失 65% 的准确率。
压缩的代价——DMR 基准测试数据：
| 压缩方法 | 准确率 | 关键洞见 |
|---|---|---|
| 时序知识图谱（Zep） | 94.8% | 时间有效性是关键 |
| MemGPT | 93.4% | 综合表现良好 |
| GraphRAG | 75-85% | 保留关系结构 |
| Vector RAG | 60-70% | 丢失关系结构 |
| 递归摘要 | 35.3% | 严重信息损失 |
结构化摘要模板：
与其让模型自由摘要，不如提供结构化模板，强制保留关键信息：
## 会话意图
[用户的核心目标]
## 已修改文件
- file1: 变更内容
- file2: 变更内容
## 已做决策
- 决策 1: 理由
- 决策 2: 理由
## 当前状态
[任务进度：完成/进行中/待开始]
## 下一步
1. 具体步骤 1
2. 具体步骤 2Opencode 中的实践：
# 带指令的定向压缩
/compact 仅保留决策、待办事项和配置更改
# 保留特定主题
/compact 保留所有关于估值模型的讨论文件追踪信息特别容易在压缩中丢失。即使使用最佳压缩方法，文件追踪评分也只有 2.2-2.5/5.0。关键文件操作应写入 AGENTS.md，而非仅依赖会话记忆。
6.8.5 分区策略：子智能体隔离上下文
最彻底的优化是从架构层面解决——将复杂任务拆分给子智能体，每个子智能体有独立的上下文空间。
子智能体的本质是上下文隔离，而非拟人化分工。
主智能体上下文：
┌──────────────────────────────────────┐
│ 系统提示 + 用户需求 + 任务规划 │
│ 容量：约 20K tokens │
└──────────────────────────────────────┘
↓ 分派任务
┌─────┴─────┐
↓ ↓
┌────────┐ ┌────────┐
│子智能体A│ │子智能体B│
│独立上下文│ │独立上下文│
│处理任务A│ │处理任务B│
└────────┘ └────────┘
↓ ↓
└─────┬─────┘
↓ 只返回摘要
┌──────────────────────────────────────┐
│ 主智能体接收：任务 A 完成，任务 B 完成 │
│ 新增消耗：约 200 tokens │
└──────────────────────────────────────┘文件交接策略：
子智能体不应将完整结果返回给主智能体（这会填满主智能体的上下文），而应：
- 将详细结果直接写入文件
- 只向主智能体返回状态摘要
错误做法：
子智能体 → [完整分析报告 5000 tokens] → 主智能体
正确做法：
子智能体 → [写入 output/analysis.md]
子智能体 → [状态摘要 100 tokens] → 主智能体金融场景示例：
主智能体（理财顾问）需要生成市场分析报告：
主智能体上下文：
┌────────────────────────────────────┐
│ 客户需求：分析科技股投资价值 │
│ 任务规划：分派给研究子智能体 │
└────────────────────────────────────┘
↓ 分派任务
┌───────────┐
│研究子智能体│
│独立上下文 │
│分析 AAPL │
└───────────┘
↓ 写入文件
output/aapl_analysis.md
↓ 返回摘要
┌────────────────────────────────────┐
│ 主智能体接收： │
│ ✅ AAPL 分析完成，盈利能力优秀 │
│ 消耗：约 50 tokens │
└────────────────────────────────────┘如果子智能体将完整分析（3000 tokens）返回主智能体，会填满上下文。
避免信息传递失真：
信息经过多个上下文传递会逐步降级。直接文件交接避免了这种损耗。
6.8.6 常见陷阱与避免方法
| 陷阱类型 | 具体表现 | 解决方案 |
|---|---|---|
| 暴力加载 | 直接粘贴所有内容到上下文 | 渐进式加载，按需检索 |
| 信息同质化 | 所有信息同等对待 | 区分必要复杂度与偶发复杂度 |
| 速度优化偏差 | 优化生成速度而非理解深度 | 关注输出质量，非延迟 |
| 跳过规划 | 直接执行，缺乏设计 | 研究-规划-实现三阶段 |
| 不主动压缩 | 频繁触发自动压缩 | 每 30-50 轮主动 /compact |
| AGENTS.md 过大 | 文件超过 200 行 | 使用 @import 分离配置 |
| 敏感数据裸存 | 未加密存储客户信息 | 加密敏感字段，环境变量存密钥 |
如果发现智能体频繁遗忘早期讨论的关键点、重复之前犯过的错误，很可能是自动压缩时丢失了重要信息。解决方案：
- 关键决策立即写入 AGENTS.md 或 REMEMBER.md
- 主动压缩时明确指定保留内容
- 使用文件而非会话记忆存储重要信息