Appearance
如何降低模型与 Context 成本：Model Delegation 与 Cache
前置：钱怎么花、模型怎么选：Token、Budget、Routing 与 Cost / Quality
核心问题：什么时候值得把子任务交给便宜模型或使用 Cache，哪些版本变化必须让缓存立即失效？
Delegation 和 Routing 不是一回事
Routing 是“这一次模型调用交给谁”；Delegation 是“把任务拆出一个更窄、可验证的子任务交给较便宜模型”。
例如：
text
强模型负责代码修复主任务
↓
小模型只做 error log → structured labels
↓ schema validation
通过 → 作为主任务 evidence
失败 → fallback / 强模型处理这样省钱的前提是子任务足够窄，而且结果可以验证。若小模型直接生成不可验证的关键决策，它的错误会被放大到后续链路；同时 delegation 本身也增加一次调用和 latency，因此不是“越多越省”。
Prompt Cache：复用稳定前缀，不复用错误语义
Prompt/provider cache 适合稳定且频繁重复的 instruction、Tool definitions 等前缀。为了提高命中率，稳定内容应保持版本和顺序尽量固定，动态用户输入放在变化区域。
但 cache 命中只是性能优化。model、instruction、tool schema、permission scope 等改变时，旧缓存不能被当成仍然语义兼容。具体 cache 能力和 key 规则取决于 Provider，Harness 仍要在 RunManifest 记录实际使用的版本。
Retrieval Cache：复用的是“某个索引版本下的检索结果”
一个安全的 retrieval cache key 至少要能区分：
text
normalized query
filters / ACL / tenant
index version
ranking config知识库更新或 ACL 变化时必须失效，否则系统会持续把 stale/越权 evidence 注入 Context。时间敏感查询甚至可能不适合长 TTL。
什么时候值得做这些优化
不要只看“省了多少 token”。至少同时比较：
| 优化 | 可能收益 | 主要风险 |
|---|---|---|
| 小模型 delegation | 降低强模型调用量 | 多一跳 latency、错误传播 |
| Prompt cache | 降低重复前缀成本/TTFT | 版本/能力漂移 |
| Retrieval cache | 降低重复搜索成本 | stale evidence、ACL 串用 |
只有在固定 Eval Set 上质量没有明显退化，且 cost/latency 真正改善时，才应该进入默认策略。
Failure Modes
Cache Key 忽略权限或版本
后果： 不同 tenant、旧 Tool schema 或旧 index 可能命中同一 entry。
处理： 把安全 scope 与语义版本放进 key；无法安全复用的数据不缓存或使用短 TTL。
小模型承担无法验证的关键决策
后果： 省下单次模型成本，却把错误带进 Planner/Tool execution。
处理： Delegation 优先用于窄、结构化、可验证任务；高风险语义决策保留更强模型和独立验证。
如何验证
对同一个固定任务集比较 baseline 与优化方案，记录 success、cost、p95 latency 和 fallback rate。若成本下降但失败集中在某类 delegated task，说明拆分边界而不是模型价格需要调整。
自测
- 哪些子任务适合委托给更小模型，哪些任务因安全/推理复杂度不应只看成本下放？
- Cache 命中降低成本，但 key 忽略 prompt/tool version 会产生什么错误复用？