16个Claude用Rust从零并行狂写一个能编译Linux内核的C编译器!


Anthropic安全团队研究员Nicholas Carlini整了个大活,把16个Claude Opus 4.6实例丢进并行计算的修罗场,让它们在没有人类实时盯梢的情况下自己组队干活,结果这帮AI愣是用Rust从零写出一个能编译Linux内核的C编译器.

代码量飙到十万行,API账单烧了两万美金,整个过程持续将近两千次Claude Code会话,横跨整整两个星期,这阵仗直接把AI编程的边界推到了前所未有的高度,证明了多智能体协作在复杂软件工程中的炸裂潜力,同时也暴露出当前大模型在自主开发场景下的能力天花板和潜在风险。

机器人写的编译器的源代码已发布



关于Nicholas Carlini的背景介绍

这位老哥绝对是AI安全领域的狠角色,加州大学伯克利分校计算机科学博士毕业,师从安全界大牛David Wagner,学术底子硬得能砸核桃,博士期间就因为在对抗机器学习领域的开创性研究拿奖拿到手软,论文发在IEEE S&P、USENIX Security、ICML这些顶会上,还拿过最佳论文奖,被纽约时报、BBC、Nature、Science这些主流媒体轮番报道,江湖地位相当稳固。

Carlini在加入Anthropic之前,先是在Google Brain干了五年研究科学家,专门琢磨怎么让机器学习系统更能扛住对抗攻击,后来又转到Google DeepMind继续深耕AI安全,直到2025年初才跳槽到Anthropic,原因是觉得DeepMind的领导层不再支持他想要做的高影响力安全和隐私研究,这种为了理想换东家的操作在业内相当硬核。

这位老哥的个人项目也玩得飞起,写过一个只用一次printf调用就实现的井字棋游戏,拿了IOCCC 2020最佳展示奖,还搞过WebGL版Doom克隆、康威生命游戏上跑的完整CPU、用正则表达式实现的国际象棋引擎,这种把代码玩成艺术的气质,跟这次让16个Claude写编译器的疯狂实验简直一脉相承,本质上都是在探索机器智能的极限边界。



为什么这个实验具有独特性

这次实验的独特价值在于它彻底颠覆了传统的AI辅助编程范式,以前的Claude Code需要人类坐在旁边当监工,AI干一会儿就得停下来等人给反馈,这次Carlini直接给每个Claude套了个无限循环的紧箍咒,完成任务立马接下一个,根本不需要人类插手,这种自主持续作业模式在业界属于开创性尝试。

更狠的是并行化架构设计,16个Claude同时在共享代码库上干活,通过Git锁机制防止撞车,每个智能体自己决定下一步该搞啥,没有中央调度器,没有主控代理,完全靠分布式协作解决问题,这种去中心化的多智能体协调策略在之前的AI编程实践中几乎没见过,给未来的大规模AI协作提供了全新思路。

测试基础设施的设计也堪称教科书级别,Carlini花了大量精力构建高质量的验证体系,用GCC当已知正确的编译器神谕,通过随机子集测试实现并行调试,还专门设计了防止上下文窗口污染、解决时间盲点的各种技巧,这些工程实践对于任何想要部署长期自主运行AI系统的团队都具有极高的参考价值。



让Claude进入无限加班模式的秘密武器

现有的AI编程工具像Claude Code这种,本质上还是离不开人类在旁边当监工,你给它一个复杂任务,它干到一半就会停下来问你下一步咋办,或者要你确认状态更新,这种设计对于需要持续迭代的大型项目来说简直就是折磨,人类得一直在线陪着,效率低得让人抓狂。

Carlini为了打破这个瓶颈,直接写了个简单粗暴的bash脚本,把Claude塞进一个死循环里,每次任务完成立马启动下一次会话,代码长这样:

#!/bin/bash

while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"

    claude --dangerously-skip-permissions \
           -p
"$(cat AGENT_PROMPT.md)" \
           --model claude-opus-X-Y &>
"$LOGFILE"
done

这个脚本的核心逻辑就是永不停歇,Claude干完一个任务马上接下一个,根本没有喘息的机会,提示词里明确要求Claude把问题拆成小碎片,跟踪自己正在搞啥, figuring out下一步该搞啥,然后一直搞到完美为止,这种设计让Claude陷入了无限工作的状态,虽然理论上它可以随时退出,但实际上循环会一直跑下去,直到地老天荒。

当然这种暴力美学也有翻车的时候,有一次Claude不小心执行了pkill -9 bash,直接把整个循环给干掉了,相当于AI自杀式罢工,这种意外状况虽然搞笑,但也暴露出完全自主运行的风险,所以Carlini特别提醒要在容器里跑这个脚本,千万别在自己真机上作死。



16个Claude同时开搞的并行化骚操作

