Appearance
Context 优化是否真的有效：Cache 与 Evaluation
前置：长任务如何跨 Context 延续：Structured Artifacts 与 Reset
核心问题：Context cache 命中率变高并不等于系统变好，怎样证明缓存/裁剪真的改善了质量、延迟或成本？
Context Cache 不是“把 Prompt 字符串缓存起来”
一个 Harness 的输入通常由稳定和动态两部分组成：
text
stable prefix
- system/developer instructions
- stable Tool schemas
- stable policy text
dynamic suffix
- user turn
- current Run state
- retrieval evidence
- recent Tool resultsProvider-side prompt cache 或应用层 context cache 只有在序列化前缀稳定时才有价值。Tool catalog 顺序每轮变化、每次写入 timestamp、把动态 trace id 塞进 system block，都可能让逻辑内容没变但 cache locality 消失。
Cache Key 必须包含会改变语义的版本
对于应用自己维护的 Context fragment cache，至少考虑：
text
tenant / permission scope
instruction version
tool catalog version
retrieval/index version
model capability/version
locale / policy version用户私有 evidence 不能因为 prompt 文本相同就跨 tenant 复用。Cache hit 是性能事实，不是权限证明。
优化 Context 不能只看 Token
假设 compaction 让输入从 40K 降到 15K。单看 token 非常漂亮，但它可能同时删掉：
- 未完成约束；
- 已失败 Tool 的错误事实；
- 用户刚刚否定的方案；
- 文件/Artifact 的 stable reference。
因此至少同时测：
text
Task success
Constraint adherence
Tool selection accuracy
Hallucinated/missing state
Input tokens
Cache hit rate
TTFT / total latency
Cost质量下降 8% 换取 token 降低 20%，不一定是合理优化。
Ablation 才能回答“哪类 Context 真有用”
同一个固定 eval set，可以建立实验组：
| Variant | 改变什么 |
|---|---|
| A Full History | 基线 |
| B Selective History | 删除低价值旧轮次 |
| C Compact Tool Results | 大 Tool result 只保留结构化摘要 + artifact ref |
| D Dynamic Tool Exposure | 只暴露当前相关 Tool |
| E Compaction | 压缩较老 working history |
| F Fresh-context Handoff | 新 Context + structured handoff |
一次只改变一个主要因素，才能知道性能变化来自哪里。多个策略一起打开后成功率变高，并不能证明是哪一个有效。
Cache 与 Compaction 的关系
两者目标不同：
text
Cache
→ 同样内容下次更便宜/更快
Compaction
→ 让下一轮根本不再携带所有旧内容稳定长前缀可能非常适合 cache，却仍然占 context window；compaction 可以减少 window 占用，却可能破坏原有 cache prefix。真实优化需要联合测量，而不是各自追一个局部指标。
Failure Modes
为了 Cache 命中把动态事实塞进错误的稳定层
后果： stale state/permission 被复用。
处理： cache 只优化可安全复用的 fragment；动态 Run facts 永远按当前版本重新组装。
Ablation 只测最终文本相似度
后果： Tool 选择、约束遵守等行为退化无法被发现。
处理： 任务成功 + trajectory/component metrics + token/latency 联合评价。
如何验证
选 50–100 个包含 Tool、Retrieval、长历史的固定任务，运行至少两个随机重复批次；比较 full history 与各优化 variant。任何优化只有在质量指标不显著退化且成本/延迟改善时才进入默认 policy。
自测
- 把动态 RunState 放进“稳定前缀”以提高 cache hit，会产生什么 correctness 风险？cache key 应包含哪些版本信息？
- Cache hit 从 30% 提到 80%，但 task success 下降。你还需要哪些 ablation/指标才能判断这次优化是否值得？