64 个 Claude 并行 11 天：Bun 重写背后的 Agent 工程学

一次没有人工写代码的运行时重写

7 月 8 日，Bun 作者 Jarred Sumner 终于把那篇拖了快一个月的复盘博客发了出来。写代码只花了 6 天，写博客反而花了将近 30 天——这个细节本身就挺说明问题的。

事情本身是这样的：2026 年 5 月 3 日到 5 月 14 日，11 天时间，Bun 完成了从 Zig 到 Rust 的完整重写，5 月中旬合入主分支。这是一个覆盖 JavaScript/TypeScript 转译器、打包器、包管理器、测试运行器、模块解析器、HTTP/WebSocket 客户端、Node.js API 层的完整运行时——原本 535,496 行 Zig 代码，外加约 20% 的 C++ 和几个嵌入的 C/C++ 库。

重写完的 Rust 版本约 78 万行，一共 6778 次提交，涉及超过 100 万行代码变更。整个过程没有一个工程师手写一行业务代码。干活的是 64 个 Claude Fable 5 实例，在 Claude Code 里跑了大约 50 个动态工作流（dynamic workflows）。API 账单 16.5 万美元，约合 111.9 万人民币。

Sumner 自己算过，如果让一个小团队人工干这件事，一年时间跑不掉。

为什么是 Rust，不是继续修 Zig

重写的直接动机不是性能，是稳定性。这一点值得强调，因为很多外围报道把这次迁移当成"Rust 又赢了"的素材，其实不是。

Bun 是极少数把 GC 语言和手动内存管理深度混用的项目——JavaScriptCore（JSC）的 GC 对象要和 Zig 侧的裸指针共存，还要跨过 C++ 层。这种混合模式在编程语言的设计假设里几乎是不被考虑的场景。Sumner 说得很直白：他不怪 Zig，别的 Zig 用户没这个问题，因为几乎没人这么用。

v1.3.14 的修复清单里，Sumner 列了一长串内存问题：内存泄漏、崩溃、UAF、异步任务竞态、甚至帮助文本的颜色显示错误。他原话是："我们的 bug 修复列表让人感觉很糟糕，我厌倦了带着对 Bun 崩溃的担忧去睡觉。"

Rust 的价值在这里就变得非常具体——编译期就能吃掉大部分内存安全问题。代价是要写 unsafe。目前 Bun 的 Rust 代码里 unsafe 块占比约 4%，13,000 个 unsafe 关键字分布在约 27,000 行代码中。其中 78% 的 unsafe 只有一行，绝大多数是 C++ 指针传递或者 C 库调用——也就是说，unsafe 都集中在 FFI 边界，业务逻辑本身几乎是纯安全的。这个分布是健康的。

结果层面：v1.3.14 里可复现的 128 个 bug 全部修复，运行速度提升 2%~5%。速度提升不算惊艳，但这本来也不是性能重构。v1.3.14 成为最后一个 Zig 版本，v1.4.0 以 Canary 的形式登场，是 Bun 的第一个 Rust 版本。

64 个 Claude 是怎么协作的

这才是这次事件真正值得开发者研究的部分。

Sumner 把日常工程抽象成一个循环：取任务 → 写代码 → 让人审查 → 应用反馈。他把这个循环整体外包给了 Claude Code 的动态工作流。峰值时是这样的编排：

• 4 个工作流并行运行
• 每个工作流里 16 个 Claude 实例
• 总计 64 个 Claude 同时在 4 个 git worktree 里干活
• 每个实例独立提交和推送
• 峰值写入速度约每分钟 1300 行代码

每分钟 1300 行——这个数字放在传统工程里是完全反直觉的。但注意，这里的"行"不是一次性堆出来的，而是分布在几十个并行子任务里，每个子任务都跑完整的"改代码-编译-测试-再改"循环。真正的稀缺资源是协调，不是键盘。

Anthropic 前几周更新的 Fable 5 提示指南其实为此埋了伏笔。文档里明确说，Fable 5 相较 Opus 4.8 的两个主要改进方向是：

1. 跨代码库和仓库历史的缺陷发现召回率提高——也就是审查者角色变强
2. 并行子 agent 调度更可靠——能稳定管理与子 agent 之间的持续通信

再加上文档反复强调的"编排器和子 agent 之间用异步通信而不是阻塞等待"、"长期存活的子 agent 保留上下文以复用缓存"——你把这些点连起来，就是 Bun 这次重写的方法论蓝图。这不是 Sumner 天才地摸索出来的路子，是模型能力和 Anthropic 的 agentic 工程范式凑到一起的结果。