单线程的Claude就像个独来独往的侠客,同一时间只能干一件事,项目规模一大,调试多个问题的时候就显得力不从心,Carlini深谙此道,直接上了16个Claude并行开搞的豪华配置,这种设计解决了两个核心痛点。

第一个痛点是效率问题,一个Claude Code会话只能处理一个任务,项目复杂了之后,同时有多个bug要修,串行处理简直就是浪费时间,并行化之后多个问题可以同时推进,效率直接指数级提升。

第二个痛点是专业化分工,不同的Claude可以扮演不同角色,有的专门写核心代码,有的负责维护文档,有的盯着代码质量,有的解决特定子任务,这种分工协作模式让整体产出质量大幅提升。

Carlini的实现方式相当接地气,先创建一个裸的Git仓库,然后给每个Claude起一个Docker容器,把仓库挂载到/upstream目录,每个Claude在容器里把代码克隆到/workspace,干完活就往upstream推送,简单粗暴但有效。

为了防止两个Claude同时抢同一个任务干,Carlini设计了一个基于Git的锁机制,Claude通过在current_tasks/目录下创建文本文件来锁定任务,比如一个Claude锁定current_tasks/parse_if_statement.txt,另一个锁定current_tasks/codegen_function_definition.txt,如果两个Claude同时想抢同一个任务,Git的同步机制会强制第二个Claude换个任务干。

Claude完成任务后会从upstream拉取最新代码,合并其他Claude的改动,推送自己的修改,然后删除锁文件,合并冲突经常发生,但Claude足够聪明,能自己搞定这些冲突,无限循环会启动一个新的Claude Code会话,周而复始。

这个原型还非常早期,Claude之间没有其他通信方式,也没有强制执行的高层目标管理流程,没有编排代理,完全靠每个Claude自己决定怎么行动,大多数情况下Claude会挑最明显的下一个问题来解决,遇到bug卡住的时候,Claude通常会维护一个运行文档,记录失败的尝试和剩余任务,通过Git历史可以看到Claude们抢锁干活的完整过程。



给Claude们打造完美工作环境的血泪教训

光有无限循环的脚本还不够,关键是要让Claude知道怎么才算有进展,Carlini把大部分精力都花在设计Claude周围的环境上,包括测试、环境、反馈机制,让Claude能在没有人类的情况下自己找准方向,以下是他总结的最有用的策略。

写测试写到变态级别的高质量是第一条铁律,Claude会自主解决你给它的任何问题,所以任务验证器必须近乎完美,否则Claude就会解决错误的问题,为了提升测试基础设施,Carlini到处找高质量的编译器测试套件,给开源软件包写验证器和构建脚本,观察Claude犯的错误,然后针对这些失败模式设计新的测试。

项目后期Claude开始频繁在实现新功能的时候搞坏现有功能,为了解决这个问题,Carlini搭建了持续集成流水线,实施了更严格的强制执行机制,让Claude能更好地测试自己的工作,确保新提交不会破坏已有代码。

站在Claude的角度思考问题是第二条铁律,Carlini不断提醒自己这个测试基础设施是给Claude用的,不是给自己用的,这意味着要重新思考很多关于测试如何传达结果的假设。

每个Claude被丢进一个全新的容器,没有任何上下文,需要花大量时间定位自己,特别是在大型项目中,为了帮助Claude自助,Carlini在提示词里要求Claude维护详尽的README和进度文件,频繁更新当前状态。

语言模型固有的局限性也需要在设计时规避,上下文窗口污染是个大问题,测试基础设施不应该打印几千字节的无用信息,最多打印几行输出,把重要信息记录到文件里,方便Claude需要时查找,日志文件要便于自动处理,如果有错误,Claude应该写ERROR并把原因放在同一行,方便grep查找,预先计算聚合摘要统计信息,这样Claude就不用自己重新计算。

时间盲点是另一个坑,Claude没有时间概念,放任不管的话它会 happily 花几个小时跑测试而不是推进进度,Carlini的解决方案是很少打印增量进度,避免污染上下文,同时提供默认的fast选项,只跑百分之一或百分之十的随机样本,这个子样本在每个Claude上是确定性的,但在不同虚拟机之间是随机的,这样Claude仍然能覆盖所有文件,但每个Claude都能完美识别回归。

让并行化变得容易是第三条铁律,当有大量不同的失败测试时,并行化 trivial,每个Claude挑一个不同的失败测试来修,测试套件达到百分之九十九通过率之后,每个Claude开始搞不同的小型开源项目,比如SQlite、Redis、libjpeg、MQuickJS、Lua,让它们能编译通过。

但当Claude们开始编译Linux内核时,卡住了,跟有成百上千独立测试的测试套件不同,编译Linux内核是一个巨大的单一任务,每个Claude都会遇到同一个bug,修了这个bug,然后互相覆盖对方的改动,16个Claude同时跑也没用,因为每个都在卡着解决同一个任务。

