🤖 16 个 Claude 组队写代码：AI Agent Teams 如何攻克 10 万行 C 编译器

*"Over nearly 2,000 Claude Code sessions and \(20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V."* > > ——Nicholas Carlini, Anthropic --- ## 一、一个疯狂的实验 2026 年初，Anthropic 的研究员 Nicholas Carlini 做了一个大胆的尝试： **让 16 个 Claude AI Agent 并行工作，从零开始写一个 C 编译器。** 不是简单的玩具编译器，而是一个能编译 Linux 内核、支持 x86/ARM/RISC-V 三种架构、通过 99% GCC torture tests 的工业级编译器。 两周后，结果出来了： - **近 2000 次 Claude Code 会话** - **20,000 美元 API 成本** - **10 万行 Rust 代码** - **能编译 Linux 6.9、QEMU、FFmpeg、SQLite、Redis、Postgres** - **甚至能跑 Doom** 这是 AI 编程史上的一个里程碑。但更重要的是，它揭示了一种全新的软件开发范式——**Agent Teams（智能体团队）**。 --- ## 二、什么是 Agent Teams？ ### 从单线程到多线程 传统的 AI 编程助手（如 Claude Code、Cursor）是**单线程**的： - 一个 AI 会话 - 一个上下文窗口 - 一次处理一个任务 当项目规模扩大时，上下文窗口会被各种信息填满：前端代码、后端 API、数据库 schema、测试文件、错误日志……模型注意力被分散，输出质量下降。 **Agent Teams 的思路很简单：就像人类团队一样，让多个 AI 并行工作，各自专注。** ``` 单 Agent 模式： ┌─────────────────────────────────────────┐ │ Claude ( overwhelmed ) │ │ 上下文: 前端 + 后端 + 数据库 + 测试... │ │ 注意力分散 → 质量下降 │ └─────────────────────────────────────────┘ Agent Teams 模式： ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Lexer Agent │ │ Parser Agent │ │ Codegen Agent│ │ 专注词法分析 │ │ 专注语法分析 │ │ 专注代码生成 │ │ 10K 上下文 │ │ 10K 上下文 │ │ 10K 上下文 │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └──────────────┼──────────────┘ │ Git 仓库 （共享状态 + 协调） ``` ### 核心架构 **1. 无限循环（The Loop）** 每个 Agent 运行在一个简单的无限循环中： ```bash #!/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-4-6 &> "\(LOGFILE" done ``` Agent 完成一个任务，立即开始下一个，永不停歇。 **2. 任务认领机制（File-based Locks）** 为了避免多个 Agent 同时修改同一份代码，系统使用**文件锁**： ``` current_tasks/ ├── parse_if_statement.txt ← Agent A 正在处理 ├── codegen_function_definition.txt ← Agent B 正在处理 └── optimize_loop.txt ← 待认领 ``` 规则很简单： - 如果锁文件存在 → 任务已被认领 - 如果不存在 → 创建锁文件并开始工作 - 完成后 → 提交代码并删除锁文件 Git 的同步机制确保只有一个 Agent 能成功创建锁文件。 **3. 并行工作流** ``` Phase 1: 独立任务并行（早期） ├── Agent 1: 修复测试 #47 ├── Agent 2: 修复测试 #52 ├── Agent 3: 修复测试 #89 └── ... Phase 2: 项目并行（中期） ├── Agent A: 编译 SQLite ├── Agent B: 编译 Redis ├── Agent C: 编译 Lua └── ... Phase 3: 协同攻坚（后期 - Linux 内核） ├── 所有 Agent 面对同一个巨大任务 ├── 引入 GCC 作为"已知好的"编译器 ├── 随机分割编译任务，对比结果 └── 逐步缩小问题范围 ``` --- ## 三、关键设计决策 ### 1. 测试即控制平面 Carlini 发现：**测试质量决定了 Agent 能走多远。** 早期，Agent 经常"解决"了错误的问题——测试不够精确，Agent 以为任务完成了，实际上没有。 改进措施： - 引入 GCC torture test suite - 为每个开源项目编写验证脚本 - 建立 CI 流水线，强制回归测试 - 新提交不能破坏已有功能 **核心洞察：测试是 Agent 的"产品经理"，告诉它们什么是对的。** ### 2. 为 Claude 设计，而非为人类 Carlini 不断提醒自己：这个系统是给 Claude 用的，不是给我用的。 **具体设计：** | 人类偏好 | Claude 需要 | |---------|------------| | 详细的错误日志 | 简洁的摘要，关键信息在一行 | | 实时输出 | 增量进度，避免上下文污染 | | 完整信息 | 预计算的聚合统计，不用重新计算 | 例如，日志格式： ``` # 好的格式（Claude 友好） ERROR: parse failed at line 47, column 12 PASS: 47/50 tests # 坏的格式（人类友好，Claude 不友好） [2026-02-01 18:23:45] Starting parse... [2026-02-01 18:23:46] Tokenizing... [2026-02-01 18:23:47] Building AST... ... 1000 行日志 ... ``` ### 3. 专业化分工 并行不仅意味着速度，还意味着**专业化**： | Agent 角色 | 职责 | |-----------|------| | **功能开发** | 实现新特性 | | **代码清理** | 合并重复代码 | | **性能优化** | 提升编译器效率 | | **代码生成优化** | 优化输出代码质量 | | **架构审查** | 从 Rust 开发者角度改进结构 | | **文档维护** | 更新 README 和注释 | 每个 Agent 在自己的领域深耕，质量远超"全栈"Agent。 ### 4. 解决 Linux 内核编译的瓶颈 当 Agent 们开始编译 Linux 内核时，遇到了麻烦： **问题：** 所有 Agent 都卡在同一个 bug 上，修复后互相覆盖对方的修改。 **解决方案：** 引入 GCC 作为"已知好的"编译器（Oracle） ```python # 新测试策略 files = get_random_subset_of_kernel_files() for file in files: # 大部分文件用 GCC 编译（已知正确） if random.random() < 0.9: compile_with_gcc(file) else: # 小部分用 Claude 的编译器 compile_with_claude_compiler(file) # 如果内核能启动，问题不在 Claude 编译的文件里 # 如果不能启动，问题在 Claude 编译的文件里 # 逐步缩小范围... ``` 这让 Agent 们可以并行处理不同的文件，各自修复不同的 bug。 --- ## 四、成果与局限 ### 成果 | 指标 | 数值 | |------|------| | 代码行数 | ~100,000 行 Rust | | 开发时间 | 2 周 | | API 成本 | ~\)20,000 | | 会话数 | ~2,000 次 | | Token 消耗 | 20 亿输入 / 1.4 亿输出 | | 能编译的项目 | Linux 6.9、QEMU、FFmpeg、SQLite、Redis、Postgres | | GCC torture tests | 99% 通过率 | | 终极测试 | 能编译并运行 Doom |

