Orkas的Commander如何拆解目标？完整拆解hand_off_to、dispatch_to、run

Orkas的Commander如何拆解目标？完整拆解hand_off_to、dispatch_to、run_worker三个调度动词的设计

【免费下载链接】OrkasOrkas is an open-source, local-first AI desktop app: a commander LLM directs specialist sub-agents, and runs your installed coding CLIs — Claude Code, Codex, OpenCode, OpenClaw, Hermes — as local sessions. Agents self-evolve via reflection and skill crystallization. BYO keys. macOS / Windows / Linux.项目地址: https://gitcode.com/gh_mirrors/or/Orkas

Orkas 是一款开源、本地优先的 AI 桌面应用：由 Commander（指挥官）LLM 负责拆解用户目标，并把任务分派给专业子 Agent 甚至本地编码 CLI（Claude Code、Codex 等）来执行。这篇文章带你彻底拆解 Orkas Commander 的三个核心调度动词 ——hand_off_to、dispatch_to、run_worker的设计思路，看懂它"为什么一个动词解决不了所有分派问题"。

为什么需要三个调度动词？

在多 Agent 协作里，"把活儿交给别人"其实有两种截然不同的结局：交出去自己还继续干活（结果要拿回来用），和交出去就收工（对方的答复就是最终答案）。如果只用一个dispatch动词，模型很难分清"我还要跟进"和"到此为止"的边界，容易在多轮循环里失控。

Orkas 的答案是把调度拆成三个动词，各自划定清晰的"责任边界"：

调度动词	是否终结回合	目标是谁	结果回给谁	可否并行
`hand_off_to`	✅ 是（直接结束 Commander 回合）	指定的命名 Agent	用户（Agent 的回复即答案）	❌ 不并行
`dispatch_to`	❌ 否（Commander 继续）	指定的命名 Agent	Commander（再消化、再综合）	✅ 可并行
`run_worker`	❌ 否（Commander 继续）	匿名临时 Worker	Commander（私有结果，无可见气泡）	✅ 可并行

三个工具的定义位于 tool-catalog.ts，实现则在 bus.ts 中。

hand_off_to：交接即收工，答案直接交付用户

hand_off_to是终结型委派（TERMINAL delegation）：当"剩余的、用户可见的产出"由某一个 Agent 完整拥有时，Commander 把整个剩余工作交给它，然后立刻结束自己的回合——目标 Agent 的可见回复就直接作为给用户的最终答案，Commander 不再追加综合总结。

它的设计要点很值得新手理解：

不与其他分派并行：代码注释明确写着"hand-off 是本轮刻意的最后一个动作"，因为它通过endTurn直接结束回合（bus.ts）；
执行契约极简：message字段只携带"动作、预期结果、验收标准、新约束"，历史上下文 Agent 本来就能看见，避免重复投喂；
失败可回滚：若 Agent 未能入队，Orkas 会回滚这次 hand-off 并提示 Commander 换用其他路径，而不是静默吞掉失败；
避免冗余气泡：由于答案已经在目标 Agent 的消息里，Commander 的空尾巴会被判定为"静默"，不会再多冒一条空消息（见 plan_executor.ts 的terminalDelivery策略）。

💡 简单记忆："谁拥有最终答案，就直接把话筒交给谁"—— 这就是 hand_off_to 的使用场景。

dispatch_to：派出去再收回，Commander 仍在回路

dispatch_to是非终结型委派：它运行一个命名 Agent，并把完整结果返还给 Commander，由 Commander 决定下一步 —— 继续调用其他工具、发起另一次分派，或把两个以上不同结果综合成一份产出。

它的两个工程细节让调度更稳：

并行安全：同一回合内多个相互独立的dispatch_to调用会并发执行，受workerSlots槽位上限约束，既快又不会打爆本地资源；
sync / async 双模式：sync等待完整结果；async只返回一张"入队回执"（任务 ID），结果稍后独立唤醒 Commander 做跟进 —— 当前回合可以先收尾，用户不必干等长任务。

官方给它的边界划得很死：只有当 Commander 必须消费这个结果去执行下一个动作、或综合至少两个不同结果时才允许用dispatch_to；"交付、格式化、审批、总结单个 Agent 结果"都不算 —— 那种情况应该用hand_off_to（bus.ts）。

上图正是dispatch_to的典型形态：指挥宫把"调研 5 家竞品 + 写报告 + 做 PPT"拆解后，按依赖顺序调度 3 个 Agent，每个 Agent 的产出回到指挥宫继续推进后续步骤。

run_worker：匿名临时 Worker，私有活儿的隔离舱

run_worker创建的是匿名的私有临时工作者：它没有会话历史、没有命名 Agent 的技能，只接受一个task字段（边界清晰、自包含的子任务），结果作为私有数据直接回给 Commander，不会在聊天里产生任何可见气泡。

适合的场景是：对一批独立输入做有边界的扫描、抽取、汇总等"体力活"。规则上同样卡得很严 —— 传入to参数会直接报错（它是 anonymous-only），需要共享演进上下文或耦合里程碑链的工作也不该交给它（bus.ts）。

⚠️ 新手常见误区：拿run_worker顶替不可用的命名 Agent，或让它干 Commander 该干的活。它的定位只是"一次性隔离算力"，不是万金油。

如何选对动词？一份决策速查表

Commander 的调度规则写在 chat_commander.md 提示词里，核心判定只有三条：

一个 Agent 独占剩余的全部用户可见产出→hand_off_to；
Commander 还要消费结果（再分派、再调工具、综合 ≥2 个结果） →dispatch_to；
边界清晰、自包含、可匿名处理的独立扫描→run_worker。

配套的"排序与恢复"规则同样重要：

相互独立的结果用并行的dispatch_to一次发出；有依赖的结果逐个串行，根据完整结果再决定下一步；
收到<worker-error>时，把结果视为失败或部分完成，从不重试已中止的运行，而是基于证据恢复；
"仅仅为了显得忙碌"而拆分任务是被明令禁止的 —— 任务小不构成多 Agent 的理由。

幕后：总线（Bus）如何保证调度不乱

三个动词只是模型侧的"语法"，真正的可靠性来自主进程里的群聊总线 bus.ts：

三个工具被统一登记为路由动词（ROUTING_TOOL_NAMES），由总线统一排队、限流与取消；
每个会话队列是FIFO，dispatch_to的异步结果与 Agent 完成通知都会走 Commander 既有队列串行投递，不会插队；
中止操作通过abort epoch（中止纪元）标记，防止旧的后台分派"诈尸"唤醒已取消的回合。

状态机与路由的其余部分可参考 state.ts、router.ts 与 task_board.ts。

写在最后

Orkas 的 Commander 把"拆目标"这件事做成了三个边界清晰的调度动词：hand_off_to管"交付即收工"，dispatch_to管"派出再收回"，run_worker管"匿名隔离扫描"。这种"用词法约束代替提示词玄学"的设计，正是本地多 Agent 编排能稳定落地的关键 —— 如果你也在做多 Agent 系统，这套动词设计非常值得一读。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析