FRONTIER · 工程实践

16 个 Claude 关在一起两周，写出一个能编译 Linux 的编译器

Building a C compiler with a team of parallel Claudes

Nicholas Carlini 对抗样本经典攻击 Carlini-Wagner 的提出者 · 长期研究模型记忆与训练数据泄露 · 前 Google Brain / DeepMind 研究员，做过渗透测试

2026 年 2 月

为什么选它很少有人把「让 agent 无人值守干两周」真正做到底，还把撞墙的地方一条条列出来。它给出了并行 agent 唯一真正的前提——任务能不能切成互不干扰的小块——以及一份可以直接抄走的测试设计清单：日志怎么打、抽样怎么做、模型为什么感知不到时间。也标出了今天自主开发的价格：2 万美元。

Nicholas Carlini 给 16 个 Claude 实例派了一个活：用 Rust 从零写一个 C 编译器，要求能编译 Linux 内核，然后他基本上就走开了。两周、近 2000 个 Claude Code 会话、2 万美元 API 账单之后，这支 agent 团队交出了一个十万行的编译器——能在 x86、ARM、RISC-V 上编出可启动的 Linux 6.9 内核，也能编 QEMU、FFmpeg、SQLite、Redis，在 GCC torture test suite 上通过率 99%，当然也能编译并运行 Doom。全程不联网，只依赖 Rust 标准库。

但这篇文章的价值不在编译器。它真正说清楚的是：让模型长时间无人值守地干活，瓶颈不在模型，在你给它搭的那套环境。作者把力气花在哪、哪里撞墙、哪里干脆作弊都摊开写了。这种把失败也列全的复盘，比「AI 写完了整个项目」的演示值钱得多。

一个不会停下来的循环

现有 agent 工具都假设有人在线陪着：丢一个庞大问题过去，模型做掉一部分就停下来问你一句。要让它自己一直干，作者的办法土得让人发笑——一个 `while true` 的 bash 循环，每轮起一个全新的 Claude Code 会话，喂同一份提示：把问题拆小、想清楚下一步、做到完美为止。循环永不退出，除非 Claude 手滑把自己 kill 掉（真发生过一次）。

并行部分同样简陋：一个 bare git 仓库当上游，每个 agent 一个 Docker 容器，各自 clone，做完再 pull、合并、push。防撞车机制是一把纯文本锁——想做哪个任务就往 `current_tasks/` 写个文件，两个 agent 抢同一件事时 git 会让后推的那个失败，它换一件做就是。没有编排 agent，没有通信协议，每个 Claude 自己挑「下一个最明显的问题」。值得和第 18 篇《别急着上多智能体》对照看。

九成力气花在给模型写测试

作者反复强调：Claude 会认真解决你给它的问题——验收标准差一点，它就认真地解决错误的问题。他的时间大半花在找高质量编译器测试集、写校验脚本、盯着 Claude 犯错再补测试。后期出现典型退化：每加一个新特性就弄坏一批旧功能，他的应对是上 CI，把「不许打破已有功能」变成硬准入。

更该抄走的是那句「这套测试是写给 Claude 看的，不是写给我看的」。上下文污染：脚本最多打印几行，其余写进日志；出错时行首写 `ERROR`、原因跟在同一行，好让 grep 一抓就到。时间盲——模型对时间流逝没有感知：放着不管，它会心安理得地花几小时跑测试而不是干活，所以测试默认带 `--fast`，只跑 1% 或 10% 的抽样；抽样对单个 agent 是确定的、跨容器是随机的，于是每个 agent 都能稳定识别自己引入的回归，16 个合起来又覆盖全部文件。这和第 15 篇上下文工程、第 22 篇评测是一个调子。

并行的前提是任务切得开

测试套件里有几百个独立失败用例时，并行几乎是白送的：一人挑一个去修。但轮到编译 Linux 内核，16 个 agent 全卡住了——它是一整个任务，所有 agent 撞在同一个 bug 上，各自修完还互相覆盖，人多毫无用处。

解法很漂亮：拿 GCC 当已知正确的对照物。随机让 GCC 编内核里的大部分文件，只留一小撮交给 Claude 的编译器；内核跑得起来说明问题不在这一撮，跑不起来就把其中一部分换回 GCC 继续二分。于是每个 agent 在不同文件上查不同的 bug，并行重新成立。这条能脱离编译器场景使用：并行 agent 的上限不取决于你开几个容器，取决于你能不能把大任务切成互不干扰、各自可判定的小块。分工也随之出现——有 agent 专管合并重复代码，有的优化生成代码质量，有的专门以 Rust 老手的视角批评项目结构。

作者自己划的天花板

这部分最该读。编译器缺一个 16 位 x86 代码生成器，没法把 Linux 从实模式引导起来——它输出的 16 位代码是对的，但产物超过 60KB，远超内核规定的 32KB 上限，只好调 GCC 顶上。它也没有自己的汇编器和链接器，生成代码的效率比关掉全部优化的 GCC 还差。作者说他很努力想修掉这几条，没成功——新功能和修复总在打破已有功能。

他把这个项目当跨模型基准跑了整个 Claude 4 系列：Opus 4 勉强产出一个能跑的编译器，Opus 4.5 能过大型测试套件但编不动真实项目，Opus 4.6 才走到今天这步。结尾他没唱赞歌：做过渗透测试的经历让他对「部署自己从未亲自验证过的软件」真心不安——自主系统最容易出的事，就是看测试全绿就以为完事了。

它到底证明了什么。这不是一条「AI 会写编译器了」的新闻，而是一个极端样本，标出了人的工作正在往哪边挪：从写代码挪到写验收标准。真正稀缺的产出是那套测试和那个 GCC 对照方案，模型只是把它们跑满。但要小心外推——编译器恰好是极少数拥有近乎完美自动验收标准的领域：对错是二值的，有几十年积累的 torture test suite，还有 GCC 这个随叫随到的正确答案。你手上的业务系统大概没有这三样中的任何一样，这才是把这套方法搬过去时真正的成本所在。另外，它和第 18 篇《别急着上多智能体》并不矛盾：那篇反对的是让多个 agent 共享一个含糊目标，而这里的 16 个 agent 之所以能并行，正是因为作者先花大力气把目标切成了互不重叠、各自可判定的小块。至于 2 万美元和 2000 个会话——把它记成今天自主开发的标价，然后注意这个价格下降得有多快。

智能体并行 agentHarness 设计自主开发测试设计

去读原文 本文是原创导读，不是原文翻译——真正的细节、证据和微妙之处都在原文里。原文Anthropic Engineering · Building a C compiler with a team of parallel Claudes →

上一篇把「感觉变差了」变成可以测的东西下一篇证明要过剩了：陶哲轩说数学的下一场危机是消化不良

本文为 AKL AI Club 原创撰写的导读，不是原文翻译；著作权归原文作者所有。篇目由编辑独立选取，来源均经人工核实。