docs(article): 补 orca 独立深度文
基于 data/projects/orca.yaml 档案成文，沿用 iPolloWork 深度文八段结构： 速览/先给结论/赛道定位/业务/场景/技术/横评/宣称vs实测/谁该用/追踪备注。 核心论点：orca 是引擎中立度打满（chart.engine_neutral=9，全场最高）、 接入深度垫底（PTY 外壳，无结构化 tool call）的极端样本；58k star 配零商业化、 巴士系数为 1、5000 条自开 issue，属「高速原型期」而非可托付生产期。 横评表数据已从六个样本档案逐项核对（许可证/成熟度/中立度分）。 emlog 未发布（article.emlog_id 仍为 0），待审阅后再发。
This commit is contained in:
gitea-publish
@@ -0,0 +1,233 @@
|
||||
# orca 深度拆解：兼容面最广的并行 agent 编排外壳
|
||||
|
||||
> **速览**
|
||||
>
|
||||
> | 项 | 值 |
|
||||
> | --- | --- |
|
||||
> | 仓库 | [stablyai/orca](https://github.com/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 项目，先判断它站在哪一层，以及它想往哪一层长：
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ 编排 / 工作台层 │
|
||||
│ 跨引擎、跨 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 节）。
|
||||
|
||||
**三端形态，成熟度不对等：**
|
||||
|
||||
| 形态 | 定位 | 成熟度 |
|
||||
| --- | --- | --- |
|
||||
| 桌面应用 | 主工作环境：并行 worktree + 分屏 + diff 比对 | 最成熟，一天一版 |
|
||||
| 移动端伴随 | **监控 + 追加指令**，不是完整工作环境 | iOS 走 App Store / TestFlight；Android 仍是手工分发 APK（0.0.47） |
|
||||
| CLI / SSH 远程 | 在远程大机上跑 agent（SSH worktree） | 可用，但 headless Linux 需另查指南 |
|
||||
|
||||
**典型用例三类：**
|
||||
|
||||
- 一条 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 的技术内核其实很薄，这也是理解它的关键：
|
||||
|
||||
```text
|
||||
┌─ 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 里并排呈现得可用**——这是一个纯前端工程量，不是协议工程。
|
||||
|
||||
### 引擎抽象：广度最大，深度最浅
|
||||
|
||||
这是全文技术上最该看清的一点。
|
||||
|
||||
| 维度 | orca 的做法 |
|
||||
| --- | --- |
|
||||
| 兼容判据 | **"能在终端里跑"即兼容**——通过 PTY 拉起任意 CLI agent |
|
||||
| 抽象层 | **无统一抽象层**；实际是终端 PTY + 约定式输出解析 |
|
||||
| 结构化 tool call | **拿不到**——只解析终端约定式输出 |
|
||||
| 统一权限回调 | **拿不到**——Computer Use / SSH 等高权限面无统一越界审批 |
|
||||
| 一致口径 token 统计 | **拿不到**——各家引擎自报口径不一 |
|
||||
| 兼容面 | 30+ 家：Codex、Claude Code、OpenCode、Grok、Cursor、Devin、Goose、Cline、Kimi、Kiro、Qwen Code、Rovo Dev、oh-my-pi ... |
|
||||
|
||||
一句话：**"完全对等，但对等在低处。"** 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 | iPolloWork | openwork | Tutti | QwenPaw |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 站位层次 | 执行编排层（并行 fan-out） | 桌面工作台层 | 能力分发层 | 多人×多 agent 协作层 | 个人助理执行层 |
|
||||
| 引擎中立度（1–10） | **9（全场最高）** | 7 | 6 | 8 | 2 |
|
||||
| 引擎接入深度 | **最浅**（PTY，无结构化调用） | 深但不齐整（OpenCode/DSH 深、Codex 仅控制面） | 中（MCP / 控制面） | 高，但偏袒 Codex（17× 差距） | 深（绑定单引擎） |
|
||||
| 差异化核心 | 并行 + 比对择优 | 交付物生成后可编辑 | 把"能力"做成产品 | 多 agent 共享上下文接力 | 安全默认值 + 健康治理 |
|
||||
| 许可证 | MIT（L1） | L3 source-available | L3 source-available | Apache-2.0（L1） | Apache-2.0（L1） |
|
||||
| 成熟度 | 原型期（一天一版） | beta（v0.50.x） | 0.x 活跃（工程治理最好） | 快速成长期（发布纪律最好） | beta 活跃（治理最健康） |
|
||||
|
||||
一句话概括 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）
|
||||
|
||||
---
|
||||
|
||||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
|
||||
Reference in New Issue
Block a user