用并行 Claude 团队构建 C 编译器¶
原文发布于 2026 年 2 月 5 日，作者 Nicholas Carlini，Anthropic Safeguards 团队研究员
概述¶
16 个 Claude 实例并行工作两周，自主生产了一个能编译 Linux 内核的 C 编译器。 这是一次"Agent 团队"（多个 Claude 实例并行协作）的实验：让 Opus 4.6 从零开始构建一个 C 编译器。作者"基本上走开了"，让 Agent 自主运行。经过近 2,000 次 Claude Code 会话、花费约 2 万美元 API 费用，16 个 Agent 产出了一个 10 万行 Rust 代码的 C 编译器，能在 x86、ARM 和 RISC-V 架构上编译 Linux 6.9。
让 Claude 持续长时间运行¶
用一个简单的无限循环实现 Agent 的持续自主运行。 现有的 Agent 框架通常要求操作者在线监控。为了让 Agent 能持续自主推进，作者构建了一个极简的循环 harness：
#!/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
Agent prompt 指示 Claude 将问题拆分成小块、追踪进度、自行判断下一步做什么、然后继续前进。有一次 Claude 不小心运行了 pkill -9 bash——直接把自己杀死了，终止了整个循环。
并行运行多个 Claude¶
并行化解决了单 Agent 的两个核心瓶颈：串行执行和缺乏专业分工。 多个并行实例弥补了单 Agent 方案的两个弱点：
| 问题 | 并行化如何解决 |
|---|---|
| 单个会话一次只能做一件事 | 多实例同时处理不同任务 |
| 缺乏专业分工 | 不同 Agent 承担不同角色 |
实现方式¶
- 创建一个裸 git 仓库
- 为每个 Agent 启动一个 Docker 容器，将仓库挂载到
/upstream - 每个 Agent 在
/workspace做本地 clone
同步算法¶
- Claude 通过向
current_tasks/写入文本文件来"锁定"任务（如current_tasks/parse_if_statement.txt）。Git 的同步机制迫使第二个 Agent 在冲突时选择不同的任务。 - Claude 完成任务后，从 upstream 拉取、合并变更、推送自己的修改、移除锁文件。"合并冲突很频繁，但 Claude 足够聪明，能自己搞定。"
- 无限循环在新的容器中启动新的 Claude Code 会话。
这里没有编排 Agent——每个 Claude 自主决定做什么，通常会选择"下一个最显而易见"的问题。
用 Agent 团队编程的经验教训¶
编写极高质量的测试¶
当 Agent 自主工作时，测试验证器的质量决定了产出的质量。 "Claude 会自主地去解决我给它的任何问题。所以，任务验证器近乎完美是至关重要的。" 改进测试 harness 需要：寻找高质量的编译器测试套件、编写验证器、在发现新的失败模式时设计新的测试。当 Claude 开始破坏已有功能后，作者增加了一个更严格的 CI pipeline。
站在 Claude 的角度思考¶
为 AI 设计工具接口，而不是为人类。 测试 harness 是为 Claude 设计的，不是为人。关键考量：
| 设计要点 | 说明 |
|---|---|
| 上下文窗口污染 | 不要打印数千字节的无用信息。将信息记录到文件中，"预先计算聚合统计数据，这样 Claude 就不必重复计算" |
| 时间感知缺失 | "Claude 没有时间概念，如果不管它，它会开心地花几小时跑测试而不是推进开发。" 加入 --fast 选项，每个 Agent 运行确定性的 1% 或 10% 随机样本 |
让并行化变得简单¶
失败测试多时并行化很容易，测试通过率高时需要更巧妙的任务分割策略。 当存在大量不同的失败测试时，并行化是轻而易举的事。在达到 99% 通过率后，Agent 转向编译不同的开源项目（SQLite、Redis、libjpeg、MQuickJS、Lua）。
对于 Linux 内核（一个巨型单一任务），Agent 不断撞上同一个 bug。解决方案是用 GCC 作为"在线已知正确编译器 oracle"——随机地用 GCC 编译大部分内核文件，只让 Claude 的编译器处理其余部分，然后逐步缩小故障范围。还运用了 Delta debugging 技术。
多 Agent 角色¶
并行化使专业分工成为可能。 不同 Agent 承担不同职责：
| Agent 角色 | 职责 |
|---|---|
| 代码整合者 | 合并重复代码 |
| 性能优化者 | 提升编译器本身的性能 |
| 输出优化者 | 优化生成代码的效率 |
| 代码评审者 | 从 Rust 开发者视角审视设计 |
| 文档维护者 | 维护项目文档 |
压力测试极限¶
该项目作为 Claude 4 系列模型的能力基准测试。 此前的 Opus 4 模型几乎无法产出可用的编译器。Opus 4.5 能通过大型测试套件但无法编译真实项目。Opus 4.6 被推到了极限。
项目数据¶
| 指标 | 数据 |
|---|---|
| 会话数 | 约 2,000 次 Claude Code 会话，跨两周 |
| Token 使用 | 20 亿输入 token、1.4 亿输出 token |
| 成本 | 略低于 2 万美元 |
| 代码量 | 10 万行 Rust 代码 |
| 实现方式 | 洁净室实现（无互联网访问），仅依赖 Rust 标准库 |
能力¶
- 可编译并启动 Linux 6.9（x86、ARM、RISC-V）
- 可编译 QEMU、FFmpeg、SQLite、PostgreSQL、Redis
- 大多数编译器测试套件通过率 99%，包括 GCC torture test suite
- 能编译并运行 Doom
局限性¶
| 局限 | 说明 |
|---|---|
| 16 位 x86 编译器 | 无法生成从 real mode 引导 Linux 所需的 16 位代码（需调用 GCC） |
| 汇编器/链接器 | 没有自己的实现，仍有些 bug |
| 替代能力 | 不能作为真实编译器的直接替代品 |
| 代码效率 | 生成代码的效率低于"关闭所有优化的 GCC" |
| 代码质量 | Rust 代码"还行，但远未达到 Rust 专家的水平" |
关于 16 位问题的细节：编译器可以通过 66/67 操作码前缀输出正确的 16 位 x86 代码，但结果超过 60KB，远超 Linux 的 32K 代码限制。对于 ARM 或 RISC-V，Claude 的编译器可以完全独立完成编译。
展望未来¶
每一代模型都带来了全新的工作方式——从 Tab 补全到完全自主的 Agent 团队。 作者回顾了与 AI 编程协作方式的演进：从 Tab 补全，到函数级补全，到与 Claude Code 结对编程，再到如今的完全自主 Agent 团队实现复杂项目。
然而，作者也表达了不安："构建这个编译器是我最近最开心的事，但我没想到这在 2026 年初就已经接近可能。" 作为前渗透测试从业者，他指出"程序员部署自己从未亲自验证过的软件，这种想法是一个真实的隐忧。"
致谢¶
特别感谢 Josef Bacik、Edwin Chen、Bernardo Meurer Costa、Jake Eaton、Dan Kelley、Felix Klock、Jannet Park、Steve Weis 以及 Anthropic 的其他同事。