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 的能力提升是实打实的但能力提升要转化成成本优势中间隔着一层配置。这层配置做得好不好决定了你是用新模型花旧钱还是用新模型省真金。
