16 个 Claude 并行编写 C 编译器：多 Agent 协作的新纪元

TL;DR

Anthropic 的研究者让 16 个 Claude Agent 并行工作，从零构建了一个能编译 Linux 内核的 C 编译器。近 2,000 个会话、$20,000 API 成本、100,000 行代码，没有中央编排器，完全自组织协作。这不是未来的科幻，而是正在发生的工程现实。本文深度解析这个实验的技术架构、协作机制和关键启示。

📋 本文结构

1. 实验概览：不可能的工程
2. 技术架构：无限循环 + Git 协调
3. 并行 Agent 设计：去中心化协作
4. 任务同步：Git 作为协调机制
5. 自组织 vs 中央控制
6. 关键发现与经验
7. 局限与边界
8. 对未来软件开发的影响
9. 结论：无需人类干预的工程团队

实验概览：不可能的工程

任务定义

目标：构建一个 C 编译器，能够编译 Linux 内核

约束：

• 使用 Rust 编写
• 从零开始（不是 fork 现有编译器）
• 支持 x86、ARM、RISC-V 架构
• 能编译 Linux 6.9 内核

实验规模

核心创新

没有中央编排器（No Orchestrator）。

传统多 Agent 系统：

中央控制器 → 分配任务 → Agent 1
          → 分配任务 → Agent 2
          → 分配任务 → Agent 3

这个实验：

Agent 1 ←→ Git ←→ Agent 2
   ↕️              ↕️
Agent 4 ←→ Git ←→ Agent 3

无中央控制，纯自组织

技术架构：无限循环 + Git 协调

单层 Agent 的局限

传统 Claude Code：

• 需要人类操作员在线
• 解决部分问题后等待输入
• 无法持续自主工作

问题：

Agent: "我完成了函数解析器的框架"
人类："好的，继续实现表达式解析"
Agent: "完成了，接下来做什么？"
人类："实现代码生成"
...

人类成为瓶颈。

无限循环 Harness

解决方案：让 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-X-Y \
    &> "$LOGFILE"
done

关键设计：

1. 循环永不停止
   • 一个任务完成，立即开始下一个
   • 没有”等待人类输入”的状态

2. Prompt 策略

   AGENT_PROMPT.md 核心内容：

   ## 任务
   构建一个能编译 Linux 内核的 C 编译器
      
   ## 工作方式
   1. 将问题分解为小模块
   2. 追踪你正在做什么
   3. 确定下一步做什么
   4. 持续迭代直到完美
      
   ## 规则
   - 每次只做一个小功能
   - 写测试验证你的代码
   - 频繁提交到 git
   - 如果卡住，尝试不同角度
   

3. 日志记录
   • 每个会话的完整输出保存
   • 便于事后分析和调试
4. 危险但有效
   • --dangerously-skip-permissions：跳过确认提示
   • 在容器内运行（安全隔离）
   • 研究者备注：有一次 Claude 不小心 pkill -9 bash 杀死了自己！

并行 Agent 设计：去中心化协作

为什么需要并行？

单 Agent 的瓶颈：

并行的优势：

单 Agent：
[词法分析] → [语法分析] → [语义分析] → [代码生成] → [优化]
   ↑___________________________________________________|
   循环迭代，一个问题卡住全部停滞

多 Agent：
Agent 1: [词法分析] ──┐
Agent 2: [语法分析] ──┼──→ Git ──→ 集成
Agent 3: [语义分析] ──┤
Agent 4: [代码生成] ──┘

并行推进，部分卡住不影响整体

容器化架构

基础设施：

主机
├── upstream/          # 中央 Git 仓库
│   ├── src/           # 源代码
│   ├── tests/         # 测试
│   └── current_tasks/ # 任务锁文件
│
├── agent_logs/        # 日志目录
│
└── Docker 容器 x 16
    ├── Container 1 (Agent 1)
    │   ├── /upstream 挂载 (只读)
    │   └── /workspace (工作目录)
    ├── Container 2 (Agent 2)
    └── ...

工作流程：

1. 每个容器启动时：

   git clone /upstream /workspace
   cd /workspace
   

2. Agent 在 /workspace 工作