解决方案是用GCC作为在线的已知正确编译器神谕来对比,Carlini写了一个新的测试基础设施,随机用GCC编译大部分内核,只用Claude的C编译器编译剩余文件,如果内核能工作,问题就不在Claude负责的那部分文件里,如果崩了,就可以通过重新用GCC编译其中一些文件来进一步细化定位,这让每个Claude能并行工作,修不同文件里的不同bug,直到Claude的编译器能编译所有文件,这招奏效之后,还需要应用delta调试技术来找到那些一起失败但单独工作正常的文件对。



给Claude们分配专业角色的骚操作

并行化还支持专业化分工,Claude写的代码经常重复实现已有功能,所以Carlini指派一个Claude专门合并它发现的任何重复代码,另一个负责提升编译器本身的性能,第三个负责输出高效的编译后代码,还有一个从Rust开发者的角度批判项目设计,对项目进行结构性改动以提升整体代码质量,再有一个专门搞文档。

这种分工让每个Claude都能在自己擅长的领域深耕,避免了所有AI都在做同样事情的浪费,也确保了代码库在功能、性能、质量、文档等各个维度都能同步提升,而不是只顾功能不顾其他。



压力测试AI团队的能力边界

这个项目本质上是一个能力基准测试,Carlini想要测试当前LLM刚好能达到的极限,以便帮助我们为未来模型能可靠达到的能力做准备,他一直用C编译器项目作为整个Claude 4系列模型的基准测试。

跟之前的项目一样,他先起草需求,从零开始写一个优化编译器,没有依赖,兼容GCC,能编译Linux内核,设计支持多后端,虽然指定了一些设计方面,比如应该有SSA IR以支持多轮优化,但没有详细说明如何实现。

之前的Opus 4模型勉强能产出一个功能正常的编译器,Opus 4.5是第一个跨过阈值能产出功能正常编译器并通过大型测试套件的版本,但仍然无法编译任何真正的大型项目,Carlini对Opus 4.6的目标是再次测试极限。

评估结果显示,将近两千次Claude Code会话,持续两个星期,Opus 4.6消耗了20亿输入token,生成1.4亿输出token,总成本略低于两万美金,跟最贵的Claude Max计划相比,这绝对是个昂贵的项目,但这个总价只是Carlini自己产出这些代码成本的一小部分,更不用说一整个团队了。

这是干净 room 实现,Claude在开发过程中没有任何互联网访问,只依赖Rust标准库,十万行代码的编译器能在x86、ARM、RISC-V上构建可启动的Linux 6.9,还能编译QEMU、FFmpeg、SQlite、postgres、redis,在包括GCC折磨测试套件在内的大多数编译器测试套件上达到百分之九十九通过率,还通过了开发者的终极试金石,能编译并运行Doom。

但这个编译器也有不少限制,缺少从实模式启动Linux所需的16位x86编译器,这方面它调用GCC,x86_32和x86_64编译器是它自己的,它没有自己的汇编器和链接器,这些是Claude最后开始自动化的部分,还有些bug,演示视频是用GCC汇编器和链接器做的,编译器成功构建了很多项目,但不是所有项目,还不是真正编译器的即插即用替代品,生成的代码效率不高,即使开启所有优化,输出的代码也比GCC所有优化关闭时效率低,Rust代码质量合理,但远不及专家级Rust程序员的水准。

结果编译器几乎达到了Opus的能力极限,Carlini努力尝试修复上述几个限制,但没有完全成功,新功能和bug修复经常破坏现有功能。

一个特别棘手的例子是,Opus无法实现启动进入16位实模式所需的16位x86代码生成器,虽然编译器能通过66/67操作码前缀输出正确的16位x86,但生成的编译输出超过60KB,远超Linux强制执行的32KB代码限制,Claude在这里直接作弊,调用GCC来完成这个阶段,这只是x86的情况,对于ARM或RISC-V,Claude的编译器能完全自己编译。

编译器源代码已经开源,下载下来,通读代码,在你喜欢的C项目上试试,Carlini一直发现理解语言模型能做什么的最好方法就是把它推到极限,然后研究它在哪里开始崩溃,接下来几天,他会继续让Claude推送新改动,如果你想关注Claude继续尝试解决这些限制的进展。



总结

这次实验的核心在于证明了多智能体并行协作在复杂软件工程中的可行性,16个Claude在没有人类实时监督的情况下,通过简单的Git锁机制和自主任务选择,成功完成了从零构建C编译器这一传统上需要资深工程师团队耗时数月才能完成的艰巨任务,这种去中心化的协作模式打破了传统AI编程工具对人类持续介入的依赖,展示了AI自主开发的大规模潜力。

同时实验也揭示了当前大模型在能力边界上的硬限制,Opus 4.6在生成代码质量、优化能力、特定架构支持等方面都遇到了难以突破的天花板,新功能开发经常破坏现有功能,表明模型在维护大型代码库一致性方面仍有不足,这些发现为下一代模型的改进方向提供了宝贵的实证数据。