速览

项	值
仓库	stablyai/orca
一句话	并行 agent 的 ADE（Agent Development Environment）——一条 prompt 扇出到 N 个 worktree，人工比对后择优合并
Star / Fork / Issues	58771 / 3987 / 5000 open（2026-09-01）
主语言 / 体积	TypeScript 97% / 671 MB
最新版本 / 节奏	v1.4.194 / 约一天一版
许可证	MIT（L1 · 真正开源，可自由再分发）
成熟度	原型期（高速迭代，治理欠账明显）

一句话结论：把「兼容面」做到极致、把「深度」和「治理」都停在草稿的并行编排外壳——广度是它的护城河，也是它最脆弱之处。

0. 先给结论

orca 的口号是 "the ADE for working with a fleet of parallel agents"——给"一群并行 agent"用的开发环境。它把 IDE 这个心智模型平移到 agent 运营上：不再盯一个终端里的一个 agent，而是同时开 N 个 agent 各干各的，最后人来做裁判。

它真正有意思的地方有三个：

1. 它赌"并行 fan-out"会成为重度开发者的主工作流。 与其让一个 agent 慢速跑到底，不如同一条 prompt 扇出给 Codex、Claude Code、OpenCode……各自在独立 git worktree 里改，跑完 diff 对比，人挑最好的 merge。这个"赛马"范式赌的是：单引擎不够强时，多引擎并行 + 人工择优，比押注单一引擎更稳。
2. 它用 PTY 把"兼容"做到了无差别。 不接协议、不解析结构化 tool call，只要"能在终端里跑"就兼容。代价是所有引擎都只拿到同一层最薄的能力；好处是兼容面瞬间铺到 30+ 家，比谁都广。
3. 它是真·MIT 开源，但商业化路径是空白。 没有企业版、没有订阅、不卖模型、不代买订阅。58k star 的体量配零营收，是个不稳定态。

而它最大的问题也有三个：接入深度全场最浅、issue 只进不出（5000 条）、巴士系数为 1。这三件事叠在一起，意味着它现在是"值得每天盯着看"，而不是"值得押注生产"。

1. 赛道定位：它站在哪一层

沿用本系列的分层法。判断一个 agent 项目，先判断它站在哪一层，以及它想往哪一层长：

┌──────────────────────────────────────────────────────────────┐
│  编排 / 工作台层                                              │
│  跨引擎、跨 worktree、跨交付物的调度与观测外壳                 │
│  ── orca 在这里（执行编排子层：扇出 + 比对 + 择优）──           │
├──────────────────────────────────────────────────────────────┤
│  编辑器内 Agent 层                                            │
│  嵌在 IDE / 编辑器里的交互层（Cline、Roo Code、Kilo Code 一类） │
├──────────────────────────────────────────────────────────────┤
│  执行引擎层                                                   │
│  真正跑 agent loop 的地方                                     │
│  Codex、Claude Code、OpenCode、Grok、Devin、Qwen Code ...     │
└──────────────────────────────────────────────────────────────┘

orca 明确站在编排层，并且明确声明不往下走。 它不 fork 任何引擎，不重写任何引擎的 agent loop，只通过 PTY 把任意 CLI agent 拉起来、塞进独立 worktree、把它们的输出并排展示。这是相当克制的站位——放弃了对执行层的任何控制，换来了"任何 agent 都能接"的合法性，也放弃了任何一家引擎的原生深度。

越往上，离引擎越远、离"运营 N 个 agent"这个动作越近。风险也一样明显：它依赖的每一层都可能向上长。一旦 Anthropic / OpenAI 的官方桌面端原生支持"并行 worktree + 结果比对"，orca 这层外壳的差异化立刻归零——因为它既没有独占的引擎，也没有独占的模型。

2. 业务维度：它靠什么活着（暂且，靠不靠都不靠）

