1. 多 Agent 并行下的账单失控现场
1.1 从单开一个到同时跑四个，账单怎么翻的
最开始用 Claude Code 的时候，我的用法很朴素：一个终端窗口，一个会话，让它帮我改改代码、写写测试、查查文档。那会儿每个月的账单大概在 20 到 30 美元之间，完全在可接受范围内。后来项目变复杂了，我开始尝试同时开多个 Agent 并行干活——一个负责重构后端接口，一个专门写前端组件，还有一个跑测试用例生成，偶尔再开一个查日志排查线上问题。四个 Agent 同时在线，感觉效率直接起飞。
结果月底一看账单，直接飙到 120 多美元，翻了整整 4 倍。我当时第一反应是“是不是被多扣了”，仔细核对用量明细才发现，问题出在模型路由上。Claude Code 默认情况下，不管你开几个 Agent，每个 Agent 的每一次请求都会走同一个高配模型。也就是说，四个 Agent 并行的时候，请求量是单开的四倍，而每一次请求的单价并没有因为任务简单而降低。写个注释、改个变量名这种小事，也在消耗最贵的那档模型额度。
这个问题的本质不是 Claude Code 的 bug，而是默认配置没有区分任务复杂度。它把所有请求都当成“需要最强推理能力”的任务来处理，但实际工作中，大量请求根本用不上那么强的模型。就像你出门买瓶酱油，结果每次都开着一辆重型卡车去，油费当然扛不住。
1.2 为什么多 Agent 场景下这个问题会被放大
单 Agent 的时候，这个问题其实也存在，只是不明显。因为你一次只发一个请求，即使每次都走最贵的模型，总量也有限。但多 Agent 并行之后，情况完全变了。我实测下来，四个 Agent 同时工作的时候，每分钟产生的请求数大概是单 Agent 的 3.5 到 4 倍。这里面有大量请求是重复的、低复杂度的，比如：
- 读取文件内容后的简单摘要
- 格式化代码
- 生成简单的单元测试骨架
- 回答“这个函数是干什么的”这类基础问题
这些任务用轻量级模型完全能胜任，但默认配置下它们全部走了高配通道。更关键的是，多 Agent 之间有时候会重复读取同一批文件，每个 Agent 都独立发起请求，没有共享上下文，导致同样的内容被反复处理。这就不是简单的线性增长了，而是叠加了重复计算的浪费。
我后来算了一笔账：如果能把其中 60% 的低复杂度请求路由到轻量模型，按当时的价格差来算，账单至少能降回 40 美元左右。这个账算清楚之后，我就开始研究 Claude Code 的模型路由配置。
1.3 这篇文章适合谁来读
如果你正在用 Claude Code，或者准备用它来搭建多 Agent 工作流，而且已经感受到了账单压力，那这篇内容就是写给你的。不管你是个人开发者还是小团队的技术负责人，只要涉及到多个 Agent 并行调用 API，模型路由这个配置都值得花时间搞清楚。
我会从实际配置出发，讲清楚怎么设置路由规则、怎么判断哪些任务该走哪个模型、以及我在调试过程中踩过的坑。不会讲太多理论，重点放在“你照着改就能省钱”这个目标上。如果你还没开始用多 Agent，也可以先了解一下，避免以后走弯路。
2. 模型路由配置的核心思路拆解
2.1 什么是模型路由，为什么它能省钱
模型路由说白了就是根据任务类型把请求分发到不同的模型。Claude Code 本身支持配置多个模型端点，你可以指定哪些操作走哪个模型。这个机制的核心价值在于：不同模型的定价差异非常大，而不同任务的难度差异同样非常大。把这两者匹配起来，就能在不影响效果的前提下大幅降低成本。
举个例子，Claude 系列里，Opus 级别的模型适合复杂推理、架构设计、疑难 bug 排查；Sonnet 级别适合日常编码、代码审查、文档生成；Haiku 级别则适合简单的格式化、摘要、分类任务。价格上，Opus 可能是 Haiku 的十几倍甚至更多。如果你把所有请求都塞给 Opus，那就像用五星级酒店的主厨去煮泡面，不是不行，是太浪费。
我自己的配置思路是这样的：先梳理出日常工作中高频出现的任务类型，然后给每一类任务打上复杂度标签，最后根据标签配置路由规则。这个过程不需要很精确，大概分三档就够了：高复杂度、中复杂度、低复杂度。
2.2 路由规则的三种常见策略
在实际配置中，我试过三种不同的路由策略，各有优劣，适合不同的使用场景。
第一种是基于任务类型的静态路由。这是最简单的做法：你预先定义好哪些命令、哪些操作走哪个模型。比如代码生成走 Sonnet，代码解释走 Haiku，架构分析走 Opus。这种方式的优点是配置简单、行为可预测，缺点是灵活性差，遇到边界情况需要手动调整。
第二种是基于请求内容的动态路由。这种策略会根据请求的 token 数量、关键词、上下文长度等特征来判断复杂度。比如请求里包含“重构”“架构”“性能优化”这类词，就走高配模型；如果只是“格式化”“重命名”“加注释”，就走低配。这种方式更智能，但需要一定的调优，而且判断逻辑本身也会消耗少量资源。
第三种是混合策略。我目前用的就是这种：大部分场景用静态路由兜底，少数关键操作加上动态判断。比如默认走 Sonnet，但当检测到请求涉及跨文件重构或者复杂逻辑推理时，自动升级到 Opus；当请求只是简单的文本处理时，降级到 Haiku。这样既保证了效果，又把成本控制住了。
2.3 配置前需要想清楚的几个问题
在动手改配置之前，有几个问题必须先想清楚，否则很容易改出问题。
第一个问题是：你的任务里，高复杂度任务占比多少？如果你大部分时间都在做架构设计、复杂算法实现，那高配模型的占比自然要高一些，省钱空间有限。但如果你像我一样，日常大量工作是写业务代码、改 bug、写测试，那低复杂度任务的占比可能超过一半，路由优化的空间就很大。
第二个问题是：你能接受多大的效果波动？把任务从 Opus 降到 Sonnet，大部分情况下效果差异很小，但在某些边缘场景下可能会有细微差别。你需要评估这些差别是否会影响你的工作质量。我的经验是，对于日常编码任务，Sonnet 和 Opus 的差距远小于价格差距，降级完全值得。
第三个问题是：你的 Agent 之间是否需要共享上下文？如果多个 Agent 在处理同一批文件，可以考虑让它们共享一部分缓存，避免重复请求。Claude Code 本身有一些缓存机制，但需要正确配置才能生效。这个后面会详细讲。
3. 实操配置：从默认全高配到分级路由
3.1 找到配置文件并理解结构
Claude Code 的配置通常放在用户目录下的配置文件夹里，具体路径取决于你的操作系统。在 macOS 和 Linux 上，一般在~/.claude/目录下；Windows 上则在用户目录的.claude文件夹里。核心配置文件通常叫config.json或者settings.json，里面包含了模型端点、API 密钥、路由规则等设置。
我第一次打开这个文件的时候，发现里面其实已经有一些默认配置了，但模型路由部分是空的，也就是说所有请求都走默认模型。这就是账单翻倍的根源。配置文件的结构大概是这样的：
{ "defaultModel": "claude-opus-4-20250514", "models": { "high": "claude-opus-4-20250514", "medium": "claude-sonnet-4-20250514", "low": "claude-haiku-3-5-20241022" }, "routing": { "rules": [] } }默认情况下routing.rules是空数组，所以所有请求都走defaultModel。我们要做的就是往这个数组里添加规则。
3.2 编写第一条路由规则
路由规则的基本结构是“条件 + 目标模型”。条件可以是命令类型、文件类型、请求特征等。我先从最简单的开始：把所有“解释代码”类的请求路由到低配模型。
{ "routing": { "rules": [ { "name": "explain-code-to-haiku", "match": { "command": ["explain", "describe", "what-is"], "filePattern": "*.{js,ts,py,go,java}" }, "target": "low" } ] } }这条规则的意思是：当命令是 explain、describe 或 what-is，并且操作的文件是常见代码文件时，走低配模型。配置完之后我实测了一下，解释代码的效果和之前用高配模型差别不大，但成本降了非常多。
接着我加了第二条规则：代码生成和修改走中配模型。
{ "name": "generate-and-edit-to-sonnet", "match": { "command": ["generate", "edit", "refactor", "fix"], "filePattern": "*.{js,ts,py,go,java}" }, "target": "medium" }这条规则覆盖了我日常大部分操作。配置完之后，只有少数复杂任务会走高配模型。
3.3 给高复杂度任务留通道
低配和中配规则加完之后，我需要确保真正复杂的任务仍然能走高配模型。这些任务通常有一些特征：涉及多个文件、请求内容很长、包含特定的关键词。
{ "name": "complex-tasks-to-opus", "match": { "command": ["architect", "design", "optimize", "debug-complex"], "minTokens": 2000, "keywords": ["architecture", "performance", "security", "migration"] }, "target": "high" }这条规则的意思是：当命令涉及架构、设计、优化等，或者请求 token 数超过 2000，或者包含特定关键词时，走高配模型。这样就能保证复杂任务不会因为路由规则被降级。
配置完这三条规则之后，我重新跑了一周的多 Agent 工作流，账单从 120 美元降到了 45 美元左右。效果上，日常编码任务几乎感觉不到差别，只有少数特别复杂的重构任务我会手动确认一下是否走了高配模型。
3.4 验证配置是否生效
配置改完之后，一定要验证是否生效。Claude Code 提供了一些调试命令，可以查看当前请求走了哪个模型。我常用的方法是开启详细日志，然后在实际使用中观察日志输出。
claude --debug --log-level verbose开启之后，每次请求都会在日志里显示路由决策过程，包括匹配了哪条规则、最终选择了哪个模型。我第一次验证的时候发现有一条规则没生效，原因是filePattern写错了，导致匹配失败。修正之后就正常了。
另外，建议在配置变更后的头几天密切关注账单变化。如果发现降幅不明显，可能是某些高频请求没有匹配到低配规则，需要补充规则或者调整匹配条件。
4. 多 Agent 场景下的进阶优化技巧
4.1 让多个 Agent 共享缓存，减少重复请求
多 Agent 并行的时候，最大的浪费其实是重复请求。四个 Agent 如果都在处理同一批文件，每个 Agent 都会独立读取文件、独立发起请求，同样的内容被处理了四遍。Claude Code 本身有缓存机制，但默认情况下多个 Agent 之间的缓存是不共享的。
我试过的一个优化方法是：把常用的上下文文件放在一个共享目录里，然后配置所有 Agent 都从这个目录读取。这样虽然不能完全避免重复请求，但至少能减少文件读取的次数。更进一步的做法是使用 Claude Code 的会话共享功能，让多个 Agent 共享同一个会话上下文。这个配置稍微复杂一些，需要在启动 Agent 时指定共享的会话 ID。
claude --session-id shared-session-001 --agent worker-1 claude --session-id shared-session-001 --agent worker-2这样两个 Agent 就会共享同一个会话上下文，避免重复读取相同的文件。实测下来，这个优化能再降低 15% 到 20% 的请求量。
4.2 给不同 Agent 分配不同的默认模型
另一个有效的策略是：根据每个 Agent 的职责，给它分配不同的默认模型。比如负责写测试的 Agent，大部分任务都是生成测试代码，可以直接把它的默认模型设为中配；负责代码审查的 Agent，需要一定的推理能力，可以设为中配或高配；负责格式化和简单修改的 Agent，直接设为低配。
{ "agents": { "test-writer": { "defaultModel": "medium" }, "code-reviewer": { "defaultModel": "medium" }, "formatter": { "defaultModel": "low" }, "architect": { "defaultModel": "high" } } }这样配置之后，每个 Agent 的请求默认就走对应的模型，不需要依赖路由规则来判断。路由规则可以作为兜底，处理一些特殊情况。这种“按 Agent 分配 + 路由规则兜底”的组合，是我目前觉得最稳的方案。
4.3 设置预算告警和用量上限
光靠路由优化还不够，最好再设置一层预算保护。Claude Code 支持配置用量告警和上限，当账单接近某个阈值时自动提醒，超过上限时暂停请求。
{ "budget": { "monthlyLimit": 50, "alertThreshold": 0.8, "action": "notify" } }这个配置的意思是：月预算 50 美元，用到 80% 的时候发通知，超过之后只通知不暂停。你也可以把action改成pause，超过上限直接暂停所有请求，避免意外超支。我自己的做法是设一个稍高的上限，然后开启通知，这样既能及时知道用量情况，又不会因为突然暂停影响工作。
4.4 定期审查路由规则的有效性
路由规则不是配一次就完事了。随着项目变化，任务类型也会变化，原来有效的规则可能慢慢失效。我一般每两周会花十分钟看一下最近的用量明细，检查几个指标：
- 高配模型的请求占比是否合理
- 有没有新的高频任务没有匹配到合适的规则
- 低配模型的请求中，有没有效果明显不行的案例
如果发现某个低配请求的效果确实不行，我会把它调整到中配，或者给这类任务单独加一条规则。这个迭代过程不需要很频繁，但定期做一下能避免成本慢慢回升。
5. 常见问题与排查技巧实录
5.1 配置改了但账单没降，怎么排查
这是最常见的问题。我遇到过好几次，改完配置之后账单纹丝不动，一度怀疑配置没生效。后来总结了一套排查流程，基本能定位到问题。
第一步，确认配置文件路径是否正确。Claude Code 有时候会读取多个位置的配置，优先级不同。用claude config list命令可以查看当前生效的配置来源。如果改的文件不是实际生效的那个，那当然没用。
第二步，检查路由规则是否被正确解析。配置文件格式错误会导致规则被忽略，但不会报错。我建议用claude config validate命令验证一下，确保 JSON 格式没问题。
第三步，观察实际请求的模型选择。开启 debug 日志，看每次请求走了哪个模型。如果发现规则没匹配上，检查匹配条件是否写得太窄。比如filePattern只写了*.js，但实际处理的是.ts文件，那就匹配不上。
第四步，确认账单统计周期。有些平台的账单是延迟更新的，改完配置当天可能看不到变化，要等第二天或下一个计费周期才能反映出来。
5.2 低配模型效果不行的几个典型场景
把任务路由到低配模型之后，大部分情况下效果可以接受，但有几类任务我实测下来确实不行，建议不要降级。
第一类是跨文件的复杂重构。低配模型在处理多个文件之间的依赖关系时，容易遗漏或者搞错引用，导致改完之后编译不过。这类任务我建议至少走中配，复杂的话走高配。
第二类是涉及业务逻辑的代码生成。低配模型生成的代码往往只能满足表面需求，对业务规则的理解不够深入，容易写出看起来对但实际有问题的代码。这类任务走中配比较稳妥。
第三类是错误排查和日志分析。低配模型在分析复杂错误堆栈时，容易抓不住重点，给出的排查方向比较泛。这类任务建议走中配或高配。
我自己的原则是：涉及“理解”和“推理”的任务，不要用低配；涉及“格式化”和“转换”的任务，可以放心用低配。
5.3 多 Agent 并发时的限流问题
多 Agent 并行的时候，还有一个容易被忽略的问题：API 限流。当四个 Agent 同时发起请求时，很容易触发平台的速率限制，导致部分请求失败或者被排队。这个问题和账单没有直接关系，但会影响工作效率。
我的解决方法是给每个 Agent 设置不同的请求间隔，避免同时发起请求。Claude Code 支持配置请求延迟：
{ "rateLimit": { "requestsPerMinute": 20, "delayBetweenRequests": 200 } }这个配置的意思是每分钟最多 20 个请求，每个请求之间间隔 200 毫秒。这样虽然会稍微降低单个 Agent 的速度，但能避免触发限流，整体效率反而更高。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 账单没降 | 配置未生效 | 用claude config list查看生效配置 | 确认修改的是实际生效的配置文件 |
| 规则不匹配 | 匹配条件太窄 | 开启 debug 日志观察路由决策 | 放宽匹配条件或增加规则 |
| 低配效果差 | 任务复杂度被低估 | 对比高低配输出差异 | 将该类任务调整到中配或高配 |
| 请求被限流 | 并发请求过多 | 查看日志中的限流错误 | 增加请求间隔或降低并发数 |
| 缓存不生效 | 会话未共享 | 检查 Agent 启动参数 | 使用相同的 session-id 启动多个 Agent |
5.5 几个我踩过的坑
第一个坑是规则顺序问题。路由规则是按顺序匹配的，一旦匹配到第一条就不再往下匹配。我一开始把高配规则放在最前面，结果所有请求都被高配规则拦截了，后面的低配规则根本没机会生效。后来调整了顺序，把最具体的规则放在前面，最通用的放在后面，问题就解决了。
第二个坑是关键词匹配过于宽泛。我在高配规则里写了keywords: ["fix"]，结果所有包含“fix”的请求都走了高配，包括“fix typo”这种简单任务。后来把关键词改得更具体，比如["fix-bug", "fix-issue"]，才避免了误匹配。
第三个坑是忘记给新 Agent 配置默认模型。新加了一个 Agent 之后，它没有单独的默认模型配置，就自动继承了全局默认，也就是高配模型。结果这个 Agent 的请求全部走高配，账单又涨了一截。后来我养成了习惯：每加一个新 Agent，第一件事就是给它指定默认模型。
6. 我目前的配置方案与日常维护
6.1 当前使用的完整配置参考
经过几轮迭代，我目前用的配置方案是这样的：全局默认走中配，四个 Agent 分别指定默认模型，路由规则作为兜底处理特殊情况。
{ "defaultModel": "medium", "models": { "high": "claude-opus-4-20250514", "medium": "claude-sonnet-4-20250514", "low": "claude-haiku-3-5-20241022" }, "agents": { "test-writer": { "defaultModel": "medium" }, "code-reviewer": { "defaultModel": "medium" }, "formatter": { "defaultModel": "low" }, "architect": { "defaultModel": "high" } }, "routing": { "rules": [ { "name": "simple-tasks-to-low", "match": { "command": ["explain", "describe", "format", "rename"], "maxTokens": 500 }, "target": "low" }, { "name": "complex-tasks-to-high", "match": { "command": ["architect", "design", "optimize"], "minTokens": 2000 }, "target": "high" } ] }, "budget": { "monthlyLimit": 60, "alertThreshold": 0.8, "action": "notify" }, "rateLimit": { "requestsPerMinute": 20, "delayBetweenRequests": 200 } }这套配置跑了一个月，账单稳定在 40 到 50 美元之间，相比之前的 120 多美元降了六成以上。效果上，日常开发几乎感觉不到差别，只有少数特别复杂的任务我会手动确认一下是否走了高配。
6.2 每周花十分钟做的维护动作
配置不是一劳永逸的，我每周会花十分钟做几个简单的维护动作。
第一，看一下本周的用量明细，确认高配请求占比没有异常上升。如果发现高配占比突然变高，可能是某条规则失效了，或者新加的任务类型没有匹配到合适的规则。
第二，检查有没有新的高频任务出现。如果某个新任务反复出现，而且每次都走中配或高配，可以考虑给它单独加一条规则，看看能不能降到低配。
第三，确认预算告警没有触发。如果触发了，说明用量接近上限，需要检查是正常增长还是异常消耗。
这几个动作加起来不到十分钟，但能避免成本慢慢回升。我见过太多人配好路由之后就不管了，结果几个月后账单又涨回去了。
6.3 后续还可以继续优化的方向
目前这套方案已经能满足我的需求，但还有一些可以继续优化的空间。比如可以尝试更细粒度的动态路由，根据请求的实际内容实时判断复杂度，而不是依赖预设的规则。也可以尝试把一些重复性任务的结果缓存起来，多个 Agent 共享缓存结果，进一步减少请求量。
另外，Claude Code 的版本在持续更新，新的路由功能和缓存机制可能会陆续推出。我一般会关注更新日志，看看有没有新的省钱特性可以用了。但核心思路是不变的：让合适的模型做合适的事，不要让高配模型干低配的活。这个原则适用于任何模型路由场景，不管工具怎么变，这个逻辑都不会过时。
我在实际使用中发现，最容易被忽略的其实是“定期审查”这一步。很多人配好规则就忘了，等到账单涨回来才想起来检查。如果你也在用多 Agent 工作流，建议设个日历提醒，每两周花十分钟看一下用量，这个习惯能帮你省下不少钱。
