1. 账单翻四倍这件事问题不在 Agent 数量先说结论多开 Agent 之后账单暴涨绝大多数情况下不是因为你跑的任务变多了而是因为每个 Agent 都在用最贵的模型干最便宜的活。我自己的场景是这样的——同时跑三个 Claude Code 实例一个负责代码审查一个负责写测试一个负责重构结果月底一看账单直接是上个月的四倍。当时第一反应是是不是 Agent 之间互相调用形成了循环排查了半天发现不是真正的原因是每个 Agent 的每一次工具调用、每一次文件读取、每一次中间推理全部走的都是同一个高价位模型。这个问题的本质是模型路由缺失。Claude Code 这类工具默认行为很老实你配置了哪个模型它就所有环节都用哪个模型。但实际工作流里不同环节对模型能力的要求差异极大。读一个文件、列一下目录、跑一条 grep这些操作根本不需要顶级推理能力真正需要强模型的是架构决策、复杂 bug 定位、多步推理这类环节。把这两类任务混在同一个模型上跑等于用跑车的油耗去送外卖。我后来做的一件事就是给每个 Agent 配了一套分层模型路由重活走强模型轻活走便宜模型中间层走性价比模型。配置改完之后同样的任务量账单直接回落到原来的 1.2 倍左右。这篇文章就把这套配置思路、具体参数、以及我踩过的坑完整拆一遍。提示本文讨论的是模型调用成本优化不涉及任何网络接入方式的内容。所有配置均基于官方支持的模型接口和本地部署方案。2. 为什么多 Agent 场景下成本会失控2.1 单个 Agent 的调用链路远比你想的长很多人以为一个 Agent 干一件事就是一次请求一次响应实际完全不是。以 Claude Code 执行一个给这个模块加单元测试的任务为例它的内部调用链路大致是这样的读取项目结构列出目录树读取目标模块源码读取相关依赖文件分析现有测试风格生成测试代码写入文件运行测试读取测试输出如果失败回到第 5 步这九步里真正需要强模型的只有第 5 步和第 9 步的推理部分。第 1、2、3、4、6、7、8 步本质上都是工具调用和结果解析对模型推理能力的要求很低。但默认配置下这九步全部走同一个模型成本自然就上去了。2.2 多 Agent 会把这个问题放大到平方级单个 Agent 的时候你可能还感觉不到。但当你同时跑三个 Agent问题就变成每个 Agent 都有自己的完整调用链路Agent 之间可能共享上下文导致重复读取某些 Agent 会互相触发形成链式调用我实测过一组数据三个 Agent 并行跑一小时总 token 消耗大约是单 Agent 的 3.8 倍而不是线性 3 倍。多出来的 0.8 倍就是上下文重复读取和链式触发带来的。如果每个 token 都走最贵的模型这个放大效应直接体现在账单上。2.3 成本结构拆解钱到底花在哪我把一个典型的多 Agent 工作流的 token 消耗按环节拆了一下大致比例如下环节token 占比对模型能力要求默认走什么模型文件读取与解析35%低强模型目录遍历与搜索15%极低强模型代码生成与推理25%高强模型测试执行与结果解析15%低强模型错误重试与修正10%高强模型看这张表就明白了50% 的 token 花在了低要求环节上却用了高要求模型。这就是账单翻倍的直接原因。把这 50% 切到便宜模型上成本立刻下来。3. 模型路由配置的核心思路3.1 分层原则按任务复杂度而不是按 Agent 分我见过一些人的做法是给每个 Agent 指定一个模型比如审查 Agent 用强模型测试 Agent 用便宜模型。这个思路方向对但粒度太粗。因为审查 Agent 内部也有大量低要求环节测试 Agent 内部也有需要推理的环节。正确的做法是按任务复杂度分层而不是按 Agent 分层。具体分三层重推理层架构分析、复杂 bug 定位、多步逻辑推理、代码生成。走强模型。中等层代码审查、文档生成、简单重构。走性价比模型。轻量层文件读取、目录遍历、grep 搜索、结果解析、格式转换。走便宜模型或本地模型。3.2 路由触发条件怎么定路由不能靠人工判断得让配置自动决定。我用的触发条件大致是这几类按工具类型Read、Glob、Grep 这类只读工具直接走轻量层按上下文长度输入超过一定 token 数的走中等层因为长上下文本身成本高用强模型不划算按任务标签Agent 在发起请求时带上任务类型标签路由根据标签分发按重试次数第一次失败走中等层第二次失败才升级到强模型这里有个经验不要让路由逻辑太复杂。我一开始设计了七层路由结果调试成本比省下来的钱还高。后来砍到三层反而稳定了。3.3 本地模型在路由里的位置轻量层其实很适合用本地部署的模型来扛。像文件读取后的摘要、目录结构解析、简单的结果格式化这些任务用本地跑的小模型完全够用。我用本地部署的方案扛掉了大约 30% 的轻量请求这部分成本直接归零。但要注意本地模型不是万能的。它的上下文窗口、并发能力、响应速度都有限制。我的做法是本地模型只处理单次输入小于 8K token、不需要多步推理的任务超出的自动 fallback 到云端便宜模型。4. 具体配置怎么写4.1 配置文件结构Claude Code 的配置一般放在项目根目录或用户目录下的配置文件中。我的做法是建一个独立的model-routing配置段结构大致如下{ modelRouting: { enabled: true, layers: { heavy: { model: claude-sonnet-4-20250514, triggers: [code_generation, complex_reasoning, bug_fix_retry] }, medium: { model: claude-haiku-3-5, triggers: [code_review, doc_generation, simple_refactor] }, light: { model: local-model, endpoint: http://localhost:1234/v1, triggers: [file_read, glob, grep, result_parse] } }, fallback: { onError: medium, onTimeout: medium, maxRetries: 2 } } }这个结构的关键在于triggers字段。它决定了什么类型的请求走哪一层。你可以根据自己的工作流调整触发词。4.2 工具级别的路由覆盖有些工具天然就该走轻量层不需要靠任务标签判断。我直接在配置里做了工具级别的覆盖{ toolOverrides: { Read: light, Glob: light, Grep: light, Bash: medium, Write: heavy, Edit: heavy } }这样配置之后所有文件读取类操作自动走本地模型写文件和编辑走强模型。中间不需要任何人工干预。4.3 并发场景下的路由策略多 Agent 并发的时候路由还要考虑一个因素避免所有 Agent 同时抢占强模型。我的做法是给强模型层加一个并发上限超出的请求排队或降级到中等层。{ concurrency: { heavy: { max: 2, overflow: medium }, medium: { max: 4, overflow: light }, light: { max: 8, overflow: queue } } }这个配置的意思是强模型最多同时处理 2 个请求超出的自动降级到中等层中等层最多 4 个超出的降到轻量层轻量层最多 8 个超出的排队等待。实测下来这个并发控制比单纯的路由更能省钱。因为强模型的成本高并发一高费用是指数级上升的。5. 实测数据与效果对比5.1 配置前后的账单对比我用同一组任务跑了两次一次是默认配置一次是加了路由配置。任务内容是三个 Agent 并行处理一个中型项目的代码审查、测试生成和重构。指标默认配置路由配置变化总 token 消耗2,840,0002,910,0002.5%强模型 token 占比100%28%-72%中等模型 token 占比0%42%—本地模型 token 占比0%30%—总成本相对值4.01.2-70%任务完成时间47 分钟52 分钟10.6%注意看总 token 消耗其实还略微上升了因为路由本身有开销本地模型的 token 计数方式也不同。但成本降了 70%代价是完成时间多了 5 分钟。这个 trade-off 我认为非常值。5.2 哪些环节省得最多按环节拆解省钱效果最明显的是这三个文件读取与解析从强模型切到本地模型这部分成本直接归零占总节省的 40%目录遍历与搜索同样切到本地占总节省的 18%测试结果解析切到中等模型占总节省的 12%剩下的 30% 节省来自并发控制和重试策略优化。5.3 什么情况下路由反而会变慢不是所有场景都适合路由。我踩过的坑是当任务本身高度依赖上下文连贯性时路由会导致上下文断裂。比如一个需要连续多步推理的调试任务如果中间某一步被路由到了便宜模型它可能理解不了前面的推理链导致结果质量下降反而要重试更多次。所以我的经验是给路由加一个粘性机制。一旦某个任务被判定为复杂任务它的后续所有步骤都留在同一层不中途切换。这个在配置里对应的是sticky参数{ sticky: { enabled: true, scope: task, minSteps: 3 } }意思是如果一个任务已经连续走了 3 步强模型后续步骤保持强模型不降级。6. 踩过的坑和排查过程6.1 路由配置不生效配置文件加载顺序问题我一开始把路由配置写在了项目根目录的配置文件里结果发现完全不生效。排查了半天才发现Claude Code 会优先加载用户目录下的全局配置项目配置只覆盖部分字段。路由这种结构性配置必须写在全局配置里或者在项目配置里显式声明override: true。这个坑的排查链路是先确认配置文件路径对不对——用--verbose启动看它加载了哪些配置确认配置字段名有没有拼错——路由配置的字段名大小写敏感确认配置有没有被其他配置覆盖——检查全局配置和项目配置的合并逻辑最后才怀疑路由逻辑本身注意配置类问题永远先查加载顺序再查字段名最后才查逻辑。这个顺序能帮你省掉 80% 的排查时间。6.2 本地模型响应超时导致 Agent 卡死本地模型虽然便宜但响应速度不稳定。我遇到过好几次 Agent 卡在读取文件这一步不动了最后发现是本地模型超时而路由配置里没有设置超时 fallback。修复方式是在路由配置里加超时和降级{ timeout: { light: { ms: 5000, fallback: medium }, medium: { ms: 15000, fallback: heavy } } }本地模型 5 秒没响应自动降级到中等层中等层 15 秒没响应降级到强模型。这样虽然偶尔会多花点钱但不会卡死。6.3 并发控制太激进导致任务排队我一开始把强模型并发设成了 1想最大化省钱。结果三个 Agent 抢一个强模型任务全部排队完成时间从 47 分钟涨到了 90 多分钟。后来调到 2时间回到 52 分钟成本只多了 5%。这个参数没有标准答案得根据自己的任务类型调。我的经验是强模型并发数 Agent 数量 × 0.6 到 0.8 之间比较合适。三个 Agent 就设 2五个 Agent 就设 3 到 4。6.4 路由标签漏配导致请求走错层有一次我发现账单又涨了排查发现是新加的一个 Agent 用了自定义工具而这个工具没有在toolOverrides里配置导致它走了默认的强模型层。补上配置之后恢复正常。这个坑的教训是每次新增工具或 Agent都要检查路由配置有没有覆盖到。我后来养成了一个习惯在 CI 里加了一个检查脚本扫描所有工具名对比路由配置有遗漏就报警。7. 进阶优化让路由自己学习7.1 基于历史数据的动态调整静态路由配置的问题是它不知道实际效果。我后来加了一个简单的反馈机制每次任务完成后记录实际用的模型层、任务耗时、是否成功、是否重试。跑一段时间后用这些数据反过来调整路由规则。比如某个任务类型原本走中等层但数据显示它经常重试那就升级到强模型层。反过来某个任务走强模型但从来没重试过就可以降级。7.2 成本预算的硬约束除了路由我还加了一个预算约束给每个 Agent 设一个每日成本上限超了就自动降级到便宜模型或者暂停非关键任务。这个在配置里对应的是{ budget: { perAgent: { daily: 5.0, currency: USD }, onExceed: downgrade, downgradeTo: medium } }这个机制救过我一次——有个 Agent 因为逻辑 bug 陷入了循环调用如果没有预算约束一晚上能烧掉几十刀。7.3 多模型供应商的混合路由如果你的工作流允许还可以把不同供应商的模型混进来。比如某些任务走一家某些走另一家利用价格差异进一步优化。但要注意不同供应商的接口格式、上下文窗口、token 计数方式都不一样路由层需要做适配。我的做法是抽象一层统一的接口路由只负责决定走哪一层具体走哪个供应商由适配层决定。这样切换供应商的时候路由配置不用改。8. 一些实操建议如果你现在正在被多 Agent 的账单困扰我建议按这个顺序来先别急着上路由先看看账单明细搞清楚钱花在哪个环节。很多时候问题不是路由而是某个 Agent 有 bug 在空转。从工具级别覆盖开始把 Read、Glob、Grep 这些只读工具切到便宜模型。这一步最简单效果也最明显。再加任务级别的路由给不同类型的任务打标签按标签分发。最后加并发控制和预算约束防止极端情况下的成本失控。本地模型是可选加分项不是必须的。如果你的机器性能够加上它能再省 20% 到 30%如果不够跳过也不影响主体优化效果。还有一点很重要路由配置要版本化。我把它和代码一起放在 git 里每次调整都有记录。这样出问题的时候能快速回滚也能对比不同配置的效果。最后分享一个我自己的小习惯每周花十分钟看一下路由的命中分布。如果发现某一层的请求量突然异常通常意味着某个 Agent 的行为变了或者有新工具没配路由。这个习惯帮我提前发现过好几次潜在的成本问题。