> *"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
---
二、什么是 Agent Teams？
从单线程到多线程
传统的 AI 编程助手（如 Claude Code、Cursor）是单线程的：
- 一个 AI 会话
- 一个上下文窗口
- 一次处理一个任务
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 ← 待认领
规则很简单：
- 如果锁文件存在 → 任务已被认领
- 如果不存在 → 创建锁文件并开始工作
- 完成后 → 提交代码并删除锁文件
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 流水线，强制回归测试
- 新提交不能破坏已有功能
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 和注释 |
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。
---
四、成果与局限
成果
| 指标 | 数值 |
|---|---|
| 代码行数 | ~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 处理这部分
- 仍在开发中
- 演示视频使用了 GCC 的汇编器和链接器
- 即使开启所有优化，输出代码比 GCC 无优化还慢
- 合理，但远不及专家级 Rust 开发者
- 新功能经常破坏已有功能
- 某些问题（如 16 位 x86 后端）Agent 无法解决
五、核心洞察：什么是真正重要的
1. 环境设计 > 提示工程
Carlini 强调：智能不在于提示，而在于循环 + 环境。
不是写更复杂的提示词，而是设计：
- 清晰的测试信号
- 合理的任务分解
- 有效的协调机制
- 快速反馈循环
2. Git 是共享大脑
没有中央规划器，没有消息总线——Git 仓库就是协调机制。
优势：
- 持久化：进度不会因崩溃丢失
- 可审计：人类可以检查一切
- 简单：没有复杂的通信协议
3. 专业化 + 并行 > 单个超级 Agent
不是让 Agent 更聪明，而是让它们更专注。
100K 行代码无法塞进一个上下文窗口，但可以分解成 10 个 10K 行的子系统，每个由一个 Agent 负责。
4. 测试驱动 > 计划驱动
没有中央规划器分解任务，测试套件定义了正确性，CI 失败生成新工作。
Agent 通过"尝试 → 测试 → 失败 → 修复 → 提交"的循环迭代前进。
---
六、对软件开发的意义
我们现在能做什么？
1. 并行代码审查
- 3 个 Agent 同时审查：安全、性能、测试覆盖
- 比顺序审查快 3 倍
- 3 个 Agent 同时探索不同的 bug 假设
- 分享发现，互相验证
- 多个 Agent 并行处理不同模块
- 通过测试确保不破坏功能
边界在哪里？
| 适合 Agent Teams | 不适合 Agent Teams |
|---|---|
| 任务可分解为独立单元 | 任务高度耦合 |
| 有明确的正确性检验 | 需要创造性设计决策 |
| 有参考实现可对比 | 从零设计架构 |
| 规格明确且稳定 | 需求频繁变化 |
开发者的角色转变
从"写代码"到"设计环境"：
- 设计测试策略
- 定义任务边界
- 建立协调机制
- 监控和调整
- 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 展示了这种可能性，也揭示了需要的条件：
- 清晰的测试和验证
- 合理的任务分解
- 有效的协调机制
- 人类的监督和决策
> *"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 的未来？欢迎在评论区分享你的想法。*