TL;DR

16 个 Claude 实例并行工作，没有项目经理，没有每日站会，只有简单的 git 同步和文件锁。7 个月后，他们交付了一个能编译 Linux 内核的 C 编译器。

Anthropic 研究员 Nicholas Carlini 的实验揭示了一个反直觉的可能性：复杂的工程任务，可以用极简的协调机制完成。这不是因为 Agent 比人类更聪明，而是因为清晰的目标替代了复杂的指令，简单的同步原语足以处理大多数协调需求。

📋 本文结构

  1. 一个激进的实验 —— 16 个 Agent，0 个管理者
  2. 为什么需要并行 Agent —— 单线程瓶颈的本质
  3. 极简协调机制的设计 —— 文本文件锁 + Git 同步
  4. 涌现的秩序 —— 无 Orchestrator 的自主行为
  5. 与 OpenAI 方法的对比 —— 去中心化 vs 中心化
  6. 去中心化协调的挑战 —— 依赖管理、全局一致性、异常处理
  7. 工程启示与未来方向 —— 简单性优于完备性
  8. 今日毒舌 —— 关于管理的残酷真相
  9. 结语 —— 分布式系统理论的新生命

一个激进的实验

2025年末，Anthropic 研究员 Nicholas Carlini 做了一个大胆的尝试：

让 16 个 Claude Agent 并行工作，从零开始构建一个 C 编译器——不是玩具项目，而是能编译 Linux 内核的工业级编译器。

规则：

  • ❌ 没有项目经理
  • ❌ 没有每日站会
  • ❌ 没有中央协调者
  • ✅ 只有简单的 git 同步和文件锁

7 个月后：

  • 2000 次 Claude Code 会话
  • $20,000 API 成本
  • 10 万行 Rust 代码
  • 成功编译 Linux 6.9（x86/ARM/RISC-V）

这个实验不仅产出了一个能工作的编译器，更揭示了一个被忽视的领域：多 Agent 协调机制。

为什么需要并行 Agent？

单 Agent 的三大瓶颈

1. 单线程瓶颈

一个 Claude Code 会话一次只能做一件事。即使任务可以并行，Agent 也必须串行处理。

2. 无法并行调试

大型项目中，多个 Bug 需要同时解决。单 Agent 只能逐个处理，效率低下。

3. 专业化缺失

没有专门负责文档、代码质量或特定子任务的 Agent。一个 Agent 试图做所有事情。

传统解决方案的局限

人类团队的解决方案是增加管理者——项目经理协调任务分配，确保没有冲突。

但 Carlini 问了一个问题：这真的是必须的吗？

极简协调机制的设计

基础设施

共享 bare git repo
├── /upstream      # 共享仓库
└── /workspace     # 每个 Agent 的本地克隆

每个 Agent 运行在独立的 Docker 容器中

任务锁：简单到荒谬

协调的核心机制：

current_tasks/
├── parse_if_statement.txt           # Agent A 正在处理
├── codegen_function_definition.txt  # Agent B 正在处理
└── optimize_register_allocation.txt # Agent C 正在处理

协议：

# Step 1: 尝试获取任务锁
# 写文件到 current_tasks/parse_loops.txt
echo "Agent-7 working on this" > current_tasks/parse_loops.txt
git add . && git commit -m "claim: parse_loops"

# 如果冲突（另一个 Agent 先写了），git push 会失败
# Agent 必须选择其他任务

# Step 2: 工作
# ... 实现 parse_loops ...

# Step 3: 完成并释放
# Pull 上游变更 → Merge → Push → 删除锁文件
git pull origin main
git push origin main
rm current_tasks/parse_loops.txt
git commit -m "complete: parse_loops"

没有中央调度器。没有复杂的状态管理。只有 Git 的原始力量。

合并冲突？让 Agent 自己解决

在并行执行中，合并冲突是常态。

Carlini 的发现：Claude 足够聪明，可以自己解决大部分冲突。

这改变了一个基本假设：

  • 传统思维：冲突是人类协调者的责任
  • Harness 思维：冲突是 Agent 工作流的一部分

涌现的秩序

无 Orchestrator 的决策

Carlini 明确说明：

“我没有实现任何其他 Agent 间通信方法，也没有使用编排 Agent。”

每个 Claude 实例被赋予完全自主权：

  • 选择”下一个最明显的问题”
  • 维护失败方法的运行文档
  • 跟踪剩余任务列表
  • 决定何时提交、何时继续、何时放弃

涌现的协调

令人惊讶的是，这种极简机制产生了有效的协调：

  • Agent 们自然地分散到不同任务
  • 没有两个 Agent 长期争抢同一任务
  • 系统以稳定的速度推进

这不是设计出来的，而是涌现出来的。

Agent-3: 我看到 parse_if_statement 被占了，那我去做 parse_while
Agent-7: codegen_function 完成了，看看还有什么...
Agent-12: 发现 type_checker 和 my work 有关，先 pull 最新代码

