Orca（stablyai/orca）：把 git worktree 变成每个智能体的独立办公室，用 Run/Task/Dispatch 管住一支编码队伍

一、导读

当「一个人同时开五个编码智能体」从炫技变成日常，瓶颈就不再是模型能力，而是隔离：五个 agent 挤在同一个 checkout 上，文件互相覆盖、git 索引互相打架。Orca 的答案是把 git worktree 提升为编辑器第一公民——每个任务独占一份磁盘副本，再把「谁拥有这次改动、哪次尝试算数、工作何时落定」写成可被命令行的编排原语。它是 MIT 许可、macOS/Windows/Linux 全平台的开源 ADE（Agent Development Environment），支持 27 个以上 CLI 智能体以及任何能在终端里跑的东西。本文拆解它的三层共享路径机制、编排状态机、九条件休眠准入与五个可复现场景。

二、项目速览

项目	内容
仓库 / 团队	stablyai/orca · Stably AI（YC W22，据 YC 公司页与 agentconn 页面）
主语言	TypeScript（约 201 MB，占代码主体）
Star 总数 / 当日涨星	95,314 / +829（GitHub API 与 Trending 日榜，2026-10-17）
Fork / 未决 Issue	6,103 / 8,545
License	MIT（含 `cloud/` 目录）
首次发布	2026-03-17 创建；最新 Release v1.4.229（2026-10-17）
平台 / 智能体	桌面 macOS·Windows·Linux，移动 iOS+Android（beta）／官方列 27 个 agent，并声明「任何 CLI agent 都能跑」
核心构件	Electron 三进程 + `orca` CLI + `cloud/`（relay / push / fence-broker）+ 10 个内置技能

一句话概括：以 worktree 为隔离单位、以 typed inbox 为协调语义的智能体开发环境。

三、为什么是它：从「一个终端」到「一支队伍」

并行是免费的，隔离不是。 智能体的边际成本已被订阅制摊平——跑一个任务和跑五个在账单上差别不大。但一台机器跑五个 agent 立刻撞上物理约束：同一个 checkout 只有一个 HEAD。通行临时解法是「手动 git worktree add + 再开一个终端」，可 worktree 是干净 checkout，node_modules、.env.local 全不在，多数 agent 一构建就崩。Orca 把这件事工程化成三层共享路径机制（第 4.3 节），这是它区别于「VS Code 装个插件」的第一道坎。

多 agent 的失败模式是语义，不是算力。 五个 agent 同时干活时真正让人抓狂的是不知道谁在做什么、哪次尝试算数、哪份产物该被采纳。多数「fan out 一个 prompt」的工具是 fire-and-forget，撒出去 N 个然后祈祷。Orca 在实验性开关后塞了一套有名字的协调原语：Run、Task、Dispatch、Message、Decision gate。

桌面端做 AI 工具，长期成本藏在平台细节里。 仓库有 95 个 GitHub Actions 工作流，大半是平台性的：Windows 崩溃存活 e2e、WSL 端到端、macOS TCC 权限归属、AppImage 解包缓存、终端 IME 端到端。仅「macOS 上终端守护进程如何在应用更新后不丢磁盘权限」一个问题，就有一份 9,405 字节的专门文档。这说明它不是一个周末项目。涨星时点也有迹可循：2026 年 10 月中旬前后第三方「Orca vs Conductor」横向内容集中出现，同时 v1.4.22x 系列连续放出 native chat、共享技能等更新。

四、【重点】架构原理

4.1 整体架构：一个内核、两条入口、一个附属面

