速览 | 项 | 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 实测）：

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. 业务维度：四条完全不同的变现路径

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. 场景维度：交付物决定了用户群

这一维度的差异比想象中大得多：

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 四种模式对照

如果只能记住一句话：下次看到「支持多引擎」，先问是哪种中立。 协议级、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 块）：

把「引擎中立」和「本地优先」拉成两个轴：

  本地优先 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. 选型建议

共同的不建议： - 都还是 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）暂未镜像，档案中已标注
• 方法论更新：本轮给许可证分级补了「混合许可降级流程」， 并给指标回写加了自愈能力（块被误删时自动重建）

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