Sumner 用得起 64 并发也是有原因的：Bun 团队 2025 年 12 月已经被 Anthropic 收购了。那 16.5 万美元本质上是内部转账。对独立开发者来说，这套方案能不能复现是另一个问题。

effort、工作流、subagent：新的三件套

从这次实战里能提炼出的最实用的东西，可能是动态工作流这个概念。它和过去大家熟悉的"多轮对话"、"Chain-of-Thought"、"ReAct"都不一样：

• 传统 agent 循环是单主体的：一个 agent 反复思考-行动-观察
• 动态工作流是多主体编排：一个编排器根据任务动态派生子 agent，子 agent 独立跑自己的循环，异步汇报

关键差异在于"动态"两个字——工作流的形状不是提前定死的 DAG，是编排器根据当前进度、失败情况、依赖关系临时决定的。这就非常接近人类团队的实际协作方式：项目经理看到某个子任务卡住了，临时拉一个人过去帮忙；某个模块提前完成了，就把人挪到下游。

结合 Fable 5 的 effort 参数（low/medium/high/xhigh），可以做出很务实的成本-质量权衡：

• 简单的样板代码转换：low 或 medium
• 需要理解跨文件依赖的重写：high
• 复杂的架构决策或棘手的 unsafe 边界：xhigh

官方给的说法是——Fable 5 上较低的 effort 通常已经能超过前代 xhigh 的表现，没必要无脑拉满。这句话在成本敏感的场景里价值不小。

冷静一下：这不是所有项目都能复制的

对这次事件，我的态度是：方法值得学，但不要神化。有几个前提条件必须说清楚：

第一，Bun 有极其完整的测试套件。 这才是 64 个 Claude 能并行狂写的地基。没有测试就没有信号反馈，没有反馈的并行只是并行制造 bug。Sumner 在博客里没有强调这一点，但任何做过重构的人都知道这才是命门。

第二，Zig → Rust 是有语义映射的迁移，不是无中生有。 原始代码定义了行为边界，AI 干的是"翻译 + 重构"，不是"设计"。让 AI 从零设计一个 JavaScript 运行时？现在还差得远。

第三，$165K 只在 Anthropic 内部才是可接受的。 对普通团队，这个成本足够雇一个高级工程师干半年了。真正的问题是：什么样的迁移，能让 AI 加速带来的"上市时间"提前值回票价？运行时这种基础设施，可能是；企业内部 CRUD 系统，大概率不是。

第四，unsafe 集中在 FFI 边界是好事，但也说明纯 Rust 项目从 AI 迁移里获得的收益会更大。 一旦要 AI 判断复杂 unsafe 生命周期，事情就没那么顺利了。

一个信号：基础设施重写正在从"不敢动"变成"可以试试"

往远一点看，Bun 这个案例的意义不在于 11 天或者 16.5 万美元，而在于它改变了某类决策的默认答案。

过去，"要不要把这个老系统重写成新语言"这个问题，答案几乎永远是"不要"——因为 ROI 算不过来。现在这个默认答案开始松动。当重写成本从"一年团队工时"降到"两周 API 账单"，那些一直被拖着的技术债——老旧的运行时、跨语言互操作的历史包袱、被 Zig/OCaml/Nim 这类小众语言写就的核心组件——会重新回到讨论桌上。

有意思的是，Sumner 用了快一个月才把博客写完，比写代码久 5 倍。他自己也承认，公开这件事需要"下决心"——因为业界对 AI 大规模重写的态度并不完全友好，Hacker News 上关于"技术债"和"手艺失控"的争论从来没停过。

但事情已经发生了。100 万行代码，128 个 bug 修复，2200 万月下载量的运行时在生产环境里跑起来。这个先例被立住之后，接下来会有第二个、第三个团队走同样的路。软件工程师的日常，会从"90% 写代码"更快地滑向"90% 审代码"——不管你准备好没有。

参考资料

• 11 天 Claude Fable 5 狂写超 100 万行代码：Rust 重构 JavaScript 运行时 Bun - IT之家：IT之家对 Sumner 博客的中文报道，含核心数据
• oven-sh/bun - GitHub：Bun 项目主仓库，可以查看 v1.4.0 Canary 版本和 Rust 重写的提交历史