diff --git a/articles/orca.md b/articles/orca.md new file mode 100644 index 0000000..d969201 --- /dev/null +++ b/articles/orca.md @@ -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） + +--- + +本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`