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