Building a C compiler with a team of parallel Claudes
这是一篇 Anthropic 关于长时运行、多智能体自主开发的工程文章。作者用 16 个并行运行的 Claude agent，从零开始构建了一个 Rust 写成的 C 编译器，并把它推到可以编译 Linux kernel 的程度。文章真正要讨论的不是“编译器项目多酷”，而是：如何设计一个能让 agent team 在共享代码库上长时间自主推进的 harness，以及这种做法目前的能力上限和风险边界在哪里。
- 这次实验的规模很大：接近
2,000次 Claude Code session、约2周运行时间、约$20,000API 成本，最终产出约100,000行代码的编译器。 - 该编译器是 clean-room 实现，开发期间无互联网访问，只依赖 Rust 标准库，能够构建 Linux
6.9在x86、ARM、RISC-V上的内核，也能编译QEMU、FFmpeg、SQLite、Postgres、Redis等项目，并在大部分编译器测试集上达到99%通过率。 - harness 的基础形态很简单但关键：单个 Claude 被放进无限循环里，完成一个任务后马上开启下一轮；多个 agent 则各自在独立容器中 clone 同一 bare repo，本地工作、合并、推送，再由下一个新 session 接手。
- 并行协作的同步机制也非常朴素：agent 通过在
current_tasks/里写锁文件来声明任务，结束后再 pull、merge、push、移除锁。作者没有使用高层 orchestration agent，而是让每个 Claude 自己判断“下一步最明显的问题是什么”。 - 文章最强调的是测试 harness 的重要性。因为 agent 会坚定地优化它眼中的目标，所以 verifier 和反馈必须足够高质量，否则模型会高效地把“错的事”做对。
- 为了让 Claude 真正长期推进，作者刻意按模型的限制来设计环境：减少上下文污染、让日志可 grep、预计算摘要、控制测试输出、用
--fast子采样缓解时间盲。 - 并行化在“很多独立 failing tests”时很好用，但在 Linux kernel 这种单个巨大任务上会失效，因为所有 agent 会撞到同一个 bug。解决办法是引入
GCC作为 online oracle，把整体故障重新切分成许多可并行定位的小问题。 - 多 agent 的另一个收益是角色分化：有的负责功能，有的负责去重、性能、生成代码效率、Rust 代码质量、文档等。这说明 agent team 的价值不只是吞吐，还包括可人为配置的专业化分工。
- 文章对结果并不粉饰：编译器还缺少完整 16-bit x86 支持、assembler 和 linker 仍不稳定、生成代码效率显著落后于 GCC，且新特性和 bugfix 经常互相破坏。
ℹ️ Conflict:
- 这个实验更像 capability stress test，不等于“已经可安全替代资深工程团队进行无人监督的生产开发”。
- 文章展示了 agent teams 的上限被显著拉高，但也同时承认：只看测试通过很容易造成虚假的完成感，质量、一致性和安全验证仍然高度依赖人类审查。
- Anthropic, “Building a C compiler with a team of parallel Claudes”, 原文摘录：[llm-wiki/raw/anthropic/Building a C compiler with a team of parallel Claudes](/raw/anthropic/Building a C compiler with a team of parallel Claudes.md)