速览

项	OpenClaw	Orca	QwenPaw	OpenWork	iPolloWork	Maka	Tutti
仓库	openclaw/openclaw	stablyai/orca	agentscope-ai/QwenPaw	different-ai/openwork	Devin-AXIS/iPolloWork	apache/maka	tutti-os/tutti
Star	388,438	58,771	34,758	23,253	5,201	4,373	3,660
Fork / Issues	81,543 / 5,925	3,987 / 5,000	3,052 / 898	2,307 / 414	976 / 80	406 / 398	371 / 185
主语言	TypeScript 91%	TypeScript 97%	Python 59%	TypeScript 90%	TypeScript 50%	TypeScript 92%	TS 49% + Go 45%
仓库体积	3,276 MB	671 MB	109 MB	291 MB	591 MB	100 MB	243 MB
最新版本	v2026.8.1	v1.4.194	v2.2.0-beta.5	v0.18.40	v0.50.12	v0.2.0-dev.9	stable / v0.2.31
许可证	MIT（SPDX 误判）	MIT	Apache-2.0	MIT + EE 切分	Source Available	Apache-2.0	Apache-2.0
建仓	2025-11-24	2026-03-17	2026-02-24	2026-01-14	2025-08-25	2026-05-27	2026-06-12

一句话结论：样本从 4 个扩到 7 个，「Agent 工作台」这个筐被撑破了—— OpenClaw 与 QwenPaw 根本不是给开发者用的，Tutti 则在争一个别人没争的维度（多人协作）。 更值得注意的是，star 数与工程纪律在本批样本里呈负相关： 388k 的 OpenClaw 版本号倒挂、沙箱默认关闭，3.6k 的 Tutti 反而是唯一持续发正式版的。

0. 先给结论

上一篇横评的四个样本（iPolloWork / OpenWork / Orca / Maka）有一个共同前提：它们的用户都是开发者。 所以那篇文章能放心地用「形态纵深 × 引擎立场 × 本地优先 × 交付物纵深」四个维度去切。

新增的三个样本把这个前提打碎了：

• OpenClaw（388k★） 是 GitHub 上星标最多的软件仓库，但它管的是收件箱、日历和登机牌， 入口是 WhatsApp 和 Telegram。它的用户不是开发者。
• QwenPaw（34.7k★） 是 OpenClaw 的正面竞品，同样做个人助理， 但把安全做成了主卖点——五层防护默认全开。它也不面向开发者。
• Tutti（3.6k★） 是七个里 star 最少、建仓最晚（2026-06-12）的， 却是唯一持续发正式版的，也是唯一把「多人 × 多 Agent」写进定位的。

三个样本各自验证了一条反直觉的结论，下面逐条展开。

1. 从 4 个到 7 个：赛道裂成了三层

原先四个样本可以塞进「开发者工具链」这一层。加入新样本后，至少是三层：

┌─ 个人助理执行层 ─────────────────────────────────────────────────┐
│  OpenClaw 388k★   QwenPaw 34.7k★                                 │
│  自己就是 agent，不接别人的引擎                                    │
│  用户：普通人       入口：聊天软件 / 本地 Gateway                   │
│  交付物：事儿办完了（邮件发了、日程改了），不是文件                  │
└────────────────────────────────────────────────────────────────┘
                              ⋮  （几乎不重叠）
┌─ 协作空间层 ─────────────────────────────────────────────────────┐
│  Tutti 3.6k★                                                     │
│  多 agent 共享上下文、接力干活；多人协作部分在闭源 VM 侧            │
│  用户：小团队       入口：Electron 桌面 + Workbench 节点            │
│  交付物：代码 + 设计稿 + 文档 + PPT                                │
└────────────────────────────────────────────────────────────────┘
                              ⋮
┌─ 开发者工具链层 ─────────────────────────────────────────────────┐
│  iPolloWork 5.2k★（争入口）    OpenWork 23.3k★（争能力分发）       │
│  Orca 58.8k★（争并行规模）     Maka 4.4k★（争可审计性）            │
│  用户：开发者       入口：CLI / IDE / 桌面                          │
│  交付物：代码及其周边                                              │
└────────────────────────────────────────────────────────────────┘

这三层之间几乎不重叠——OpenClaw 的用户不会去比较它和 Orca 谁的多引擎中立做得好， 因为 OpenClaw 根本不接引擎。把它们放进同一张象限图是可行的，但解读时必须先分清层。

2. 反直觉一：star 数与工程纪律负相关

这是本批样本最刺眼的一条。把「工程纪律」拆成三个可核实的指标来看：

三个观察：

① 版本号最能说明问题。 OpenClaw 最近 12 个 release 里，8-28 发的是 v2026.9.1-beta.1，8-31 发的正式版却是 v2026.8.1——beta 的版本号比正式版还新； 而 v2026.6.33 / v2026.6.34（8-08 发布）又晚于 v2026.7.1-1 / -2（8-04 发布）。 多线并行导致版本号与实际时间顺序倒挂，用户无法从版本号判断新旧。

