· AI 智能体实操用例库

· 评分 · 状态：

作者/出处：
原文：
日期： · 工具：
成本： · 耗时：

title: 让智能体管十个并行会话：30 天合并 1,029 个 PR，先给每个子智能体写明模型

category: 编程搭建

score: 82

status: 已实现（作者自测账本；$97,000 为按公开价折算的标尺，非实付账单；PR 数含作者本人工作，无法拆分）

source_author: Jackson Ly

source_url: https://jacksonly.xyz/blog/225-billion-claude-code-tokens-in-30-days

source_date: 2026-10-18（统计窗口 2026-09-15 至 2026-10-14；dev.to 同步版同日）

tools: [Claude Code, ccusage, Codex, GLM-5.3（Z.ai，便宜模型）]

cost: 作者自述在多个按固定费用计费的编码套餐内，具体套餐价原文未给；$97,000 只是按公开价折算的标尺，不要写成实付

time_needed: 读者用 ccusage 跑自己的账本约 30 分钟；照搬“简报 + 模型字段 + 状态文件”分工约半天

---

速览卡

分类：编程搭建
结果：30 天 225.1B token、736,633 次 API 响应；同期合并 1,029 个 PR（406 个新功能、293 个修复，21 个仓库，约 3 智能体小时/PR）
状态：已实现（作者自测账本；金额为标尺非实付；PR 数无法拆分作者与智能体各自贡献）
成本：固定费用套餐内，套餐价未给；ccusage 本身免费
耗时：跑自己的账本约 30 分钟；照搬分工约半天

一句话

一个人、一台 Mac、一台家用 PC，高峰时十几个智能体并行，30 天合并上千个 PR——账本拆开后发现，token 数衡量的 mostly 是“重读上下文”，而不是干了多少活；真正省额度的是给每个子智能体写明模型、把状态写进文件、让管理智能体只递决策。

原作者怎么做的

先立计量规矩：用 ccusage 扫两台机器上的全部 Claude Code 记录，按（message.id, requestId）去重——作者实测两机合并会把 43.8B token 算两遍；单日手工抽查误差在 0.3% 以内。智能体小时的算法也写明：同一记录内相隔不超过 5 分钟的两次响应算工作时间。
拆账本：225.1B token 里 97.90% 是缓存重读、1.75% 缓存写入、0.34% 输出、0.01% 全新输入；平均每次响应读入约 305,000 token，其中约 299,000 来自缓存，每写 1 个 token 就要重读 291 个。Opus 模型合计占 94.3%。
找增长来源：周 token 从 4.0B（8 月 31 日当周）涨到 60.8B（四周后），但每智能体小时的 token 基本没变（52M–80M）；变的是并行数（平均 2.0 → 6.9 个）和有智能体在跑的小时数（38 → 145 小时/周，接近每天 21 小时）。
换管理方式：每个智能体拿到书面简报、开工前定好的“完成”标准、共享任务清单；一台家用 PC 上跑一个“总管”智能体，只把需要他拍板的决策递上来。作者借用管理学里的“管理幅度”类比：含糊任务几分钟就要找他一次，写清简报的任务可以一小时不找他。
先测一个单元再放大：给 534 位活动参与者写个人回顾邮件，单封约 340,000 token，全量约 1.8 亿。作者在约 5,500 万处暂停，用 5 封埋了错误的邮件测便宜模型，通过后再跑完剩余部分，总计约 1.1 亿。给 4,255 家公司找 logo 时，纯代码先解决 2,003 家，只把 1,603 家不清楚的交给小模型 Haiku 审，最终选出 1,552 家。
修好模型继承的坑：2026 年 9 月下旬到 10 月初，59%–80% 的子智能体没有写明模型，于是继承父会话的 Opus。10 月 11 日起，PC 上的执行会话改用便宜模型 GLM-5.3，接下来一周便宜模型写了 14% 的输出 token，只占总 token 的约 5%。但便宜模型也有翻车：一次回退调用 84 次、花 6 美分，多出 7 个错误答案、0 个正确答案——此后规定：回退模型必须先在已知答案的小样本上证明有效才启用。
给失败的目标重写：一个 Codex 目标模式任务跑了 4.5 天、烧 40.8M token、0 次提交、约 2GB 产物——因为停止条件需要作者本人动手，永远到不了；且“把开放需求变成证据”的规则让智能体不停写证据。改成以“能用的软件”为交付物、写明什么不算数、加三振规则后，下一会话提交 17 次。
设好评审关：作者自述的“新鲜评审员”制度——让不知情的评审员对每句话开原始来源核查，抽查的三篇文章分别纠出 11/64、11/44、17/26 处；而一个用工具日志判报告可信度的 LLM 评审员 AUROC 只有 0.48（约等于瞎猜），连简单的词频分类器（0.65）都不如，两者都未投入使用。

