# 四个 Agent 工作台的路线分野：把「多引擎中立」拆开看 > **速览** > | 项 | iPolloWork | OpenWork | Orca | Maka | > | --- | --- | --- | --- | --- | > | 仓库 | Devin-AXIS/iPolloWork | different-ai/openwork | stablyai/orca | apache/maka | > | Star | 5,201 | 23,253 | 58,771 | 4,373 | > | Fork / Issues | 976 / 80 | 2,307 / 414 | 3,987 / 5,000 | 406 / 398 | > | 主语言 | TypeScript 49.5% | TypeScript 89.9% | TypeScript 97.0% | TypeScript 91.7% | > | 仓库体积 | 591 MB | 291 MB | 671 MB | 100 MB | > | 最新版本 | v0.50.12 | v0.18.40 | v1.4.194 | v0.2.0-dev.9 | > | 许可证 | Source Available（L3） | MIT + EE 切分（L3） | MIT（L1） | Apache-2.0（L1） | > | 建仓 | 2025-08-25 | 2026-01-14 | 2026-03-17 | 2026-05-27 | > > **一句话结论**：四个项目都在「Agent 工作台」这个筐里，但争的完全不是同一件事—— > iPolloWork 争入口，OpenWork 争能力分发，Orca 争并行规模，Maka 争可审计性。 > 把它们的「多引擎中立」拆开看，会发现这根本是四个不同的词。 --- ## 0. 先给结论 这个追踪系列的第一个样本是 iPolloWork。只有它的时候，我判断它是「桌面工作台层的一个多引擎整合尝试」。 样本增加到四个之后，这个判断需要修正：**「桌面工作台」不是一个赛道，是四条不同的路。** - **Orca（58.8k★）** 是人气第一，但它的 5,000 个 open issue 里绝大多数是开发者自己开的任务卡—— 最近 100 次提交中 `nwparker` 独占 79 次。广度做到极致，治理还是草稿。 - **OpenWork（23.3k★）** 是工程治理最好的一个，但它和自称要替代的 Claude Cowork 不是一个物种—— 它的主体是一个只暴露两个工具的 MCP 服务，桌面 app 是可选的。 - **Maka（4.4k★）** 是唯一自带评测框架、唯一把「执行记录」当地基的项目， 但也是唯一没有任何正式 release、只支持 Apple Silicon Mac 的项目。 - **iPolloWork（5.2k★）** 是唯一把交付物从代码延伸到 PPT / 网页 / 设计 / 视频的， 但它的三种引擎接入深度并不齐整。 最值得记住的一点是：**许可证的开放程度，完全不能预测项目的治理质量。** Orca 用最开放的 MIT，治理最弱；OpenWork 用最受限制的混合许可，工程规范最强。 --- ## 1. 从 1 个样本到 4 个：为什么现在能出象限图了 只有一个样本的时候，任何对比都是过度抽象——你不知道一个坐标点代表的是什么水平。 四个样本足够看出**分布**，但还不足以看出**规律**。所以这一篇是横向对比，不是最终结论。 四个项目都满足同一个筛选条件：**面向真实工作的、可在本地运行的 Agent 工作台**， 而不是某个 agent 的 demo 或 SDK。这也是本系列的收录标准。 先看它们的硬指标分布（数据日期 2026-09-01，全部来自 GitHub API 实测）： | 项目 | Star | 建仓 | 距今天数 | 日均 Star | | --- | --- | --- | --- | --- | | iPolloWork | 5,201 | 2025-08-25 | 372 天 | 14.0 | | OpenWork | 23,253 | 2026-01-14 | 230 天 | 101.1 | | Orca | 58,771 | 2026-03-17 | 168 天 | 349.8 | | Maka | 4,373 | 2026-05-27 | 97 天 | 45.1 | Orca 的增速是第二名的三倍多。但 Star 增速和成熟度从来不是一回事—— Orca 的版本号 `v1.4.194` 泄露了另一面：一个 1.x 版本号跑到第 194 个补丁版本， 说明日均不止一次发版。 --- ## 2. 赛道分层：它们在争什么 按 Agent 工具的三层栈来定位： ``` ┌─────────────────────────────────────────────────────────────┐ │ 第 3 层 · 桌面工作台层 │ │ │ │ iPolloWork ──────► 争「入口」：把多引擎收进同一界面 │ │ Orca ────────────► 争「规模」：并行 N 个 agent 各自 worktree │ │ Maka ────────────► 争「可信」：执行记录 + 可复现评测 │ └─────────────────────────────────────────────────────────────┘ ▲ 消费 ┌─────────────────────────────────────────────────────────────┐ │ 第 2 层 · 能力分发层 │ │ │ │ OpenWork ────────► 争「复用」：一次创建的能力处处可用 │ │ （不接管执行，只提供 capabilities） │ └─────────────────────────────────────────────────────────────┘ ▲ 依赖 ┌─────────────────────────────────────────────────────────────┐ │ 第 1 层 · 执行引擎层 │ │ Codex · Claude Code · OpenCode · DSH · Pi · Kimi · ... │ └─────────────────────────────────────────────────────────────┘ ``` **关键观察**：OpenWork 不在这条纵轴上跟其他三个竞争，它横插在中间做「能力层」。 Maka 也不完全在第 3 层——它自带 Runtime，实际上从第 1 层一路做到第 3 层。 所以严格说，**只有 iPolloWork 和 Orca 是正面竞品**， OpenWork 和 Maka 是从不同方向切进来的。这也解释了为什么功能对比表对它们意义不大。 --- ## 3. 业务维度：四条完全不同的变现路径 | 项目 | 变现方式 | 免费边界 | 商业意图 | | --- | --- | --- | --- | | **iPolloWork** | 双轨：个人与 <3 人免费；3 人以上及任何商用需书面授权 | 人数 + 用途双重限制 | 用社区版铺量，商业授权变现，iPolloCloud 承载身份与权益 | | **OpenWork** | Den 订阅（组织控制面） | ≤5 人组织免费、30 天评估、开发测试永久免费 | GitLab 式开源核心 + 付费管控面 | | **Orca** | **未明示** | 全部免费 | 无公开营收路径 | | **Maka** | 无 | 全部免费 | ASF 孵化项目，无商业实体 | ### 3.1 OpenWork 的许可设计值得单独说 它的根目录 `LICENSE`（36 行）声明 `ee/` 之外是 MIT，`ee/LICENSE`（72 行）是 OpenWork EE License。 这种「目录切分许可」是 GitLab 带火的做法，但 OpenWork 加了一个少见的条款： > Grant of Future License: Different AI, Inc. hereby irrevocably grants you > an additional license to use each version of the Software under the MIT license, > **effective on the second anniversary** of the date that version of the Software > is first made publicly available. **每个 ee/ 版本发布满两年后自动转 MIT。** 这是一个很有说服力的承诺—— 它把「开源核心会不会被收回」这个疑虑，用一个不可逆的、带时间锁的授权消解掉了。 对比那些纯粹靠「我们承诺不会作恶」的项目，这个设计硬得多。 顺带说一个方法论上的收获：这个仓库的 SPDX 标识是 `NOASSERTION`， 自动化脚本会把它判成 L3 / 私有镜像。但人工复核后发现， **排除 `ee/` 目录之后，剩下的内容是纯 MIT，完全可以公开镜像。** 同一个仓库，两种正确答案，取决于镜像是否包含受限目录。 我据此给追踪体系的许可证分级规则补了一条「混合许可降级流程」—— 否则这类项目会被系统性地过度保守处理。 ### 3.2 Orca 的空白才是最值得警惕的 58.8k Star、MIT 全开源、无企业版、无订阅层，README 还明确写着 「不提供模型，也不替你购买订阅」。 **一个没有营收路径的 58k Star 项目，是一个不稳定态。** 它要么在准备融资，要么在准备改条款。参考 Redis、Terraform、Elasticsearch 的先例， 「先用 MIT 铺到不可替代，再换成限制性许可」是已经被验证过的路径。 这不代表 Orca 一定会这么做，但选型时应该把这个可能性算进去。 --- ## 4. 场景维度：交付物决定了用户群 这一维度的差异比想象中大得多： | 项目 | 最终产出 | 产出后还能改吗 | 由此决定的用户群 | | --- | --- | --- | --- | | **Orca** | code、diff、review comment | 能（就是普通代码） | 专业开发者 | | **OpenWork** | workflow、skill 包、capability | 能，且可跨工具复用 | 团队 / 组织 IT | | **Maka** | code、artifact、**eval 报告**、**执行记录** | 能，且执行记录可回溯 | 研究者 / 受监管团队 | | **iPolloWork** | code、doc、**PPT**、**网页**、**设计**、**视频** | 能，且定位就是「继续手工改」 | 内容团队 | **Maka 的「执行记录」是本轮唯一的新物种。** 它的 README 有一句话很能说明设计取向： > Shorter context is not deleted history. 上下文压缩只省略下次 prompt 里的旧 tool 输出，不会删掉已经落盘的证据。 model 消息、tool call、tool result、turn 的结束方式全部写进 append-only 日志。 对受监管行业的团队来说，这是「能不能用」的前提条件，不是锦上添花。 **Orca 的交付物最窄（只有代码），但它的并行规模最大**—— 一条 prompt 扇出到 5 个 agent，各自在独立 git worktree 里实现，人工比对后合并优胜解。 这是把「多方案比选」做成了产品，而不是让用户自己开 5 个终端。 --- ## 5. 技术维度：四种「多引擎中立」 这是我认为全篇最值得看的一节。四个项目都声称或暗示支持多个 agent 引擎， 但实现方式完全不同，深度也完全不对等。 ### 5.1 iPolloWork：协议级 adapter，但深度不对等 ``` 桌面 UI │ ▼ Engine Protocol（local API） ├──► OpenCode adapter ← 原生，默认本地 runtime，独立 sidecar ├──► DSH adapter ← 原生，但仍在开发中 └──► [MCP 控制面] ─────► Codex ← 浅 ``` README 自己承认了这种不对等：Codex「currently uses the MCP control surface rather than claiming a native Codex engine adapter」。 快是真的快（8 小时打通），但**快是因为走了控制面，深度也就止于控制面**。 ### 5.2 Orca：PTY 级平等，但平等在低处 ``` 桌面 UI │ ▼ PTY（伪终端） ├──► Codex ├──► Claude Code ├──► OpenCode ├──► Kimi / Qwen Code / MiMo Code ... └──► 共 30+ 个 CLI agent ``` 兼容判据就一条：**「能在终端里跑」**。 代价是没有任何一家能拿到原生能力——拿不到结构化 tool call、 拿不到统一的权限回调、拿不到一致口径的 token 统计。 **广度最大，深度最浅。** 这是 Orca 一切优点和缺点的共同根源。 ### 5.3 OpenWork：MCP 级反注入，桌面是可选 ``` OpenWork MCP（只暴露 2 个工具） ├── search_capabilities └── execute_capability ▲ │ 作为 MCP 客户端连入 ├──► Codex codex mcp add openwork --url ... ├──► Claude Code claude mcp add --transport http openwork ... ├──► Cursor └──► OpenCode ← 真正深度绑定的（仓库描述即 powered by opencode） ``` 注意方向反了：它不是去接引擎，而是**让引擎来接它**。 所以它不接管 agent 的执行循环、不负责上下文、不做权限回调。 README 那句「桌面 app 是可选的」不是谦虚，是架构的直接结果。 ### 5.4 Maka：不做接入，自己就是引擎 ``` Desktop ┐ TUI/CLI ┼──► Runtime Host ──► AgentRun（自带） Eval ┘ └─► [external subject adapter] ← 仅评测用 ``` Maka 对**自己的**引擎深度是满分——一个 Runtime Host 统管所有入口。 对**外部**引擎深度是零，只在 eval 里当被测对象。 它压根不参与「多引擎中立」这条赛道的竞争。这是定位选择，不是能力缺陷， 但读者必须知道它和另外三个不是同一类选手。 ### 5.5 四种模式对照 | 项目 | 抽象层 | 引擎数 | 深度 | 本质 | | --- | --- | --- | --- | --- | | iPolloWork | Engine Protocol | 3 | **不对等** | 想做深，但只做成了一家半 | | Orca | 无（PTY） | 30+ | **都浅** | 用广度换深度，很诚实 | | OpenWork | OpenWork MCP | 4+ | 能力面 | 不接管执行，只分发能力 | | Maka | Runtime Host | 1（自己） | 满 | 不做中立，做纵深 | **如果只能记住一句话**：下次看到「支持多引擎」，先问是哪种中立。 协议级、PTY 级、能力级、还是根本不中立——这四种的成本和价值差了一个数量级。 --- ## 6. 宣称 vs 实测 四个项目合计核出 14 条落差。这里挑最有代表性的 8 条，完整清单见各项目档案。 ### 6.1 Orca：5,000 个 issue 的真相 > **宣称**：5,000 个 open issue —— 看起来是严重的社区问题积压。 > **实际**：抽样最近 100 条，**全部创建于 2026-09-01 同一天，94% 没有任何标签**， > 标题是 `fix(ssh): ...` / `refactor: name split modules` / `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」， > 这种文学化的措辞不像人手写的。 > > **但要说清楚另一面**：这同时意味着这 5,000 条从来没有被当作对外承诺管理过。 > **来源**：GitHub API `/repos/stablyai/orca/issues?state=open`，2026-09-01 抽样 100 条。 ### 6.2 Orca：巴士系数为 1 > **宣称**：「The AI Orchestrator for 100x builders」，面向多人协作的成熟开发环境。 > **实际**：最近 100 次提交中 `nwparker` 独占 **79 次**，第二名 `AmethystLiang` 仅 9 次。 > **来源**：GitHub API `/repos/stablyai/orca/commits?per_page=100`，2026-09-01。 ### 6.3 OpenWork：它要替代的东西，和它不是一个物种 > **宣称**：「The open-source alternative to Claude Cowork」。 > **实际**：Cowork 是**桌面操控型** agent（直接操作你的电脑完成工作）； > OpenWork 是**能力分发型** MCP 层。README 原文写得很直白： > 「The desktop app is there when you want a dedicated workspace, but it is not required」。 > > 它替代的是 Cowork 唤起的「能力复用」诉求，不是 Cowork 本身。 > **来源**：README 开篇与「Use OpenWork from any agent」段。 ### 6.4 OpenWork：NOASSERTION 反而是治理最好的 > **宣称**：（无明确宣称，但 SPDX 为 `NOASSERTION`，容易被读成「不够开源」） > **实际**：恰恰相反，它是四个里工程治理最规范的—— > 强制 DCO sign-off（每个 commit 都要 `Signed-off-by`）、 > `ee/` 目录改动还需额外 CLA、`evals/` 放可执行测试规格并要求 PR 附测试证据、 > `worlds/` 放声明式的开发与测试环境。 > > `NOASSERTION` 只因为根目录 LICENSE 是个混合声明文件，不代表开放度低。 > **来源**：README「Getting started (contributors)」与「Sending a pull request」段。 ### 6.5 Maka：Apache 光环不等于生产可用 > **宣称**：Apache 品牌 = 成熟稳定。 > **实际**：孵化状态恰恰是「尚未被 ASF 完全背书」的标记，README 自带官方免责声明。 > 截至 2026-09-01 **没有任何 Apache 正式 release**，对外分发的只有 Desktop Nightly， > README 明确标注「not an ASF release, not intended for production use」。 > > 平台支持也最窄：macOS arm64 是唯一正式档，Windows 为未签名预览，Linux 标注 `soon`。 > **来源**：README 的 NOTE / IMPORTANT 段、Releases and downloads 段、平台 badge。 ### 6.6 Maka：本地优先，但 API key 是明文 > **宣称**：「Your machine, your data」本地优先、数据主权。 > **实际**：数据确实不出机器，但 README 自己承认 `credential-vault.json` 是 > 「local plaintext file, readable only by your OS account」。 > > 防护依赖操作系统账户权限，不是加密也不是系统钥匙串。 > renderer 进程拿不到，但同机任一以你身份运行的进程都能读到。 > **来源**：README「Local data and recovery」段。 ### 6.7 Maka：崩溃恢复的两个附加条件 > **宣称**：崩溃恢复与可选续跑。 > **实际**：续跑**默认关闭**，需手动设 `MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1`， > 且 README 警告该调用会打模型、消耗 token。 > 另有**升级断代**：旧版 JSONL transcripts 与 Electron safeStorage 凭据不会被导入， > 升级后的工作区可能出现空线程，凭据必须重新录入。 > **来源**：README「Local data and recovery」段。 ### 6.8 Orca：三端覆盖，成熟度不对等 > **宣称**：桌面 / 移动 / VPS 全覆盖。 > **实际**：Android 仍是手工分发 APK（0.0.47），iOS 走 App Store 与 TestFlight， > VPS 场景需另查 headless Linux 指南。 > 移动端实际是「监控与追加指令」的伴随形态，不是完整工作环境。 > **来源**：README Install 段与 Mobile Companion 段。 --- ## 7. 象限图：四个坐标 按四个维度打分（0–10，人工标定，见各项目档案的 `chart` 块）： | 项目 | 形态纵深 | 引擎中立 | 本地优先 | 交付物纵深 | | --- | --- | --- | --- | --- | | iPolloWork | 8 | 7 | 7 | 7 | | OpenWork | 5 | 6 | 6 | 5 | | Orca | 8 | 9 | 6 | 3 | | Maka | 6 | 1 | 10 | 6 | 把「引擎中立」和「本地优先」拉成两个轴： ``` 本地优先 10 │ │ Maka (1,10) 9 │ │ iPolloWork (7,7) 7 │ │ OpenWork (6,6) Orca (9,6) 6 │ │ 5 │ └────┬────┬────┬────┬────┬────┬──── 1 3 5 7 9 引擎中立 → ``` **读图**： - **右上（高本地 + 高中立）目前是空的**。这四个项目里没有一个同时做到 「完全本地」和「多引擎中立」——这大概就是下一个值得关注的空白位。 - Maka 在左上角孤零零一个点：它用「放弃中立」换来了「完全本地」。 - Orca 在右下：中立度最高，但本地优先只有 6 分（强依赖各家云端订阅）。 样本只有四个，象限图只是示意，不构成统计结论。 --- ## 8. 选型建议 | 如果你的情况是 | 选 | 理由 | | --- | --- | --- | | 已重度使用 CLI agent，想并行跑多方案比对 | **Orca** | 兼容面最广，并行 worktree 是独一份 | | 团队已固定在某款 agent，只想让能力跨工具复用 | **OpenWork** | MCP 反注入是唯一解，不逼你换工具 | | 有审计 / 数据主权 / 可复现评测的硬要求 | **Maka** | 执行记录 + eval 框架，别家都没有 | | 希望 agent 产出的 PPT / 网页 / 设计之后还能手工改 | **iPolloWork** | 交付物纵深最广 | **共同的不建议**： - 都还是 0.x 或 1.x 早期版本，没有一家适合放进关键生产路径。 - 都要求 BYOM（自带模型），模型成本与额度需要自己算。 **再看一段时间的信号**： - Orca 的营收路径是否公开（决定它会不会改许可） - OpenWork 是否发布 1.0（当前 v0.18.40） - Maka 是否产出第一个 Apache 正式 release（当前只有 Nightly） - iPolloWork 的 Codex 是否从 MCP 控制面升级为原生 adapter --- ## 9. 追踪备注 - **数据日期**：2026-09-01 - **指标来源**：GitHub API 自动化快照（无 token，匿名配额） - **下次跟进点**： 1. Orca 的 issue 是否会开始做社区 triage（当前 94% 无标签） 2. Maka 的首个 Apache 正式 release 3. OpenWork 1.0 与 ee/ 两年转 MIT 的首批到期版本 - **相关档案**：`data/projects/{ipollowork,openwork,orca,maka}.yaml` - **源码镜像**： - `gitinbox/iPolloWork`（私有 · L3 source-available） - `gitinbox/maka`（公开 · L1 Apache-2.0） - OpenWork / Orca 因体积超限（291 MB / 671 MB）暂未镜像，档案中已标注 - **方法论更新**：本轮给许可证分级补了「混合许可降级流程」， 并给指标回写加了自愈能力（块被误删时自动重建） --- 本文为「全球智能体开源应用追踪」系列之一 · 总纲见 [系列索引](https://blog.apescale.com/?post=98) · 数据与脚本开源于 `gitinbox/agent-radar`