graph TB
    subgraph HOST["宿主进程 Electron 43"]
        M["src/main 主进程<br/>worktree / PTY / 浏览器 / orcad"]
        P["src/preload 桥"]
        R["src/renderer React 19 + Zustand<br/>xterm 终端 / 差异 / 标签页"]
        M --- P --- R
    end
    subgraph CLI["控制面 orca CLI"]
        C1["worktree / terminal / repo / reference"]
        C2["orchestration Run·Task·Dispatch·Message"]
        C3["computer 无障碍树控制 / browser 自动化"]
    end
    subgraph AG["被编排的 CLI 智能体"]
        A1["Claude Code / Codex / Grok / Gemini / Cursor / OpenCode / 任意 CLI"]
    end
    subgraph CLOUD["cloud/ 独立工作区"]
        RL["apps/relay 出站 WebSocket 中继 director / cell"]
        PS["apps/push APNs + FCM 网关"]
        FB["apps/relay-fence-broker IAM-only 变更租约"]
    end
    subgraph DISK["磁盘隔离单位"]
        W1["worktree A 独立分支+目录"]
        W2["worktree B ..."]
    end
    C1 --> W1
    C2 --> A1
    A1 --> W1
    A1 --> W2
    R --> C1
    R --> C2
    RL -.配对手机与桌面.-> M
    PS -.推送令牌.-> RL

仓库结构本身就是架构说明：根目录是 Electron 应用（src/main、src/renderer、src/preload、src/cli），cloud/ 是独立 pnpm 工作区（自带 Terraform 与 Cloud Run 部署工作流），skills/ 与 skill-guides/ 存 10 个内置技能。三层职责清晰：隔离层是磁盘上的 worktree 与其分支，一个 worktree 独占自己的 agent 终端、编辑器标签、浏览器标签；协调层是 orchestration 的五个原语，纯逻辑、不碰磁盘布局；远程层是 cloud/——手机和桌面从不直连，各自向中继 cell 开一条出站 WebSocket，由中继配对会话并拼接帧。三层解耦很干净：不开编排也能用 worktree，不用手机也能用编排。

4.2 分层模块拆解

主进程是唯一持有真实状态的地方：管理 worktree 生命周期、PTY、内嵌浏览器与 orcad（托管式 SSH 服务端，即 headless server）。这里有个值得单独说的安全设计：桌面端用 Electron safeStorage（操作系统钥匙串）封装凭据，但 headless 的 orcad 没有 Electron，于是在 src/main/orcad/orcad-secret-store.ts 里自实现 AES-256-GCM——主密钥首启生成，存于 ~/.orca/orcad-secret-store-<machine>.json，权限 0600，并与机器标识（/etc/machine-id、macOS 硬件 UUID、Windows MachineGuid）混合。文档解释了为何不用 macOS Keychain：只能通过 SSH 抵达的 Mac，重启后登录钥匙串是锁着的，凭据会一直读不出来，直到有人到屏幕前登录。

渲染进程是 Electron + React 19 + Zustand。更值得看的是工程纪律：29 个运行时依赖对 122 个开发依赖，脚本含 check:zustand-selector-fanout（状态选择器扇出检查）、lint:design-system、audit:perf 与 test:perf:contracts——性能契约与设计系统约束被 CI 强制。终端用 @xterm/xterm 6.1.0-beta，README 承诺滚动缓冲可跨重启存活。

orca CLI 是给 Agent 用的控制面。 skill-guides/orca-cli.md 的 description 直接告诉模型「当用户说 $orca-cli、『Orca worktree』、『handoff』时使用本技能」，并要求「优先用它而不是裸 git worktree、临时 PTY 或 Computer Use」。命令族按状态域划分：worktree、terminal、repo、reference、agent、automation、computer、browser、search、orchestration；几乎都支持 --json，指南写明「Prefer --json for agent-driven calls」。

cloud/ 是不该忽略的独立子系统。 apps/relay 同一镜像靠 ORCA_RELAY_ROLE 决定跑 director 还是 cell；apps/relay-fence-broker 是仅限 IAM 调用的私有服务，持有持久化变更租约与 Terraform checkout，调用它的工作流只有读与 invoke 权限，从不持有变更权限。推送链有个细节：手机从不持有注册用 Orca 凭据，桌面端用与 relay 相同的 X25519 密钥回答一次加密挑战换 24 小时会话。文档还坦承 FCM 通知在离线时可折叠、并发 collapse-key 预算很小，「每条待处理告警都被送达」并不被保证——把不可保证项写进文档，比宣称可靠性更有用。

