Agent 一多，真正费脑子的往往不是写代码，而是谁领任务、谁已完成、哪里需要人拍板。Orca 编排把拆分、派发、等待与汇总放进同一协调层，适合把并行工作从“多开窗口”升级为可跟踪流程。
一、编排解决什么问题
普通分屏让你同时看见多个终端，编排则描述多个 Agent 之间如何协作。它有四类核心对象：Message、Task、Dispatch 与 Decision gate。Message 可以是 status、dispatch、worker_done、escalation、decision_gate 或 heartbeat；Task 会处在 pending、ready、dispatched、completed、failed、blocked 之一；Dispatch 把 task 派给终端；Decision gate 则把必须拍板的问题变成阻塞式决策。
这套模型解决的是协调成本：任务有身份，派发有去向，worker 有完成信号，长任务有心跳，阻塞点能升级成提问或决策门。你不必靠记忆判断哪个窗口“可能已经做完”，而是按明确消息继续流程。
尤其在多个 worktree 并行时，终端数量本身并不等于协作。只有 task、dispatch 与消息对应起来，协调者才知道该等待什么：正常结束看 worker_done，需要上报问题看 escalation，必须选择方案则看 decision_gate。这也是编排和单纯分屏的根本差别。
二、开启编排（Settings → Experimental）
Orca 编排属于多 agent 协调层，需要先在 Settings → Experimental 开启。开启后再决定使用自动 fan-out，还是自己创建 task、worktree 与 dispatch。前者适合目标清楚、希望 Orca 自动分派的任务；后者适合你要掌控每个 worker 和检查点的流程。
无论选哪条路，都先明确当前 worktree。自动命令里的 --worktree active 就是在指定活动工作区；输出要交给脚本继续处理时保留 --json，并发上限则由命令中的 --max-concurrent 明确给出。
开启开关只是得到编排入口，不代表每件事都该自动拆分。先看任务是否需要多个 worker、是否要按 task 追踪，以及是否存在必须由人决定的分支，再选择 run 或手动派发。轻量旁观仍然可以留在 terminal send，不必为了形式把简单动作包装成完整任务。
三、自动 fan-out：一条 run 命令拆分并合并
最直接的入口是 orchestration run。下面这条命令把 checkout QA 拆给可用 Agent，收集各自结果，再汇总阻塞项；同时把最大并发设为 3，绑定活动 worktree，并返回 JSON。
orca orchestration run --spec "Split the checkout QA across available agents, collect results, summarize blockers." --max-concurrent 3 --worktree active --json这里的重点不是把一句 spec 写得很长，而是让目标同时包含拆分对象、希望收集的结果和最终汇总内容。Orca 负责自动 fan-out 与合并，你负责给出可判断的任务边界。并行上限写在命令里，方便脚本和操作者看到同一个约束。
命令中的 spec 原文同时写了三个动作：拆分 checkout QA、收集结果、汇总 blockers。这样的表达让自动编排不只负责把活发出去，也知道最后要收回来什么。--max-concurrent 3 则把本轮同时工作的数量限制为三，避免把“可用 Agent”误解成不受约束地全部启动。
四、手动派发：task-create → dispatch → check
需要控制每一步时，先创建 task，再为 worker 建 worktree，把 task 注入指定终端，最后等待关键消息。官方给出的完整顺序如下，占位符应替换为实际 taskId 和 handle。
orca orchestration task-create --task-title "..." --spec "..."
orca worktree create --name x --agent codex
orca orchestration dispatch --task <taskId> --to <handle> --inject
orca orchestration check --wait --types worker_done,escalation,decision_gate --timeout-ms 900000check 同时等待三类值得处理的消息：worker 完成、worker 升级问题、或流程到达决策门。900000 毫秒超时只表示来到检查点，不等于任务失败；此时应该读取当前状态，再决定继续等待还是处理阻塞，而不是直接把 task 标记为失败。
手动派发的优势是责任边界清楚：task 记录要做什么，worktree 隔离代码，Dispatch 记录派给谁，check 负责把控制权交还给协调者。任务较长时，worker 还应按合约发送 heartbeat，让外部知道它仍在工作。
把这四步逐一核对，会比一次执行到底更稳：task-create 先固定标题和 spec；worktree create 给 Codex 一个隔离工作区；dispatch 用 taskId、handle 与 inject 建立派发关系；check 只等待官方列出的三类关键消息。任一步信息不明确，都可以停在当前检查点，而不是继续向错误终端派活。
五、群组广播：@all / @idle / @codex
需要向一组终端发送同类消息时，可以使用群组地址。@all 面向全部，@idle 面向空闲项；还可按 agent 使用 @codex、@cursor、@grok、@droid，或按 worktree id 定位。
orca orchestration send --to @all@idle
@codex
@cursor
@grok
@droid
@worktree:<id>PowerShell 会把以 @ 开头的内容按自己的语法理解，因此群组地址必须加引号。参数要写成下面这样，别省略双引号。
--to "@all"广播适合发共享上下文或统一提醒，但它不替代 task 跟踪。只要你需要知道具体 worker 对哪项任务负责、何时完成，就应回到 dispatch 与 worker 合约。
并行越多越吃号，先把稳定可用的 Agent 账号准备好。
六、Worker 合约与决策门
Worker 合约的第一条是 worker_done 只发一次，并同时带 --task-id 与 --dispatch-id，这样完成消息才能对应到具体任务和派发记录。长任务发送 heartbeat；遇到无法自行解除的阻塞，则用下面的提问入口。
orca orchestration ask需要人在候选项中拍板时创建 Decision gate。它是阻塞式决策：问题、选项和所属 task 一起建立，得到结论后再解析对应 gate。下面两行保持官方文档中的命令形式。
orca orchestration gate-create --task <id> --question "..." --options '["yes","no"]'
gate-resolve --id <id> --resolution "yes"提问与决策门不要混为一谈：ask 用于 worker 报告阻塞并请求帮助；Decision gate 用于流程必须拿到明确选择才能继续的节点。前者暴露问题，后者记录结论。
合约最重要的是消息不含糊。完成只报一次，避免协调层把重复完成当成新进展；task-id 与 dispatch-id 同时存在，避免同名任务或不同派发互相串线；长任务用 heartbeat 表明仍在运行；真正卡住再 ask。到了需要明确选项的节点，才用 gate-create 建门并用 gate-resolve 写入结论。
七、三选一：terminal send vs dispatch vs run
只想轻量旁观或给现有终端补一句话，使用 terminal send；需要 worker 汇报、按 task 跟踪，使用 dispatch 加 inject；希望 Orca 自动分派和合并，使用 orchestration run。三者不是等级关系，而是协调强度不同。
orca terminal send --terminal <h> --text "continue" --enter
orca orchestration dispatch --task <taskId> --to <handle> --inject
orca orchestration run --spec "Split the checkout QA across available agents, collect results, summarize blockers." --max-concurrent 3 --worktree active --json一个实用判断法是看你是否需要“可追踪责任”。不需要，只是催一下终端，用 send；需要知道哪位 worker 对哪项 task 负责，用 dispatch；连拆分方式和结果汇总也希望交给 Orca，就用 run。这样选择，编排不会变成额外负担。
还可以再看结果由谁收口：terminal send 的结果仍由你旁观终端；dispatch 依靠 worker 消息与 check 回到协调者手里；run 则覆盖自动 fan-out 和合并。任务越复杂，越应该提前写清完成、升级与决策条件，而不是等多个 Agent 同时停下来后再临时判断。
延伸阅读
主题授权提示：请在后台主题设置-主题授权-激活主题的正版授权，授权购买：RiTheme官网
评论(0)