TL;DR

本文核心观点：

  1. 极简协调的可行性 — 16个Claude实例并行工作，没有项目经理，没有每日站会，只有简单的git同步和文件锁，7个月后交付了一个能编译Linux内核的C编译器。
  2. 目标替代指令 — 复杂的工程任务可以用极简的协调机制完成，不是因为Agent比人类更聪明，而是因为清晰的目标替代了复杂的指令。
  3. 同步原语足够 — 简单的git同步和文件锁足以处理大多数协调需求，无需中央调度器。
  4. 协调作为副作用 — 当每个Agent都遵循相同的目标和反馈机制，有效的协调可以自然涌现。

一个激进的实验

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

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

💡 Key Insight

复杂的工程任务，可以用极简的协调机制完成。这不是因为 Agent 比人类更聪明，而是因为清晰的目标替代了复杂的指令，简单的同步原语足以处理大多数协调需求。

规则：

  • ❌ 没有项目经理
  • ❌ 没有每日站会
  • ❌ 没有中央协调者
  • ✅ 只有简单的 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 问了一个问题：这真的是必须的吗？

极简协调机制的设计

基础设施

Carlini 的基础设施选择极其克制：

  • 容器化环境隔离每个 Agent
  • 共享 Git 仓库作为唯一的同步点
  • 文件锁机制防止并发写入冲突

💡 Key Insight

极简基础设施的优势不在于功能强大，而在于可理解、可调试、可预测。当协调机制复杂到无人能理解时，它本身就成为了风险的来源。

任务锁：简单到荒谬

协调的核心机制：

协议：

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

合并冲突？让 Agent 自己解决

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

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

这改变了一个基本假设：

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

合并冲突？让 Agent 自己解决

涌现的秩序

无 Orchestrator 的决策

Carlini 明确说明：

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

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

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

涌现的协调

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

💡 Key Insight

协调不一定要被”设计”出来。当每个 Agent 都遵循相同的目标和反馈机制时，有效的协调可以作为副作用自然涌现，而无需中央调度。

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

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

与 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，如何保证系统整体方向正确？

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

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

挑战 3：异常处理

Agent 可能做出破坏性操作。

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

应对机制：

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

工程启示与未来方向

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

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

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

启示 2：信任 Agent 的自主性

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

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

启示 3：测试即协调

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

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

未来研究方向

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

💡 Key Insight

我们可能需要重新思考”管理”的价值。16 个 Agent 没有项目经理、没有 Scrum Master、没有每日站会，交付了一个能编译 Linux 内核的编译器；而 3 个工程师加 1 个产品经理的团队还在延期。问题可能不是 Agent 太聪明，而是人类的管理太臃肿——很多”管理活动”只是仪式感，让我们感觉在做事情，而不是真的在做事情。当然，Agent 不会写 PPT、不会在项目评审会上辩护决策、不会在绩效考核时为自己争取晋升——也许这就是为什么我们还需要人类管理者。

结尾

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

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

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

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

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

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

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

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

深度阅读时间：约 8 分钟

参考来源：

  • 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 工程系列