技能面小而精。 skills/ 下 10 个，含 computer-use、orchestration、orca-cli、orca-emulator(-android)、orca-jira、orca-linear。它们不是「知识」，而是对这个 IDE 自身能力的操作手册——让被编排的 agent 也能操作 IDE 本身。

4.3 核心机制一：让干净 checkout 可用的三层共享路径

矛盾在于：worktree 的价值来自「干净、独立」，但 agent 需要的恰恰是 gitignore 掉的东西。Orca 用三层叠加解决，语义各不相同：

机制	位置	行为	典型用途
Worktree Shared Paths	Settings → Repository（每仓库每用户）	从主 checkout 物化：macOS 支持时用 APFS clone-copy，否则符号链接	个人机器上的通用依赖
`orca.yaml` 的 `worktree.sharedDirectories`	仓库内签入	以链接/共享方式落地（不复制）	团队约定的 `node_modules`、`.cache`
`.worktreeinclude`	仓库根目录	复制（不链接）到每个 worktree	`.env`、`.env.local`、`.vscode/settings.json`

合成规则有明确优先级：orca.yaml 条目追加到用户 Shared Paths，永不替换；已被 .worktreeinclude 复制过的路径不再共享。更关键的是只支持字面路径，glob 与取反会被跳过并警告——理由写在设计说明里：静默的 glob 展开，就是有一天把 ~/.ssh 复制进子智能体 worktree 的成因。用「功能更少」换「不会酿成事故」，值得同类工具抄。配套细节：worktree 创建对话框异步提交——点击后立即关闭，git fetch 与 git worktree add 后台继续，新 worktree 以进度行出现在侧边栏，期间你继续用 Orca。

4.4 核心机制二：Run / Task / Dispatch 与 typed inbox

编排层（仍标实验性，需在 Settings → Experimental 打开）的创新不在「并行」，而在把完成语义做成有权威来源的状态机。五个原语：

Run — 持久命名空间与主收件箱，从不调度、从不放置 worker。
Task — 工作项，含 spec、依赖与状态：pending / ready / dispatched / completed / failed / blocked。
Dispatch — 任务在某个终端上的一次尝试，是 worker_done 与 heartbeat 的生命周期权威。
Message — inbox 邮件，带类型：status、dispatch、worker_done、escalation、question、heartbeat。
Decision gate — 协调者持有的问题，阻塞任务直到决策被记录。

完成的权威来自「当前活跃的 dispatch 上下文」，因此 worker 的完成与心跳消息必须同时带 taskId 与 dispatchId——目的是让一次过期重试无法错误地完成另一次 dispatch。同理 worker_done 强制 --outcome succeeded|failed，缺参数直接报错，不存在隐式的「默认成功」路径。官方规范形式（可直接复现）：

# 1) 建 Run（命名空间+主收件箱）与 Task
orca orchestration run-create --objective "Split checkout QA and summarize blockers" --json
orca orchestration task-create --spec "Audit billing settings for mobile layout" \
    --task-title "Billing audit" --json

# 2) 起 worker：可复用当前 worktree，也可新建子 worktree 并指定 model / effort
orca orchestration worker-start --task <taskId> --worktree current --agent codex --json
orca orchestration worker-start --task <taskId> --worktree new-child \
    --name billing-audit --agent claude --model <opaque-model-id> --effort high --json

# 3) 等待：默认 check 是本 Run 最旧的未 ack Delivery（FIFO），处理完必须 --ack
orca orchestration check --wait --types worker_done,escalation,question \
    --timeout-ms 900000 --json
orca orchestration check --ack <deliveryId> --wait --types worker_done,escalation,question --json

Worker 侧对称：

orca orchestration send \
  --type worker_done --subject "Completed mobile audit" \
  --body "Fixed footer overlap; no follow-ups." \
  --task-id <taskId> --dispatch-id <dispatchId> \
  --outcome succeeded --files-modified "src/app/settings/Billing.tsx" --json

