成本要能归因到每一步

只优化总 token 会掩盖问题：成本要能拆到 Run、Wave、Agent、模型、上下文来源和 Tool，并同时报告每个成功任务的成本。

只盯着总 token 会掩盖问题。成本必须能按 Run / Wave / Agent / 模型 / 上下文来源 / Tool 拆开，并同时报告「每个成功任务的成本」。没有拆解，手里只有一个涨落的总数，说不清它来自能力变强还是失败重试变多。

先拆开，再优化

分解维度至少覆盖：Project / 任务类型 → Run / Wave / Step → Agent / Skill → 模型 → 上下文来源 → Tool / Connector → 命中缓存 / 未命中 → 成功 / 失败。

拆开的目的不是省钱，是定位：涨出来的那部分，究竟来自某个 Skill 的重试、某个 Tool 的无效调用，还是某段上下文被重复加载。三条纪律要一起守：先建 Baseline；不拿单次端到端运行证明收益；不把供应商公布的降幅写成项目结论——你的缓存命中率、上下文构成和重试率和它都不一样。

前置条件是埋点：Trace 从第一版就开始，按 Run、Agent Step、Model Call、Tool Call、Retrieval、Context Build 逐层记，并保留模型、Prompt、Tool 和配置的版本。事后补，就只能等下一个基线。

稳定前缀与上下文账本

缓存命中的前提是稳定前缀加动态后缀：系统提示、工具定义、固定知识块放前面且逐字稳定，变化内容放后面。不要为凑命中率把无关内容塞进前缀——命中率上去了，精度和成本一起变坏。

配套做一本上下文成本账本：按来源统计 token，找三类浪费——重复加载（同一份文件被多个子 Agent 各读一遍）、无效加载（检索进来却没参与有效推理）、未被使用（整块注入、一次没引用）。

还有一个精度约束：把窗口塞满不是出路。GPT-5 用满 256K 时精度 90%，GPT-5.4 窗口更大，超 500K 后掉到 36%，而且更贵。上下文不是免费容量。

两项优化同开，节省不能相加

稳定前缀和压缩历史这两个开关，必须放在一起实测。书里的对照实验固定了一个八轮客服退款任务（查订单、物流、退款政策与知识库，再做风控、退款、通知、关单），调用 gpt-4o-mini，把两个开关各自打开或关闭，得到四组结果 ai-agent-book：

28.3% 加 17.5% 不等于 30%。两个开关在互相蚕食而不是叠加：压缩历史的同时，也缩短了可以命中缓存的那段前缀。所以每项优化都要能独立开关，并且在完整任务上合起来再测一次——把各自的节省比例相加，得到的是纸面收益。

同一组数据也指出了成本是从哪里涨上去的：基线里每轮输入从 1,113 token 一路升到 3,668，其中工具返回跟着历史反复进入后续请求，八轮累计占掉 9,544 个输入 token，两项优化同开后降到 5,248。一次网页搜索返回 2,000–5,000 token，之后的每一轮推理都把它当输入重新计费一次。第 1 轮发 1,000 token，第 2 轮就要发 2,000，第 3 轮 3,000，三轮总量是 6,000 而不是 3×1,000——轮次越多，差距越大。Agent 的成本不是线性增长，是这种复利。

预算、路由与确定性前置层

预算在 Run 开始时解析，在 Step 和 Tool 边界更新成本：soft limit 触发压缩、范围缩减或模型路由，hard limit 停止或请求审批，预算变更和批准都要留记录。没有 hard limit 的预算只是仪表盘。

模型分层路由按能力、风险、上下文长度和模态选模型：分类、格式转换、摘要这类低风险任务交给足够能力的便宜模型，但必须定义升级条件，并用 Eval 证明路由策略达到质量门槛。只按价格选模型是最常见的省钱翻车方式。

「看起来简单」也不能当分流判据。「9.9 和 9.11 哪个大」「家离洗车店 50 米，走路还是开车」这类题一旦被划成简单题交给轻量模型，产出的就是错误决策——分流要按可测的任务类型和规则走，而且整套组合要由评估确认它带来的收益超过它新增的系统复杂度，某些场景是否出现性能回退也要单独看 ai-agent-book。

再往前一层是确定性前置层——在 LLM 之前放向量搜索：语义路由为已知意图准备参考语句，相似度过阈值就调绑定的工具；语义缓存把请求响应成对存起来，相似请求直接返回；语义护栏在越界请求产生成本之前拦下它。Redis 的实测是完整链路 13 秒、约 400 token，命中后 345ms、0 token redis-semantic-routing。

细节决定它能不能上线：阈值必须用测试数据校准；长请求按句分块匹配，真实意图常埋在闲聊里；缓存按用户隔离元数据防 PII 串用户；TTL 按语义时效分级。还要警惕否定敏感——通用 embedding 里「X 是什么」和「X 不是什么」距离极近，缓存会返回相反答案。这三个模式不是银弹，只在意图集合收敛时适用。这层「先确定性、再模型」该放在复杂度阶梯的哪一级，先问这件事要不要 Agent 有同组实测的完整展开。

单位成功成本才是结论

单位成功成本 = 全部运行成本 ÷ 成功完成的任务数，它比单次端到端成本更有意义：跑十次失败八次，单次均价再低也是贵的——失败的运行同样烧 token，只是没换来结果。

优化必须以质量、安全、稳定为护栏：同时看质量和单位成功成本，不能单独以最低 token 为目标。反例很典型：Cursor 想用更贵模型做上下文摘要，在线 A/B 测发现对质量改善微乎其微，直接搁置——离线 eval 看不出这个结论 cursor-agent-harness。另一方向的教训：把默认 reasoning effort 从 high 降到 medium 确实省了延迟和 token，用户立刻报「变笨了」，只能回退。替用户选低智能默认值是错误权衡，正确做法是让用户主动 opt-in 低 effort。

多 Agent 与环境的隐藏账单

多 Agent 会重复加载：每个子 Agent 各把同样的文件、工具定义和知识块读一遍，token 翻倍而信息量不增加。合并共享前缀、只给子 Agent 真正需要的上下文，通常比换更便宜的模型省得多。

环境 setup 也是一笔被忽略的成本。脑手耦合时，每个会话都要先付全额容器 setup——clone repo、起进程、拉 pending 事件，即使从不碰 sandbox 的会话也得付，这段死时间直接落在 TTFT 上。解耦后容器只在需要时经工具调用 provision：p50 TTFT 降约 60%，p95 降超 90% anthropic-managed-agents。这笔账的环境侧做法——快照、install 与 start 分离——在环境反馈决定能力边界 里展开。

取舍很明确：整套归因、预算和路由都建在 trace 之上，对只跑几十次的内部脚本不划算。检查方法是挑一个高频任务问四件事——成本能拆到 Skill 吗？能区分成功与失败的开销吗？能说出单位成功成本吗？缓存命中率有基线吗？任一个是「不能」，就先补埋点，不要先优化。