前两天我帮项目组收拾完一个烂摊子同一个仓库同时开了五个 Claude Code Agent 去改不同模块半天时间活确实干了不少但晚上看了一眼账单差点没坐稳——平时一天四五十美元的花费那天直接飙到两百多翻了四倍还不止。查了一圈网络、API、费率都没问题最后发现是我自己把 Agent“放养”了。多 Agent 并行听起来很爽一个写代码、一个补测试、一个迁移数据库、一个刷文档、一个跑安全审查各干各的效率看起来提升了好几倍。但 Claude Code 的计费逻辑是按 token 算的不是按 Agent 数量算的。你开多少 Agent每个 Agent 跑多少轮工具调用每一轮调用携带多大的上下文这些才是账单的最终构成。这篇文章不聊空泛的“省 token 技巧”就从我自己踩坑的账单出发讲清楚多 Agent 场景下成本失控的根因以及一个真正管用的配置怎么落地。1. 多 Agent 成本失控的根因不是模型贵是 Agent 在空转1.1 拆开 Claude Code 的账单四个计费项Claude Code 每次调用 API 产生的费用主要由四块构成Input tokens输入 token发给模型的全部内容包括系统提示词、工具定义、项目指令文件CLAUDE.md、你的输入以及 Agent 到目前为止积累的对话历史和工具返回结果。这部分容易被低估尤其在多 Agent 场景下仓库上下文反复被加载Input 往往是账单最大头。Output tokens输出 token模型生成的回复内容包括代码、解释、计划等。按输出价计费比输入贵得多。Thinking tokens思考 token模型在推理模式下内部思考产生的 token。这部分很多人忽略但 Claude 新一代模型的思考量不小经常比正式输出还多而且按输出价计费属于隐形大户。Cache read / write缓存读写启用 prompt caching 后重复发送的相同前缀通常覆盖系统提示词和工具定义走缓存通道读取价约为标准输入价的十分之一。对多 Agent 场景如果多个 Agent 上下文高度重合缓存能省很多钱反过来如果上下文各不相关这部分收益就很小。我给你一个量纲级的价格参考表方便后面算账模型级别输入价约输出/思考价约Opus 级$15 / 百万 token$75 / 百万 tokenSonnet 级$3 / 百万 token$15 / 百万 tokenHaiku 级$1 / 百万 token$5 / 百万 token具体数值随时间和渠道会有调整但倍率关系基本稳定Sonnet 比 Opus 便宜约 5 倍Haiku 比 Sonnet 又便宜约 3 倍。记住这个关系后面实操部分会用到。1.2 为什么并行 Agent 会让成本非线性暴涨单个 Agent 跑任务成本是线性增长的轮数越多上下文越大费用越高。但多个 Agent 并行成本会变成超线性增长我总结为两个“放大器”第一个是上下文雪球。每轮工具调用模型看到的 input 都是“系统提示 全部历史 最新的工具结果”。这就像滚雪球即使每轮只新增 2K token到了第 30 轮它要支付的是前 30 轮所有历史的总和而不是只付第 30 轮新增的那一点。多个 Agent 同时滚相当于同时有多个雪球在滚每一轮都在为“全部历史”付费。第二个是死循环重试。Agent 改完代码通常会自己跑测试测试挂了它会读日志、改代码、再跑。遇到环境问题、网络抖动、编译报错一个“小修复”能滚出十几轮重复操作。多个 Agent 同时处于这种状态API 请求量成倍上升而每一轮重试都在重复支付已经付过的上下文费用。所以你会看到“开了 4 个 Agent账单不是 4 倍经常是 5 到 6 倍”。这不是模型计价有 bug而是每个 Agent 都在独立扩张自己的上下文没有一个全局的截止阀。1.3 用真实数字算一笔账46 轮是如何变成 200 多美元的拿我踩坑那天的数据来拆解。当时我用的是 Opus 级模型开了 5 个 Agent。看本地会话记录5 个 Agent 总计跑了约 167 轮工具调用其中有一个处理数据库迁移的 Agent 因为连接不上测试库自己反复重试了 37 轮。按 Opus 价格粗略估算项目数值计算费用约总 Input7.6M token7.6 × $15 / M$114总 Output Thinking1.3M token1.3 × $75 / M$97.5缓存及其他少量—$5 左右合计——约 $216这就是账单翻 4 倍的过程。平时单 Agent 跑类似任务可能只花三四十美元。一旦并行而且没有上限约束Agent 会利用“无人值守”的空子把轮数滚上去。账单失控往往不是你做了什么复杂的工作而是同一个动作重复付了很多次钱。2. 给 Agent 装上“截止阀”--max-turns 配置详解2.1 max-turns 到底是什么--max-turns是 Claude Code 命令行启动参数用于限制 Agent 在自动执行模式下最多连续调用工具的次数。比如你设置--max-turns 30Agent 连续执行 30 轮工具调用后就会停下来把当前状态汇报给你等你确认“继续”或“中断”不会自己无限跑下去。它有点像洗衣机的程序次数限制。洗衣机可以全自动洗完但如果中途衣物缠住它一遍遍重启脱水程序水和电都翻倍。设置次数限制后它到次数就停下来让你人工介入处理。关键点是它并不减少单轮费用但切断了“无限循环重试”这个成本黑洞。在多 Agent 场景下死循环重试往往贡献了三分之一甚至更多的成本。有了这个截止阀多出来的费用直接被砍掉。2.2 三种设置方式总有一种适合你命令行参数是最直接的方式一条命令搞定claude 帮我把用户服务模块重构完并补好单元测试 --max-turns 30Shell 别名适合每天都要开多个 Agent 的重度用户。把下面这行写进~/.bashrc或~/.zshrc以后统一用claude-agent替代claude配置就固定了alias claude-agentclaude --max-turns 30项目级约定适合团队协作。在项目根目录的CLAUDE.md里写清楚约定例如本仓库所有 Agent 任务单次启动 max-turns 不得超过 30。达到上限后先汇报进度由人工确认下一步禁止无限制重试。需要说明的是不同版本的 Claude Code 对相关环境变量的支持不完全一致有的版本支持在settings.json里配置默认轮数字段名有差异。我的建议是以claude --help输出为准最稳妥的还是命令行参数加 Shell 别名因为这是 CLI 层面长期稳定的入口。2.3 轮数设多少合适轮数设置太保守Agent 还没完成一次完整的“分析、修改、验证”循环就停了设置太激进等于没设。我按任务复杂程度给一个参考区间任务类型建议 max-turns单文件 bug 修复5 - 15新增一个 API 接口 单元测试20 - 35多模块重构 跑全量测试40 - 60数据库迁移 / 跨服务改动40 - 60多 Agent 并行拆分后的子任务单任务需求的 70% - 80%多 Agent 并行时我建议把单个 Agent 的上限下调一点因为任务已经被拆小了并行整体吞吐高单个 Agent 没必要拖太长。宁可设小一点、跑完后人工喊“继续”也不要设到 200、300 等于是白设。3. 实操记录从 216 美元到 18 美元我改了什么配置3.1 第一天的“放养式”多 Agent 账单先交代测试场景一个中型 Python 微服务仓库我需要完成 5 件事——重构用户服务模块、迁移数据库连接配置、补齐核心单元测试、更新 API 文档、跑一轮依赖安全检查。第一天我开了 5 个 Claude Code Agent 并行处理默认 Opus 模型没加任何限制。四个小时后回来看结果活确实完成了一部分但其中一个 Agent 在处理数据库迁移时反复连不上测试库不停重试。开 Agent 时的“放养”状态让所有 Agent 都在无人确认的情况下继续跑。本地会话记录显示5 个 Agent 总计约 167 轮工具调用总 Input 消耗约 7.6M token输出加思考约 1.3M token。按 Opus 的人emo 级价格估算总账单约 216 美元。这就是开头说的“翻了 4 倍”的来源。3.2 第二天加了限制之后的对比第二天同样 5 个任务我在启动命令里统一加了--max-turns 30模型仍然用 Opus其他条件不变claude 重构用户服务模块30 轮内先完成主流程 --max-turns 30结果很明显5 个 Agent 总计跑的轮数从 167 轮降到约 83 轮。为什么降这么多因为重试循环被截断了。尤其是那个数据库迁移的 Agent第一天跑了 37 轮其中至少 15 轮是无效重试第二天它不到 30 轮就停下来汇报由我确认配置后继续。总 Input 降到约 1.8M token输出加思考约 0.58M token账单大约 74 美元。一个配置从 216 美元拉回正常区间。第三天我又做了两步优化把模型从 Opus 切到 Sonnet同时在项目CLAUDE.md里加了一条规则要求 Agent“先搜索后读取、不要全文拉大文件”总账单进一步降到 18 美元左右。三天数据对比如下维度Day 1 放养Day 2 加 max-turnsDay 3 综合优化Agent 数量555模型OpusOpusSonnetmax-turns无3030总工具轮数约 167约 83约 96总 Input约 7.6M约 1.8M约 1.4MOutput Thinking约 1.3M约 0.58M约 0.35M预估费用约 $216约 $74约 $18如果你想复现这个动作建议同模型条件下先只加--max-turns看看账单降多少再考虑切模型。这样你能清楚分辨出“哪个配置贡献了多少”。3.3 几个值得一起用的配套配置尝到甜头之后我又把几个配套做法固化到了日常流程里按收益排序--permission-mode acceptEdits减少交互打断。多 Agent 跑的时候如果每个文件修改都要弹确认框Agent 会被频繁打断同样轮数内能做的事变少。配合--max-turns使用让 Agent 在有限轮数内尽量完整地完成任务效率更高总成本反而更低。在 CLAUDE.md 里限制读取范围。比如“只读取 src 和 tests 目录”“不要全文加载日志文件”“优先用 grep 定位而不是打开整个文件”。这条对降低 Input 特别有效因为多 Agent 并行时最大的浪费就是同一个仓库被不同 Agent 重复加载。让 Agent 先给计划再动手。如果任务复杂先让它用几轮输出做计划你确认后再执行。这能在源头上减少返工比事后靠限轮切断重试更优雅。设置预算告警。在 Anthropic Console 里设置每日或每月的支出提示账单异常时第一时间知道而不是等到月底看账单才心疼。4. 常见问题与排查技巧实录4.1 max-turns 会拖慢任务吗任务没跑完怎么办很多人担心加了限制会拖慢任务。其实不会被切断的是重复循环净效率通常是提升的。真正需要接受的事实是复杂任务本来就不该完全无人值守中途人类介入一次的成本远低于让 Agent 盲目重试一整晚的成本。如果任务真的没跑完建议直接在当前会话里说“继续完成上一次任务”或者“从上一步失败点继续”而不是重新开一个会话。重开会话意味着 Agent 要重新读取全部上下文之前的 Input 相当于白花了。我个人的判断标准是任务拆得越细max-turns 越好设。5 个小任务分别开 5 个 Agent比 1 个大任务开 1 个 Agent 更省钱也更可控。4.2 多个 Agent 到底要不要共享上下文这取决于任务相关性。如果是同一个仓库、同一技术栈的并行任务优先考虑用 Claude Code 的子 Agent 机制让主 Agent 统一读仓库背景子 Agent 只执行局部任务。这样公共上下文只付一份不像独立会话那样每个 Agent 各自加载一遍。如果任务完全独立比如不同分支、不同依赖环境的实验那独立会话加--max-turns是合理的。一个反面教训别在一个大仓库里同时开 10 个独立会话。同一批文件被读 10 次你就要付 10 份 Input 费用再便宜的模型也扛不住这么花。4.3 快速定位账单大头的排查方法遇到账单异常我一般按这个顺序排查会话内运行/cost看当前会话的 token 估算快速判断是不是某一次任务特别费。翻本地会话记录。Claude Code 会把历史会话存成 JSONL 文件通常在~/.claude/projects/下按项目名分目录。打开记录搜usage字段能看到每次 API 调用的 input、output、cache 用量这是定位“哪一轮最贵”的最直接方法。用claude --debug启动打开详细日志看每次请求的 token 明细。不同版本输出格式有差异但能看出单次请求的体量。去 Anthropic Console 的 Usage 页面导出用量数据按小时看消费曲线。如果某一小时的尖峰和你开 Agent 的时间重合基本可以锁定就是多 Agent 并行造成的。看成因而不是只看金额。检查有没有某个 Agent 在反复重试如果上下文已经滚到几十万 token 还在硬跑问题通常出在任务指令不清晰或环境配置不完整。4.4 多 Agent 成本与安全的避坑清单最后整理一份实战避坑清单都是花过钱买的教训别让多个 Agent 拥有过大的 Bash 权限。给它能完成任务的最小权限就够了这既省无效调用也降低误操作风险。多 Agent 并行时建议错峰启动间隔一到两分钟。同时启动容易触发 API 限流限流后的自动重试也在花钱。发现 Agent 在循环重试时手动中断比等它自己跑完便宜得多。我在数据库迁移那次就是麻痹大意让它多烧了十几轮。用--max-turns作最后防线但别指望它解决一切。任务清晰度和代码库组织方式同样影响成本指令写得含糊Agent 就要靠多轮试探来理解你的意图。团队共用账号时务必在 Console 里设置支出限制。别等月底看账单吓一跳提前设好告警阈值一条邮件就能避免一次灾难。踩过这次坑之后我给自己定了一条规矩任何无人值守的 Claude Code Agent启动命令里必须带--max-turns。它不是用来限制能力而是保证每跑一段时间就向我汇报一次由我来决定下一步。控制成本最快的方法从来不是天天盯着单价而是控制循环次数。如果你现在的多 Agent 账单也在疯涨先别急着怪模型贵、API 贵。去查一下你的 Agent 到底跑了几轮、每轮读了多少 token八成能发现问题。顺手加个--max-turns账单会很诚实地给你回应。