几个反直觉但重要的约束：worker_done 与 heartbeat 永远不能发到群组地址，只能指向具体 dispatch；群组地址只用于扇出（@all、@idle、@claude、@codex、@worktree:<id>）。Windows 上因 PowerShell 把单个 @ 当 splat 操作符，文档要求写成 --to "@all"。等待期间 CLI 每 15 秒向 stderr 输出一行小 JSON 心跳，stdout 保持为最终命令结果——为「把 stdout 直接管道给 jq」留路。失败恢复路径显式命名：release_pending、release_unknown、circuit_broken，文档明确禁止「用一条宽泛的 terminal close 替代 release」，必须按回执给的恢复动作走。另需注意：Run 持久，但调度不是——Run 只提供命名空间与收件箱，不提供 cron 触发；定时能力在 automations（v1.4.224 起可用 --extra-agent-args 指定模型与 effort）。

4.5 核心机制三：九条件休眠与可恢复会话

并行开到几十个 worktree 时，成本不在磁盘而在内存：每个空闲 agent 都是一条活 PTY，且往往还握着 20 万 token 的暖上下文。休眠策略是准入式的，以下条件全部成立才可能休眠：

agent 处于 done 状态（已结束上一轮、不在等输入）；
该终端不在活跃 worktree，也不在任何正渲染前台终端的 worktree；
agent 结束后没有再收到按键；
该 agent 属于可恢复会话那批：Claude、Codex、Gemini、Antigravity、OpenCode、Pi、MiMo Code、Droid、Grok、Devin、OMP；
空闲超过配置窗口（默认 30 分钟，范围 1 分钟至 24 小时）；
没有移动端会话正在驱动该终端；
没有未落定的 orchestration Dispatch（pending/dispatched/unknown）——只有运行时确认 completed、failed 或 circuit_broken 后才允许休眠；
该面板上没有存活的子智能体/队友名册（provider 报「done」而子进程仍挂着不算）；
若 worktree 有多个 agent 面板，它们作为整体一起休眠，以免出现「半暂停的 worktree 被发布」。

恢复保的是会话而不是面板：重开 worktree 时用与会话历史一致的 resume 参数重启 CLI（claude --resume <id>、codex resume <id>），对话、工作目录与 provider 会话原地接续，无需点击。若无法恢复（transcript 被删、provider 轮换 session id），终端回到全新提示符，但旧 transcript 仍保留在会话历史里。限制明确：Cursor CLI、Hermes、Copilot、Trae 等不可恢复终端不会被休眠，会一直跑着。

4.6 性能优化手段与设计取舍

取舍有一条一致主线：用「更少的隐式行为」换「更可预测的状态」。

共享路径不支持 glob → 代价是手动列路径，收益是不会意外大范围复制。
休眠是九条件准入而非计时器 → 代价是逻辑复杂，收益是不打断正在干活或被手机驱动的会话。
worker_done 强制 outcome、完成消息强制双 ID → 代价是调用方更啰嗦，收益是过期重试不污染状态。
心跳走 stderr、结果走 stdout → 代价是两路输出，收益是 JSON 管道不被污染。
headless 凭据自实现 AES-256-GCM 而非用系统钥匙串 → 代价是自管密钥（文档已说明计划后续把密钥留在客户端，如 VS Code 与 Zed 做法），收益是 SSH-only 机器重启后凭据仍可用。

平台层面同样如此。docs/reference/agent-browser-focus-isolation.md 记录了一条用实测数据支撑的铁律：agent 的浏览器输入只到达它目标的那一页，绝不移走用户键盘焦点、绝不落进用户正在输入的框里。文档给出的 Electron 43 实测表显示，CDP 的 Input.dispatchKeyEvent 在 <webview> guest 上会落到宿主的 textarea——即「agent 以为在给页面打字，其实打进了你的输入框」。这类只有在框架层量过才写得出的结论，是判断项目是否真在生产里跑过的可靠信号。