目标用户是自称"100x builders"的重度个人开发者，以及需要在多套实现方案之间择优合并的小团队，核心画像是已经在重度用 Codex / Claude Code / OpenCode、只是想并行跑的人。orca 不是给"没用过 agent"的新手准备的——它的价值恰恰建立在"你手上已经有好几个引擎"这个前提上。

变现路径目前是空白。 这是它最大的商业不确定性，值得单独说：

• 许可证是 MIT，L1，可自由再分发。 没有企业版、没有订阅层、没有"3 人以上要授权"这类的门槛（对比 iPolloWork 的 source-available 协议，orca 在许可上干净得多）。
• 但也没有任何公开的营收路径。 README 明确写着 "Orca does not provide models, nor does it buy subscriptions for you"——不卖模型、不代买订阅，用户完全 BYO（自带各 agent 的订阅与额度）。

把这两件事放一起看：一个 58k star 的项目，许可全开、模型不碰、订阅不碰。它要么是"融资前先把生态和声量做起来"，要么是"后续会变更条款 / 加企业版"。参照 Redis、Terraform 的先例，MIT 今天不等于 MIT 永远。这不是许可证风险，而是商业模式空白本身就是风险。

护城河目前主要来自功能广度的组合：并行 worktree + 自研 WebGL 终端 + 移动端配对 + Design Mode，再叠加 30+ agent 的兼容面。功能广度能构成短期壁垒——别人要复刻这一整套得不少时间；但它不是结构性壁垒，因为它建立在"引擎会继续碎片化 + 官方不会自己下场做编排"这两个外部假设上。

3. 场景维度：它在什么场合被用

人机协作是强人在环。 orca 不是全自动，也不追求全自动——它要的是人做裁判：并行结果并排呈现、人工批注 diff、批准哪个合并。它的"人在环"比审批式（approval-gated）更进一步，是比对式（comparison-gated）：多个结果摆出来，人来择优。

有意思的副产品是：README 里那 5000 个 open issue，相当一部分本身就是 orca 在"用 AI 改进 orca"的痕迹——产品自身也在被它编排的 agent 自动改进（见第 6 节）。

三端形态，成熟度不对等：

典型用例三类：

• 一条 prompt 扇出给 5 个 agent，各自在独立 git worktree 里改，最后 diff 对比，挑一个 merge
• 开 Design Mode，点页面元素，把 HTML / CSS / 裁剪截图直接塞进 agent 的提示词
• 通勤路上用手机查看刚跑完的 agent 结果，追加一句 follow-up

交付物是 code、diff、review-comment——注意它是"产出 + 审查意见"，不是"成品文件"。这跟 iPolloWork 把 PPT / 网页 / 设计做成"生成后仍可编辑"的纵深是两条路：orca 的交付纵深停在代码层，靠的是数量（多方案）与比对，不是单交付物的可编辑性。

4. 技术维度：它怎么做到的

架构：一个 PTY 外壳

orca 的技术内核其实很薄，这也是理解它的关键：

┌─ orca 桌面 / 移动端 ──────────────────────────────────────┐
│                                                            │
│  一条 prompt ──扇出──> N × ( git worktree + PTY )         │
│                          │                                 │
│                          ├──> Codex        (在终端里跑)     │
│                          ├──> Claude Code  (在终端里跑)     │
│                          ├──> OpenCode     (在终端里跑)     │
│                          └──> ... 30+ 任意 CLI agent       │
│                                                            │
│  WebGL 终端分屏 + AI diff 批注 + 通知 / 未读态 + 用量追踪    │
│                                                            │
│  观测的是「agent 的输出与结果」，不是「内部执行轨迹」         │
└────────────────────────────────────────────────────────────┘

技术栈是标准的 Electron + React + TypeScript + Node.js，终端是自研 WebGL 渲染，iOS 伴随端用 Swift。它做的最难的事不是"接引擎"，而是把 N 个终端 + N 个 worktree + N 份 diff 在同一个 UI 里并排呈现得可用——这是一个纯前端工程量，不是协议工程。

