Claude Code 子代理省不省钱，要算两笔账

Claude Code 的子代理到底省不省 token？有人报告账单减少 40%，也有人同时启动 5 个子代理，约 15 分钟就耗尽 Pro 额度。原文给出的解释是：子代理每次启动都要付一笔上下文成本，但它也能把大量搜索结果、日志和文件内容留在主会话之外。

对程序员来说，关键不是多开几个代理，而是判断哪些工作值得隔离。作者用一次会话里的 19 个子代理做了测量，也给出了从本地记录核算用量的方法。这套方法比直接照搬别人的节省比例更有用。

子代理省的是主会话上下文，启动却要重新付费

普通非 fork 子代理有独立的上下文窗口。它收到主代理整理的任务说明，却看不到此前的对话、已经调用的 skills，以及主代理读过的文件。

独立上下文带来两种相反的效果。

一方面，子代理可能重复查资料。主会话二十轮前确认过的约束，如果没写进委派消息，它就可能漏掉，或者重新搜索。另一方面，它读到的几千行搜索结果、测试日志和源码，可以留在自己的上下文里，最后只返回一个短列表。

子代理的价值，往往来自少把原始材料带回主会话。

但空白对话不等于轻量启动。按原文引用的文档，普通子代理启动时会加载系统提示、任务消息、CLAUDE.md 层级、git status 和预加载 skills；作者另补充了每次模型请求携带的工具定义。假如全局与项目 CLAUDE.md 合计 8,000 tokens，启动 5 个普通子代理，就要分别携带这份内容。继承 40 个 MCP 工具，也会增加工具 schema 的负担。

Explore 和 Plan 跳过 CLAUDE.md。原文还指出，Explore 跳过 git status，只提供只读工具，但它不能恢复运行，追问会启动新实例，重新产生启动成本。

缓存也有区别：新子代理的系统提示不同，无法直接复用主会话已经预热的提示缓存；通过 /subtask 创建的 fork，则因系统提示和工具定义与父会话一致，可以在首次请求复用父缓存。代价是它同时继承整段对话，适合依赖现有上下文的旁支任务。

先查真实用量，再判断哪次委派划算

作者检查了自己在 2026 年 9 月的一次 Claude Code 会话，模型为 claude-opus-5。19 个子代理的首次请求都没有缓存读取，cache_read_input_tokens 为 0；首次缓存写入量在 12,427 到 40,763 tokens 之间。

数据大致分成 12,400～15,600 和 37,000～40,800 两组。作者没有核对各组对应的代理类型，所以 CLAUDE.md 是否造成差异，只是猜测。

另一个长时间运行的子代理，在记录第 481 行出现一次 253,567 tokens 的缓存写入，缓存读取仍为 0。缓存为什么没命中，作者没有确认。这只能说明运行中可能再次发生大额写入，不能据此认定每个长任务都会如此。

这些数字来自一台机器的一次会话，是量级参考。

要核算自己的情况，可以读取每个子代理的 JSONL 记录。下面的命令按代理汇总请求数，以及普通输入、缓存写入、缓存读取和输出：