4.7 与其他架构路线的差异

最本质的分歧是「隔离单位」选了什么。

维度	Orca（worktree-native）	单体 IDE + 插件	云端 agent 平台	工作流框架（LangGraph 类）
隔离单位	每任务一个 git worktree + 分支	一个 checkout 下的会话/标签	远端沙箱（厂商托管）	进程内图节点
谁提供模型	自带订阅，不卖推理	插件配置	厂商模型	自行接入
协调语义	有类型的 Run/Task/Dispatch/Message	多为 fire-and-forget	平台 API	代码内定义 DAG
人机界面	桌面 + 移动 + CLI 三入口	主要是 IDE	Web 控制台	无界面
数据落点	本机为主（SSH/自有 VPS 可选）	本机	厂商云	自部署
主要弱点	编排层仍标实验性；长尾 agent 深度不一	worktree 需自行处理	数据出本地	面向开发者而非使用者

它的赌注可概括成一句：AI 时代的编辑器不是给人打字用的，而是给人「监督一支队伍」用的。

五、【重点】应用场景

前提：Orca 是桌面工具 + 一套 CLI，不是可托管产品；它不自带模型、不卖推理。官方口径是「bring your own subscription」——前提是你已有 Claude Code / Codex 之类的订阅或本地模型。

场景一：一个 prompt 扇出多个 agent，挑最好的合并

痛点。 面对边界模糊的重构（如「把结算页拆成可复用组件」），你不知道哪种拆法更好，靠一个 agent 一轮轮试，每次试错都要等它跑完、回滚、再重来。

做法。 用「Parallel Worktrees」把同一 prompt 扇到 N 个 agent，各占一个隔离 worktree。

orca worktree create --name split-billing-claude --no-parent --agent claude \
  --prompt "把 src/pages/Billing.tsx 拆成可复用组件，保持现有测试通过" --json
orca worktree create --name split-billing-codex --no-parent --agent codex \
  --prompt "把 src/pages/Billing.tsx 拆成可复用组件，保持现有测试通过" --json
orca worktree list --json

要点。 用 --no-parent 建独立顶层 worktree，除非明确要做堆叠分支；提交是异步的，创建后可继续干别的。比较时在应用内看差异，对任意 diff 行直接加注释回传给 agent（Annotate AI Diffs）；合并走应用内 GitHub PR 面板或本地 merge。

收益与指标。 官方定位是「fan one prompt across five agents, each in its own isolated git worktree」。官方定量 benchmark 未公开（待确认）；可自行度量的代理指标是「首版可评审时间」与「需人工重写行数」。第三方实测（aniketkarneai.com）记录的主要收益是等待时间被摊平：过去串行等两轮 refactor，现在并行推进、先完成的先审。

适用边界。 ①扇出成倍消耗订阅额度与 rate limit，单账号紧配额下扇 5 个很快撞上限——README 把「usage tracking 与 account switcher」当核心配套，正说明这是真实痛点。②高度耦合的任务不适用：需严格顺序的迁移（schema 先改、代码后改）扇出必冲突。③小改动不值得，多个 worktree 的磁盘与心智成本高于收益。

场景二：把 agent 放到远程算力机，人留在笔记本

痛点。 本地笔记本跑长构建太慢；但把开发体验整个搬到远程，又失去编辑器与评审的流畅度。

做法。 创建 worktree 时把目标从 Local 换成 SSH 主机：worktree 建在远端，agent 经 SSH 在远端运行，Orca 同步文件事件，编辑器/差异/浏览器保持本地感。

orca repo add --path /abs/repo --json
# 之后在 UI 里对任意 worktree 选择 SSH 执行主机
orca worktree create --name remote-build --agent codex --setup run --json

