多智能体协作：从入门到分工调查
米其林后厨建立直觉 → @Russell3402 四平台硬核调查 → @thinkszyg 并行 Plan 编程实战。
开篇：米其林后厨讲清 Agent Teams
先建立直觉。以下来自 @aehyok 的"三分钟大白话"系列（2026-03-27）：全文用米其林餐厅后厨讲清多智能体协作。
背景铺垫两个前置概念：Agent Skills ＝ 给 Agent 换更好的工具；SubAgent ＝ 主 Agent 的帮手，做完单独任务回来汇报，中间不沟通。
Agent Team 是什么
一句话："AI 小队合作干活"——一个统筹的 AI（队长 / 总厨）带几个分工不同的 AI（队员 / 厨师），随时沟通协作。队长负责分配任务、看进度、提醒配合、整理结果；队员各负责自己擅长的一部分（备菜 / 主菜 / 摆盘 / 甜点）。
SubAgent 是"单独叫个帮手"：你让帮厨去切菜，他切完端回来，中间不说话。Agent Team 是"组了个后厨班子"：总厨盯全场，备菜的切完喊一声，炒菜的接上，摆盘的随时问"这道先上吗"——"会吵架"（随时沟通）才是真团队。
什么时候用 Team，什么时候不用
适合：复杂、可拆分、需要多角度思考、需要互相沟通的任务。不适合：任务太小太简单、必须串行、多人容易打架——这时 SubAgent 或单 Agent 更好。
7 个现实问题（@aehyok 原文列出）
- 人多协调复杂（组织成本）；
- 更费资源（token 成本）；
- 重复劳动（职责边界不清）；
- 沟通误会（任务说明不清）；
- 小任务不值得；
- 同时改同一处会冲突；
- 团队不永远比单人聪明。
硬核调查：触发四类、拓扑七种、调用链八环
直觉有了，上硬菜。以下来自 @Russell3402 的工程调查（2026-05-18，作者自述"很硬很干，偏工程"）：从触发、拓扑、调用链三个维度，横评 Codex / Claude Code / OpenClaw / Hermes 的多智能体分工机制。
触发四类：谁决定派活
| 触发方式 | 机制 | 代表 |
|---|---|---|
| 显式触发 | 用户明说 "use parallel subagents" | Codex 为主 |
| 语义触发 | 按 subagent description 匹配 | Claude Code 普通 subagent |
| 路由触发 | 按 channel / account / thread / peer 入口选 agent | OpenClaw |
| 队列触发 | board / queue / cron / dispatcher 拉起 worker | Hermes Kanban |
拓扑七种：活怎么组织
默认选项：需求模糊 / 小改动 / 强依赖时最稳。先问"单 agent 能否做"，能就别拆。
Codex / Claude / Hermes delegate_task 都用。缺点：worker 不能互纠错，冲突全压到主 agent merge。
强顺序任务，一步接一步。
大任务分层拆解，须严控 depth 与并发。
多假设问题互相挑战；代价是消息 / 上下文 / 协调成本。
多入口常驻系统。
长期协作：任务 / 评论 / handoff 落持久存储。
调用链八环：活在每一步经历什么
input event → router / dispatcher → context builder → worker profile selection → execution sandbox → state store → merge / reduce → final output。
谁有权建 worker？给多少上下文？能否写文件？失败、超时、中断如何恢复？谁做 merge、谁担责？
@Russell3402 的断言："很多 demo 漂亮是因为跳过了 merge 难题——merge 才是多智能体成败的地方。"
四平台横评与场景选型
以下仍来自 @Russell3402 的调查，四家逐个拆：
默认克制，不自动 fan-out（"深入分析一下"被理解为质量要求，而非并行授权）；星型拓扑；内置 agent 类型 explorer（只读）/ worker（限 ownership）/ default；自定义 agent 放 .codex/agents/ TOML；护栏 agents.max_threads 与 agents.max_depth。
L1 普通 subagent：description 即路由规则，"写得像触发条件，不像愿望"；L2 Agent Teams（实验功能默认关闭）：lead ＋ teammates 共享任务列表、可互通信，适合多假设问题但成本高、需明确 ownership；L3 Agent View / worktrees / batch：人类调度台、文件隔离、大规模机械重构按文件边界拆而非按角色拆。
Routing layer（入口绑定选 agent）→ Agent isolation layer（workspace / agentDir / session store / 工具策略隔离）→ Execution layer（native background subagent 或 ACP 接外部 harness）。本质是"agent 操作系统 / 消息网关"而非单次 coding 并行器；maxSpawnDepth 默认 1。
delegate_task（短任务 RPC：临时 child、父等结果、状态在本轮；并发默认 3、leaf 默认不可再 delegate、"subagents know nothing"故 context 必须写全）vs Kanban（长任务 durable queue：持久 task、worker 接力、状态在 board、支持 block / retry / 等人类）。"短任务上 Kanban 显笨重，长任务用 delegate_task 会丢状态。"
五个场景怎么选
| 场景 | 选型 |
|---|---|
| PR review | 星型，只读 worker |
| 生产登录故障 | 先只读并行定位，再单 worker 写 patch；team 适合互相挑战假设 |
| 多渠道个人助理 | OpenClaw 主场：入口隔离优先 |
| 两天调研报告 | Kanban ＋ 局部 delegate_task |
| repo-wide migration | worktree ＋ batch，按文件边界拆 |
① 单 agent 能否做 → ② 主上下文是否被污染 → ③ 子任务能否独立 → ④ 结果是否本轮返回 → ⑤ worker 是否需互挑战 → ⑥ 是否并行写文件（先写 ownership）→ ⑦ 是否需入口隔离 → ⑧ 失败如何恢复。
委派合同、反模式与金句
Delegation contract 模板（@Russell3402）
"委派信息就是需求文档"——派活时一次写清八项：
Role / Goal / Context / Allowed actions / Ownership / Forbidden actions / Output format / Stop condition即：上下文、权限、边界、输出和收口。
Delegation contract 就像包工头派活的施工单：干什么（Role/Goal）、图纸在哪（Context）、能动哪些墙（Allowed/Ownership）、哪些绝对不能碰（Forbidden）、交工什么样（Output format）、什么时候算完（Stop condition）。没有施工单的工地，就是多智能体的"重复劳动＋互相冲突"现场。
七个反模式
- 拿复杂度当触发器；
- 不给 delegation contract；
- 多 worker 写同一片代码；
- 无 reducer；
- 短任务队列化 / 长任务 RPC 化；
- 权限过宽；
- 无观测审计。
编程实战：复杂需求先并行出 Plan
理论收束到实战。以下来自 @thinkszyg（2026-06-02）：复杂需求先让 Claude Code / Codex / Cursor 并行出 Plan 再执行。
痛点："需求想一半就丢给 AI 写代码，结果方案目标错了，只能删代码回滚重来"——"AI 编程最浪费时间的是浮躁心态。"
基础做法：三终端并行 Plan
开三个终端窗口，同一需求、同一背景、同一约束、同一目标，分别丢给 Claude Code / Codex / Cursor（Composer 2.5），只让出 Plan，不许写代码。
可复制 prompt："请先不要写代码。阅读当前项目结构后，给我一个实现方案……"（含：改哪些文件 / 为什么 / 复用现有模块 / 边界情况 / 执行步骤 / 最大风险）。
四维度对比选优
- 是否乱动文件（大重构＝高风险）；
- 是否复用现有模块；
- 有无边界情况（权限 / 缓存 / 迁移 / 回滚 / 兼容 / 测试入口）；
- 步骤是否可执行。
可以融合：如 Codex 架构判断 ＋ Claude Code 执行。实操案例：给 FastAPI 项目加 JWT＋RBAC 权限系统——并行出 Plan → 人工四维度对比 → 选最优方案＋最顺手工具执行。
开源项目 drivelineresearch/moa-x：Layer 0 Claude Opus 派发 → Layer 1 Codex / Gemini / Sonnet 各写方案 → Layer 2 交叉审阅 → Layer 3 Opus 汇总终版 Plan。适合屎山代码、老项目。
开源项目 am-will/swarms：任务显式声明依赖，按 Wave 执行（Wave 1 无依赖先并行 → Wave 2 等前序 → ……）。"AI 并行不是一堆 Agent 同时瞎搞，而是先把依赖讲清楚。"
Claude Code 创始人极限工作流：5 个 iTerm2 Tab 各跑一个 Claude Opus（测试 / 重构 / 文档 / ……），系统通知自动报告。普通人可学的两点：大模型用在 Plan 阶段、把犯过的错写进 CLAUDE.md / AGENTS.md 项目记忆。
三个必须避免
- Plan 阶段不许写代码；
- 小需求别并行（"钱多"）；
- 三份输入的上下文必须一致。
经验谈：Claude Code 顺现有项目结构（适合多文件重构）、Codex 擅工程实践与任务编排（适合先拆解）、Cursor 贴编辑器（适合看改动路径）。
术语翻卡：点卡片看解释
自测一下：点问题展开参考答案
SubAgent 是"单独叫个助手"：做完汇报，中间无沟通；Agent Teams 是"组工作小组"：自己分工、互相商量、彼此提醒、组长收尾。用后厨比喻：帮厨切完菜端回来 vs 总厨带班子随时沟通。
触发：显式触发（Codex）、语义触发（Claude Code）、路由触发（OpenClaw）、队列触发（Hermes Kanban）。拓扑：单 agent、星型 fan-out/fan-in、链式 pipeline、树型、网状 team、Gateway routing、Durable board。
很多 demo 漂亮是因为跳过了 merge 难题。星型拓扑下 worker 不能互纠错，冲突全压到主 agent 合并；调用链八环里"谁做 merge、谁担责"是最难的工程问题。
三终端同一需求/背景/约束/目标，分别让 Claude Code / Codex / Cursor 只出 Plan 不许写代码。四维度：是否乱动文件、是否复用现有模块、有无边界情况、步骤是否可执行；可融合（如 Codex 架构判断＋Claude Code 执行）。
Role / Goal / Context / Allowed actions / Ownership / Forbidden actions / Output format / Stop condition——即上下文、权限、边界、输出和收口。