for f in ~/.claude/projects/*/SESSION_ID/subagents/agent-*.jsonl; do
  jq -s -c --arg f "$(basename "$f")" '
    map(select(.message.usage)) | unique_by(.message.id) | map(.message.usage)
    | {agent: $f,
       requests: length,
       input: (map(.input_tokens) | add),
       cache_write: (map(.cache_creation_input_tokens) | add),
       cache_read: (map(.cache_read_input_tokens) | add),
       output: (map(.output_tokens) | add)}' "$f"
done

先安装 jq，再替换 SESSION_ID。最需要保留的是 unique_by(.message.id)：流式响应可能把同一个请求的 usage 重复写入多行，作者见到过重复三次的情况，直接逐行求和会算重。

读结果时，先找启动写入占比高、请求数却很少的代理，它可能没做多少工作就结束了；再找请求特别多或明显高于其他代理的实例，检查是否搜索越界。40 次请求就是 40 次携带上下文的往返。

不过，这段脚本统计的是 token 分类用量，并非美元账单。缓存写入、缓存读取和普通输入的成本不同，不能把它们简单相加就当费用。

哪些任务值得拆，哪些设置能压低成本

作者给出的判断公式是：

工作带入主上下文的 tokens × 主会话剩余轮数，大于启动成本、子代理自身工作和返回摘要的合计成本。

它解释了为什么长日志值得隔离。假设在一个 60 轮会话的第 10 轮读入 30,000 tokens 的日志，后续 50 轮可能继续处理这部分内容，多数是较便宜的缓存读取，但仍有成本，也会增加上下文压缩压力。

适合委派的任务包括大范围搜索、测试失败排查、彼此独立的包级工作，以及需要避开主会话既有判断的审查。它们的共同点是原始材料多，结果可以很短。

已经打开的一两个文件、前后步骤紧密依赖的修改，以及几千 tokens 就能完成的小任务，通常留在主会话更合适。只想问现有上下文里的问题时，原文建议使用 /btw：它能看到完整上下文，没有工具访问能力，回答也不加入历史。

确定需要子代理后，再调整配置：

• 自定义代理可设置 omitClaudeMd: true，要求 Claude Code v2.1.271 或更高版本。它跳过用户、项目和本地 CLAUDE.md，但仍加载受管理策略；必须执行的规则要写入委派提示。
• 收紧 tools 列表，让搜索代理只拿需要的工具；如果 MCP schema 占比大，再考虑 lazy MCP loading。
• model 接受 sonnet、opus、haiku、fable、完整模型 ID 或 inherit。子代理上下文窗口由自身模型决定，CLAUDE_CODE_SUBAGENT_MODEL 会覆盖单独配置。
• 用 maxTurns 限制探索轮数。达到上限可能只返回部分结果，可恢复的代理可以继续执行。

默认同时运行上限为 20，可通过 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS 修改。但并发上限不是预算：5 个代理仍要支付 5 份启动和执行成本，Pro、Max 的额度也会累计计算。

我的判断

我认同作者把注意力从「开几个代理」转向「隔离多少无用上下文」。对日常 AI 编程，委派提示里的输出要求很关键。「返回失败测试、错误信息和相关文件」比「给一份完整报告」更能控制主会话的体积。

但原文的收支公式只能当启发式判断。严格比较费用，需要考虑缓存命中、模型价格、上下文压缩和子代理内部的多轮读取。原文把日志放进子代理描述为「付一次」，也有简化：子代理后续调用同样会反复携带自己的上下文。

并行通常能缩短等待时间，不能直接证明总用量更低。

原文引用 Research 系统中代理约为聊天 4×、多代理约为 15× 的用量，以及 agent teams 在 plan mode 下约 7× 的警告。它们来自不同系统，agent teams 也不是普通 subagents，不能拿来预测一次代码委派的倍数。

还有一处口径需要打问号：2026 年 7 月 18 日那份 66K～84K tokens 的公开报告，开头被描述为写代码之前的消耗，后面又称整段运行用量，原文没有统一解释。40% 节省和约 15 分钟耗尽额度，也都是不同负载的个案；后者虽提到顺序处理约 30 分钟，却没有足够条件支持普遍结论。

因此，先过滤测试输出、缩小搜索范围，再决定是否增加代理，通常是更直接的起点。作者没有提供这些替代方案的对照实验，这部分仍属于经验之谈。

能拿来做什么

• 从最近一次发生委派的会话开始，用脚本核算各代理用量，再检查异常实例的首次请求，记录自己的启动成本。
• 排查前端或 Node 测试时，先过滤输出；仍然很长时再交给子代理，并要求只返回失败用例、错误信息和必要文件位置。
• 为搜索或排查代理收紧工具列表，按需使用 omitClaudeMd: true，同时把不可遗漏的项目约束写进任务说明，再比较相近任务的用量与结果质量。
• 修改已读过的少量文件时留在主会话；旁支任务确实依赖当前讨论时，再考虑 /subtask，避免让全新代理重新寻找已有信息。