安全要点。 OpenSSH 集成有明确规格：主机密钥校验对照你有效的 known_hosts 与 Orca 曾保存的密钥；密钥变更、被吊销或类型意外不同，会在 Orca 询问密码或口令之前就被拒绝（避免「被中间人提示后交出凭据」）；默认启用连接复用，避免每条 setup 命令都付一次握手；口令仅存内存，关闭 Orca 即清除。

收益与边界。 收益是把 GPU 机/大内存机的算力与笔记本的编辑体验解耦；配合休眠，可挂 30 个远程 worktree 而只为真正在干活的那几个付内存。边界是官方明确标注 Remote Server 属实验特性、可能有 bug（v1.4.223 发布说明原文），跨网络高延迟会体现在终端手感上。

场景三：用编排层跑「有依赖关系的多任务」

痛点。 一次发布准备里既有可并行的事（审计计费页、更新文档），也有必须等结论才能做的决策（是否合并共享组件改动）。

做法。 用 Run + Task + Decision gate 表达依赖，用 check --wait 阻塞等待，用 gate-resolve 放行。

orca orchestration run-create --objective "Release 2.4 准备" --json
orca orchestration task-create --spec "审计移动端计费页布局" --task-title "Billing audit" --json
orca orchestration worker-start --task <billingTaskId> --worktree new-child \
  --name billing-audit --agent claude --model <model-id> --effort high --json
orca orchestration gate-create --task <docsTaskId> \
  --question "Merge the shared button change into the task branch?" \
  --options '["yes","no"]' --json
orca orchestration gate-resolve --id <gateId> --resolution "yes" --json
orca orchestration check --wait --types worker_done,escalation,question --timeout-ms 900000 --json
orca orchestration check --ack <deliveryId> --wait --types worker_done,escalation,question --json

收益与边界。 收益是「谁拥有这次改动、哪次尝试是权威、工作何时算落定」变成可查询状态；--files-modified 让 worker 完成后回报改了哪些文件，可直接作为评审入口。边界是编排层仍是实验特性，官方提示「标志名仍可能变动」，不建议放进无人工兜底的生产流水线；单次性任务用 orca terminal send 更轻。

场景四：把巡检写成定时自动化

痛点。 有些活不需要人盯着开工：每日依赖升级检查、每周回归、PR 队列清理。

做法。 用 automations（CLI 与应用内都可建），可对每次运行指定模型与 effort：

# v1.4.224 起支持在自动化里指定本次运行的模型与思考档位
orca automations create --extra-agent-args "-model haiku --effort high" ...
orca automations runs --json     # 查看历史运行

收益与边界。 收益是让「定时触发 → agent 干活 → 产出 diff 或报告」不依赖人起床，也可用低档模型跑巡检、高档模型跑复杂任务来控制成本。边界是官方定位为本地/自有机器上的定时，机器关机即不触发。

场景五：安全团队做「配置可信」与权限归因核查

痛点。 大规模铺开编码智能体时，平台组要回答的不是「能不能跑」，而是「它动了哪些文件、用了什么凭据、有没有越权」。

做法。 用三层现成能力拼出核查路径：

# ① 把需求挂到 worktree，让「这次改动对应哪个需求」可追溯
orca reference add https://github.com/acme/api/pull/5123 https://linear.app/acme/issue/STA-1234 \
  --worktree name:api --json
# ② 跨会话检索（可限定 agent / 时间窗 / 路径）
orca search "blank restore" --agent codex --since 2026-09-01T00:00:00Z --json
# ③ 检查可用性、权限与凭据落点
orca status --json
ls -l ~/.orca/orcad-secret-store-*.json      # 确认权限为 0600，勿外传内容

收益与边界。 收益是三个问题都有命令行答案：任务-代码映射（reference）、历史行为检索（search）、凭据落点与权限（0600 ACL）。边界必须说清：这是「本机可审计性」，不是企业级合规证据链——官方在对比材料中标的是「SOC 2 readiness」而非 SOC 2 Type II。它也没有消掉「agent 的行为风险」：computer-use 能驱动原生应用，browser 与 Design Mode 会读取真实页面并把 HTML/CSS/截图送进提示词，这两项都需额外的权限约束与审查。

