按成功任务核算成本，在权限和知识版本约束下评估缓存与上下文压缩。
本文于 2026-09-12 补充整理，按 2026-07 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
先定义成本的计算单位
只看平均每次模型调用的费用，会鼓励把任务拆成很多看似便宜的调用。业务更关心的是完成一个有效任务需要多少钱，包括失败、重试、检索、重排和工具资源。
可以定义：
每成功任务成本
= 同批全部任务产生的总成本 / 成功任务数
分子包含失败任务的消耗。成功数为零时，该指标应标记为不可计算，而不是显示为零。退款或供应商补偿也应按明确口径处理。
用虚构价格说明计算方法
假设某实验模型的输入价格是每百万 token 2 个计费单位，输出价格是 8 个计费单位。一项任务进行了 3 次调用，每次输入 4000、输出 500 token：
输入：3 × 4000 / 1,000,000 × 2 = 0.024
输出：3 × 500 / 1,000,000 × 8 = 0.012
模型成本合计：0.036 个计费单位
这些数字纯粹用于演示，不对应任何供应商实时报价，也不包含重排、embedding 和存储。生产核算使用当时生效的价格表，并保存价格版本。
上下文预算按用途分配
提示词、必要证据、工具 schema、历史对话和输出预留共同占用上下文。可以先给每类设置预算，再按任务类型调整。对话越长越不应默认原样累积。
压缩时优先保留明确约束、已执行动作、未完成事项和证据引用。可以丢弃重复闲聊，但不能把“不要操作生产环境”压缩掉，也不能把“已准备提案”压成“已创建工单”。
压缩后的历史是新生成的数据，需要通过任务约束检查。节省 token 的同时若提高了错误率，整体成功任务成本反而可能上升。
缓存先判断正确性
| 缓存对象 | 适用条件 | 失效依据 |
|---|---|---|
| 文档 embedding | 输入与模型相同 | 内容哈希、模型版本 |
| 检索候选 | 权限与知识快照一致 | ACL、索引版本、查询配置 |
| 已验证答案 | 问题语义与访问范围稳定 | 证据版本、规则、时间 |
| 工具查询结果 | 业务允许短时陈旧 | 资源版本或短 TTL |
写操作不应作为普通答案缓存复用。返回“已创建工单”的旧答案，不能代表当前用户的请求已经执行。
语义缓存的相似度也不等于业务等价。“测试环境如何清理”和“生产环境如何清理”可能非常相似，却要求完全不同的行为。关键实体、权限和时间条件应作为硬约束。
模型路由需要质量门槛
简单分类使用较小模型是否省钱，必须包含分类错误导致的后续重试和人工处理成本。复杂任务升级模型也要设置总预算，否则“先便宜尝试，再昂贵重做”可能比直接使用合适模型更贵。
使用同一评测集比较总任务成本与成功率，保留各类失败。不要只在最容易的样本上计算节省比例。
观测 token 与调用元数据可以参考 Spring AI 观测能力。本例的价格版本、预算结算和成功任务口径属于业务账务设计。
验收预算是否真的生效
构造不断要求更多检索的任务，确认模型调用和工具调用都能触发预算停止；模拟流式中断且没有 usage 的响应，确认它不会被计为零成本；撤销权限后检查旧答案缓存无法命中。
成本优化的前提是质量和权限约束保持成立。明确记录节省来自少调用、短上下文还是缓存复用，才能判断下一轮优化应该落在哪里。