与 OpenAI 方法的对比

维度 Carlini C编译器 OpenAI Harness
Agent 数量 16 并行 3→7 工程师驱动
协调模式 去中心化（无 orchestrator） 中心化（人类+Agent 混合）
任务粒度 细粒度（函数级） 粗粒度（PR 级）
同步机制 Git + 文件锁 Ralph Wiggum Loop（自评审）
持续时长 单任务 6 小时（无人值守） 平均 3.5 PRs/人/天
人类介入 最小化（仅环境设计） 中等（PR 评审、任务分配）

两种模式的适用场景

Carlini 方法：

  • ✅ 目标明确的工程任务（如编译器）
  • ✅ 可以模块化分解的问题
  • ✅ 需要长时间无人值守运行

OpenAI 方法：

  • ✅ 需要产品判断的场景
  • ✅ 需要人类保留控制权的项目
  • ✅ 复杂的用户体验决策

没有绝对的好坏，只有适合的场景。

去中心化协调的挑战

挑战 1：任务依赖管理

简单任务锁无法表达”任务 B 依赖任务 A”的关系。

Carlini 的应对：

  • 大部分任务被设计为相对独立
  • Agent 遇到依赖时，自己决定是等待还是尝试解决

局限：这种方法适合编译器这种模块化程度高的项目，对于高度耦合的系统可能需要更复杂的依赖图。

挑战 2：全局一致性

没有中央 orchestrator，如何保证系统整体方向正确？

答案：测试套件作为隐性协调机制

所有 Agent 的目标：通过测试
          ↓
    测试定义了"正确"
          ↓
    Agent 自然朝着同一方向努力

这是一种目标层面的协调，而非过程层面的协调。

挑战 3：异常处理

Agent 可能做出破坏性操作。

案例：

“有一次我看到 Claude 意外执行 pkill -9 bash，杀死了自己和整个循环。Whoops!”

应对机制：

  • 容器化隔离
  • 定期人类检查（虽然频率很低）
  • 从失败中恢复的机制（自动重启 Agent）

工程启示与未来方向

启示 1：简单性优于完备性

Carlini 的机制极其简单——文本文件锁 + Git。没有分布式事务，没有状态机，没有复杂协议。

但正是这种简单性，让系统可理解、可调试、可扩展。

启示 2：信任 Agent 的自主性

传统工程思维倾向于严格控制。Carlini 的实验表明：当给定正确的目标和反馈机制，Agent 可以自我协调。

这不是说完全不需要监督，而是说监督的粒度可以更粗。

启示 3：测试即协调

在没有显式协调者的情况下，测试套件成为隐性的协调机制。

所有 Agent 都朝着同一个目标优化：通过测试。这比任何人类分配的任务都更清晰、更客观。

未来研究方向

方向 问题 可能方案
显式依赖图 如何表达复杂依赖？ 任务依赖图 + 自动拓扑排序
Agent 间通信 如何共享知识？ 消息总线或共享知识库
混合人机协调 何时人类介入？ 动态自主度调整

今日毒舌

Carlini 的实验揭示了一个尴尬的事实：

我们可能需要重新思考”管理”的价值。

16 个 Agent，没有项目经理，没有 Scrum Master，没有每日站会——交付了一个能编译 Linux 内核的编译器。

而你的团队，3 个工程师，1 个产品经理，半个项目经理，每周 3 次站会，每天无数 Slack 消息——还在延期。

问题可能不是 Agent 太聪明，而是人类的管理太臃肿。

当目标清晰、反馈及时、冲突可自动解决时，很多”管理活动”可能只是仪式感——让我们感觉在做事情，而不是真的在做事情。

当然，Agent 不会写 PPT 汇报进度，不会在项目评审会上辩护决策，不会在绩效考核时为自己争取晋升。

也许这就是为什么我们还需要人类管理者。

结语

Carlini 的并行 Agent 实验，展示了一个反直觉的可能性：

复杂的工程任务，可以用极简的协调机制完成。

这不是因为 Agent 比人类更聪明，而是因为：

  • 清晰的目标替代了复杂的指令
  • 简单的同步原语足以处理大多数协调需求
  • Agent 的自主性减少了中央调度的负担

这对软件工程的启示是深远的：

我们长期以来假设大型工程需要复杂的项目管理、详细的任务分配、频繁的同步会议。但也许，当系统被正确设计，工程可以更像一个自组织的生态系统。

Harness 工程的真正突破，不是让 Agent 能写代码，而是让多个 Agent 能协作写代码。

分布式系统的理论，正在 AI Agent 领域获得新的生命。

参考来源：

  • Carlini: Building a C compiler with a team of parallel Claudes (Anthropic)
  • OpenAI: Harness engineering: leveraging Codex in an agent-first world
  • George: Harness 工程就是控制论

← 返回 AI-Native 工程系列