Building a C Compiler with a Team of Parallel Claudes（用一组并行 Claude 构建 C 编译器）
- 原文标题
- Building a C Compiler with a Team of Parallel Claudes（用一组并行 Claude 构建 C 编译器）
- 原文链接
- https://www.anthropic.com/engineering/building-c-compiler
- 作者
- Nicholas Carlini（Anthropic Safeguards 团队）
- 发布日期
- 2026-02-05
🎯 一句话
用多个 Claude 并行实现一个 C 编译器。⭐ 它真正的看点不是「能做出来」，而是任务是怎么被切成互不干扰的块的——这才是并行 Agent 能不能成立的关键。
把 Claude Opus 4.6 组织成在共享代码库上无人监督工作的自主 Agent 团队，可以完成大规模复杂软件工程——一个从零写出的 C 编译器。这是自主 LLM 开发能力的一个里程碑式压力测试。
架构与方法
核心设计
- 无限循环 harness： 每个 Agent 跑在永续循环里，完成一个任务立即领取下一个
- 并行执行： 16 个独立 Docker 容器、各自隔离的工作区，从共享上游仓库克隆、合并后推回
- 同步机制： 基于文件的简单锁——Agent 在
current_tasks/目录创建文本文件认领任务，靠 Git 自带的冲突解决机制竞争。合并冲突频繁发生，但 Claude 足以自行解决
角色分工
不把所有 Agent 一视同仁，而是分派专职角色：核心编译器开发、代码去重、性能优化、代码质量审查、文档维护。
关键经验
- 测试质量就是基础设施： Agent 自主工作时，测试套件是它们的主要导航系统；劣质测试会把 Agent 引向错误方案。作者重点投入：高质量编译器测试套件、开源软件包构建验证脚本、CI、回归检测
- 上下文窗口优化： harness 只输出几行摘要，重要信息全部记入日志文件供 Claude 需要时查阅
- 时间盲区： Claude 缺乏时间感知，可能在不必要的测试上浪费数小时。方案：
--fast标志做确定性子采样，每个 Agent 只跑 1-10% 测试，但整个团队合起来覆盖完整 - 并行化瓶颈： 编译 Linux 内核是单体任务，所有 Agent 会撞上同一瓶颈。巧解：随机把内核的一部分交给 GCC 编译，只用 Claude 的编译器编译剩余部分——制造出相互独立、可并行的调试机会
- 安全提醒： 「在容器里跑，不要在你的真机上」
成果数据
| 指标 | 数值 |
|---|---|
| 开发时长 | 近两周 |
| Claude Code 会话数 | 约 2,000 |
| Token 消耗 | 20 亿输入 / 1.4 亿输出 |
| 成本 | 略低于 $20,000 |
| 代码规模 | 100,000 行 |
| 支持架构 | x86、ARM、RISC-V |
功能验证： 成功引导编译 Linux 6.9 内核（三种架构）；编译 QEMU、FFmpeg、SQLite、PostgreSQL、Redis；GCC torture 测试套件通过率 99%；能跑 Doom。全程「无尘室」实现——只依赖 Rust 标准库、开发期间无互联网访问。
已知局限： 无原生 16 位 x86 代码生成（实模式引导借用 GCC）；无自制汇编器和链接器；生成代码效率低于关闭优化的 GCC；Rust 代码质量称职但非专家级。16 位代码生成器超出了 Opus 4.6 在上下文和 token 约束下的实际能力（生成产物超出 32KB bootloader 限制两倍）。
模型代际进步
- Opus 4（早期）： 勉强能产出可用的编译器
- Opus 4.5： 首次跨过「通过测试套件」的门槛，但真实项目失败
- Opus 4.6： 达成编译真实项目的目标
结论与警示
作者的定位是「压力测试 LLM 今天勉强能做到什么」。Opus 4.6 代表从「结对编程助手」到「半独立贡献者」的质变。但作者（渗透测试背景）同时表达担忧：「程序员部署自己从未亲自验证过的软件，是真实的隐患」——更强的代码生成能力不自动等于质量和安全。「我们正进入一个需要新策略来安全航行的新世界。」项目已开源供独立验证。
✅ 检查点
- 并行能成立的前提是什么？
- 编译器这个任务为什么适合并行？
- 从这个案例能迁移出什么通用做法？
👀 答案
- ⭐ 子任务之间的接口必须先被固定下来。只要接口（输入输出的格式、函数签名、数据结构）是确定的，各个 Agent 就能独立工作而不互相踩；接口不定，并行必然产生冲突。
- 因为编译器天然分阶段：词法 → 语法 → 语义 → 代码生成，每个阶段的输入输出都有明确定义（token 流、AST、IR）。⭐ 而且每个阶段都有客观的验证手段——测试用例能直接判对错。
- 三条：①先定接口再并行；②每个子任务要能独立验证（否则合并时才发现问题，代价极高）；③留一个负责集成的角色，专门处理接口不匹配和整体一致性。⚠️ 没有第三条，并行产出的东西经常拼不起来。
🛑 可以停在这里
⚡ 走神救援
用多个 Claude 并行实现 C 编译器。⭐看点不是「能做出来」，是任务怎么被切成互不干扰的块。⭐⭐并行成立的前提：子任务之间的接口必须先固定下来（输入输出格式、函数签名、数据结构）——接口不定，并行必然冲突。编译器适合的原因：天然分阶段（词法→语法→语义→代码生成），每阶段输入输出有明确定义（token流/AST/IR），且每阶段都有客观验证手段（测试用例直接判对错）。三条通用做法：先定接口再并行、每个子任务要能独立验证（否则合并时才发现问题代价极高）、⚠️留一个负责集成的角色——没有它并行产出的东西经常拼不起来。