3. 完成后：

   git pull origin main    # 获取最新代码
   git merge               # 解决冲突
   git push origin main    # 提交
   

4. 容器销毁，新容器启动

专业化分工（自然涌现）

虽然没有预设分工，但 Agent 自然形成了专业化：

关键：不是预先分配，而是 Agent 自主选择任务的结果。

任务同步：Git 作为协调机制

去中心化任务分配

传统方法：中央任务队列

# 中央控制器
task_queue = ["parse_if", "parse_for", "codegen_add", ...]

def assign_task(agent_id):
    return task_queue.pop()

问题：单点故障、扩展性受限。

Git 锁文件机制

创新方案：用 Git 文件系统作为分布式锁

current_tasks/
├── parse_if_statement.txt        ← Agent A 正在处理
├── codegen_function_call.txt     ← Agent B 正在处理
├── semantic_check_types.txt      ← Agent C 正在处理
└── ...

工作流程：

# 1. Agent 选择一个任务
TASK="parse_while_loop"

# 2. 尝试获取锁
echo "Agent $AGENT_ID working on $TASK" > current_tasks/${TASK}.txt
git add current_tasks/${TASK}.txt
git commit -m "Claim task: $TASK"
git push

# 3. 如果成功（无冲突），开始工作
#    如果失败（别人已认领），重新选择任务

# 4. 完成任务后
git pull
# ... 合并其他人的更改 ...
git rm current_tasks/${TASK}.txt
git commit -m "Complete task: $TASK"
git push

Git 的原子性保证：

• 两个 Agent 同时尝试认领同一任务
• 只有一个能成功 push
• 另一个自动失败，重新选择

冲突解决

频繁但可管理：

场景：
Agent A 修改了 parser.rs
Agent B 同时修改了 parser.rs

Agent A push 成功
Agent B push 失败（冲突）

Agent B 自动处理：
1. git pull
2. Claude 分析冲突
3. 合并更改
4. git push

成功率：

• 大部分冲突 Claude 能自动解决
• 复杂冲突可能导致任务放弃，重新选择

自组织 vs 中央控制

两种架构对比

涌现行为

没有预定义的角色，但角色自然涌现。

示例 1：专业化

Agent 5 连续多次选择 "lexer" 相关任务
→ 它在 lexer 代码上积累了更多经验
→ 它更擅长 lexer 任务
→ 它更倾向于选择 lexer 任务
→ 成为事实上的 "lexer 专家"

示例 2：代码所有权

parser.rs 主要由 Agent 3 修改
→ Agent 3 最了解这部分代码
→ 其他 Agent 遇到 parser 问题会避开
→ Agent 3 成为 parser 模块的 "维护者"

示例 3：任务依赖解决

Agent 7 想做 "codegen_if"
但它发现需要先完成 "ast_if"
Agent 7：我先做 "ast_if"
Agent 2：我来做 "codegen_if"（看到 ast_if 已完成）

自组织的代价

1. 不可预测性

无法预测：

• 哪个 Agent 会做什么任务
• 任务完成的顺序
• 最终代码结构

2. 效率损失

场景：
Agent A 开始实现 "for 循环"
Agent B 同时开始实现 "for 循环"
（两者都看到任务可用）

结果：
两者都 push 了自己的实现
需要合并或选择一个
浪费了一些工作

3. 调试困难

当出现问题时：

• 不知道哪个 Agent 引入了 bug
• 需要查看大量日志
• 难以复现问题场景

关键发现与经验

发现 1：测试是关键

没有测试 = 混乱

实验初期：

• Agent 生成代码不验证
• 代码能编译但逻辑错误
• 错误累积，项目停滞

加入测试后：

• 每个功能必须有测试
• Agent 运行测试验证
• 测试失败阻止合并
• 代码质量显著提升

测试即规范：

#[test]
fn test_parse_if_statement() {
    let code = "if (x > 0) { return 1; }";
    let ast = parse(code);
    assert!(matches!(ast, Ast::IfStatement { .. }));
}

发现 2：小步快跑优于大步前进

失败模式：

Agent: "我要重构整个解析器"
→ 修改 5000 行代码
→ 测试全部失败
→ 无法回滚
→ 项目卡住