引擎抽象：广度最大，深度最浅

这是全文技术上最该看清的一点。

一句话："完全对等，但对等在低处。" 30+ 引擎共享同一套 PTY 外壳，所以没有任何一家能拿到原生能力。

对照 iPolloWork 为 OpenCode 做的原生 Engine Protocol adapter——那能拿到结构化调用、权限回调、一致口径。orca 与任一单引擎的耦合都明显更浅。这不是缺陷，是它换取兼容广度的主动选择：你不可能既"无差别兼容 30 家"又"跟每家都有原生深度"，orca 选了前者。

多 agent：并行 worktree 编排

这是它的招牌能力：一条 prompt 扇出到 N 个独立 git worktree，每个 worktree 里一个 agent 各改各的，跑完把 diff 摆出来比对、择优合并。另有任务页与 CLI 编排能力。

用 git worktree 而不是多 clone，是懂行的选择——共享同一个 object store，磁盘开销小、切换快，天然契合"同仓库多方案并行"。

本地优先是真的，但要分清"本地"的含义

local_first: true 成立——agent 跑在用户本机（或用户自己的远程机上），代码不经过 orca 的服务器。但要说清"本地"的边界：这里的"本地"是agent 执行本地，不是"离线可用"。模型调用仍走各引擎的订阅（BYO），首次拉取引擎 CLI 也需要联网。

扩展体系：几乎为零

README 没有提及独立的 skills 体系、没有插件机制、也没有把 MCP 作为一等公民。orca 的能力边界 = 各 agent 自身生态的并集，它自己不加东西，只做调度与呈现。这跟"纯外壳"的站位是自洽的：它不抢引擎的活，自然也不用自己养一套扩展生态。

5. 横向对比