局限

1. 依赖 GCC 的部分功能

• 缺少 16 位 x86 编译器（启动 Linux 必需）
• 调用 GCC 处理这部分

2. 汇编器和链接器不完整

• 仍在开发中
• 演示视频使用了 GCC 的汇编器和链接器

3. 代码效率不高

• 即使开启所有优化，输出代码比 GCC 无优化还慢

4. Rust 代码质量

• 合理，但远不及专家级 Rust 开发者

5. 接近能力上限

• 新功能经常破坏已有功能
• 某些问题（如 16 位 x86 后端）Agent 无法解决

五、核心洞察：什么是真正重要的

1. 环境设计 > 提示工程

Carlini 强调：智能不在于提示，而在于循环 + 环境。

不是写更复杂的提示词，而是设计：

• 清晰的测试信号
• 合理的任务分解
• 有效的协调机制
• 快速反馈循环

2. Git 是共享大脑

没有中央规划器，没有消息总线——Git 仓库就是协调机制。

优势：

• 持久化：进度不会因崩溃丢失
• 可审计：人类可以检查一切
• 简单：没有复杂的通信协议

3. 专业化 + 并行 > 单个超级 Agent

不是让 Agent 更聪明，而是让它们更专注。

100K 行代码无法塞进一个上下文窗口，但可以分解成 10 个 10K 行的子系统，每个由一个 Agent 负责。

4. 测试驱动 > 计划驱动

没有中央规划器分解任务，测试套件定义了正确性，CI 失败生成新工作。

Agent 通过"尝试 → 测试 → 失败 → 修复 → 提交"的循环迭代前进。

六、对软件开发的意义

我们现在能做什么？

1. 并行代码审查

• 3 个 Agent 同时审查：安全、性能、测试覆盖
• 比顺序审查快 3 倍

2. 多假设调试

• 3 个 Agent 同时探索不同的 bug 假设
• 分享发现，互相验证

3. 大规模重构

• 多个 Agent 并行处理不同模块
• 通过测试确保不破坏功能

边界在哪里？

开发者的角色转变

从"写代码"到"设计环境"：

• 设计测试策略
• 定义任务边界
• 建立协调机制
• 监控和调整

从"实现者"到"架构师"：

• Agent 负责执行
• 人类负责决策
• Agent 处理细节
• 人类把握方向

七、未来展望

短期（1-2 年）

• Agent Teams 产品化：内置并发控制、审计、可视化
• 验证栈扩展：更多 oracle 和差分测试工具
• 企业采用：治理层管理回归、溯源、执行权限

中期（3-5 年）

• 自主开发团队：Agent 承担更多架构决策
• 跨项目学习：Agent 从多个项目积累经验
• 人机协作新模式：人类专注创新，Agent 处理实现

长期（5 年+）

• 软件工程范式转变：从"写代码"到"设计 Agent 环境"
• 大规模自动化：复杂系统的大部分开发由 Agent 完成
• 新的软件形态：为 Agent 优化设计的编程语言和工具

八、结语：我们站在哪里？

16 个 Claude Agent 写出 10 万行 C 编译器，这件事本身令人惊叹。

但更令人深思的是：这不是终点，而是起点。

我们正从"AI 辅助编程"走向"AI 主导开发"。Agent Teams 展示了这种可能性，也揭示了需要的条件：

• 清晰的测试和验证
• 合理的任务分解
• 有效的协调机制
• 人类的监督和决策

Carlini 在文章结尾写道：

"Building this compiler has been some of the most fun I've had recently, but I did not expect this to be anywhere near possible so early in 2026."

（构建这个编译器是我最近最有趣的经历之一，但我没想到在 2026 年初就能做到这种程度。）

未来来得比预期更快。

参考链接

• 原文：Building a C compiler with a team of parallel Claudes
• GitHub：claudes-c-compiler
• Claude Code Agent Teams 文档：https://code.claude.com/docs/en/agent-teams

你怎么看待 AI Agent Teams 的未来？欢迎在评论区分享你的想法。