用 Rust 重写 Bun：AI 智能体主导的大型工程重构实录

用 Rust 重写 Bun

Jarred Sumner 自从 5 月 9 日起 就一直承诺要撰写这篇博客文章——关于他将 Bun 从 Zig 重写为 Rust 的过程。然而，事实上，他完成这次重写的耗时，竟然比当初承诺的还要长得多。

老实说，这段等待确实值得。这篇文章对一项极其复杂的代理式工程进行了详尽的阐述，其中包含了动态工作流、试运行、对抗性评审以及各种其他有趣的技巧。

在文章的前半部分，Jarred 赞美 Zig 为将 Bun 推进到这一步所付出的努力。随后，我们迎来了文章中的核心观点——我着重强调：

我们的漏洞修复列表简直糟糕透顶，而且我已经厌倦了每晚入睡时都为 Bun 中的崩溃而忧心忡忡。我并不责怪 Zig——Zig 的其他用户并没有我们曾经遇到过的那些问题； 而将垃圾回收机制与手动管理的内存相结合，这种做法在软件开发中其实并不常见， 甚至可以说几乎没有任何语言会特意为之设计。 若非 Zig 的帮助，我们根本不可能走到今天这一步，对此我始终心怀感激。 直到不久前，对于像 Bun 这样的项目来说，选择编程语言往往只是一次性的决策。

众所周知，你绝不能停下脚步，把整套大型软件从头开始重新编写。 Joel Spolsky 在 2000 年 4 月的《你永远不该做的事： 第一部分》一文中就曾指出过这一点！

如今，由前沿模型驱动的编码代理，彻底改变了这一局面。

为什么选择 Rust？这一切都归结于内存管理方面所面临的种种挑战：

该列表中高达相当一部分的错误，都是由于在错误路径中出现“使用后释放”、“双重释放”， 以及“忘记释放”等问题所致。而在安全的 Rust 中，这些问题都可以通过编译器错误来解决，并借助 RAII 风格的自动清理机制——通过 Drop 来实现。

此次重写的关键促成因素之一在于：Bun 的测试套件是用 TypeScript 编写的，这意味着它能够作为 一致性测试套件发挥作用。 这一特性使得代理能够自动化完成从 Bun 到 Rust 的大部分初始迁移工作，最初还只是作为一个实验，用来尝试我们如今已能使用的早期版本的模型——也就是 Mythos/Fable。

起初，我原本并不指望这项工作能成功。 但仅仅过了几天，测试套件的通过率便大幅提升，我亲眼见证了全新的 Rust 代码与原始的 Zig 代码库之间的高度契合。我的看法也从“这值得一试”迅速转变为“我要把这项工作合并入主干”。 ……

在接下来的整整 11 天里（乃至之后），我持续监控着整个工作流程——手动读取输出结果，以排查各类问题和漏洞， 并且不断提示 Claude 对循环进行修改，以修复那些隐患。

如何评审一份新增了超过 100 万行代码的 PR？又该如何逐步建立起足够的信心，从而负责任地合并大量由大语言模型生成的代码？

一个独立于语言的测试套件，拥有上百万条断言、对抗性代码评审机制；一旦出现问题，系统会自动修复——而不是由人工手动修正代码。

Bun 的新实现已经在 Claude Code 中运行了将近一个月：

Claude Code v2.1.181（发布于 6 月 17 日）及后续版本，均采用了 Rust 版本的 Bun。在 Linux 系统上，启动速度提升了 10%，不过除此之外，几乎无人察觉。无聊，却也很好。 在 Anthropic 工作的一大优势在于：你无需为自己的 Token 支付费用——当预估成本高达 165,000 美元时，这可真是帮了大忙！ 在合并前，这项任务需要消耗 59 亿个未缓存的输入 Token、6.9 亿个输出 Token，以及 720 亿次缓存的输入 Token 读取——按 API 价格计算，大约花费 165,000 美元。

整件事堪称一次引人入胜的案例研究：在协同并行代理的帮助下，我们成功迎接了极具雄心的项目挑战。

来自 Hacker News

标签：AI, Rust, Zig, 生成式 AI, LLMs, AI 辅助编程, Anthropic, Bun, 一致性测试套件, 代理式工程, Claude-Mythos-Fable