说明：下表项目均已收录进本系列追踪库，数据来自各自档案（data/projects/*.yaml，2026-09-01 快照）。"引擎中立度"取自档案 chart.engine_neutral（1–10），"接入深度"取自 risk.claim_vs_reality 的定性判断。

一句话概括 orca 在谱系里的位置：引擎中立度打满（9 分）、接入深度垫底的那一端。 iPolloWork（7 分）用"原生 adapter"换深度、让兼容面收窄一点；openwork（6 分）干脆不碰引擎、把能力做成可分发的层；orca 走的是另一条路——用"PTY 外壳"把中立度做到全场最高，代价是牺牲全部单引擎深度。三条都是"多引擎中立"的不同实现，但 orca 是把这个维度推到极限、在另一个维度上清零的极端样本。

6. 宣称 vs 实测

这一节是本系列最看重的部分。orca 项目方基本没说谎，但有几个数字，单独看会被误读。

① 宣称 / 数字：5000 个 open issue。 实际：抽样最近 100 条——全部创建于 2026-09-01 同一天，94% 无任何标签，标题是 fix(ssh) / refactor / fix(task-page) 等内部任务口吻；提交者 TOP3 为 nwparker(51)、OrcaWin(13)、klaidliadon(12)。它不是社区投诉积压，也不是 triage 压力，而是团队自开的任务待办板，且带明显 AI 批量生成痕迹（如 OrcaWin 提交的 "pty.spawn can leak a running agent process unboundedly: host holds the door open"）。它同样说明：这 5000 条从未被当作对外承诺来管理——只进不出。 来源：GitHub API /repos/stablyai/orca/issues?state=open，2026-09-01 抽样 100 条。

② 宣称：面向"100x builders"的多人协作成熟开发环境。 实际：巴士系数为 1。 最近 100 次提交中 nwparker 独占 79 次，第二名 AmethystLiang 仅 9 次。功能面由单人 + AI 高强度驱动，而非团队协作成果。"多 agent 并行"的产品，背后却是"单人在场"的维护结构。 来源：GitHub API /repos/stablyai/orca/commits?per_page=100，2026-09-01。

③ 宣称：支持 30+ 种 agent，生态最开放。 实际：兼容判据是"能在终端里跑"，靠 PTY 拉起而非协议对接。广度最大，但深度最浅——所有引擎都拿不到结构化 tool call 与统一权限回调。与 iPolloWork 为 OpenCode 做原生 adapter 相比，orca 与任一单引擎的耦合都更浅。 来源：README "Works with any CLI agent — if it runs in a terminal, it runs in Orca"。

④ 宣称：MIT 全开源，可放心用于生产。 实际：许可证本身无风险（L1，可再分发）。但项目没有任何公开的营收路径（无企业版、无订阅、不卖模型、不代买订阅）。58k star 的体量与零商业化不匹配，属于"要么即将融资、要么后续变更条款"的不稳定态——MIT 今天不等于 MIT 永远。 来源：README License 段；README 明确 "Orca does not provide models, nor does it buy subscriptions for you"。

⑤ 宣称：桌面 / 移动 / VPS 全覆盖。 实际：三端成熟度不对等。Android 仍是手工分发 APK（0.0.47）、iOS 走 App Store 与 TestFlight、VPS 场景需另查 headless Linux 指南。移动端实际是"监控与追加指令"的伴随形态，不是完整工作环境。 来源：README Install 段与 Mobile Companion 段。

第 ① 和 ② 两条合起来看，是理解 orca 工程治理的钥匙：58k star、一天一版、5000 条自开 issue、巴士系数为 1——这是一个"高速原型期"的典型画像，而不是"可托付生产期"。它迭代得快，是因为一个人（加 AI）在猛冲；它 issue 多，是因为把内部待办也堆到了 public issue 里。这两件事都说明它处在"跑通范式、还没建立治理"的阶段。

7. 结论：什么人该用它

该用： - 已经在重度使用 CLI agent、想同时跑多个方案横向比对择优合并的个人开发者与小团队 - 想在远程大机上并行跑 agent（SSH worktree）、并想在手机上监控 + 追加指令的人 - 看重"MIT 真开源、代码可自由再分发、不碰你的数据"、愿意接受原型期风险的早期尝鲜者

不该用： - 需要稳定 SLA、指望社区 triage 与多人维护保障的团队——巴士系数为 1，主力开发者一停，进度就停 - 指望它统一各引擎能力（结构化调用、统一权限回调、一致口径 token 统计）的架构选型者——PTY 外壳在结构上给不了这些 - 期待移动端完整工作环境的人——移动端是伴随形态，不是主环境 - 想要"MIT 永久不变"承诺的合规场景——零商业化下的 MIT 存在事后变更的现实可能

再看看： 等三件事落地再评估——① 巴士系数是否上升到 3 以上（出现第二梯队实质贡献者）② 是否从 PTY 外壳向上长出哪怕一个引擎的原生 adapter（验证它会不会往深走）③ 商业化路径是否浮出水面（融资 / 企业版 / 条款变更），以及那 5000 条 issue 是否开始被当作对外承诺来 triage。

8. 追踪备注

• 数据日期：2026-09-01（GitHub API 快照）
• 指标：★ 58771 / fork 3987 / open issues 5000 / subscribers 121 / 671 MB / TypeScript 97%
• 最新版本：v1.4.194，节奏约一天一版
• 源码镜像：gitinbox/orca（public，source-only 快照——本环境 github 的 git 端点被封，走 codeload tarball 路线，剔除非源码素材后 ~104 MB 裸仓，无完整历史）
• 结构化档案：data/projects/orca.yaml

下次跟进点：

1. 巴士系数：第二梯队贡献者是否出现（当前最近 100 提交中第二名仅 9 次）
2. 接入深度：是否从 PTY 外壳长出第一个原生 adapter，或引入结构化 tool call 解析
3. 商业化：融资 / 企业版 / 许可证条款是否变更（零营收 + 58k star 的不稳定态）
4. 治理：5000 条自开 issue 是否开始被当对外承诺管理（打标签、分派、triage）

_{本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar}