gitea-publish
e5cdb1801e
样本 - openwork (different-ai/openwork) 23.2k★ 能力分发层，DCO + evals + worlds - orca (stablyai/orca) 58.8k★ 并行编排外壳，5000 issue 实为团队自开任务板 - maka (apache/maka) 4.4k★ 执行记录层，Apache 孵化但无正式 release 档案 - 三份五维档案填完，risk.claim_vs_reality 均已核实到证据 - ipollowork 象限坐标从占位 9/9/9/9 校准为 8/7/7/7（与新样本同一标尺） 文章 - 新增横评文《四个 Agent 工作台的路线分野：把「多引擎中立」拆开看》(emlog id=99) - 总纲文回填四项目矩阵 + 双视图象限图 (emlog id=98) 镜像 - gitinbox/maka 已推送（public，source-only 快照 12 MB） - openwork(291MB) / orca(671MB) 受 50KB/s 带宽约束，档案标 mode: pending 规则 - license-tiers.yaml 新增「目录切分许可」降级流程（OpenWork 判例： 排除 ee/ 后为纯 MIT → public，完整镜像 → private） - registry.yaml openwork 可见性改 public + mirror_excludes: ["ee/"] 脚本修复 - _common.py 新增 upsert_block：手工整块覆盖 ecosystem 删掉 metrics 时能自愈 - mirror_sync.sh：SOURCE_ONLY 未初始化（set -u 下偶发炸）； 浅仓推送被服务端拒绝 → 自动 --unshallow，失败降级快照； 量体积前先 repack（此前新 commit 全是 loose object，恒打印 0 MB） - build_matrix.py：成熟度长文本移出表格（新增 maturity_level 短标签）； 象限图标签靠右时翻转到左侧防溢出；SVG 加 max-width 防窄屏溢出； 文章索引改为自动生成（原先手抄，横评文发了索引里却没有） - publish_emlog.py：ID 回写按「有无同名档案」分流， 00-* 跨项目文章落到 articles/<id>.meta.yaml（此前 ID 无处可写）
414 lines
21 KiB
Markdown
414 lines
21 KiB
Markdown
# 四个 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）暂未镜像，档案中已标注
|
||
- **方法论更新**：本轮给许可证分级补了「混合许可降级流程」，
|
||
并给指标回写加了自愈能力（块被误删时自动重建）
|
||
|
||
---
|
||
|
||
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见 [系列索引](https://blog.apescale.com/?post=98) · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
|