我如何用 Claude Code 的子代理，让 Claude Pro 的额度撑得更久

HN Claude Code Adoption 2026-10-08T11:35:37.584285

为什么

我用的是 Claude Pro，每月 20 欧的套餐，几乎每天都在用它跑 Claude Code，主要花在副业项目 Draft Omen 和 Book Corners 上。Pro 是固定月费，所以我一个月最多也就花 20 欧，真正会被耗尽的不是钱，而是用量。Pro 每 5 小时、每周都给一定额度，用完之后就得等它重置，才能接着干活。

直到上周，我每次会话都是从头到尾跑 Opus 5.5。Opus 负责读文件、写代码、跑测试、修 lint 报错、再跑一遍测试、提交代码、开 pull request。可这里面只有一小部分工作真的需要最强的模型。方案一旦定下来，写代码和跑测试交给更便宜的模型完全够用。

于是我改了配置。主会话还是 Opus 5.5、medium 力度，负责做决策；写代码交给 Sonnet 5.5 子代理；另外两个更轻的活儿分给 Haiku 5.5。这篇文章里我会把这个配置讲清楚，附上复制所需的全部文件，再说说它帮我省了多少。

配置方式

Claude Code 可以从 ~/.claude/agents/ 下的 Markdown 文件里加载自定义子代理，每个文件开头的 frontmatter 用来指定模型、力度和该代理可用的工具，剩下的正文就是它的系统提示词（system prompt）。子代理启动时上下文是空的，所以它只知道主会话告诉它的那些信息。

我用的是下面这四个代理：

Opus 是我的默认模型，在 ~/.claude/settings.json 里，我给 Opus 5.5 和 Sonnet 5.5 都设了 medium 力度：

只把代理建出来还不够。Claude Code 是靠读代理的 description 来决定什么时候调用它的，也就是说，记不记得用这个代理，全看模型自己。为了让它每次都照做，我在自己的 CLAUDE.md 里加了些说明，告诉主会话什么时候该派活、交接时该写清什么、以及拿回来的结果该怎么审。

一次会话的工作流程

我给 Claude Code 派活时，通常是这么走的：

我把一个 issue 编号交给主会话。
如果当前会话还不熟悉这段代码，它就会调用 scoper。Haiku 读一遍 issue，找出涉及的文件和测试，写一份简短说明，附上文件路径。小模型可能会出错，所以主会话在采信这份说明前，会先打开其中几个文件核实一下。
主会话决定怎么实现改动。这一步值得动用 Opus。
它把计划交给 implementer，一并附上验收标准、相关文件、已经定下的决策和要运行的命令。Sonnet 负责写代码和测试，反复运行直到通过。
主会话查看 diff，跟计划对照，再跑一遍完整测试。如果发现问题，就通过 SendMessage 把修改意见发回给同一个 implementer，这样它不会丢掉上下文。
当我要提交 PR 时，shipper 会检查工作区，只暂存属于这次改动的文件，提交、推送，并带上说明开一个 PR。

reviewer 不在常规流程里。主会话本来就会审查每个 diff，再让另一个 Opus agent 审一遍，成本几乎和写代码一样高。我只在主动要求审查时，或者改动涉及安全、并发、数据迁移或公开 API 时才用它。

有些细节影响很大：

小改动留在主会话里做。写交接说明、审查 diff 本身也要花 token，所以如果改动只有几行，Opus 又已经知道该怎么写，那它就直接写了。
implementer 不做任何重新设计。如果计划和代码对不上，它的提示会要求它回报，而不是自作主张做重大决定。
scoper 什么都不能改。它在 plan 模式下运行，没有编辑工具，跑满 12 轮就停。它报告里的每条结论都必须指向具体文件。
shipper 发现异常就停下，比如冒出了无关文件、changelog 条目缺失，或者分支是 master。它会报告问题，由主会话来修。它从不改文件，也从不用 force push。

文件

点击文件名可以展开。

我的用户级 CLAUDE.md

这是我 ~/.claude/CLAUDE.md 的内容。第一行导入了 ~/.agents/AGENTS.md，里面放的是我通用的编码和写作规范，和其他编码智能体（coding agent）共用，所以这里不再重复。剩下的内容都只对 Claude Code 生效。

智能体（agents）

这些文件想放进所有项目，就放到 ~/.claude/agents/；只想让某个仓库用，就放到该仓库里的 .claude/agents/。

现在一个 PR 要花多少额度

