🤖 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 运行在一个简单的无限循环中：

#!/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 友好）
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 在自己的领域深耕，质量远超"全栈"Agent。

4. 解决 Linux 内核编译的瓶颈

当 Agent 们开始编译 Linux 内核时，遇到了麻烦：

问题： 所有 Agent 都卡在同一个 bug 上，修复后互相覆盖对方的修改。

解决方案： 引入 GCC 作为"已知好的"编译器（Oracle）

# 新测试策略
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。

---

四、成果与局限

成果

局限

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 的未来？欢迎在评论区分享你的想法。