track: 新增 OpenWork / Orca / Maka 三项目，样本达到 4 个
样本 - 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 无处可写）
This commit is contained in:
gitea-publish committed
1 parent
78b87e8b2f
commit
e5cdb1801e
18 files changed
+1771
-114
No files matched your search
@@ -0,0 +1,413 @@
|
||||
# 四个 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>
|
||||
@@ -0,0 +1,5 @@
|
||||
# 发布元数据（由 scripts/publish_emlog.py 维护）
|
||||
# 本文不属于单个项目，ID 不落在 data/projects/ 下
|
||||
emlog_id: 99
|
||||
url: "https://blog.apescale.com/?post=99"
|
||||
last_published: "2026-09-01"
|
||||
+104
-18
@@ -1,6 +1,7 @@
|
||||
# 全球智能体开源应用追踪 · 总纲
|
||||
|
||||
> 这是一个**持续更新**的追踪索引。每收录一个新项目，会先发一篇深度文，再回来回填这里。
|
||||
> 这是一个**持续更新**的追踪索引。每收录一个新项目会先建档，够一批样本就发一篇横向对比，
|
||||
> 再按价值排序补单项目深度文——所以索引里「待发布」是常态，不是遗漏。
|
||||
> 所有数据来自 GitHub API 的定时快照，所有结论都标注了核实来源。
|
||||
> 数据与脚本开源在 `gitinbox/agent-radar`。
|
||||
|
||||
@@ -69,24 +70,48 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出
|
||||
| 项目 | 定位 | 目标用户 | 变现 | 许可证 | 成色 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **iPolloWork** | 站在 Agent 工具链的**工作台层**而非引擎层：不替代 Codex / DSH / OpenCode 中任何一个，而是把它们收进同一个项目空间，并把交付物从代码延伸到文档、演示稿、网站、设计与视频 | 企业研发团队、需要人机协作的 agent 团队、需要产出并持续修改 PPT / 网页 / 设计 / 视频的内容团队 | 双轨：个人自用与少于 3 人的小规模内部使用免费；3 人及以上、以及任何售卖 / 转售 / 付费服务 / SaaS / 托管 / 白标 / 市场分发 / 面向客户的使用，均需书面授权。配套 iPolloCloud 承载身份、组织、权益与商业 App | iPolloWork Source Available License 1.0 | L3 |
|
||||
| **maka** | 站在「执行记录层」：不追功能广度，把「agent 干过什么必须可复现、 可审计、可评测」做成地基。同时是四个里唯一自带评测框架的项目。 | 对可审计性与数据主权有硬要求的团队、需要横向评测不同 agent / 模型的研究者与工程团队、愿意用功能丰富度换确定性的自用开发者 | 无。Apache 孵化项目，无商业实体、无双许可、无付费层。 | Apache License 2.0 | L1 |
|
||||
| **openwork** | 站在「能力分发层」，不争桌面入口。核心资产是 OpenWork MCP 与 Den 控制面—— 把 skills / MCP / 连接服务做成可跨工具、跨人、跨机器复用的组织级能力包。 | 已在使用 Codex / Claude Code / Cursor 且不想换工具的开发者、需要统一管控 agent 能力的中大型组织、想把自己搭好的工作流分发给同事或朋友的团队 | Den 订阅（组织控制面）。免费额度写得很明确： 5 人以下组织的非 Enterprise 功能全免、任意规模 30 天评估、开发测试永久免费。 | 目录切分许可（GitLab 式）：ee/ 之外为 MIT；ee/ 为 OpenWork EE License | L3 |
|
||||
| **orca** | 站在「执行编排层」：不造引擎、不卖模型，只做并行 agent 的调度与可观测外壳。 上游是各家 CLI agent，下游是开发者的本机/远程 worktree。 | 自称 100x builders 的重度个人开发者、需要同时试多种实现方案再择优合并的小团队、已在用 Codex / Claude Code / OpenCode 并想并行跑的人 | 未明示，且这是它最大的商业不确定性。MIT 全开源、无企业版、无订阅层， README 明确不提供模型也不代买订阅。收入路径尚未公开。 | MIT License | L1 |
|
||||
|
||||
### 场景维度
|
||||
|
||||
| 项目 | 交互形态 | 人机协作 | 交付物 |
|
||||
| --- | --- | --- | --- |
|
||||
| **iPolloWork** | desktop-app | approval-gated | code、doc、ppt、website、design、video |
|
||||
| **maka** | 桌面应用、TUI / CLI、评测框架 | 强：工具越过沙箱边界必须审批；运行可中止；失败被分类。 | code、artifact、eval-report、execution-record |
|
||||
| **openwork** | MCP 远程服务、桌面应用（可选）、浏览器登录授权 | 能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。 | workflow、skill-package、capability |
|
||||
| **orca** | 桌面应用、移动端伴随、CLI、SSH 远程 | 强人在环：需人工比并结果、批注 diff、批准合并。 但 5000 个自开 issue 说明产品自身也在被 AI 自动改进。 | code、diff、review-comment |
|
||||
|
||||
### 技术维度
|
||||
|
||||
| 项目 | 形态 | 引擎抽象 | 接入深度 | 模型绑定 | 本地优先 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| **iPolloWork** | Electron 桌面应用（另支持 dev:ui 只起浏览器 UI） | Engine Protocol（经 local API）；Codex 与 MCP 客户端另经 ipollowork-ui-mcp 控制面接入 | **三种引擎的接入深度并不对等**：OpenCode 是默认本地执行 runtime，走 local API → Engine Protocol 的原生 adapter，以独立 sidecar 形式存在（首次桌面构建时下载，不 fork、可独立升级）；DeepSeek Harness 是可选 peer runtime 与子代理委派目标，同样走 Engine Protocol；Codex 则**仅**通过 ipollowork-ui-mcp 的 MCP 控制面接入，README 明确写明 currently uses the MCP control surface rather than claiming a native Codex engine adapter | byom | 是 |
|
||||
| **maka** | 桌面应用 + TUI/CLI + 评测框架，三者共用同一 Runtime Host | Runtime Host（单一所有者的生命周期 + 协议 + 客户端引导） | 与另外三家正好相反：Maka 对**自己的**引擎深度是满分 （一个 Runtime Host 统管所有入口），对**外部**引擎深度是零 （只在 eval 里当被测对象）。 它压根不参与「多引擎中立」这条赛道的竞争——这是定位选择而非能力缺陷， 但读者必须知道它和 Orca / OpenWork / iPolloWork 不是同一类选手。 | 完全 BYO：云 API、本地模型或兼容网关， 不捆绑任何共享账号（README 明确 "You bring the model"）。 | 是 |
|
||||
| **openwork** | MCP 远程服务 + 可选桌面应用 + Web 控制面 | OpenWork MCP（能力面，不是执行面） | 接入「对等且都浅」：所有引擎都以同一个 MCP 客户端身份接入， 拿到的是能力调用，不是执行控制——OpenWork 不接管 agent 的执行循环、 不负责上下文管理、不做权限回调。 真正深度绑定的是 OpenCode：仓库描述即写 powered by opencode， 桌面端属 OpenCode 生态，其余引擎只是 MCP 外挂。 这与 iPolloWork 的「Codex 仅 MCP 控制面」是同一个问题的两种解法： iPolloWork 把 MCP 当补丁（主体是桌面），OpenWork 把 MCP 当主体（桌面是可选）。 | Den 侧可统一配置与配额控制 model provider；桌面 app 本身 BYO | 是 |
|
||||
| **orca** | 桌面应用（含移动端伴随 + CLI） | 无统一抽象层；实际是终端 PTY + 约定式输出解析 | 接入深度「完全对等，但对等在低处」：30+ 引擎共享同一套 PTY 外壳， 因此没有任何一家能拿到原生能力——拿不到结构化 tool call、 拿不到统一权限回调、拿不到一致口径的 token 统计。 广度最大，深度最浅。对照 iPolloWork 为 OpenCode 做的原生 Engine Protocol adapter，Orca 与任一单引擎的耦合都明显更浅。 | 完全 BYO——用户自带各 agent 的订阅与额度 | 是 |
|
||||
|
||||
### 生态与风险
|
||||
|
||||
| 项目 | Star | Fork | Issues | 最新 release | 节奏 | 成熟度 | 数据日期 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| **iPolloWork** | 5201 | 976 | 80 | v0.50.12 | 一天多版 | beta | 2026-09-01 |
|
||||
| **maka** | 4373 | 406 | 398 | v0.2.0-dev.9.20260831 | 一天多版 | 孵化期 | 2026-09-01 |
|
||||
| **openwork** | 23253 | 2307 | 414 | v0.18.40 | 约 1 天/版本 | 0.x 活跃 | 2026-09-01 |
|
||||
| **orca** | 58771 | 3987 | 5000 | v1.4.194 | 约 1 天/版本 | 原型期 | 2026-09-01 |
|
||||
|
||||
**成熟度详解**
|
||||
|
||||
- **iPolloWork**：beta
|
||||
- **maka**：治理成熟度最高（ASF 流程 + 评测框架 + 文档契约），
|
||||
产品成熟度最低（无正式 release、平台只支持 arm64 macOS、功能默认保守）。
|
||||
属于「地基打得最实，房子盖得最慢」。
|
||||
- **openwork**：工程成熟度最高：有可执行测试规格（evals/）、声明式环境（worlds/）、
|
||||
明确的贡献契约与许可边界。但仍处 0.x 主版本（v0.18.40），
|
||||
API 与数据格式可能变动。
|
||||
- **orca**：功能广度第一，工程治理末位。一天多版（v1.4.194）说明迭代极快，
|
||||
但 issue 只进不出、巴士系数为 1，属于「高速原型期」而非「可托付生产期」。
|
||||
|
||||
### 宣称 vs 实测
|
||||
|
||||
@@ -99,36 +124,97 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出
|
||||
| **iPolloWork** | 统一的插件与 Skills 生态 | 统一的是**生命周期**（安装/启用/更新/卸载一次），不是能力本身。README 明确各 runtime 保留自己的 agents、Skills、插件与执行模型，引擎专属增强只是可选 | README 的 Agent runtime compatibility 一节 |
|
||||
| **iPolloWork** | 仓库 topics 标注 claude-code | 中英文 README 均未描述任何 Claude Code 接入方式。topic 更像搜索曝光策略，不应视为已支持的能力 | GitHub topics 与 README 全文对照 |
|
||||
| **iPolloWork** | 企业级（enterprise-grade） | 版本号仍在 0.50.x，无公开 Roadmap，发布节奏为一天多版，仓库体积 591 MB。工程投入可观，但版本语义上尚未到企业可用的稳定态 | GitHub releases；README 版本说明；仓库 size 字段 |
|
||||
| **maka** | 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 |
|
||||
| **maka** | 「Your machine, your data」本地优先、数据主权 | 数据确实不出机器，但 **API key 以明文文件存放**—— README 原文承认 credential-vault.json 是 「local plaintext file, readable only by your OS account」。 防护依赖操作系统账户权限，而非加密或系统钥匙串。 renderer 进程拿不到，但同机任一以你身份运行的进程都能读到。 | README「Local data and recovery」段 |
|
||||
| **maka** | 崩溃恢复与可选续跑 | 续跑**默认关闭**，需手动设 MAKA_RUNTIME_SAFE_BOUNDARY_RESUME=1， 且 README 明确警告该调用会打模型、消耗 token。 另存在**升级断代**：旧版 JSONL transcripts 与 Electron safeStorage 凭据不会被导入，升级后的工作区可能出现空线程，凭据必须重新录入。 | README「Local data and recovery」段 |
|
||||
| **maka** | （无明确宣称，但易被期待为开箱即用的完整工作台） | 内置工具只有 Read / Write / Edit / Bash / Glob / Grep 六个； Computer Use 与 catalog skills 属可选且默认关闭； IM bot（聊天应用接入）标注 experimental。 功能面是四个里最保守的——取舍很明确：用广度换确定性。 | README「Current capabilities」段 |
|
||||
| **maka** | 支持 Graph 多算子并行 | Graph 的实现算子跑在独立 git worktree，且**要求源项目是干净 worktree**—— 有未提交改动就用不了。相比 Orca 的并行 worktree（产品级封装）， Maka 的 Graph 更接近实验性能力。 | README「Terminal entry points」段 |
|
||||
| **openwork** | 「Claude Cowork 的开源替代品」 | 形态完全不同。Cowork 是桌面操控型 agent（直接操作你的电脑完成工作）； OpenWork 是能力分发型 MCP 层，桌面 app 被明确定位为可选—— 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」段 |
|
||||
| **openwork** | 跨 Codex / Claude Code / Cursor / OpenCode 多引擎通用 | 对 OpenCode 是原生的（仓库描述 powered by opencode，桌面端属其生态）； 对其余引擎只通过自己暴露的两个 MCP 工具对接。 这是能力调用面，不是引擎执行面——OpenWork 不接管这些引擎的执行循环、 上下文与权限。对外宣称的「跨引擎」与内部实际的主从关系存在落差。 | README「It exposes two tools」段；仓库 description「powered by opencode」 |
|
||||
| **openwork** | free, open-source（免费开源） | 需要分目录看：ee/ 之外确实 MIT 且免费；但 ee/（Den 组织控制面、 MCP 网关、推理）属 source-available，生产使用需付费订阅， 只有 5 人以下组织、30 天评估、开发测试三种情形豁免。 个人免费，团队与企业要付费。 | README Licensing 段 + ee/LICENSE 原文 72 行 |
|
||||
| **openwork** | （无明确宣称，但 SPDX 为 NOASSERTION，易被误读为「不够开源」） | 恰恰相反——它是四个项目里工程治理最规范的：强制 DCO sign-off、 ee/ 需额外 CLA、evals/ 目录放可执行测试规格并要求 PR 附测试证据、 worlds/ 放声明式的开发与测试环境定义。 NOASSERTION 只因根目录 LICENSE 是混合声明文件，不代表开放度低。 | README「Getting started (contributors)」与「Sending a pull request」段 |
|
||||
| **orca** | 5000 个 open issue 反映社区问题积压与项目质量压力 | 抽样最近 100 条：全部创建于 2026-09-01 同一天，94% 无任何标签， 标题为 fix(ssh) / refactor / fix(task-page) 等内部任务口吻； 提交者 TOP3 为 nwparker(51)、OrcaWin(13)、klaidliadon(12)。 实为「团队自开的任务待办板」，且带明显 AI 批量生成痕迹 （如 OrcaWin 提交的「pty.spawn can leak a running agent process unboundedly: host holds the door open」）。 它不是社区投诉，也不构成 triage 压力——但同样说明这 5000 条 从未被当作对外承诺来管理。 | GitHub API /repos/stablyai/orca/issues?state=open，2026-09-01 抽样 100 条 |
|
||||
| **orca** | 「100x builders 的 AI Orchestrator」，面向多人协作的成熟开发环境 | 巴士系数为 1：最近 100 次提交中 nwparker 独占 79 次， 第二名 AmethystLiang 仅 9 次。功能面由单人 + AI 高强度驱动， 而非团队协作成果。 | GitHub API /repos/stablyai/orca/commits?per_page=100，2026-09-01 |
|
||||
| **orca** | 支持 30+ 种 agent，生态最开放 | 兼容判据是「能在终端里跑」，靠 PTY 拉起而非协议对接。 广度最大但深度最浅——所有引擎都拿不到结构化 tool call 与统一的权限回调。与 iPolloWork 为 OpenCode 做原生 Engine Protocol adapter 相比，Orca 与任一单引擎的耦合都更浅。 | README「Works with any CLI agent — if it runs in a terminal, it runs in Orca」 |
|
||||
| **orca** | MIT 全开源，可放心用于生产 | 许可证本身无风险，但项目没有任何公开的营收路径 （无企业版、无订阅、不卖模型、不代买订阅）。 58k star 的体量与零商业化不匹配，属于「要么即将融资、 要么后续变更条款」的不稳定态。 | README License 段；README 明确「Orca does not provide models, nor does it buy subscriptions for you」 |
|
||||
| **orca** | 桌面 / 移动 / VPS 全覆盖 | 三端成熟度不对等：Android 仍是手工分发 APK（0.0.47）、 iOS 走 App Store 与 TestFlight、VPS 场景需另查 headless Linux 指南。 移动端实际是「监控与追加指令」的伴随形态，不是完整工作环境。 | README Install 段与 Mobile Companion 段 |
|
||||
|
||||
### 一句话结论
|
||||
|
||||
| 项目 | 结论 | 适合 | 不适合 |
|
||||
| --- | --- | --- | --- |
|
||||
| **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用 | 想在同一个界面管理多引擎项目、并希望 agent 产出的 PPT / 网页 / 设计 / 视频之后还能继续手工修改的个人开发者，或少于 3 人的极小团队 | 3 人以上需要正式落地的团队（许可证要求书面授权）、期待 Codex 原生级集成的用户（目前只有 MCP 控制面）、以及追求稳定的生产环境（v0.50.x、一天多版、DSH 集成未进稳定版） |
|
||||
| **maka** | 四个里唯一把「执行记录」当地基的项目——治理与可复现性最强，产品成熟度最弱。 | 对审计、数据主权、可复现评测有硬要求的团队； 做 agent 横向对比研究的工程团队。 | 要开箱即用、要 Windows / Linux、要丰富第三方集成的人； 以为 ASF 品牌等于生产可用的决策者。 |
|
||||
| **openwork** | 把「能力」而不是「桌面」做成产品——工程治理最好的一个，但它和自称要替代的东西不是一个物种。 | 已固定在某款 agent 上、只想让团队能力跨工具复用的开发者； 需要统一管控 agent 能力与模型配额的组织 IT。 | 想要一个开箱即用的桌面 agent 工作台的人； 以为拿到的是完整 Cowork 平替的人。 |
|
||||
| **orca** | 兼容面最广的并行 agent 编排外壳——广度做到极致，深度与治理都还是草稿。 | 已在重度使用 CLI agent、想同时跑多个方案横向比对的个人开发者与小团队。 | 需要稳定 SLA、指望社区 triage 与多人维护保障的团队； 指望它统一各引擎能力（结构化调用、统一权限、一致口径）的架构选型者。 |
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 执行引擎层 （暂无收录）
|
||||
│ └ 真正跑 agent loop 的地方
|
||||
│ │
|
||||
│ 编辑器内 Agent 层 （暂无收录）
|
||||
│ └ 嵌在 IDE / 编辑器里的交互层
|
||||
│ │
|
||||
│ 桌面工作台层 iPolloWork★5201
|
||||
│ └ 跨引擎、跨项目、跨交付物的统一界面
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
> 当前收录 1 个项目，不足 4 个，此阶段只出分层图。样本够了之后会自动切换为象限图。
|
||||
<svg viewBox="0 0 720 420" width="720" height="420" xmlns="http://www.w3.org/2000/svg" style="font-family:sans-serif;max-width:100%;height:auto">
|
||||
<text x="360" y="26" text-anchor="middle" font-size="15" font-weight="600" fill="#1f2328">视图 A · 形态纵深 × 引擎立场</text>
|
||||
<rect x="70" y="55" width="580" height="295" fill="#fafbfc" stroke="#d8dee4"/>
|
||||
<line x1="215.0" y1="55" x2="215.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="128.75" x2="650" y2="128.75" stroke="#eaeef2"/>
|
||||
<line x1="360.0" y1="55" x2="360.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="202.5" x2="650" y2="202.5" stroke="#eaeef2"/>
|
||||
<line x1="505.0" y1="55" x2="505.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="276.25" x2="650" y2="276.25" stroke="#eaeef2"/>
|
||||
<text x="70" y="372" font-size="11" fill="#6a737d">单点工具</text>
|
||||
<text x="650" y="372" text-anchor="end" font-size="11" fill="#6a737d">统一工作台</text>
|
||||
<text x="62" y="356" text-anchor="end" font-size="11" fill="#6a737d">绑定单引擎</text>
|
||||
<text x="62" y="67" text-anchor="end" font-size="11" fill="#6a737d">多引擎中立</text>
|
||||
<circle cx="534.0" cy="143.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="545.0" y="147.5" font-size="12" fill="#1f2328">iPolloWork</text>
|
||||
<circle cx="418.0" cy="320.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="429.0" y="324.5" font-size="12" fill="#1f2328">maka</text>
|
||||
<circle cx="360.0" cy="173.0" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="371.0" y="177.0" font-size="12" fill="#1f2328">openwork</text>
|
||||
<circle cx="534.0" cy="84.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="545.0" y="88.5" font-size="12" fill="#1f2328">orca</text>
|
||||
</svg>
|
||||
<svg viewBox="0 0 720 420" width="720" height="420" xmlns="http://www.w3.org/2000/svg" style="font-family:sans-serif;max-width:100%;height:auto">
|
||||
<text x="360" y="26" text-anchor="middle" font-size="15" font-weight="600" fill="#1f2328">视图 B · 本地优先 × 交付物纵深</text>
|
||||
<rect x="70" y="55" width="580" height="295" fill="#fafbfc" stroke="#d8dee4"/>
|
||||
<line x1="215.0" y1="55" x2="215.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="128.75" x2="650" y2="128.75" stroke="#eaeef2"/>
|
||||
<line x1="360.0" y1="55" x2="360.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="202.5" x2="650" y2="202.5" stroke="#eaeef2"/>
|
||||
<line x1="505.0" y1="55" x2="505.0" y2="350" stroke="#eaeef2"/>
|
||||
<line x1="70" y1="276.25" x2="650" y2="276.25" stroke="#eaeef2"/>
|
||||
<text x="70" y="372" font-size="11" fill="#6a737d">强云依赖</text>
|
||||
<text x="650" y="372" text-anchor="end" font-size="11" fill="#6a737d">完全本地</text>
|
||||
<text x="62" y="356" text-anchor="end" font-size="11" fill="#6a737d">只出代码</text>
|
||||
<text x="62" y="67" text-anchor="end" font-size="11" fill="#6a737d">多模态可编辑</text>
|
||||
<circle cx="476.0" cy="143.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="487.0" y="147.5" font-size="12" fill="#1f2328">iPolloWork</text>
|
||||
<circle cx="650.0" cy="173.0" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="661.0" y="177.0" font-size="12" fill="#1f2328">maka</text>
|
||||
<circle cx="418.0" cy="202.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="429.0" y="206.5" font-size="12" fill="#1f2328">openwork</text>
|
||||
<circle cx="418.0" cy="261.5" r="7" fill="#0969da" fill-opacity="0.75" stroke="#fff" stroke-width="1.5"/>
|
||||
<text x="429.0" y="265.5" font-size="12" fill="#1f2328">orca</text>
|
||||
</svg>
|
||||
<!-- MATRIX:END -->
|
||||
|
||||
---
|
||||
|
||||
## 深度文索引
|
||||
## 文章索引
|
||||
|
||||
| 项目 | 一句话结论 | 文章 |
|
||||
> 这一段由 `scripts/build_matrix.py` 从项目档案的 `article` 块与
|
||||
> `articles/*.meta.yaml` 自动生成。发新文后重跑脚本即可，不要手工改。
|
||||
|
||||
<!-- INDEX:BEGIN -->
|
||||
| 项目 | 一句话结论 | 深度文 |
|
||||
| --- | --- | --- |
|
||||
| iPolloWork | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用 | 见同期发布的《iPolloWork 深度拆解》 |
|
||||
| **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作 | [已发布](https://blog.apescale.com/?post=97) |
|
||||
| **maka** | 四个里唯一把「执行记录」当地基的项目 | 待发布（见下方横评） |
|
||||
| **openwork** | 把「能力」而不是「桌面」做成产品 | 待发布（见下方横评） |
|
||||
| **orca** | 兼容面最广的并行 agent 编排外壳 | 待发布（见下方横评） |
|
||||
|
||||
**跨项目文章**
|
||||
|
||||
- [四个 Agent 工作台的路线分野：把「多引擎中立」拆开看](https://blog.apescale.com/?post=99) — 2026-09-01
|
||||
|
||||
> 待补深度文：maka、openwork、orca。当前可先读上方跨项目文章，其中已包含这些项目的完整分维度对比。
|
||||
<!-- INDEX:END -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in new issue
Block a user