我在状态栏脚本里加了几行来测量。Claude Code 会往脚本里传一个 JSON 对象，里面包含了 5 小时窗口和 7 天窗口已用掉的比例，以及本次会话的花费等信息。只要这两个百分比中有一个发生变化，脚本就往 ~/.claude/usage-log.jsonl 追加一行记录。

然后我把日志里的每个会话和它开出的 PR 对应起来，办法是在会话记录里找 gh pr create 的调用。下面这张表是最近十次「把活派给子智能体」的会话，最新的排在最前。其中三次各开了两个 PR，所以表格里一共是 13 个 PR。

这些会话加起来用掉了 5 小时窗口的 80%，折算下来花费 30.05 美元。平均到每个 PR：约占 5 小时窗口的 6%、花费 2.31 美元；一个只开单个 PR 的会话，周计数器大约会涨 1%。

看这些数字时，有几点要说明一下：

这个花费不是我实际掏的钱。我付的是每月 20 欧元。那个美元数字是 Claude Code 按 API 计价算出来的「如果走 API 要多少钱」，子智能体也算在内。不过拿它来比较不同会话还是很有用的。
Claude Code 报的百分比不带小数。「<1%」表示这次会话期间周计数器没有变动。
限额是按账号算的，不是按会话算的。如果两个会话同时跑，一个会话的部分用量可能被计到另一个会话的日志里。我在统计时对每一次增量只算一次。
我剔除了一个会话。那天是发布日，四个半小时里开了八个 PR，主要都是版本号和网站更新，占掉了 5 小时窗口的 25%、花了 10.67 美元。要是把这次摊到八个小 PR 上，会让我的数字看起来比实际情况更好看，所以就把它拿掉了。
我几天前才加上 scoper 和 shipper，所以大部分记录只用了 implementer。只有最近一条用到了 shipper。

和只用 Opus 相比，我到底省了多少

我是在调整配置之后才开始记录用量的，所以之前的会话没有百分比数据。不过我有成本数据，因为 Claude Code 会保存每个会话的记录，里面包含每次请求的 token 用量。我取的是调整之前、只开一个 pull request 的最后 24 个会话。它们跑在 Opus 5.5 中等强度上，和我现在主会话用的模型、强度一样，但没有用任何子代理。然后我用同样的方法，算出这些会话的成本，以及上面那 10 个会话的成本。

现在每个 pull request 大约便宜 40%，而且 PR 反而更大。我的计算比 Claude Code 显示的成本低几个百分点，所以我只拿它来比较这两组数据。如果按我上面测出的比例把成本换算成用量，只用 Opus 做一个 PR 大约要占 5 小时窗口的 10%，而不是 6%。在 Pro 套餐上，这意味着大约做 10 个 pull request 就用完，而不是 16 个左右。

让我意外的是节省的来源。我本以为是因为 Sonnet 比 Opus 便宜，但如果把子代理的 token 按 Opus 价格来算，那 10 个会话也只贵了 5%。Claude Code 会话里大部分 token 是缓存读取，而这些会话运行时，Opus 5.5 和 Sonnet 5.5 的缓存读取价格一样，都是每百万 token 0.20 美元。

Anthropic 今天把 Sonnet 5.5 的缓存读取价格降到了每百万 token 0.10 美元。按我的算法再算一遍，用新价格，那 10 个会话的成本会是 27.31 美元，而不是 27.84 美元，也就是每个 PR 2.10 美元，而不是 2.14 美元。有用，但帮助有限，因为子代理只用到每个会话 token 的一小部分。

真正省下来的，是主会话一直保持很小。每次请求都会把整段对话重新发一遍，所以如果让 Opus 自己去跑「改代码—跑测试」这个循环，每一行测试输出、每一次修复，都会让后面所有请求再大一点。而把循环交给子代理去跑，主会话只看到计划书和一份简短汇报，实现者那边的上下文在任务结束后就直接丢掉。具体数字上，Opus 会话平均请求数从每次 75 降到 54，每次请求的上下文从 119k token 降到 107k token。

值得这么折腾吗？

对我来说，值。用 Pro 的时候，卡住我的是那个 5 小时窗口，现在同样的窗口能产出大约十六个 pull request，之前只有十个。

质量靠的是那个审查环节。实现者没有最终发言权。主会话会读 diff、重新跑一遍测试，如果结果和计划对不上就把活儿打回去。这个审查很便宜，因为读 diff 花掉的 Opus 额度，比写代码少得多。

查看原文