摘要
1) 一句话总结 Anthropic 研究员利用 16 个 Claude 智能体，在无人工干预的情况下耗时两周、花费约 2 万美元，成功从零构建出一个包含 10 万行代码且能编译 Linux 内核的 C 语言编译器。
2) 核心要点
- 项目产出：耗时两周，进行约 2000 次会话，API 成本约 20000 美元，最终生成 10 万行基于 Rust 的 C 语言编译器代码。
- 性能指标：通过了 99% 的 GCC 折磨测试（torture test），支持 x86、ARM 和 RISC-V 架构，成功编译了 Linux 6.9 内核、FFmpeg、Redis 等开源项目及游戏《毁灭战士》。
- 控制框架：项目核心在于验证了“长期自主运行的智能体团队控制框架”，通过让智能体在简单循环中持续处理任务直至完美，消除了对人类持续输入的依赖。
- 无中心编排（No Orchestrator）：16 个智能体运行在独立 Docker 容器中，共享 Git 仓库，没有中心指挥官，智能体自主决定解决“下一个最显而易见”的问题。
- 任务同步机制：智能体通过在
current_tasks/目录下写入文本文件来“锁定”任务，利用 Git 同步机制防止重复认领，并能自主解决代码合并冲突。 - 解决协作冲突：为防止多个智能体在同一 Bug 上互相覆盖代码，引入 GCC 作为参照基准（混合编译内核树），并将不同智能体分配至不同项目。
- 开发者技能演进：业界评论指出，未来开发者的核心技能将从解决复杂 Bug 转向设计自动化测试体系与反馈循环。
3) 风险与不足
- 代码生成的潜在风险：项目主导者 Carlini 明确警告，如此轻松地生成大量代码会带来潜在风险，需要新策略来安全应对技术变革。
- 多智能体工作覆盖：在复杂任务（如编译 Linux 内核）中，多个智能体容易在遇到同一个 Bug 时给出不同修复方案并互相破坏/覆盖彼此的工作。
- 仍需人类底层支持：尽管运行过程无人工干预，但仍需人类工程师预先设计测试、搭建 CI 流程，并在智能体集体卡死在同一 Bug 时制定变通方案。
- 训练数据复现争议：花费 2 万美元生成的代码被质疑只是训练数据中早已存在的同类代码，缺乏真正的创新。
- 开源生态反噬风险：若 AI 仅消耗开源代码而不回馈源头，未来可能面临无专业代码可供参考的生态断层。
正文
为探索自主软件开发的极限，Anthropic 研究员 Nicholas Carlini 进行了一项极具前瞻性的实验：使用 16 个 Claude Opus 4.6 AI 智能体，从零开始构建了一个基于 Rust 的 C 语言编译器。
在为期两周的时间里，这些智能体在没有人工干预的情况下进行了大约 2000 次会话，消耗了约 20000 美元的 API 费用。最终的产出令人瞩目——一个包含 10 万行代码的编译器。该编译器不仅通过了 99% 的 GCC 折磨测试（torture test），支持 x86、ARM 和 RISC-V 架构，还成功编译了 Linux 6.9 内核，以及 FFmpeg、Redis、PostgreSQL、QEMU 等大量开源项目，甚至可以运行经典游戏《毁灭战士》（Doom）。
Carlini 表示，这项成果“极大地拓展了大语言模型智能体所能实现的能力边界”。
突破大模型局限的“控制框架”
尽管这款编译器本身是一个“有趣的成果”，但 Carlini 强调，该项目更深层的意义在于**“为长期自主运行的智能体团队设计控制框架”**。
通常情况下，当人类让大模型解决一个长期且复杂的问题时，模型往往只能完成其中一部分，随后便会停下来等待持续的输入（如问题、状态更新或澄清请求）。为了解决这一痛点，Carlini 将 Claude 置于“一个简单的循环中”：让智能体持续处理指定任务直至完美完成，随后立即转向下一个任务。这种机制确保了智能体在无人监督的情况下，依然能够保持正确的方向并并行推进工作。
16 个智能体的高效协同机制
为了让 16 个 Claude 实例高效协作，Carlini 设计了一套精巧的并行与同步架构：
- 独立运行与共享代码库： 每个 Claude 实例都运行在独立的 Docker 容器中，但共同访问同一个共享的 Git 仓库。这使得 Claude 能够同时处理多项任务。
- 专业化分工： 在协作过程中，智能体逐渐形成了专业化分工，部分负责编写文档，另一些则专注于代码质量。
- 基于锁的任务同步： 智能体通过在
current_tasks/目录下写入文本文件来“锁定”任务。如果两个智能体同时尝试认领同一任务，Git 的同步机制会强制第二个智能体选择其他任务。 - 自主解决冲突： 任务完成后，智能体会在本地合并其他智能体的修改，推送分支并释放锁。Carlini 指出：“Claude 足够聪明，可以自行解决合并冲突。”
- 无编排智能体（No Orchestrator）： 整个架构中没有设置中心的“指挥官”。每个 Claude 智能体自主决定如何行动，通常会选择解决“下一个最显而易见”的问题。当遇到 Bug 卡住时，Claude 会维护一个记录失败方法和剩余任务的运行文档。
克服多智能体协作的挑战
在项目推进过程中，Carlini 采取了多项关键措施以确保成功。他致力于维持高质量的测试和持续集成（CI），同时避免让 Claude 在测试上耗费过多时间。
一个突出的问题是：多个智能体可能会同时遇到同一个 Bug，给出不同的修复方案并互相覆盖彼此的工作。这一现象在编译 Linux 内核时尤为明显。
为了解决这个问题，Carlini 引入了 GCC 作为编译器的“参照基准”。他让每个智能体使用 GCC 编译内核树的一个随机子集，而剩余部分则由 Claude 的编译器处理，并仅在该子集上优化输出。此外，当不同项目可能出现相同 Bug 时，他会将不同的智能体分配至不同的项目，以减少冲突。
社区争议与深层探讨
这项耗资 2 万美元的尝试在网络上引发了广泛的讨论，评价褒贬不一，也引发了业界对 AI 编程实际影响的深度思考。
关于人类干预的必要性： X 平台用户 @chatgpt21 认为这确实是了不起的成就，但也指出其背后依然离不开人类工程师的努力——人类需要“不断重新设计测试、在智能体相互破坏工作时搭建 CI 流程、以及在 16 个智能体全部卡在同一个 Bug 上时制定变通方案”。
关于训练数据与成本的质疑： 用户 @hryz3 强调，这些智能体是“在需要复现的同类代码上训练的”。@TomFrankly 的批评则更为尖锐：“他们花费了 2 万美元的 Token 费用，输出的却是训练数据中早已存在的代码？”
打破“37 年工作量”的神话： 针对部分人惊叹“Claude 在两周内完成了人类工程师 37 年的工作量”，微软的 Steve Sinofsky 予以反驳。他指出，GCC 并非花了 37 年才完成，早在 1987 年它对当时的编程语言就已完全可用，过去的 37 年只是其随着技术演进而持续迭代的过程。
开源生态与未来开发者： @WebReflection 从开源贡献的角度提出疑问：如果 AI 只是消耗开源代码而不回馈源头，未来将没有专业代码可供参考。 @RituWithAI 则总结了这可能对软件开发岗位带来的颠覆性影响：“我们正在进入这样一个时代：10 倍开发者（10x Developer）的核心技能不再是解决复杂 Bug 的能力，而是设计自动化测试体系与反馈循环的能力——这些机制能让模型的十六个并行实例替他们解决问题。”
最后，项目主导者 Carlini 本人也发出了警示：如此轻松地生成代码可能会带来潜在风险，未来的世界需要“新的策略来安全应对”这一技术变革。