② 「停更 7 周」是媒体的失真转述。 多家媒体报道 OpenClaw 在 7 月中旬后停更七周。 查 release 时间轴：7-18 → 7-28 → 8-01 → 8-02 → 8-04 → 8-08 → 8-15 → 8-24 → 8-28 → 8-31 一直在发。停的是稳定版，beta 从未停。 真实问题不是停更，是版本号失序。

③ star 最少的 Tutti 反而是唯一持续发正式版的。 它 8 个 release 全部 prerelease=False，还维护一个 stable 滚动 tag（始终指向最新稳定版）。 对比 QwenPaw——34.7k star，最近 8 个 release 全部是 beta，至今没有一个正式版。

需要说清楚：这不构成统计结论，7 个样本说明不了普遍规律。 但它足够推翻一个常见直觉——「star 多 = 更成熟」在本批样本里不成立， 甚至方向相反。

3. 反直觉二：同赛道直接竞品，安全哲学完全相反

OpenClaw 与 QwenPaw 是七个样本里唯一的一对正面竞品：都做个人助理、 都跑在本地、都接 IM 渠道、都不代理第三方 agent。但安全默认值南辕北辙。

OpenClaw 的 README 自己写着：

"Tools run on the host for the main session unless you configure sandboxing." （除非你配置沙箱，否则工具直接跑在宿主机上。）

"DM-capable channels pair unknown senders by default." （支持私信的频道默认配对未知发送者。）

即：沙箱默认关闭。历史上它出过 CVE-2026-25253（CVSS 8.8）—— 访问一个恶意页面即可窃取认证令牌、禁用沙箱、在宿主机执行任意代码。 2.0 补齐了信任边界、最小权限、基于角色的权限分配与提示词滥用防护， 但"默认不开沙箱"这件事在 README 里是明示的。

QwenPaw 则是五层默认全开：

但两边都有各自的坑，别急着下结论：

• QwenPaw 的 Tool Guard 提供 OFF 档，整层可以关掉；Access Policy 也可配置为放行。 五层安全的强度取决于用户配置，不是不可绕过的硬边界。
• QwenPaw 主打「数据归你」，但 README 的 Telemetry 章节写明： qwenpaw init --defaults 会自动接受遥测，且每升级一个版本重新收集一次。 而 --defaults 恰恰是快速上手文档推荐的默认路径。
• OpenClaw 的坦诚反而值得肯定——它把"默认无沙箱"直接写在 README 的 Security 章节里， 并明确建议"不要把 Gateway 暴露到开放互联网"。明说风险，比不说的产品更可预期。

4. 反直觉三：三种「开源」，没有一种是字面意思

三个新样本的许可证分别是 MIT、Apache-2.0、Apache-2.0，但没有一个是字面意义上的"拿走就能完整用"。

OpenClaw：真 MIT，但自动化合规工具会误判。 LICENSE 原文是完整无改动的 MIT（Copyright 2026 OpenClaw Foundation）， 末尾多了一段 "Third-party notices ... recorded in THIRD_PARTY_NOTICES.md."。 就因为这段附加文字，GitHub 的 licensee 检测器判定为 NOASSERTION， 自动定级会给出"私有"的错误结论。法律上零风险，工程上会被合规扫描拦下。

Tutti：open-core 切分最干脆的一个。 README 的 Two Versions 对照表白纸黑字写着，以下七项开源版全部没有：

而 VM 版是 Early Access，创建一个 Room 就要邀请码（waitlist）。 也就是说：宣传语 "Where people and agents build in tune" 里的 "people" 那部分， 开源版里是不存在的。Apache-2.0 保证你能自由改代码，不保证你能用到它宣传的完整体验。

5. 代码级实测：Tutti 的引擎接入深度有多不对等

Tutti 是唯一能读到完整源码的样本（本地浅克隆 8291 个文件）， 所以这一节的每个数字都是 wc -l 实测，不是转述。

它的引擎接入是双层架构，这是七个样本里分层最清楚的：

第 1 层  packages/agent/daemon/runtime/acp_provider_*.go   ← ACP 协议适配
           opencode 301 行（+540 行测试）
           cursor   205 行
           nexight  122 行
           openclaw  52 行  ← 零测试
第 2 层  packages/agent/runtimeprep/                       ← 运行时准备
           codex  2170 行（16 个文件）
           tutti   653 行
           cursor  446 行
           claude  410 行
           opencode 392 行
           kimi    127 行
           computeruse / browseruse  43 行

全仓 363 个文件引用 ACP——是真集成，不是营销词。但两个问题很硬：

① 深度极不对等。 Codex 2170 行，是 Kimi（127 行）的 17 倍。 而且只有 Codex 有 Windows 变体文件（codex_directory_windows.go 149 行等 4 个）， 其余引擎一个 Windows 变体都没有——只有 Codex 在 Windows 上被真正验证过。

② 测试密度与投入规模成反比。

投入最重的 Codex 恰恰是质量保障最薄弱的地方——因为它的边界情况最多 （Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。 另有 19 个通用测试文件共 7851 行（preparer_test.go 单文件 2906 行）覆盖跨引擎路径，部分弥补了缺口。

