多 Agent 协同编排

一个大任务拆成几块，开几个会话分头跑，这件事本身不难 —— 难的是谁来盯。

你得守在屏幕前，等 A 跑完去看一眼，不满意就让它返工，满意再把结果喂给 B。人一走开，整条流水线就停了。

如果让一个 AI 会话来当这个「工头」呢？它拆任务、派活、验收、驳回，全程不用你在场。

AICoder 的协同编排就是这个：一个总控会话 + 若干工作会话，总控通过 MCP 工具指挥其它会话，你只在开头确认方案、结尾看结果。

为什么不是轮询

让总控「每隔一会儿去问问好了没」是最直觉的做法，但它在真实任务里跑不通：

做法	代价
轮询「好了吗」	一小时几百轮完整推理，全烧在看进度上；几小时后总控的编排计划会被上下文压缩（compact）挤掉
事件唤醒	总控派完活就真的停下（会话空闲、零 token 消耗），工作会话跑完时由 AICoder 主动唤醒它

事件唤醒的消耗只跟真实事件数有关，跟等待时长无关 —— 派 3 个活就醒 3 次，等 10 分钟和等 3 小时的花费完全一样。

  总控会话                          工作会话 A / B / C
     │
     │ ① start_agent_session 派活 ──────► 开始跑
     │
     │ ② watch_session 登记等待
     │
     ▼
   ┌─────┐                              (跑了很久……)
   │ 空闲 │  零 token 消耗
   │     │
   └─────┘                                    │
     ▲                                        │ 跑完
     │  ③ [AGENT-EVENT] 注入输入框并回车 ◄────┘
     │
     │ ④ 读产出 → 裁决 → 驳回或派下一步
     ▼

四个编排工具

总控通过这四个 MCP 工具指挥全场（需先在设置里接入 AICoder 的 MCP 服务，见让外部 AI 接入 AICoder）：

工具	作用	关键点
`start_agent_session`	新开一个会话并派活	返回 `sessionId`，后续所有指令都认这个 id
`send_to_session`	往已在跑的会话追加指令	驳回返工走这条，对方上下文不丢
`watch_session`	登记「被盯的会话跑完就叫醒我」	一次性，每轮派完活都要重新登记
`get_session_status`	查一批会话此刻在干什么	派活前确认目标还活着

派活：start_agent_session

新建会话、开 Tab、启动真实 CLI、把提示词喂进去并回车，一步到位。可以指定工作目录、provider（Claude Code / Codex / Gemini / OpenCode 等）、模型。要并行跑多个模块就多次调用。

它返回的 sessionId 是后续一切操作的凭据。早期版本只返回标题，编排方只能按标题去模糊匹配 —— 并行开多个会话时标题可能重名，必然认错。

追加指令：send_to_session

驳回返工必须走这条，不能新开会话：新开等于让对方从头再来，之前积累的上下文全丢。

语义是排队而非立即送达：消息排进目标会话的任务队列，等它当前这轮答完、终端回到空闲才自动发出。目标在长作业时可能要等几分钟，不是没生效。

登记等待：watch_session

派完活后必须调它，然后就停下别动。

参数	说明
`watch_session_ids`	要盯的会话 id 数组，最多 20 个
`notify_session_id`	唤醒谁（总控自己的会话 id）
`timeout_min`	超时分钟数，默认 60；到点没完成会推 `timeout` 事件
`label`	这批等待的名字，唤醒时回显，便于认出是哪一步

watcher 是一次性的：触发即失效。所以每次醒来派完新活都要重新登记，否则下一轮永远等不到。超时、被盯会话被关掉也会推事件，不会让总控无声干等。

唤醒事件刻意不带产出摘要 —— 总控必须自己去读原文再裁决。因为可得的摘要源都不可靠（终端画面是 TUI 差分渲染后的残留，最后一条消息可能滞后好几轮），给一份不准的摘要会让总控基于错误信息做判断，比不给更糟。

查看状态：get_session_status

状态	含义
`running`	正在回答（此刻发指令会排队等它答完）
`idle`	空闲，可接指令
`dead`	没有打开的 Tab，收不到指令，需先重新打开会话
`unknown`	主窗口没运行，拿不到运行态

返回里还有 queued（排队未发出的消息数）和 paused（队列是否被暂停，如余额不足）。

这是只读查询，用来「派活前确认目标还活着」或「被唤醒后确认还有几个没回来」，不能拿它写轮询循环 —— 那正是事件唤醒要消灭的做法。

怎么用起来

有两个现成入口，不用自己从零写提示词：

入口	位置	适合
新建会话模板	新建会话弹窗 → 模板选「协同编排」	固定入口，开箱即用
编排配方片段	⚡ 指令面板 → 「协同编排」	带，填任务目标 / 验收标准 / 模型分工，可复制改成自己的配方

片段版会弹出变量填写框，逐项填完再注入终端：

变量	填什么
任务目标	这次要做成什么
工作目录	项目根目录绝对路径
验收标准	怎样算通过
实现模型 / 验收模型	分别用哪个 provider 和模型，可以让不同模型互相把关
最大驳回轮次	同一步驳回几次仍不过就停下汇报，避免无限重试

模板选中后可以就地编辑再发出 —— 改过之后旁边会出现「还原模板」。

配方里的关键约定

内置配方不只是提示词，其中几条是可靠性的关键：

派完活必须登记等待然后停下，不许轮询 —— 否则烧 token，且编排计划会被上下文压缩挤掉
每次醒来先读 state.json 确认自己在哪一步 —— 总控的上下文可能已被压缩，编排计划只有落盘（<工作目录>/.agent-pipeline/state.json）才不会丢
驳回走追加指令，不新开会话 —— 保住对方的上下文
超过最大驳回轮次就停下汇报，不无限自动重试

派给子会话的任务书也有固定要求：只做指定那一步、答完停下回报、范围写死、结论区分「实测」与「未验证」、允许否决（查下来不该做就给建议否决，不为了有产出硬做）、长任务分批跑。

注意事项

事项	说明
总控自己也是一个会话	它需要知道自己的会话 id 才能登记唤醒
工作会话的 Tab 要开着	已关闭的会话收不到追加指令
默认全自动	派出去的会话按 provider 注入跳过权限确认的标志，自己跑到底。仅用于可信任务
主窗口要运行	AICoder 主窗口关闭时无法新建会话，也拿不到运行态

多 Agent 协同编排 ​

为什么不是轮询 ​

四个编排工具 ​

派活：start_agent_session ​

追加指令：send_to_session ​

登记等待：watch_session ​

查看状态：get_session_status ​

怎么用起来 ​

配方里的关键约定 ​

注意事项 ​

相关章节 ​