六、快速上手

# 安装
brew install --cask stablyai/orca/orca     # macOS（Arch 用 yay -S stably-orca-bin）
# 第一次跑通
orca status --json                                     # 运行时与权限状态
orca repo add --path /abs/path/to/your-repo --json     # 登记仓库
orca worktree create --name first-task --no-parent --agent claude \
  --prompt "为 utils/date.ts 补齐单元测试" --setup run --json
orca worktree list --json
orca terminal list --worktree id:<repoId>::<worktreePath> --json

最小配置——仓库根目录放 orca.yaml（可签入、团队共享）与 .worktreeinclude（复制而非链接）：

worktree:
  sharedDirectories:
    - node_modules
    - .cache

.env
.env.local
.vscode/settings.json

注意：两处都只支持字面路径，写 glob 会被跳过并警告——这是刻意设计。让 agent 自己操作 Orca 则用 orca skills list --json 与 orca skills get orchestration --full。

七、横向对比

事实核对于 2026-10-17，来源为各项目官网、README 与第三方对比页（superset.sh 标注核对于 2026-10-13）。

对比项	Orca	Conductor	Superset	单体 IDE + agent 插件
许可与价格	MIT，完全免费	专有；Pro $50 月 / Teams $60 每人月	自有方案（含企业版）	通常免费或随 IDE
平台	macOS / Windows / Linux	仅 macOS（Win/Linux 候补）	macOS + 实验性 Linux	全平台
支持的 agent	27 个 + 任意 CLI agent	Claude Code、Codex、Cursor、OpenCode（4 个）	任意 CLI agent，内置 20+ 预设	视插件而定
隔离模型	每任务一个 worktree + 分支	workspace + 分支	每任务 worktree	通常无（同 checkout）
评审回路	行内 diff 注释回传 agent；应用内 GitHub/Linear	diff / checks / PR / merge / archive	提交、推送、开 PR、CI、行注释回传	依赖 IDE 与 Git 工具
远程与云	SSH worktree；Remote Server（beta）；`orca serve`	托管 Linux 沙箱（Pro 及以上）	自有机器或云 workspace	一般无
编排 / 移动端	Run/Task/Dispatch/Message/Decision gate（实验性）／iOS + Android APK（beta）	Routines（云端定时）／iOS（需 Pro）	MCP server + TS SDK + CLI + Slack bot／iPhone、iPad	无／无
企业能力	SOC 2 readiness，桌面与服务器可自托管	SAML、SCIM、SLA、SOC 2 Type II	SAML、SCIM	视 IDE

三点结论。第一，「免费 + 跨平台 + agent 覆盖最广」是 Orca 的清晰站位：Conductor 是打磨过的专有 Mac 应用，Superset 的差异点在「能被外部软件驱动（MCP/SDK/Slack）」，Orca 押的是开放与覆盖面。第二，云端取舍是方向性问题：Conductor 卖托管沙箱，Orca 让你用自己的机器或自有 VPS——前者省事、后者数据不出本地，取决于合规与信任模型，不是优劣。第三，企业级深度上 Orca 仍是追赶者：SAML、SCIM、SLA 与 SOC 2 Type II 这些项，对标产品已具备。

八、局限、风险与社区观察

第一，编排层实验性，且表面在动。 文档原文提示「命令面稳定到可以让技能基于它构建，但标志名仍可能变动」。发布说明里可见多条 fix(orchestration) 提交（如「own a worker terminal from creation, not after the boot wait」「fence worker release on mobile keystrokes」）——这正是抽象还在被塑造的证据。在每日一发节奏下，把实验层放进无人值守流水线需三思。

第二，agent 支持「广而不深」。 任何能在终端跑的 agent 都能跑，但深度不均：--model 与 --effort 官方支持 Claude、Codex、Muse、Cursor、Antigravity、OpenCode，Grok、Pi、Droid 等不支持。

