1. 模型升级那天，我盯着账单反而更慌了
Claude Opus 5.5 上线那几天，社群里最热闹的话题不是"新模型写代码强了多少"，而是"要不要把生产环境的 Agent 全量切过去"。我一开始也是这么想的——新模型嘛，能力更强，贵一点也值。结果真把几个跑量的 Agent 从旧版本迁到 5.5 之后，账单并没有像预期那样"贵得离谱"，反而在某个环节上省了一大截。但省下来的钱，跟我换模型这件事几乎没关系。
真正让成本曲线拐弯的，是配置迁移。具体说，是 Prompt Caching 的命中率、上下文裁剪策略、工具调用的编排方式，以及 Claude Code 这类客户端在本地会话里的缓存复用逻辑。模型换了，如果这些配置还停留在旧版本的默认值上，你花的是新模型的单价，跑的是旧模型的效率，等于两头亏。
这篇东西写给谁看？写给已经在用 Claude 系列模型跑 Agent、或者正准备从旧版本迁到 Opus 5.5 的开发者。不管你是用 Claude Code 做本地开发，还是自己搭 Agent 框架跑批量任务，只要涉及"模型切换 + 成本控制"，这里面的坑你大概率会踩。我会把迁移过程中真正影响成本的那几个配置点拆开讲，包括为什么这么配、怎么验证、以及我实测下来哪些默认值必须改。
先说结论方向：换模型带来的单价变化是线性的，而配置迁移带来的成本变化是非线性的。前者你控制不了，后者你能控制，而且空间比你想的大。很多人把注意力全放在"哪个模型更便宜"上，却忽略了 Agent 场景下真正吃 token 的是重复的系统提示、冗余的工具描述、以及每一轮都重新计算的上下文。这些才是迁移时该动刀的地方。
2. 为什么"换模型省钱"是个伪命题
2.1 单价差异在 Agent 场景里被稀释了
单看 API 定价表，Opus 5.5 和上一代之间的单价差确实存在，但放到 Agent 场景里，这个差异会被迅速稀释。原因很简单：Agent 的 token 消耗结构跟单轮对话完全不同。单轮对话里，输入输出基本对半开，单价差异直接体现在账单上。但 Agent 是"多轮 + 工具调用 + 长上下文"的组合，输入 token 往往是输出的十几倍甚至几十倍。
我拿一个实际跑的任务举例：一个负责代码审查的 Agent，单次任务平均触发 8 轮工具调用，每轮都要带上完整的系统提示、工具定义、以及之前所有轮次的对话历史。算下来，输入 token 占了总消耗的 85% 以上。这种情况下，你换一个输出单价便宜 20% 的模型，对总成本的影响可能不到 3%。真正的大头在输入侧，而输入侧的成本由缓存命中率和上下文长度决定，跟模型单价关系不大。
2.2 缓存命中率才是成本的分水岭
Prompt Caching 是 Anthropic 这套体系里最被低估的功能。它的逻辑是：如果你连续请求的前缀部分完全一致，这部分 token 可以走缓存，价格大幅降低。在 Agent 场景里，系统提示、工具定义、few-shot 示例这些内容每一轮都重复，天然适合缓存。
问题在于，很多人迁移模型时只改了模型名，没动缓存配置。旧版本的缓存断点位置、缓存有效期、以及哪些内容该放进缓存前缀，这些在新模型上可能需要重新调。我见过最典型的错误是：系统提示里塞了一个动态的时间戳或者随机的 session id，导致每次请求的前缀都不一样，缓存命中率直接归零。这种情况下，你换什么模型都是全价跑，省钱的幻觉瞬间破灭。
2.3 上下文膨胀是隐形成本黑洞
Agent 跑久了，对话历史会越来越长。如果不做裁剪，每一轮都要把之前所有内容重新发一遍。假设一个任务跑了 20 轮，第 20 轮的输入里包含了前 19 轮的全部内容，这些内容里可能有一大半是已经处理完的中间结果、失败的尝试、以及无关的工具返回。
迁移到 Opus 5.5 之后，如果你的上下文管理策略还是"全量保留"，那新模型更强的理解能力反而会让你更放心地堆上下文，成本涨得更快。我实测过一个对比：同一个任务，全量保留上下文 vs 每 5 轮做一次摘要压缩，后者总 token 消耗降低了约 40%，而任务成功率几乎没有下降。这个 40% 跟模型单价无关，纯粹是配置问题。
3. 迁移前必须盘清楚的三个配置层
3.1 系统提示与工具定义的缓存边界
迁移第一步，不是改模型名，而是把系统提示和工具定义拆出来，单独审视它们的缓存友好度。判断标准很简单：这部分内容在同一个 Agent 的多次请求之间，是否完全一致？如果一致，它就应该被放在缓存前缀里；如果里面有动态内容，就要把它挪到缓存断点之后。
具体操作上，我会把系统提示分成三段：第一段是绝对静态的角色定义和输出规范，第二段是工具定义和调用约定，第三段是动态注入的任务上下文。前两段拼成一个固定的前缀字符串，第三段放在后面。然后在请求里设置缓存断点，让前两段走缓存。
这里有个容易忽略的细节：工具定义的顺序也会影响缓存。如果你用的是一个会自动排序工具列表的框架，每次生成的工具定义顺序可能不一样，缓存就失效了。我踩过这个坑，排查了半天才发现是框架在序列化工具时用了无序的字典。解决办法是手动固定工具顺序，或者在序列化时强制排序。
3.2 上下文裁剪策略的迁移适配
旧版本模型上下文窗口可能比较小，你被迫做了裁剪。迁移到 Opus 5.5 之后，窗口变大了，很多人第一反应是"终于不用裁了"，然后把裁剪逻辑关掉。这是个陷阱。窗口大不代表成本低，塞满窗口的输入 token 照样按量计费。
我的做法是保留裁剪逻辑，但调整阈值。具体来说，保留最近 N 轮的完整对话，更早的内容做摘要压缩，摘要里只保留任务状态、已确认的结论、以及未解决的阻塞点。N 的取值根据任务类型定：代码审查类任务 N 取 3 到 5 就够，因为审查结论一旦给出就不需要反复回看原始代码；而多步推理类任务 N 可以取大一点，因为前面的推理链可能还有用。
迁移时还要注意摘要的生成方式。如果你用模型自己生成摘要，这部分也是要花 token 的。我的经验是，摘要生成用便宜的小模型就够了，没必要用 Opus 5.5 来做这种压缩工作。把贵模型留给真正需要推理的环节。
3.3 工具调用编排的并发与重试配置
Agent 跑批量任务时，工具调用的编排方式直接影响成本。旧版本可能因为模型能力限制，工具调用经常失败需要重试，重试就意味着重复的输入 token。迁移到 Opus 5.5 之后，工具调用的准确率通常会提升，但如果你还保留着旧版本激进的重试策略，反而可能造成浪费。
我建议迁移时重新审视三个参数：最大重试次数、重试间隔、以及失败后的降级策略。最大重试次数从 3 降到 2，因为新模型的首次调用成功率更高，第三次重试的边际收益很低。重试间隔可以适当拉长，避免在服务端瞬时压力大时连续撞墙。降级策略上，如果某个工具连续失败，与其无限重试，不如让 Agent 换一条路径或者直接报告阻塞，这样省下的 token 比硬重试多得多。
4. Prompt Caching 的命中率是怎么被悄悄吃掉的
4.1 动态内容混入缓存前缀的典型场景
缓存失效最常见的原因，是动态内容不小心混进了本该静态的前缀。我整理了几个高频场景，你可以对照检查自己的配置。
| 场景 | 表现 | 修复方式 |
|---|---|---|
| 系统提示含时间戳 | 每次请求前缀不同，命中率 0 | 时间戳移到缓存断点之后 |
| 工具定义含 session id | 工具描述每次变化 | session id 从工具定义中剥离 |
| few-shot 示例随机采样 | 每次示例不同 | 固定示例集，或按任务类型分组固定 |
| 用户信息注入位置错误 | 用户相关字段放在前缀 | 用户信息放到断点之后 |
| 框架自动排序不稳定 | 序列化顺序随机 | 强制固定顺序 |
这个表格里的每一条我都实际遇到过。最隐蔽的是最后一条，因为它在你的代码里看不出来，是框架内部行为。排查方法是把两次请求的完整 payload 打出来做 diff，如果发现前缀部分有差异，就顺着差异找源头。
4.2 缓存断点位置的取舍逻辑
缓存断点不是越多越好。每设一个断点，系统就要在断点处做一次缓存写入，写入本身也有成本。我的经验是，一个 Agent 请求设 1 到 2 个断点就够了：第一个断点放在系统提示和工具定义之后，第二个断点放在固定的 few-shot 示例之后（如果有的话）。
断点位置的选择逻辑是：断点之前的内容，在同一个 Agent 的多次请求之间必须完全一致。如果你不确定某段内容是否稳定，就不要把它放进断点之前。宁可少缓存一点，也不要因为一个不稳定的字段导致整个前缀失效。
还有一个细节：缓存有有效期。如果你的 Agent 请求间隔很长，比如隔几小时才跑一次，缓存可能已经过期了，这时候缓存写入的成本就白花了。对于低频 Agent，我建议干脆不设缓存断点，或者把断点设在更靠后的位置，只缓存最核心的那部分。
4.3 用日志验证命中率的实操方法
光配置不够，你得能验证。我的做法是在请求返回后，把响应里的缓存相关字段记下来，包括缓存写入的 token 数、缓存读取的 token 数、以及未缓存的 token 数。这三个数字的比例就是命中率的直接体现。
如果发现缓存读取数一直是 0，说明断点没生效或者前缀不稳定。如果缓存写入数很高但读取数很低，说明每次请求的前缀都在变，缓存写了但用不上。理想状态下，稳定运行的 Agent 应该是缓存读取数占输入 token 的绝大部分，写入数只在第一次或者前缀变化时出现。
我一般会跑一个 20 次请求的小批量测试，观察命中率曲线。正常情况下，第一次请求全是写入，第二次开始读取数应该大幅上升。如果到第 10 次读取数还是 0，那肯定是配置有问题，得回去查前缀稳定性。
5. Claude Code 本地会话里的省钱细节
5.1 会话复用与上下文继承的边界
Claude Code 这类本地客户端有个特点：它会维护一个持续的会话，你在同一个会话里连续提问，上下文是继承的。这个机制用好了很省，用不好很费。省的地方在于，会话内的系统提示和项目上下文只需要加载一次；费的地方在于，如果你在一个会话里干了太多不相关的事，上下文会越滚越大。
我的习惯是：一个会话只做一类任务。比如这个会话专门用来改某个模块的代码，那个会话专门用来排查某个 bug。任务切换时开新会话，而不是在旧会话里继续。这样每个会话的上下文都保持在合理范围内，不会因为历史包袱导致每轮输入都很大。
迁移到 Opus 5.5 之后，我注意到会话的初始加载内容也需要重新审视。旧版本可能默认加载了某些项目文件作为上下文，新版本如果默认行为变了，加载的内容可能更多。建议迁移后先跑一个空会话，看看初始上下文有多大，如果超出预期，就去配置里调整加载范围。
5.2 项目级配置文件的迁移检查清单
Claude Code 的项目级配置文件里，有几个字段在迁移时值得逐一检查。我列一个清单，你可以照着过一遍。
- 模型名称字段：确认已经改成 Opus 5.5 对应的标识，别漏改。
- 上下文加载范围：检查是否加载了不必要的目录或文件，尤其是 node_modules、构建产物这类。
- 工具权限配置：新版本可能新增了工具，旧配置里没有对应权限，会导致工具调用失败后重试，浪费 token。
- 缓存相关配置：如果有显式的缓存开关或断点配置，确认它们在新版本下仍然有效。
- 超时与重试：本地客户端的超时设置如果太短，会导致请求中断重发，重复消耗。
这个清单里，最容易漏的是工具权限。我迁移时遇到过一次，新版本默认启用了某个文件操作工具，但我的配置里没给它权限，结果 Agent 反复尝试调用、反复失败，白白烧了一堆 token。后来在配置里显式声明了权限才解决。
5.3 本地模型与云端模型的混合编排
有些场景下，你会在 Claude Code 里同时用到云端模型和本地模型。比如简单的代码格式化、文件重命名这类任务，用本地小模型就够了；复杂的重构和推理，才走 Opus 5.5。这种混合编排如果配置得当，能省下不少云端调用。
迁移时的关键是：确认本地模型的调用路径没有被新版本的配置覆盖。我遇到过升级后本地模型的 endpoint 配置被重置的情况，导致所有请求都走了云端，成本瞬间上去。排查方法是看日志里每个请求实际打到了哪个 endpoint，如果发现本该走本地的请求走了云端，就去检查配置的优先级。
混合编排的另一个细节是任务路由的判断逻辑。什么任务走本地、什么任务走云端，这个判断本身如果也用模型来做，那判断的 token 也是成本。我的做法是用规则来判断，比如按文件类型、按任务关键词、按代码行数阈值，规则判断不花 token，而且稳定可控。
6. 迁移后成本不降反升的排查链路
6.1 从账单异常到配置定位的完整过程
迁移后如果发现成本没降甚至涨了，别急着怀疑模型，按下面的链路一步步排查。我把这个过程写成一个可复现的流程，你可以照着走。
第一步，拉出迁移前后各一周的 token 消耗明细，按输入、输出、缓存读取、缓存写入四个维度拆分。如果输入 token 涨了，问题在上下文或缓存；如果输出 token 涨了，问题在提示词或任务复杂度；如果缓存读取占比降了，问题在缓存配置。
第二步，对比迁移前后的请求 payload。重点看前缀部分是否一致，以及上下文长度是否变化。我一般会抓 5 个典型请求做 diff，差异点往往就是问题所在。
第三步，检查工具调用次数。新模型可能更"主动"，会调用更多工具，每次工具调用都带一轮输入。如果工具调用次数明显增加，就要审视工具描述是否过于宽泛，导致模型过度调用。
第四步，检查重试和失败率。失败重试是隐形成本，日志里如果看到大量重试记录，就要定位失败原因。
6.2 三个最容易被忽略的成本泄漏点
排查过程中，有三个泄漏点特别隐蔽，我单独拎出来说。
第一个是工具返回结果的体积。有些工具返回的数据量很大，比如读取一个大文件、查询一个宽表，这些返回内容会进入下一轮的输入。如果工具返回没有做裁剪，每轮都带着一大坨无关数据，成本就上去了。解决办法是在工具层做返回裁剪，只返回 Agent 真正需要的字段。
第二个是系统提示的冗余。迁移时如果直接把旧提示词复制过来，里面可能有很多针对旧模型特性的说明，新模型不需要了。这些冗余说明每轮都占 token。我建议迁移时把系统提示精简一遍，删掉所有"因为旧模型容易犯某错误所以特别强调"的内容。
第三个是并发任务的缓存冲突。如果你同时跑多个 Agent 实例，它们如果共享同一套缓存前缀，可能互相干扰。尤其是当不同实例的动态内容被错误地放进了共享前缀时，会导致缓存频繁失效。解决办法是给不同任务类型的 Agent 用不同的缓存前缀，或者干脆隔离缓存空间。
6.3 用 A/B 对比锁定真正的省钱配置
排查到最后，你需要用数据说话。我的做法是设计一组 A/B 对比：A 组用迁移后的新配置，B 组用旧配置但只改模型名。两组跑同样的任务集，对比总 token 消耗和任务成功率。
这个对比能帮你区分：哪些成本变化是模型本身带来的，哪些是配置带来的。如果 A 组比 B 组省很多，说明配置迁移起了作用；如果两组差不多，说明你的配置迁移没做到位，还有优化空间。
对比时要注意控制变量：任务集要一样，并发度要一样，运行时段尽量接近（避免服务端负载差异影响）。我一般会跑三轮取平均，单轮结果波动太大不可信。
7. 我踩过的几个坑和对应的处理方式
7.1 缓存断点设太靠前导致写入浪费
有一次我把缓存断点设在了系统提示的最开头，想着这样缓存范围最大。结果发现缓存写入量很高，但读取量上不去。排查后发现，系统提示开头有一段包含当前日期的内容，每天变化一次，导致缓存每天失效一次，写入的成本全白花了。
处理方式是把日期这类低频变化的内容挪到断点之后，断点只覆盖真正静态的部分。改完之后，缓存读取量明显上升，写入量降到了只在配置变更时出现。
7.2 工具描述过于详细反而增加调用
迁移时我为了"让新模型更好理解工具"，把工具描述写得很详细，每个参数都加了长段说明。结果模型调用工具的频次反而增加了，因为它觉得每个工具都能做很多事，倾向于多试几个。工具调用增加意味着输入轮次增加，成本上升。
后来我把工具描述精简到只保留必要信息，明确每个工具的适用边界和不适用场景。调用频次降下来了，任务成功率没受影响。这个经验说明，工具描述不是越详细越好，清晰边界比详细说明更重要。
7.3 上下文摘要压缩的粒度选择
做上下文摘要时，我一开始压缩得太狠，把中间结果全丢了，导致 Agent 后面需要某个中间结果时找不到，只能重新计算，反而更费。后来调整了粒度：任务状态和关键结论必须保留，中间的计算过程可以丢，但计算用到的输入参数要保留。
这个粒度需要根据任务类型调。代码类任务，保留文件路径和修改点；数据分析类任务，保留查询条件和结果摘要；多步推理类任务，保留每一步的结论和依据。没有通用答案，得自己试。
7.4 并发场景下的缓存隔离
跑并发任务时，我遇到过缓存互相干扰的问题。多个 Agent 实例共享同一套前缀，但各自的动态内容不同，导致缓存频繁失效。后来给每个任务类型分配了独立的前缀模板，实例之间不再共享缓存空间，命中率才稳定下来。
这个坑的教训是：缓存设计要考虑并发场景。单实例跑得好好的配置，放到并发环境里可能完全失效。迁移时如果涉及并发，一定要单独测缓存表现。
8. 迁移完成后我保留的一套检查习惯
迁移不是一次性动作，而是一个持续调优的过程。我现在保留了一套检查习惯，每隔一段时间跑一次，确保成本没有悄悄回升。
第一项检查是缓存命中率的周环比。如果某周命中率明显下降，说明有新的动态内容混进了前缀，或者任务类型发生了变化。这个检查我一般看缓存读取 token 占总输入 token 的比例，低于某个阈值就报警。
第二项检查是单任务平均 token 消耗。这个指标能反映上下文管理是否退化。如果单任务消耗持续上升，说明上下文裁剪可能失效了，或者任务复杂度真的增加了，需要区分对待。
第三项检查是工具调用失败率。失败率上升往往意味着工具描述或权限配置出了问题，失败重试会直接推高成本。
第四项检查是并发实例的缓存隔离情况。如果新增了任务类型但没有配置独立前缀，命中率会被拖累。
这套习惯跑下来，每次也就花十几分钟，但能避免成本在不知不觉中涨上去。模型会更新，配置会漂移，唯一能做的就是定期看一眼数据，别让省下来的钱又漏回去。
最后分享一个我自己的判断标准：如果迁移后一个月，你的单任务成本没有下降 20% 以上，那大概率不是模型的问题，而是配置还有优化空间。Opus 5.5 的能力提升是实打实的，但能力提升要转化成成本优势，中间隔着一层配置。这层配置做得好不好，决定了你是"用新模型花旧钱"还是"用新模型省真金"。