结果

30 天总量：225.1B token、736,633 次响应，97.9% 为缓存重读（已实现，作者自测账本）
产出：同期合并 1,029 个 PR，406 个新功能、293 个修复、21 个仓库（已实现，作者自述；PR 以作者账号合并，作者与智能体的贡献无法拆分，不要写成“智能体独立完成 1,029 个 PR”）
标尺金额：按公开价折算约 $97,000，无缓存约 10 倍（仅作标尺，作者明言自己在固定费用套餐内，实付不是这个数）
单点教训：4.5 天 0 提交的任务改写目标后下一会话 17 次提交；回顾邮件从预计 1.8 亿 token 压到约 1.1 亿（已实现，作者自测）
反面结果：LLM 评审员 AUROC 0.48 未采用；便宜模型回退 84 次调用只产错误答案（失败结果，作者如实记录）

提示词结构

（按原文做法还原的任务下达结构，非原文逐字提示词）

```

给每个智能体一份书面简报：[任务] + [完成标准，开工前定死] + [共享任务清单位置]。

给每个子智能体写明模型字段：model: [haiku/sonnet/opus/完整模型 ID]，不写就是一次决策——默认继承父会话的贵模型。

状态写进文件，不写进对话：[任务清单] + [进度文件]，会话断了也能从文件续跑。

先跑一个单元再放大：先测 1 个单元的 token 数，乘以总量再决定用哪个模型；便宜模型先过已知答案小样本再启用。

目标必须写清三样：[交付物是能用的软件] + [什么不算数] + [智能体自己能到达的停止条件]，另加三振规则。

评审关：新鲜评审员逐句开原始来源；不采纳未经验证的自动评审员。

```

中国读者怎么迁移

国内用 Claude Code / Codex / Cursor 的读者都能搬：先跑 ccusage（或同类日志统计）看自己的缓存重读占比，再把最常见的子智能体任务（跑测试、查日志、读文档）指派给小模型并写明模型字段；长会话先 /clear 再开新任务，跨天任务把状态写进文件。别先买更贵的套餐——作者的账本说明，额度多半是被“重读 + 并行数 + 不写模型的继承”吃掉的。

风险与限制

金额是标尺不是账单：$97,000 按公开价折算，作者实付为固定费用套餐价（未公开），引用时必须带这个限定，不许写成“一个月烧了 $97,000”。
规模不对等：作者高峰时 10 个以上智能体并行、每周 145 小时有智能体在跑，普通读者是 1–2 个智能体；可搬的是方法（简报、模型字段、状态文件、单单元测算），不是总量。
PR 数无法归因：作者明言日志分不出哪些 token 产出了哪些结果，PR 以他的账号合并，含他本人的工作。
同题材密度高：已发布 CI/CD token 分流、待审批的 19 项分工实验都谈 token；本条的不同在于它是生产级多智能体运营账本 + 管理幅度方法，不是受控实验，发布节奏请审批时定。
便宜模型有质量风险：作者的回退翻车（84 次调用、7 错 0 对）是现成反例，启用前必须过已知答案样本。

原文链接

https://jacksonly.xyz/blog/225-billion-claude-code-tokens-in-30-days