- tags
- [Agent, 架构, 多Agent, 协同, 编译器]
- created
- 2026-04-12
- updated
- 2026-04-28
- sources
- [raw/notes/carlini-parallel-agents-no-orchestration.md, raw/notes/google-agent-platform-research-2026-04-28.md]
定义¶
用文件系统 + Git 替代复杂编排框架的多 Agent 协同模式。Nicholas Carlini（Anthropic）在 C 编译器项目中验证：16 个 Claude Agent 并行两周，无中心编排器，仅靠共享文件夹 + 锁文件 + Git 同步协作，产出 10 万行 Rust 代码。
关键要点¶
- 核心洞察：编排（Orchestration）不是必须的。复杂的 Agent 编排框架增加了管理成本，而最朴素的 Bash 循环 + 文件锁就够了
- 同步协议——三个原语：
- 任务池：
current_tasks/共享文件夹，所有 Agent 都可以提交和认领任务 - 互斥锁：Agent 写入
.lock文件标记"我在做了"，Git 同步天然处理竞态 - 分布式协同：Git 处理并行修改，合并冲突由 Claude 自行解决
- 单次循环逻辑：启动容器 → 拉取 upstream → 扫描目录认领未锁定任务 → 编码 → push 并释放锁
- 自组织任务生成：
current_tasks/的任务来自 Agent 自身——所有 Agent 都可以提交新任务，规则写在 AGENT_PROMPT.md 中 - 专业化角色分工：Refactorer（去重）、Performance Tuner（优化）、Code Critic（代码审查）、Documenter（文档）——但分工通过 prompt 而非编排器实现
- 项目成果：近 2000 个 Claude Code 会话，$20,000 API 成本，产出的编译器可编译 Linux 6.9（x86/ARM/RISC-V）、QEMU、FFmpeg、SQLite、Postgres、Redis，GCC torture 测试通过率 99%
- 已知瓶颈：当任务不可并行化时（如编译 Linux 内核是一个整体任务），16 个 Agent 会撞同一个 bug 互相覆盖。解决方案：用 GCC 作为 oracle 将单体任务拆成可并行子集
- 设计哲学：用最简单的基础设施（文件系统、Git、Bash）解决协同问题，而非构建复杂的中间件。与 harness-engineering 中"记忆选 Markdown 而非向量数据库"的朴素选择一致
反方向证据：行业头部正在押显式编排（2026-04 Google ADK 升级）¶
Google Gemini Enterprise Agent Platform Build 柱的 ADK（Agent Development Kit） 在 2026-04-22 Cloud Next 公布重大升级——从线性子 agent 改为graph-based 子 agent 网络（显式 DAG 编排）。Google 官方原话："organizing agents into a network of sub-agents capable of solving complex problems, using its new graph-based framework"。
这是与本概念反方向的行业证据。2026-04 同期出现至少三种路径：
| 路径 | 代表 | 哲学 | 适用场景 |
|---|---|---|---|
| 显式 graph 编排 | Google ADK 2026 / LangGraph | 子 agent 间协作要 DAG 编排 | 企业级复杂工作流，需要可审计 + 可视化 + 可治理 |
| 父→子 Subagent（层级） | Claude Agent SDK | 单次启动新上下文，只返回最终结果 | 任务可拆分到独立子 agent，无需复杂协作 |
| 无编排（本概念） | Carlini C 编译器 | 文件锁 + Git + 自组织任务池 | 任务高度可并行 + 团队工程文化偏 UNIX 朴素 |
| Amphiflow | amphiflow-pattern | 默认 workflow + agent 兜底 | 高频固定模式 + 异常路径少 |
含义：
- 不是单一路径正确——三/四种路径都有产品实证支撑（Carlini C 编译器 / Google ADK / Claude Agent SDK / 张铁蕾 amphiflow）
- Carlini "无编排" 哲学的边界：当任务高度可并行 + 团队工程文化偏 UNIX 朴素 + 任务定义可由 agent 自生成时强；当企业治理需要可审计 / 可视化 / 多角色协作时弱
- Google ADK graph-based 押的是"企业级复杂工作流场景显式编排是对的"——这条赌注 2026 还没分胜负，但反映了行业从"单 agent + tool-calling"到"orchestrated 多 agent"转向
对中间层 agent 平台的具体含义（sentino-agent）：
- 当前 Sentino 是单 agent + 工具化集成 + Standalone Agent 数据生产者模式，没有显式 graph-based 子 agent 编排
- 选哪条路径要在客户场景需求明确后再定——但当前不必跟随 Google ADK graph 化
- 真要押多 agent 复杂协作时，要在三条路径中显式选择并标注理由，不要默认 graph 编排
相关概念¶
- harness-engineering — Harness 的多 Agent 部分：能力分区而非角色扮演，本项目是实战案例
- agent-tool-design — Agent 的工具就是文件系统和 Git，最朴素也最可靠
- seal-architecture — SEAL 是单 Agent 的事件循环，本概念是多 Agent 的协同模式
- observe-think-act-cycle — 多 Agent 协作里每个 Agent 内部都是 OTA 循环，无编排是协作维度的设计选择，不取代单 agent 内的 OTA
- google-agent-platform — Google ADK 2026 graph-based 子 agent 网络是反方向行业证据；三种 agent 复杂度管理路径并存
- amphiflow-pattern — 第三条路径：默认 workflow + agent 兜底，与本概念无编排和 ADK 显式编排并存