Orca 和 Emdash 属于同一类产品，共同主流程都是：
Issue/Prompt → 独立 Git Worktree → 启动 CLI Agent → 监控状态 → Review Diff/PR → 合并结果
两者都已经不只是"开几个终端"：都有任务隔离、Agent 状态、编辑器、浏览器、Diff/PR 和远程运行。Orca 最明确的差异不是功能更多，而是它把工作区、终端和协调状态开放成 Agent 可调用的 CLI，让 Coordinator Agent 可以显式创建并监督 Worker。这已经是真实可用的控制面，但还不是"输入一个目标，Orca 自己规划并完成所有并行协作"。
核实基准：Orca 公开仓库提交
02a1251c，2026-08-07。
orca是英语里的"虎鲸"，也叫 killer whale，项目图标同样采用虎鲸形象。官方 README、文档和仓库历史没有解释为什么选这个名字。"虎鲸以群体协作捕猎，象征多个 Agent 协作"可以作为产品联想。
Orca 到底做了什么
Orca 给用户提供四层能力。
1. 多任务隔离
每项工作可以放进独立 Worktree，绑定自己的 Git 分支、Agent 终端、Issue、Diff/PR、状态和父子工作区关系。
官方定位就是让多个 Agent 分别运行在独立 Worktree 中，并行处理任务或对同一 Prompt 赛马，再比较结果：README.md:L18-L20、README.md:L49-L57。
2. Agent 工作台
Orca 不实现自己的 Coding Agent，而是管理能在终端运行的现有 CLI，例如 Claude Code、Codex、OpenCode、Cursor 和 Copilot。
它提供持久终端、分屏、状态检测、账号与额度管理，以及重启后仍保留的 Scrollback。官方把兼容边界写得很宽："只要能在终端运行，就能在 Orca 运行"，见 README.md:L171-L180。
3. 开发闭环
Orca 把启动 Agent 前后的工作也收进桌面应用：
- 从 GitHub、Linear 任务创建 Worktree
- 内嵌编辑器、浏览器和文件预览
- Design Mode 将 DOM、CSS、截图交给 Agent
- 将 Diff 行评论发回 Agent
- 创建 PR、查看 CI、合并
- SSH 远程执行和端口转发
- 用手机查看 Agent 状态并继续发消息
这些能力可在 README.md:L35-L165 逐项核对。
4. Agent 可调用的控制面
Agent 不只被 Orca 托管，还可以通过 Orca CLI 控制开发环境。这个控制面分为两层：
| 层级 | 命令 | 作用 |
|---|---|---|
| 直接控制 | orca worktree ...、orca terminal ...、浏览器与文件命令 |
创建工作区、启动 Agent、发送输入、读取终端；每条命令只负责自己的直接动作 |
| 受监督协调 | orca orchestration ... |
在直接控制之上增加 Run、Task、Dispatch、消息、完成确认和结果回收 |
因此，Agent 控制 Orca 不等于使用 Orchestration。Orchestration 是控制面中的一个子系统，只在需要 Coordinator 持续监督 Worker 时使用。
一次不需要监督的普通委派可以直接创建 Worktree 并启动 Agent：
bash
orca worktree create \
--name login-fix \
--agent codex \
--prompt "修复登录超时并补测试"这条命令是 handoff，不是 Orchestration 。它返回新 Worktree 和 Agent Terminal handle，但不会创建 Run、Task 或 Dispatch，也不会注入 worker_done 协议。原 Agent 发出委派后可以结束；结果由人查看，或由后续调用通过 terminal read 主动读取。
worktree create 支持仓库、运行主机、Agent、Prompt、基线分支、Issue、父 Worktree 和初始化策略，见 core.ts:L86-L132。需要持续监督和自动回收结果时，才进入下一节的 Orchestration 流程：
bash
orca orchestration run-create
orca orchestration task-create
orca orchestration worker-start
orca orchestration check --waitOrca 的多 Agent 协作
普通模式不协作，实验性的 Orchestration 模式支持结构化协调。
普通模式：隔离并行
多个 Agent 分别在独立 Worktree 工作。它们可以处理不同任务，也可以对同一 Prompt 赛马，但默认不互相通信，仍由人比较、Review 和合并。
Orchestration 模式：Coordinator 监督 Worker
Orca 的协调层包含：
- Run：持久化命名空间和 Coordinator Inbox
- Task：任务、依赖和状态
- Dispatch：某个 Task 的一次执行
worker_done、Heartbeat、Escalation- 阻塞式 ask/reply
- Decision Gate
- 失败计数和熔断
- 本地或远程 Worker
数据模型包含 Run、Message、Task、Dispatch 和 Gate，并把 taskId + dispatchId 作为执行归属的一部分，见 types.ts:L1-L52、types.ts:L225-L303。
典型关系是：
text
用户
↓ 高层目标
Coordinator Agent
├─ Worker Agent A
├─ Worker Agent B
└─ Worker Agent C它属于 Coordinator-Worker 协作，不是开放、对等、能跨系统发现 Agent 的 A2A 协议。
结果怎么回到 Coordinator
Orca 不把"启动 Worker"和"等待 Worker 完成"做成一次长阻塞调用，而是拆成三层：
- 启动回执 ：
worker-start只等到 Worker 启动并进入ready，随后返回runId、taskId、dispatchId和创建资源。这里的ready表示可以工作，不是任务已经完成，见 handlers/orchestration.ts:L855-L910。 - 完成通知 ：Orca 给 Worker 注入一段协议，要求它结束时发送一次
worker_done，携带outcome、三句话摘要、修改文件和可选报告路径，见 preamble.ts:L60-L87。 - 结果读取 ：Coordinator 用
check --wait等待worker_done、escalation或question。收到摘要后，如果需要完整过程或长报告，再调用worker-read --dispatch <id>读取 Agent transcript；无法确认 transcript 时回退到终端输出，见 orchestration.ts:L80-L110、orchestration-worker-specs.ts:L42-L56。
text
Coordinator Orca Runtime Worker
│ worker-start │ │
├───────────────────────────────────>│ 创建终端并注入任务 ─────────────>│
│<──── ready + taskId + dispatchId ──┤ │
│ │ │ 执行任务
│ check --wait │ │
├───────────────────────────────────>│ │
│ │<──── worker_done + 摘要 ─────────┤
│<──── Delivery(worker_done) ─────────┤ 持久化 Task/Dispatch 结果 │
│ worker-read（按需） │ │
├───────────────────────────────────>│ │
│<──── transcript / terminal output ──┤ │所以这里确实有阻塞调用，但阻塞的是 check --wait 这次长轮询 ，不是 worker-start，更不是整个 Orca Runtime。check --wait 在匹配消息到达或超时后返回，并每 15 秒向 stderr 写 keepalive；超时只表示本轮没有消息，不表示 Worker 失败。Coordinator 可以继续发起下一轮等待。
此外还有三种非阻塞读取方式：
orchestration check：立即读取当前最早的一批未确认消息。orchestration check --peek/--all：查看消息而不消费。task-list、worker-show、worker-read：分别查询任务状态、Worker 状态和详细输出。
消息不是"读一次就丢"。Run 会保存 Delivery，在 Coordinator 显式传入 --ack <deliveryId> 前重复返回同一批消息，避免 Coordinator 崩溃或处理中断后丢结果。Worker 发出的有效 worker_done 还会把摘要、文件列表、报告路径和结果状态写入 Task/Dispatch，见 lifecycle-reconciliation.ts:L241-L304。
普通 worktree create --agent --prompt 属于另一种语义：它只做 handoff ，返回 Worktree 和 Agent Terminal handle，不建立 worker_done 协议，也不自动把结果送回原 Agent。需要结果时只能由人查看，或由后续 Agent 调用 terminal wait、terminal read 主动读取终端；terminal wait --for tui-idle 只能说明 TUI 暂时空闲，不能像 worker_done 一样证明业务任务成功。
一个重要限制
Orca 当前不会接收一个目标后自动拆解、选址并调度全部 Worker。
现在的推荐流程是：
- Coordinator Agent 拆解目标并创建 Run 和 Task；
- Coordinator 明确选择 Worktree、Agent 和并发方式；
worker-start创建或复用终端并记录 Dispatch；- Orca 持久化消息、状态、完成凭证和 Decision Gate；
- Coordinator 处理 Worker 结果并决定下一步。
bash
orca orchestration run-create --objective "修复登录问题"
orca orchestration task-create --spec "定位登录超时根因并补测试"
orca orchestration worker-start \
--task <task_id> \
--worktree new-child \
--name login-fix \
--agent codex
orca orchestration check \
--wait \
--types worker_done,escalation,question源码明确说明 Run "不会调度或放置 Worker"，worker-start 也要求调用方传入 Task、Worktree 和 Agent，见 orchestration.ts:L7-L14、orchestration-worker-specs.ts:L3-L39。
旧版的自动 Coordinator Loop 已退休。orchestration run、run-stop 现在不产生任何执行效果，只返回迁移提示，见 orchestration.ts:L207-L233、handlers/orchestration.ts:L1208-L1221。
因此，Orca 的价值是提供协调控制面和可靠状态，而不是内置一个会自主规划的"总管模型"。这套协调能力仍需在 Settings → Experimental 中启用，官方文档也标为 Experimental。
与 Emdash 的核心差别
| 维度 | Emdash | Orca |
|---|---|---|
| 共同底座 | Task + Worktree + CLI Agent + Review | Worktree + Terminal + CLI Agent + Review |
| 普通多 Agent | 隔离并行、人工汇总 | 隔离并行、人工汇总 |
| Agent 控制产品 | 公开能力以桌面 UI 和定时 Automation 为主 | Agent 可通过 CLI 操作 Worktree、Terminal、Browser 和协调状态 |
| 结构化协作 | 公开文档未见等价的 Run/Task/Dispatch 协议 | 有实验性的 Run、Task DAG、Dispatch、消息和 Gate |
| 浏览器与自动化 | 已有内嵌浏览器和定时任务 | 同样具备，并额外开放较完整的浏览器与 Computer Use CLI |
| 远程执行 | 支持 SSH 项目 | 支持 SSH、orca serve 和跨 Orca Server 的 Worker |
| 成熟边界 | 主流程仍以人管理 Task 为中心 | 普通工作台成熟，协调层仍是实验能力 |
浏览器、自动化和远程运行已经不是 Orca 独有能力。Emdash 当前也公开提供 独立 Worktree Task、内嵌浏览器 和 定时 Automation。