③ README 与代码对不上，两个方向都偏。 README 宣称「当前支持 Claude Code、Codex、Hermes；OpenClaw in development」。 实际上：Hermes 没有 hermes.go，它走的是 extension_runtime.go 的 RTK Python 插件 （provider 标识 acp:hermes），只有测试文件；而 Cursor / OpenCode / Kimi / ComputerUse / BrowserUse 在代码里都有完整实现，README 的支持列表一个字没提。 结论：那份列表更像营销优先级排序，不是代码覆盖的如实反映。

6. 巴士系数全景：7 个样本第一次完整对照

这一轮补完了全部 7 个样本的提交分布（各取 main 分支最近 100 次提交）：

两个需要修正此前判断的地方：

• OpenWork 去重只有 3 人。 上一篇横评我评它"工程治理最好"——那说的是流程规范 （DCO sign-off、可执行的 evals、声明式 worlds、ee/ 需 CLA）。 但流程规范好和人员多样性好是两回事：它的规范是给外部贡献者准备的流程， 而实际干活的只有 3 个人。 规范是面向未来的基础设施，不是已经形成的分散式社区。
• Tutti 的 59% 修正了我的初步印象。 它发布纪律最好（全正式版 + stable 滚动 tag）， 但提交集中度 59%、去重仅 10 人。发布纪律好 ≠ 人员分散，两个维度各自独立。

Star 数与巴士系数同样没有相关性：58.8k 的 Orca 最集中（79%）， 34.7k 的 QwenPaw 最健康（15%）。

7. 坐标系的自我修正：OpenClaw 撑破了四个维度

上一篇建立的四个维度是为"开发向工作台"设计的。OpenClaw 进来后，四个维度没一个是为它准备的：

关键点在于「引擎立场」这一项：给 OpenClaw 打 1 分，含义不是"被绑定了"，而是"不需要中立"。 这两者在用户侧的风险完全不同：

• 「绑定单引擎」= 想换换不了（Maka 属于此类）
• 「自身即引擎」= 压根不用换（OpenClaw、QwenPaw 属于此类）

把它们混在同一根轴上会得出误导性结论。本系列的做法是照实标注而不是强行打分—— 在档案里把该项标记为「自身即引擎」，并在象限图脚注里说明。 同理，QwenPaw 的「引擎立场」也不适用，但要注意区分：它的模型层是真中立的 （14+ provider 可换），只是 agent 引擎层不存在中立问题。

象限图上还出现了一个新的技术性处理：7 个点里有两组坐标完全重合 （视图 A 里 Maka 与 OpenClaw 都是 6/1，视图 B 里 iPolloWork 与 Tutti 都是 7/7）。 完全重合的点会被后画的那个整个盖住，读者会以为少收录了一个项目， 所以脚本现在会把重合组沿一个小圆散开，并在图下注明。

8. 选型建议

按"你要解决什么问题"来选，而不是按 star 数：

通用提醒（对七个项目都成立）：

• 别把 star 数当成熟度指标——本批样本里它与工程纪律负相关。
• 别把许可证当功能完整度指标——Tutti 是 Apache-2.0，但核心协作功能在闭源侧。
• 引入前先查最近 100 次提交的作者分布，比看 contributor 总数有用得多。 本批样本里 contributor 基数与实际集中度完全脱钩（OpenClaw 号称 3001 人，实际 TOP1 占 64%）。

9. 追踪备注

本轮方法上的两点自我修正：

1. 不轻信媒体转述，也不轻信项目方宣称。 本轮有两条结论来自"核实后推翻"： - 「OpenClaw 停更 7 周」→ beta 从未停，真实问题是版本号倒挂 - 「OpenClaw 的 PR 已泛化成 AI 灌水」→ 抽样 60 条 open PR 全是规范的 conventional commits， 去重 22 位作者，未见灌水特征。但另一组数字值得警惕：60 条全部创建于同一天， 说明日 PR 量超过 60 条——流量压力真实存在，只是"质量崩坏"缺乏证据。
2. 档案里新增了"判定被推翻"的记录。 OpenClaw 的许可证自动定级为 L3/private， 人工读 LICENSE 原文后推翻为 L1/public（真 MIT）。这是本系列第二次遇到 「SPDX 不可信」，前一次是 OpenWork 的目录切分许可。 规则已经在 schema/license-tiers.yaml 里沉淀，但个案判例要留在档案里， 否则下次遇到同类项目还得重新推理一遍。

下一轮计划：

• 补齐 6 个项目的独立深度文（目前只有 iPolloWork 有）
• 坐标系需要演进：现有四维度对"个人助理层"适配度差，考虑引入 「是否代理外部引擎」「安全默认值强度」两个新维度
• OpenClaw（3.2 GB）受带宽与推送上限约束，本系列不镜像，仅存链接与元数据

数据与脚本开源在 gitinbox/agent-radar。 所有指标取自 GitHub API 2026-09-01 快照，所有代码行数均为本地源码实测。