成功模式：

Agent: "我添加一个 if 语句解析"
→ 修改 50 行代码
→ 测试通过
→ 提交
→ 下一个 Agent 继续

发现 3：Prompt 工程至关重要

不好的 Prompt：

"Build a C compiler"

好的 Prompt：

"Build a C compiler by:
1. Breaking down into small modules
2. Writing tests for each module
3. Implementing one small feature at a time
4. Committing frequently
5. Checking tests before each commit
6. If stuck, try a different approach"

发现 4：涌现的质量控制

没有预定义的质量检查，但质量机制自然涌现：

Agent A 提交了有问题的代码
→ 测试失败
→ Agent B 尝试使用代码，发现问题
→ Agent B 修复或回滚
→ Agent A 看到修复，学习避免类似错误

分布式纠错机制

局限与边界

当前局限

1. 编译器是结构化问题

• 明确的阶段（词法→语法→语义→代码生成）
• 清晰的接口定义
• 可验证的输出（能否编译 Linux）

非结构化问题可能更难：

• UI/UX 设计
• 产品需求定义
• 创新性架构设计

2. 大量计算资源

• $20,000 API 成本
• 数千次 LLM 调用
• 不是所有项目都能负担

3. 调试工具不完善

• 难以理解 Agent 决策过程
• 问题定位困难
• 缺乏可视化工具

4. 偶尔的自我毁灭

研究者备注：

“有一次 Claude pkill -9 bash 杀死了自己。Whoops!”

需要容器隔离和自动重启。

适用场景

对未来软件开发的影响

1. 开发团队的新形态

传统团队：

人类开发者 x 10
├── 前端工程师 x 3
├── 后端工程师 x 4
├── 测试工程师 x 2
└── DevOps x 1

未来团队：

人类架构师 x 1-2
├── AI Agent x 50
├── 质量检查 Agent x 5
├── 文档维护 Agent x 3
└── 协调人类（部分时间）

2. 开发流程的变化

从”人类编写”到”人类指导”：

3. 软件架构的演进

AI 友好的架构将成为标准：

• 模块化、清晰接口
• 完善的测试覆盖
• 详尽的文档
• 标准化的结构

不是为人类开发者优化，而是为 AI Agent 优化。

4. 经济模型变化

从人力成本到算力成本：

传统：$150K/年 x 10 工程师 = $1.5M/年

AI 辅助：$200K/年 x 2 架构师 + $100K API = $500K/年

但初期投入高：

• Harness 构建成本
• 流程设计成本
• 工具链建设成本

结论：无需人类干预的工程团队

这个实验证明了什么？

核心证明

AI Agent 可以在没有人类实时干预的情况下，协作完成复杂的工程任务。

不是：

• ❌ 完全自主（仍需要人类定义目标和 Harness）
• ❌ 通用智能（特定领域的结构化问题）
• ❌ 低成本（$20K 证明仍然昂贵）

而是：

• ✅ 特定任务的自主性
• ✅ 可扩展的并行协作
• ✅ 涌现的质量控制
• ✅ 实际可用的成果

对开发者的启示

1. 拥抱变化
   • 编码技能仍然重要，但角色在转变
   • 从”写代码”到”设计约束”
2. 投资 Harness 技能
   • 学习如何设计有效的约束
   • 理解测试即规范
   • 掌握上下文工程
3. 保持批判性思维
   • AI 不是万能药
   • 理解适用边界
   • 知道何时需要人类判断

最后思考

这个实验是 AI 工程的一个里程碑。

16 个 Claude Agent，没有中央控制，自组织协作，构建了一个能编译 Linux 内核的 C 编译器。

这不是科幻，这是 2026 年的现实。

软件开发的未来，可能不是人类与 AI 竞争，而是人类设计规则，AI 在规则内自主协作。

Harness 工程师，可能是一个新职业的开端。

参考与延伸阅读

• Building a C compiler with a team of parallel Claudes - Anthropic
• The Compiler Code - GitHub
• Harness Engineering - Anthropic
• Building Effective Agents - Anthropic

本文基于 Anthropic Engineering 博客文章解读。

发布于 postcodeengineering.com