第三，远程与移动端仍是 beta。 发布说明连续多版标注「Remote Server 是实验特性、可能有 bug」；移动端为 iOS + Android beta。

第四，凭据方案是过渡设计。 headless 的 orcad 自实现 AES-256-GCM 并自管主密钥于 ~/.orca/，文档明说后续预期把密钥留在客户端（如 VS Code 与 Zed 的做法）。当前方案在 SSH-only 机器上可用，但主密钥与被加密数据同机存放，威胁模型上等价于「保护目录权限」而非「硬件隔离」。

第五，社区信号偏正面但需交叉验证。 95,314 星、6,103 fork，但 8,545 个未决 issue 也是信号——快速迭代与 open issue 堆积是同一枚硬币两面。官网首页推荐语全部引用公开推文（含 Coinbase/Zora 前工程负责人等），但这是厂商挑选的正面引用，不构成独立评价。第三方评测在肯定的同时点出：编排的失败恢复路径文档仍偏薄。

第六，安全面在扩大。 computer-use 会驱动原生桌面应用（需辅助功能权限，macOS 还需屏幕录制权限）；browser 与 Design Mode 会读取真实页面并把内容送进 agent 提示词。仓库对这类边界处理相当认真——浏览器焦点隔离有一份带实测表的专门规则，明确「agent 输入绝不落到用户正在输入的地方」。但认真处理 ≠ 风险归零，把桌面控制权交给 agent 的组织需要额外约束。

九、小结与行动建议

Orca 的贡献不在于「让 agent 写得更快」——那是模型的事。它把并行编码智能体当成一个系统工程的隔离与协调问题来处理：用 git worktree 做隔离单位，用三层共享路径让干净 checkout 变得可用，用 Run/Task/Dispatch/Message 让「谁拥有这次改动、哪次尝试算数、工作何时落定」变成可查询状态，再用九条件准入的休眠把「挂 30 个 worktree」的内存成本压回可接受区间。

五条建议：

先验证隔离，再谈并行。 第一步不是扇出五个 agent，而是把 orca.yaml 的 sharedDirectories 与 .worktreeinclude 配好，确认新建 worktree 能直接通过构建与测试。这一步不做，后面每个并行任务都会以「依赖缺失/环境不一致」失败，而你会误以为是模型能力问题。
扇出只用于边界模糊的任务。 用它比较不同实现方案（重构拆法、UI 布局、命名策略），不要用它加速有严格顺序的迁移，同时盯住订阅配额与 rate limit。
编排层当成「有回执的协作规范」而不是流水线引擎。 立刻可用的是 run-create/task-create/worker-start/check --wait 这套监督循环；暂别放进无人值守 CI。
远程优先考虑 SSH worktree，而非把项目搬上云。 若诉求是「用 GPU 机算力、留笔记本体验」，SSH worktree + 休眠是当前最稳组合；Remote Server 仍标 beta，先自测再依赖。
把权限与凭据当成独立议题。 headless 凭据是自管密钥方案、computer-use 需要辅助功能权限、Design Mode 会把页面内容送进提示词——团队内铺开前先把这三条写进安全基线。

最后一个观察：这段时间的 GitHub 日榜前十里，编码智能体与其配套基建（插件目录、检索层、技能库、IDE）几乎占满。2026 年下半年开源竞争的主线，已从「模型有多强」迁移到「如何让人安全、可审计地同时指挥一支智能体队伍」。

资料来源（均抓取于 2026-10-17）：GitHub Trending 日榜与 GitHub REST API（仓库元数据、目录树、Release、Languages）；本仓库 README、package.json、skill-guides/orca-cli.md、skill-guides/orchestration.md、docs/reference/ 设计文档、cloud/README.md、95 个 GitHub Actions 工作流清单；Orca 官方文档 onorca.dev（orchestration、hibernation、CLI 页）；superset.sh 的 Orca vs Conductor 对比页；aniketkarneai.com 的 ADE 评测长文（2026-09-12）。未能独立核实的信息已在正文标注「待确认」。