耗费2万美元、两周写10万行Rust代码！16个Claude智能体写的C编译器，能编译Linux内核却卡在“Hello World”？
要把时间拨回几年之前，可能没人会认真讨论这样一个问题：AI 是否能在基本无人干预的情况下，从零写出一个可用的 C 编译器，甚至编译 Linux 内核？
而在 2026 年初，这件事不再只是科幻设想：
近日，Anthropic 研究员 Nicholas Carlini 发布了一篇长文，分享了一项颇具冲击力的实验：他使用 Claude Opus 4.6 模型，组织了一个由 16 个 Claude 智能体组成的“Agent Teams”——在长时间自主运行的情况下，从零构建了一个 Rust 实现的 C 编译器，并声称该编译器已经能够在 x86、ARM 和 RISC-V 架构上编译 Linux 6.9 内核。
一次“放手让 AI 干活”的极限实验
按照 Nicholas Carlini的说法，这次实验的核心并不是“写一个编译器”，而是测试多智能体系统在长期、复杂工程中的自主能力边界。
整个项目持续约两周时间：运行了近 2000 次 Claude Code 会话，消耗约 200 亿输入 token、1.4 亿输出 token，API 成本接近 2 万美元，最终产出了一个约 10 万行代码规模的 C 编译器。
更重要的是，这个编译器并非“玩具级”成果。根据 Nicholas Carlini 的描述，它已经能够：
●构建 Linux 6.9 内核
●编译 QEMU、FFmpeg、SQLite、Postgres、Redis 等大型项目
●在多个主流编译器测试集中取得 约 99% 的通过率
●甚至完成了编译器圈内的“终极彩蛋”——成功编译并运行 Doom
从“能力展示”的角度看，这显然已经远远超出了以往人们对 LLM 编程能力的认知。
Agent Teams：真正的变化不在模型，而在“协作方式”
值得注意的是，这次实验最大的创新点，并不只是模型升级，而是使用方式的改变。
如 Nicholas Carlini 所说，现有的智能体框架，包括Claude Code 在内，一般都需要操作员全程在线协作，若向模型提出一个复杂的长期问题，它可能会解决其中一部分，但最终会停滞不前，等待人工的后续输入——可能是一个问题、状态更新，或是澄清请求等等。
而 Nicholas Carlini 为 16 个 Claude 智能体设定了极为严苛的目标：从零编写一款基于 Rust 的 C 编译器，无需依赖第三方工具，最终需具备编译 Linux 内核的能力。
为了实现这一目标，他搭建了一个简单的循环框架，让智能体完成一个任务后，能立即接手下一个任务。该框架需在 Docker 容器中运行，避免对本地机器造成影响，其核心脚本如下：
whiletrue; doCOMMIT=$(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
在智能体提示词文件中，Nicholas Carlini 明确要求每个 Claude 实例将核心任务拆解为小模块，实时记录工作进度、规划下一步行动，并持续推进直到任务完善。
此外，为了实现多智能体并行协作且不冲突，其团队还采用了简洁高效的同步机制：他们首先创建一个全新的空 Git 仓库，为每个智能体分配一个独立的 Docker 容器，并将 Git 仓库挂载到容器内部。每个智能体在本地克隆仓库副本，完成工作后将代码推送至上游仓库；同时，通过“任务锁定”机制避免冲突——智能体通过在 current_tasks/ 目录下创建文本文件锁定任务，若两个智能体尝试锁定同一任务，Git 的同步功能会迫使后者选择其他任务。
随着项目推进，不同 Claude 逐渐形成了“分工”：有的专注修 Bug、有的合并重复代码、有的优化性能、有的从 Rust 工程角度重构架构、还有的负责文档维护……在没有统一调度 Agent、几乎没有高层规划的前提下，这个系统依然能够持续推进一个超大规模工程，这是这次实验最令人震撼的地方。
争议随之而来：能编译内核，却卡在 Hello World？
然而，随着代码被公开，开发者社区很快发现了一些尴尬的问题。
有用户在 GitHub 上反馈：这个“能编译 Linux 内核”的编译器，居然连一个最基础的 hello world 程序都无法直接编译成功。
相关 issue 一度引发热议。后续有人补充说明，只要手动指定正确的 include 路径，hello world 其实是可以编译通过的。但这并没有完全平息争议，反而招来更多调侃：
“这种事情，理论上你根本不该手动做吧？”
这种反差，也让不少人开始重新审视项目的实际成熟度。
博文并没有“夸大”，限制其实写得很清楚
值得注意的是，Anthropic 并没有刻意隐瞒这些问题。在 Nicholas Carlini 发布的长文中，他非常明确地列出了该编译器当前的主要限制。其中包括：
（1）并非完全独立完成 Linux 内核编译：在 x86 架构下，Linux 启动阶段所需的 16 位实模式代码，Claude 的编译器无法生成，仍然需要调用 GCC。
（2）缺少完整的汇编器和链接器：目前使用的 assembler 和 linker 仍然是 GCC 的组件，Claude 只实现了部分能力，而且稳定性不足。
（3）尚不能作为现有编译器的直接替代品：它可以成功编译“很多”项目，但并非“所有”项目。
（4）生成代码性能明显偏低：即便开启所有优化，其输出代码效率仍不如关闭优化的 GCC。
（5）Rust 代码质量处于“可用但不优秀”水平：与资深 Rust 工程师手写的代码仍有明显差距。
换句话说，这是一个工程上真实可跑，但技术债务清晰可见的系统。
真正的难点，不在“写代码”，而在“写环境”
Nicholas Carlini 在文章中反复强调：这个项目最难的部分，并不是让 Claude 写出代码，而是设计一个能让它“不迷路”的环境。
为了让智能体长期自主运行，他在测试和反馈机制上投入了大量精力：极其严格的测试集（测试一旦有问题，Claude 会“完美地解决错误问题”）、为模型设计的日志格式（少输出、可 grep、错误显式标记）、防止模型“时间失明”的机制（避免一跑测试跑几个小时），甚至连 README 和进度文档，都被要求强制维护，否则新启动的 Claude 智能体很容易陷入“失忆状态”。
其实从研究者的角度来看，这个项目更像是一次“极限压力测试”：当前的大模型，在几乎完全自主的前提下，究竟能把一个复杂系统工程推进到什么程度？
目前看来，这个答案是：比很多人想象得远，但离真正可靠的工程自动化，还有明显距离——它可以完成“宏大目标”，却容易在基础细节上翻车；可以写出 10 万行代码，却仍然需要人类工程经验来兜底关键环节。
参考链接：
https://www.anthropic.com/engineering/building-c-compiler
https://www.reddit.com/r/theprimeagen/comments/1qx03og/anthropic_built_a_c_compiler_with_a_team_of/