【当AI独自工作两周后，它写出了能编译Linux内核的编译器】

Anthropic最近做了一个实验：让Claude Opus 4.6组建智能体团队，从零开始写一个C语言编译器。研究人员基本上就是设计好测试环境，然后走开了。两周后，这个编译器成功编译了Linux内核。

这不是玩具项目。最终产出是10万行代码，能在x86、ARM和RISC-V三个架构上构建可启动的Linux 6.9，还能编译QEMU、FFmpeg、SQLite、PostgreSQL、Redis，在GCC酷刑测试套件上达到99%的通过率。当然，它也能跑Doom。

有人说写编译器不难。这话对也不对。写一个能跑的编译器确实不算太难，但写一个能编译Linux内核的编译器是另一回事。Linux内核依赖大量规范边缘情况、内联汇编、非标准扩展和精确的代码生成特性。目前能做到这点的编译器，大概只有GCC和Clang。这两个项目背后是数十年积累和数千名贡献者。

整个过程花了近2000次Claude Code会话，API成本约2万美元。研究人员的主要工作不是写代码，而是设计环境。他搭建测试框架、寻找高质量测试套件、编写验证脚本，观察Claude犯的错误然后设计新测试。他的原话是：让Claude自主解决问题，所以任务验证器必须近乎完美，否则Claude会解决错误的问题。

这揭示了一个关键洞见：当前AI编程的瓶颈不在模型能力，而在环境设计。大多数真实项目没有现成的高质量测试套件，你甚至不知道该测试什么。只有当你能清晰定义成功标准时，长时间自主运行的智能体编程才可行。

编译Linux内核时遇到了有趣的协调问题。16个智能体同时工作，却都卡在同一个bug上，互相覆盖修复。解决方案是用GCC作为参照：随机用GCC编译大部分内核文件，只让Claude的编译器处理剩余部分，通过二分法定位问题。这让每个智能体能并行修复不同bug。

生成的代码质量如何？诚实地说，汇编输出质量一般，优化程度不如关闭优化的GCC。能用，但不快。这是一个重要的诚实声明。

关于效率问题，有人指出Codex 5.3在SWE-bench上用一半的token达到了早期模型的性能。如果这个趋势持续，一年后同样任务的成本可能降低一个数量级。但目前的主要问题是模型在困难任务上会反复迭代，消耗大量token。真正的突破在于一次做对。

研究人员在文章结尾写道：这个实验让我兴奋，也让我不安。我没想到这在2026年初就能实现。语言模型和交互框架的快速进步，打开了编写大量新代码的大门。我预期正面应用会超过负面，但我们正在进入一个需要新策略才能安全导航的新世界。

有人担心这会带来安全问题。经典论文「对信任的反思」讨论过恶意编译器注入漏洞的可能。AI生成的海量代码中，那些看似无用的冗余部分，可能藏着等待多年后才被触发的漏洞。这不是杞人忧天。

www.reddit.com/r/singularity/comments/1qwur8p/we_tasked_opus_46_using_agent_teams_to_build_a_c/