GitOS-inbox/agent-radar
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 补齐 5 篇深度文（maka/openclaw/openwork/qwenpaw/tutti）+ 重算矩阵 + 总纲回填

Browse Source 
- articles/: 新增 5 篇深度文（八段结构，每篇含 claim_vs_reality）
  - maka.md → emlog_id=105
  - openclaw.md → emlog_id=106
  - openwork.md → emlog_id=107
  - qwenpaw.md → emlog_id=108
  - tutti.md → emlog_id=109
- data/projects/*.yaml: 回写 emlog_id 到 6 个档案（orca 前序已回写）
- articles/00-overview.md: build_matrix.py 重算矩阵 + 回填总纲
This commit is contained in:
gitea-publish
2026-09-03 23:39:58 +08:00
parent d9b9227d0a
commit de6cf8f3c0
12 changed files with 1263 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files
articles/00-overview.md
+6 -8
View File
@@ -261,19 +261,17 @@ Go 守护进程），但引擎接入深度严重向 Codex 倾斜、开源版功
| 项目 | 一句话结论 | 深度文 |
| --- | --- | --- |
| **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作 | [已发布](https://blog.apescale.com/?post=97) |
| **maka** | 唯一把「执行记录」当地基的项目 | 待发布（见下方横评） |
| **OpenClaw** | 388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动 | 待发布（见下方横评） |
| **openwork** | 把「能力」而不是「桌面」做成产品 | 待发布（见下方横评） |
| **orca** | 兼容面最广的并行 agent 编排外壳 | 待发布（见下方横评） |
| **QwenPaw** | 安全默认值最完整、巴士系数最健康的个人助理 | 待发布（见下方横评） |
| **Tutti** | 把「多 agent 共享上下文、接力干活」做成了产品，且是发布纪律最好的 | 待发布（见下方横评） |
| **maka** | 唯一把「执行记录」当地基的项目 | [已发布](https://blog.apescale.com/?post=105) |
| **OpenClaw** | 388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动 | [已发布](https://blog.apescale.com/?post=106) |
| **openwork** | 把「能力」而不是「桌面」做成产品 | [已发布](https://blog.apescale.com/?post=107) |
| **orca** | 兼容面最广的并行 agent 编排外壳 | [已发布](https://blog.apescale.com/?post=104) |
| **QwenPaw** | 安全默认值最完整、巴士系数最健康的个人助理 | [已发布](https://blog.apescale.com/?post=108) |
| **Tutti** | 把「多 agent 共享上下文、接力干活」做成了产品，且是发布纪律最好的 | [已发布](https://blog.apescale.com/?post=109) |
**跨项目文章**
- [四个 Agent 工作台的路线分野：把「多引擎中立」拆开看](https://blog.apescale.com/?post=99) — 2026-09-01
- [七个 Agent 项目，三种「开源」：当 star 数开始说反话](https://blog.apescale.com/?post=100) — 2026-09-01
> 待补深度文：maka、OpenClaw、openwork、orca、QwenPaw、Tutti。当前可先读上方跨项目文章，其中已包含这些项目的完整分维度对比。
<!-- INDEX:END -->
---
articles/maka.md
+239
View File
@@ -0,0 +1,239 @@
# maka 深度拆解：唯一把「执行记录」当地基的 agent 工作区
> **速览**
>
> | 项 | 值 |
> | --- | --- |
> | 仓库 | [apache/maka](https://github.com/apache/maka) |
> | 一句话 | local-first 的 AI agent 工作区——消息、工具调用、工具结果、权限决策、终止事件全部落 append-only 日志 |
> | Star / Fork / Issues | 4373 / 406 / 398 open（2026-09-01） |
> | 主语言 / 体积 | TypeScript 91.7% / ~100 MB |
> | 最新版本 / 节奏 | v0.2.0-dev.9.20260831 / 一天多版（全部为 Nightly，无正式 release） |
> | 许可证 | Apache-2.0（**L1 · 真开源，可自由再分发，自带专利授权**） |
> | 成熟度 | **孵化期**（ASF Incubating，治理最成熟、产品最年轻） |
>
> **一句话结论**：七个样本里唯一在「执行记录层」做事的项目——地基打得最实，房子盖得最慢；它和另外六家不是同一类选手，不该用同一把尺子量。
---
## 0. 先给结论
maka 的口号是 *"a local-first AI agent workspace"*，但真正定义它的是 tagline 后半句：**model messages, tool calls, tool results, permission decisions, and termination events are recorded as an append-only log**——把 agent 干过什么做成不可篡改的执行记录。
它真正有意思的地方有三个：
1. **它赌「可复现」是 agent 的生死线。** 别人卷功能广度（多少引擎、多少工具、多少平台），maka 卷的是"这个 agent 到底干了什么、能不能复现、能不能审计"。README 里有一句值得抄下来：*"Shorter context is not deleted history"*——上下文压缩只省略下次 prompt 里的旧 tool 输出，**已存证据不删**。
2. **它是七个样本里唯一自带评测框架的。** `maka eval run <spec>` 支持 task × repetition × subject 的 multi-arm 实验，对同一任务横向比较得分/成本/耗时，还可以把外部 agent（Codex / Claude Code 等）当被测对象（external subject adapter）拉进来跑。这让它在「agent 评测」这个还没被产品化的赛道上占了先发。
3. **它是 Apache 孵化项目，但没有任何正式 release。** 截至 2026-09-01，对外分发的只有 Desktop Nightly，README 明确标注 *"not an ASF release, not intended for production use"*。治理流程（DISCLAIMER-WIP、ASF_SOURCE_RELEASE 候选契约、SECURITY、中文文档）一步没少，产品交付一步未成。
而它最大的问题也有三个：**平台支持最窄**（macOS arm64 是唯一正式档，Windows 未签名预览，Linux 标 "soon"）、**功能面最保守**（内置工具只有 Read/Write/Edit/Bash/Glob/Grep 六个）、**API key 明文落盘**。
---
## 1. 赛道定位：它站在哪一层
沿用本系列的分层法：
```text
┌──────────────────────────────────────────────────────────────┐
│ 编排 / 工作台层 │
│ 跨引擎、跨 worktree、跨交付物的调度与观测外壳 │
│ ── orca（执行编排）/ iPolloWork（桌面工作台）在这里 ── │
├──────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
│ 嵌在 IDE / 编辑器里的交互层 │
├──────────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ 真正跑 agent loop 的地方 │
│ ── maka 的 AgentRun 在这里，且它是自己引擎的满分实现者 ── │
├──────────────────────────────────────────────────────────────┤
│ 执行记录层（maka 额外占的一层） │
│ append-only 日志 + 评测框架：agent 行为的可复现底座 │
└──────────────────────────────────────────────────────────────┘
```
**maka 的站位在七个样本里是独一份**：它对**自己的**引擎深度是满分（Desktop / TUI / CLI / Eval 四个入口全部经同一个 Runtime Host 执行），对**外部**引擎深度是零（只在 eval 里把外部 agent 当被测对象，不做执行层兼容）。
它压根不参与「多引擎中立」这条赛道的竞争——这是**定位选择而非能力缺陷**。Orca 用 PTY 外壳把 30+ 引擎拉平到最薄的一层；iPolloWork 用原生 adapter 给个别引擎做深；maka 直接不接，自己造引擎、自己记录、自己评测。它想回答的问题不是"怎么接最多 agent"，而是"agent 干了什么，怎么证明"。
越往这层走，越接近基础设施而非产品。风险也在这里：**「执行记录 + 评测」是引擎厂商最容易原生化的能力**——一旦 Codex / Claude Code 自己把 event log 和 eval 做进产品，maka 的地基优势会被稀释成一层"合规装饰"。这是它护城河最薄弱的地方，也是它最该被盯住的地方。
---
## 2. 业务维度：它靠什么活着（答案是：不靠）
**目标用户**三类，且都很垂直：
- 对**可审计性与数据主权**有硬要求的团队（金融、政务等受监管场景）
- 需要**横向评测**不同 agent / 模型的研究者与工程团队
- 愿意**用功能丰富度换确定性**的自用开发者
**变现路径：无。** Apache 孵化项目，无商业实体、无双许可、无付费层、不卖模型。这是七个样本里商业色彩最淡的一个——甚至淡到"商业模式空白"都不算风险，因为人家根本没打算有。它要的是标准、是治理背书、是生态位，不是营收。
**许可证**是 Apache-2.0，L1，七个样本里最干净的一档：可自由镜像与再分发、自带专利授权与反诉终止条款、修改需声明、NOTICE 须随分发保留、不授予 Apache/ASF 商标使用权。没有任何商业条款陷阱。
**护城河**由三件需要长期投入、无法速成的东西构成：**执行记录模型 + 可复现评测框架 + ASF 治理背书**。三者互相咬合——记录模型是评测框架的数据源，评测框架是记录模型的价值出口，ASF 治理背书则是前两者在"可信"维度上的放大器。但三者的共同弱点是**都不产生用户黏性**：换掉 maka 的迁移成本主要是历史执行记录，而非生态锁定（见 `vendor_lockin`：无付费层、无共享账号、数据落本地 SQLite、执行记录格式公开）。
---
## 3. 场景维度：它在什么场合被用
**人机协作是强人在环**，且是审批式：工具越过沙箱边界（写文件 / 跑 shell）必须先过审批；运行可中止；失败被分类。它不追求全自动——对"可审计"这个核心承诺来说，人的审批决策本身就是执行记录的一部分（permission decisions 也落日志）。
**三端形态，一个 Runtime Host：**
| 形态 | 定位 | 成熟度 |
| --- | --- | --- |
| 桌面应用（Electron） | 主工作环境 | Nightly，macOS arm64 唯一正式档 |
| TUI / CLI | 终端工作区 + 评测入口（`maka eval`） | 与桌面共用 Runtime Host |
| 评测框架 | multi-arm 实验：task × repetition × subject | 七个样本里独一份 |
**典型用例三类：**
- 在保密项目里用本地模型跑 agent，所有 tool call 与权限决策落 append-only 日志备查
- `maka eval run <spec>` 对同一任务跑 multi-arm 实验，横向比较不同 agent / 模型的得分 / 成本 / 耗时
- 会话崩了以后从执行记录恢复，并从任一 Turn 分叉出新会话继续
**交付物**是 code、artifact、**eval-report、execution-record**——后两项是七个样本里独一份的。orca 的交付纵深停在"代码 + 比对"，iPolloWork 纵深在"生成后仍可编辑"，maka 纵深在"过程本身成为可交付、可审计的资产"。
---
## 4. 技术维度：它怎么做到的
### 架构：四个入口，一个 Runtime Host
maka 的技术骨架一句话：**Desktop / TUI / CLI / Eval 全部经同一个 Runtime Host 执行**——单一所有者的生命周期 + 协议 + 客户端引导。技术栈是 Electron + React + TypeScript + Node.js + SQLite，外加两块"硬"的：peer mesh 的 **Rust native addon**（本地多设备 mesh）和 Runtime 的 Grep 工具对 **ripgrep** 的依赖。
```text
┌─ 桌面 / TUI / CLI / Eval ──────────────────────────────┐
│ │
│ 四个入口 ──统一──> Runtime Host（单一生命周期所有者） │
│ │ │
│ ├──> AgentRun（自带 agent loop）│
│ ├──> append-only 执行记录 │
│ └──> 沙箱边界审批（越界必过） │
│ │
│ 外部 agent：仅在 eval 环节经 external subject adapter │
│ 作为被测对象接入，不参与执行层 │
└─────────────────────────────────────────────────────────┘
```
与 orca 正好相反：orca 的 Runtime 是"薄外壳 + N 个别人的引擎"，maka 的 Runtime 是"厚内核 + 零个别人的引擎"。
### 引擎抽象：对内满分，对外为零
| 维度 | maka 的做法 |
| --- | --- |
| 兼容判据 | **不兼容外部引擎**（执行层） |
| 抽象层 | Runtime Host（单一所有者的生命周期 + 协议 + 客户端引导） |
| 结构化 tool call | 自家引擎全量结构化（自己记录，当然拿得到） |
| 统一权限回调 | 自家引擎全量统一（越界审批走 Runtime Host） |
| 外部 agent 对接 | 仅 eval 环节的 external subject adapter，当被测对象 |
这是 `engine_neutral = 1` 的含义：**它不是"中立做得差"，是"根本不玩这个游戏"**。把它和 orca（9 分）画在同一个坐标轴上，是系列对比的刻意选择——极端样本互相校准坐标系，中间值才有意义。
### 多 agent：Graph 模式，偏实验性
Graph 多算子并行，实现算子跑在**独立 git worktree**，但**要求源项目是干净 worktree**——有未提交改动就用不了。对比 orca 的并行 worktree（产品级封装，对脏工作区有处理），maka 的 Graph 更接近实验性能力。
### 本地优先：全场最彻底，但有一个明文暗礁
`local_first_score = 10`，七个样本最高——数据与执行记录不出机器，模型完全 BYO（云 API、本地模型或兼容网关，README 原话 *"You bring the model"*，不捆绑任何共享账号）。
但有一个细节必须单独说（见第 6 节 ②）：**API key 以明文文件存放**，README 自己承认 `credential-vault.json` 是 *"local plaintext file, readable only by your OS account"*。防护靠操作系统账户权限，不靠加密、不靠系统钥匙串。"数据不出机器"是真的，"数据都安全"则打问号。
### 扩展体系：有 MCP，skills 默认关，无插件市场
- **MCP**：`packages/mcp` 提供 provider-neutral 的 MCP 客户端集成
- **skills**：catalog skills 存在，但可选且**默认关闭**
- **plugins**：无独立插件市场
功能面是七个样本里最保守的：内置工具只有 **Read / Write / Edit / Bash / Glob / Grep** 六个；Computer Use 与 catalog skills 属可选且默认关闭；IM bot（聊天应用接入）标注 experimental。取舍很明确：**用广度换确定性**——每个内置能力都要先过"能不能落进执行记录"这道闸。
### 观测性：全场最强项
append-only 执行记录：model 消息、tool call、tool result、**turn 结束方式**全部落盘。上下文压缩只省略下次 prompt 里的旧 tool 输出，**不删已存证据**——*"Shorter context is not deleted history"*。崩溃恢复与可选续跑（注意：续跑**默认关闭**，见第 6 节 ③）。
---
## 5. 横向对比
> 说明：下表项目均已收录进本系列追踪库，数据来自各自档案（`data/projects/*.yaml`，2026-09-01 快照）。"引擎中立度 / 本地优先"取自档案 `chart.*`（1–10）。
| 维度 | maka | orca | iPolloWork | openwork | Tutti | QwenPaw | OpenClaw |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 站位层次 | **执行记录层 + 自带引擎** | 执行编排层（并行 fan-out） | 桌面工作台层 | 能力分发层 | 多人×多 agent 协作层 | 个人助理执行层 | 个人助理执行层（多渠道 Gateway） |
| 引擎中立度（1–10） | **1（不参与该赛道）** | 9（全场最高） | 7 | 6 | 8 | 2 | 1（自身即引擎） |
| 本地优先（1–10） | **10（全场最高）** | 6 | 7 | 6 | 7 | 9 | 8 |
| 交付纵深 | code + artifact + **eval-report + execution-record** | code + diff + review-comment | 生成后可编辑的多形态交付物 | 能力（MCP） | 多人协作会话 | 个人助理任务 | 个人助理任务 |
| 许可证 | **Apache-2.0（L1）** | MIT（L1） | L3 source-available | L3（目录切分） | Apache-2.0（L1） | Apache-2.0（L1） | MIT（L1，机器读不出） |
| 成熟度 | **孵化期（无正式 release）** | 原型期（一天一版） | beta（v0.50.x） | 0.x 活跃 | 快速成长期 | beta 活跃 | 高速迭代（约 4 天/版本） |
| 评测能力 | **唯一自带 eval 框架** | 无 | 无 | 无 | 无 | 无 | 无 |
maka 在谱系里的位置，用一句话概括：**引擎中立度清零、本地优先打满、观测性独一份的那个角落。** orca 与 QwenPaw/OpenClaw 是同一坐标轴上的两个极端（9 分 vs 1-2 分），maka 是第三个极端——它让"引擎中立"这个维度对自己失去意义，换来"执行记录"这个新维度上的独占。七个样本里，只有它值得问"agent 干了什么"；其他六家的交付物回答的是"agent 做出了什么"。
---
## 6. 宣称 vs 实测
这一节是本系列最看重的部分。maka 项目方没有说谎——它的 README 甚至是七个样本里自我披露最充分的（多处主动写限制）——但"披露得充分"和"没有坑"是两回事。
**① 宣称：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。
**② 宣称：「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_RUNTIME_SAFE_BOUNDARY_RESUME=1`，且 README 明确警告该调用会打模型、消耗 token。另存在**升级断代**：旧版 JSONL transcripts 与 Electron safeStorage 凭据不会被导入，升级后的工作区可能出现空线程，凭据必须重新录入。
**来源**：README「Local data and recovery」段。
**④ 宣称：（无明确宣称，但易被期待为开箱即用的完整工作台）。**
**实际**：内置工具只有 Read / Write / Edit / Bash / Glob / Grep 六个；Computer Use 与 catalog skills 属可选且**默认关闭**；IM bot（聊天应用接入）标注 experimental。功能面是七个样本里最保守的——取舍很明确：用广度换确定性。
**来源**：README「Current capabilities」段。
**⑤ 宣称：支持 Graph 多算子并行。**
**实际**：Graph 的实现算子跑在独立 git worktree，且**要求源项目是干净 worktree**——有未提交改动就用不了。相比 Orca 的并行 worktree（产品级封装），Maka 的 Graph 更接近实验性能力。
**来源**：README「Terminal entry points」段。
五条里有四条是 README **自己写出来的**——这是 maka 工程文化的一个侧面：不藏限制，但也不粉饰。① 和 ② 合起来看是理解 maka 的钥匙：**「治理成熟度最高、产品成熟度最低」**——治理文件（DISCLAIMER-WIP、ASF_SOURCE_RELEASE 候选契约、CONTRIBUTING、SECURITY、中文文档齐全）一步没少，产品交付（正式 release、平台覆盖、功能面）一步未成。
---
## 7. 结论：什么人该用它
**该用：**
- 对**审计、数据主权、可复现评测**有硬要求的团队（受监管场景尤甚）
- 做 **agent 横向对比研究**的工程团队——`maka eval` 是当前唯一"自带、可复现、multi-arm"的开源评测入口
- 愿意用 Nightly 的稳定性风险，换"执行记录不出机器 + Apache-2.0 可再分发 + 无商业实体锁定"的自用开发者
**不该用：**
- 要**开箱即用完整工作台**的人——六个内置工具、skills 默认关、Computer Use 默认关，功能面全场最保守
- 需要 **Windows / Linux 正式支持**的人——目前只有 macOS arm64 是正式档
- 以为 **ASF 品牌等于生产可用**的决策者——没有正式 release 就是没有正式 release
- 把 **API key 安全**托付给应用层的团队——明文文件 + OS 账户权限，不满足最小权限/加密存储的合规要求
**再看看：** 等四件事落地再评估——① 第一个 **Apache 正式 release**（INCUBATING → 毕业信号，当前连 ASF_SOURCE_RELEASE 候选都还没有）② Linux 与 Windows 是否进入正式支持档 ③ 上游引擎是否把「event log + eval」原生化（这是它护城河的头号威胁，**Codex / Claude Code 官方做评测框架的动作值得每季度盯一次**）④ 续跑与 Graph 是否从实验能力走向默认能力（worktree 干净度要求是否会放宽）。
---
## 8. 追踪备注
- **数据日期**：2026-09-01（GitHub API 快照）
- **指标**：★ 4373 / fork 406 / open issues 398 / subscribers 23 / ~100 MB / TypeScript 91.7% + Rust 1.7%
- **最新版本**：v0.2.0-dev.9.20260831，一天多版（均为 Nightly，无正式 release）
- **源码镜像**：`gitinbox/maka`（**public**，source-only 快照 ~12 MB——depth=1 浅仓被 Gitea 拒绝，--unshallow 后完整裸仓 163 MB 超 nginx ~50 MB 上限，遂剔除 png/gif/mp4/字体降级为源码快照；完整保真裸仓保留在本地 `.mirrors/maka.git`，服务器放开上限后可推完整版）
- **结构化档案**：`data/projects/maka.yaml`
**下次跟进点：**
1. ASF 孵化进度：DISCLAIMER-WIP 何时移除、第一个正式 release 何时出（毕业信号）
2. 平台覆盖：Linux / Windows 是否从 "soon" / 未签名预览 进入正式档
3. 上游威胁：Codex / Claude Code 官方是否原生化「执行记录 + 评测」能力
4. 功能面：续跑（safe boundary resume）与 Graph 是否从实验/默认关闭走向默认开启
---
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
articles/openclaw.md
+228
View File
@@ -0,0 +1,228 @@
# OpenClaw 深度拆解：388k star 的个人 AI 助理，以及它撑破坐标系的方式
> **速览**
>
> | 项 | 值 |
> | --- | --- |
> | 仓库 | [openclaw/openclaw](https://github.com/openclaw/openclaw) |
> | 一句话 | 常驻你自己机器上的个人 AI 助理，从 WhatsApp / Telegram / iMessage 等聊天软件直接驱动 |
> | Star / Fork / Issues | **388438** / 81543 / 5925 open（2026-09-01，GitHub 星标最多的软件仓库） |
> | 主语言 / 体积 | TypeScript 91% / **3.3 GB**（七个样本最大） |
> | 最新版本 / 节奏 | v2026.8.1（2.0）/ 约 4 天/版本（10 个月 237 次迭代） |
> | 许可证 | MIT（**L1**，但 SPDX 误判为 NOASSERTION，机器读不出来） |
> | 成熟度 | 高速迭代期（功能面极广、版本号体系失序、安全默认偏松） |
>
> **一句话结论**：七个样本里唯一不面向开发者的项目——它撑破了本系列的坐标系，四个维度均非为其设计；它也是"本地运行 ≠ 默认安全"最典型的判例。
---
## 0. 先给结论
OpenClaw 的 tagline 是 *"Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞"*。它做的不是 agent 工作台，不是编排外壳，不是能力分发层——**它自己就是 agent**，跑在自己的执行循环里，不代理任何第三方引擎，用户入口也不是 IDE 或桌面工作台，而是**你已经在用的聊天软件**。
这一条把它和其余六个样本彻底分开：**其余六个的用户是开发者，OpenClaw 的用户是普通人。**
它真正有意思的地方有三个：
1. **它是 GitHub 星标最多的软件仓库（388k），但三个月内改过两次名。** Clawdbot（2025-11）→ Moltbot → OpenClaw（2026-01-30 定名）。检索历史资料时极易漏掉前两个名字，这是研究它时第一个要建立的认知。
2. **创始人在项目登顶前加入了 OpenAI。** Peter Steinberger 2026-02 加入 OpenAI，项目转由独立非营利基金会（OpenClaw Foundation）运营，OpenAI 承诺在保持 MIT 的前提下继续赞助。这是一个"创始人进了最大潜在竞争对手"的罕见结构。
3. **它是七个样本里唯一出过高危 CVE 的。** CVE-2026-25253（CVSS 8.8）：**访问一个恶意页面**即可窃取认证令牌、禁用沙箱、在宿主机执行任意代码。配合"默认无沙箱"的默认值，这一条不是边缘案例，而是主路径风险。
而它最大的问题也有三个：**沙箱默认关闭**、**版本号体系乱到无法判断新旧**、**巴士系数接近 1**（最近 100 次提交创始人独占 64%）。
---
## 1. 赛道定位：它不在坐标系里
沿用本系列的分层法，OpenClaw 的站位需要单独处理：
```text
┌──────────────────────────────────────────────────────────────┐
│ 编排 / 工作台层 │
│ ── orca / iPolloWork / tutti 在这里 ── │
├──────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
├──────────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ ── OpenClaw 在这里（自身即引擎）── │
├──────────────────────────────────────────────────────────────┤
│ 个人助理执行层（OpenClaw 额外占的一层） │
│ 面向非开发者：聊天渠道入口 + 本地 Gateway 控制面 │
│ 交付"事务结果"（邮件/日程/值机）而非文件型交付物 │
└──────────────────────────────────────────────────────────────┘
```
**`engine_neutral = 1` 的含义必须读对**：OpenClaw 不是"多引擎中立做得差"，而是**自身即引擎**，`supported: []`——它压根不接别人的 agent。横向对比时把它的引擎立场标记为「自身即引擎」而非「绑定单引擎」，两者在用户侧的风险完全不同：**绑定单引擎是"换不了"，自身即引擎是"不用换"**。
档案里对四个坐标轴有一条诚实的 `chart_note`：**"本样本撑破了现有坐标系——四个维度均非为其设计，坐标仅作同图可比之用"**（form 6 / eng 1 / local 8 / deliv 2）。deliverable_depth = 2 不是贬义——它产出的是"事儿办完了"（邮件发了、日程改了、值机办了），不是可编辑交付物体系；用"交付物纵深"这把尺子量它，本身就是错配。
越往这一层走，越接近消费级产品。风险也一样明显：**它的价值建立在"替用户操作真实账号"之上，而这个能力任何一家操作系统厂商（Apple Intelligence / 微软 Copilot）都能在系统层直接拿走**；更近的威胁是创始人所在的 OpenAI 随时可能推出官方同类覆盖。
---
## 2. 业务维度：它靠什么活着（靠赞助，暂且）
**目标用户**是七个样本里唯一非开发者的画像：想让 AI 接管日常事务（收件箱、日历、出行）的**非技术用户**、重度聊天软件用户（WhatsApp / Telegram / iMessage / Signal）、以及想在自己机器上跑私人助理、**拒绝 SaaS 托管**的数据敏感用户。
**变现路径：免费 + 赞助。** README 有 Sponsors 段；创始人加入 OpenAI 后，OpenAI 承诺在保持 MIT 的前提下继续赞助，项目转独立非营利基金会运营。目前看不到任何收费层——没有企业版、没有订阅、没有付费插件。
**许可证**是 MIT，L1，法律上零风险。但有一个必须在企业落地前知道的工程细节：GitHub 的 licensee 检测器因为 LICENSE 末尾多了一段第三方声明指引（*"Third-party notices ... recorded in THIRD_PARTY_NOTICES.md"*）而判定 **NOASSERTION**，自动定级会给出 L3/private 的错误结论。**这是继 OpenWork 之后第二个「SPDX 不可信，必须读原文」的判例**——原文主体是完整无改动的 MIT（Copyright 2026 OpenClaw Foundation），附加段落不构成许可条款变更。后果是：自动化合规扫描（licensee / FOSSology）会把它拦下，企业引入需要人工出具复核说明。"机器读不懂"的成本，比许可证本身的限制更影响落地。
**护城河**是网络效应，且在两侧同时成立：**聊天渠道覆盖面**（WhatsApp / Telegram / Slack / Discord / Google Chat / Signal / iMessage 等 8+ 通道）+ **3001 名累计贡献者的插件生态**（Skills 系统 + ClawHub 市场 clawhub.ai）+ 跨端伴侣 App（macOS / Windows / iOS / Android 节点）。渠道越全，插件生态越厚；插件越厚，渠道越有粘性。这是七个样本里唯一同时押注"入口"和"生态"两个网络效应的结构。
---
## 3. 场景维度：它在什么场合被用
**人机协作是配对审批式**：支持 DM 的频道**默认会配对未知发送者**，需人工 `openclaw pairing approve` 确认——防止陌生人通过你的聊天渠道使唤你的助理。2.0 新增私密凭据请求（遮罩输入，敏感信息不进聊天记录与模型上下文）与插件安装前能力展示。
**形态是"本地守护进程 + 多渠道前端"：**
| 形态 | 定位 | 说明 |
| --- | --- | --- |
| 本地 Gateway（守护进程） | **控制面**，唯一本体 | 没有 IDE 形态，不是传统桌面工作台 |
| 聊天软件频道 | **主要入口** | 8+ 通道：WhatsApp / Telegram / Slack / Discord / Google Chat / Signal / iMessage |
| Web Control UI / CLI / TUI | Gateway 的管理面 | Control UI 只是 Gateway 的一个 Web 前端 |
| 桌面 / 移动端伴侣 App | 能力延伸 | macOS / Windows / iOS / Android 节点，提供语音 / 摄像头 / 屏幕 / Canvas |
**典型用例三类：**
- 发一张后院蛇的照片给助理，它识别物种、给出当地动物救助电话、建议怎么抓
- 让助理每天早上把行业资讯摘要推到 Telegram
- 2.0 起：在 Mac 上开始一件事，交给云端 worker 继续跑完；一条会话授权给同事，多人带完整上下文接力
**交付物**是**事务结果**（邮件 / 日程 / 预订 / 消息）而非文件型交付物，外加文件与本地系统操作、Canvas / 语音 / 图像（伴侣 App 侧）。这是 `deliverable_depth = 2` 的由来——它的"交付"是状态改变，不是工件。
---
## 4. 技术维度：它怎么做到的
### 架构：本地 Gateway 为控制面，多渠道为前端
```text
┌─ 聊天渠道（主要入口）─────────────────────────────────────┐
│ WhatsApp · Telegram · Slack · Discord · iMessage · Signal │
│ Google Chat · ...（8+ 通道） │
└──────────────────────────┬────────────────────────────────┘
│
┌──────────────────▼──────────────────┐
│ 本地 Gateway（守护进程，控制面） │
│ ───────────────────────────────── │
│ 自己的 agent loop（自身即引擎） │
│ tools / skills / plugins（ClawHub） │
│ 配对审批 · 权限 · 密钥 · 记忆 │
│ SQLite（2.0 从文件系统迁移） │
└──────────────────┬──────────────────┘
│
伴侣 App 节点（macOS / Windows / iOS / Android）
语音 / 摄像头 / 屏幕 / Canvas + 2.0 云端 worker
```
技术栈是 TypeScript 91% + Swift 4.6%（macOS / iOS 原生）+ Kotlin 1.8%（Android 原生），仓库 3.3 GB——七个样本里最大，也是它无法被本体系镜像的硬原因（见第 8 节）。
### 引擎抽象：不适用
`engine_abstraction` 字段对 OpenClaw **不适用**，这是它区别于其余 6 个样本的根本点：不代理任何第三方 agent，自己跑自己的执行循环。可扩展性走 **tools / skills / plugins** 三条路（ClawHub 市场），不是"接别人的引擎"。2.0 起插件安装前展示能力、来源、版本；来自可执行来源的插件需强制参数确认。
### 模型绑定：不绑，但 2.0 有了默认值
支持 hosted 与 local model providers；2.0 默认 **GPT-5.6**，本地模型方面把 node-llama-cpp 换成托管 llama-server，默认上下文提到 64K。BYO 成立，但有厂商默认值——这跟 maka 的"完全 BYO、无默认"是两条路。
### 多 agent：2.0 的共享云端会话
一个会话可授权给多名成员，完整上下文保留、可接力与实时协作；会话能在本地设备、配对机器、云端 worker 之间迁移；底层存储从文件系统迁到 SQLite。这是它 `local_first_score` 从 9 降到 8 的原因——**2.0 主动把一部分会话放上了云**。
### 权限与沙箱：⚠️ 默认无沙箱
README Security 章节原文：*"Tools run on the host for the main session unless you configure sandboxing."*——不显式配置，工具直接跑在宿主机上。官方另建议：不要暴露 Gateway 到开放互联网、维持强认证。2.0 补齐了信任边界、最小权限、基于角色的权限分配与提示词滥用防护，但**默认值没有变**。
### 观测性：够用，非卖点
Gateway 提供事件流；Control UI 可实时观看正在执行的任务、查看组件仪表盘；2.0 新增会话精确搜索（可按词句回跳到上下文消息）。对比 maka 的 append-only 执行记录，OpenClaw 的观测是"看得见正在做什么"，不是"事后可完整复现与审计"。
---
## 5. 横向对比
> 说明：下表项目均已收录进本系列追踪库，数据来自各自档案（`data/projects/*.yaml`，2026-09-01 快照）。OpenClaw 的坐标带保留警告：四维度均非为其设计。
| 维度 | OpenClaw | QwenPaw | maka | orca | iPolloWork | openwork | Tutti |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 目标用户 | **非开发者（普通人）** | 开发者 + 数据敏感用户 | 审计/评测硬要求团队 | 重度 CLI agent 用户 | 需要交付物的知识工作者 | 想把"能力"产品化的团队 | 多人协作开发者 |
| 引擎立场 | **自身即引擎（不接别人）** | 自身即引擎（模型层 14+ provider 中立） | 自带 Runtime（eval 里测外部） | PTY 外壳（30+ 引擎，最深 9 分） | 原生 adapter（7 分） | 能力面接 4+ 引擎（6 分） | ACP 双层（8 分） |
| 本地优先（1–10） | 8（2.0 云端会话扣分） | 9 | **10** | 6 | 7 | 6 | 7 |
| 入口 | **聊天软件（8+ 通道）** | 桌面/CLI/IM | 桌面 + TUI/CLI + Eval | 桌面 + 移动端伴随 | 桌面工作台 | CLI / SDK | 桌面 + 多 Agent |
| 交付物 | **事务结果**（邮件/日程/值机） | 助理任务结果 | code + eval-report + execution-record | code + diff | 生成后可编辑的多形态 | 能力（MCP） | 多人协作会话 |
| 许可证 | MIT（L1，机器读不出） | Apache-2.0（L1） | Apache-2.0（L1） | MIT（L1） | L3 source-available | L3（目录切分） | Apache-2.0（L1） |
| 安全默认 | **⚠️ 默认无沙箱 + 出过 CVE 8.8** | 五层安全全部默认开启 | 越界审批 + 记录全落盘 | 无统一权限回调 | 沙箱 + 审批 | MCP 层控制面 | 沙箱边界 |
| 体量 / 节奏 | **388k ★ / 3.3 GB / 约 4 天/版** | 34.8k ★ / 约 1 天/版 | 4.4k ★ / 一天多版（无正式 release） | 58.8k ★ / 约 1 天/版 | 5.2k ★ / 一天多版 | 23.3k ★ / 约 1 天/版 | 3.7k ★ / 约 3 天/版 |
OpenClaw 在谱系里的位置，用一句话概括：**star 数一个数量级高于其余六家之和、用户画像完全不同（唯一非开发者向）、且是"自身即引擎"阵营里体量最大的那个。** 和 QwenPaw 同处"个人助理执行层"，但 QwenPaw 靠安全默认值与本地可跑取胜、面向开发者；OpenClaw 靠渠道覆盖与插件生态取胜、面向普通人——同一个层，两个完全相反的风险面。
---
## 6. 宣称 vs 实测
这一节是本系列最看重的部分。OpenClaw 项目方基本没说谎，但它的数字和"媒体转述的数字"都有失真——**两边都要核实**。
**① 宣称（多家媒体转述）：停更 7 周（7 月中旬 v2026.7.1 之后断更）。**
**实际**：失真。查 release 时间轴：7-18 → 7-28 → 8-01 → 8-02 → 8-04 → 8-08 → 8-15 → 8-24 → 8-28 → 8-31 **一直在发。停的是稳定版，beta 从未停。** 但真实问题比"停更"更值得警惕：版本号体系已经乱到无法从版本号判断新旧——8-28 发的 v2026.9.1-beta.1 **早于** 8-31 的正式版 v2026.8.1；而 v2026.6.33 / v2026.6.34（8-08）又晚于 v2026.7.1-1 / -2（8-04）。多线并行导致版本号与实际时间顺序倒挂。
**来源**：GitHub releases API（2026-09-01 取最近 12 个 release 的 published_at）。
**② 宣称（项目方与媒体反复引用）：3001 名贡献者 / 933 人共建 2.0。**
**实际**：数字属实，但不能推导出"去中心化"。抽样最近 100 次提交：创始人 steipete **独占 64 次（64%）**，第二名 vincentkoc 仅 4 次，去重作者 27 人。**巴士系数接近 1**——贡献者基数和实际决策集中度是两回事。388k star 的仓库，主路径代码系于一人之手。
**来源**：GitHub commits API（2026-09-01 取 main 分支最近 100 次提交的 author.login 分布）。
**③ 宣称（多家媒体报道）：PR 已经泛化成 Prompt Requests，AI 批量灌水。**
**实际**：抽样最新 60 条 open PR，**不支持**这个说法：标题全部是规范的 conventional commits（fix(memory-core)、refactor(sessions)、perf(media)），去重 22 位作者，未见灌水特征。但另一组数字确实异常：60 条**全部创建于 2026-09-01 同一天**，说明日 PR 量超过 60 条——流量压力真实存在，只是"质量崩坏"缺乏证据。媒体报道的"必须附对话记录/截图/测试证据才能过审"是维护方的应对动作，从这批样本看，它似乎有效。
**来源**：GitHub pulls API（state=open, sort=created, direction=desc, per_page=60）。
**④ 宣称：跑在你自己的设备上、own your data。**
**实际**：前半句属实（Gateway 是本地控制面，支持本地模型）。但**安全默认值偏松**：README 原文承认工具默认跑在宿主机上、除非你配置沙箱；支持 DM 的频道默认配对未知发送者（需人工 approve）。历史上出过 **CVE-2026-25253（CVSS 8.8）：访问一个恶意页面即可窃取令牌、禁用沙箱、在宿主机执行任意代码**。**"本地运行"不等于"默认安全"**——这是本系列里"数据主权"宣称与"安全默认值"落差最大的一个样本。
**来源**：README Security 章节原文；CVE-2026-25253（媒体报道，CVSS 8.8）。
**⑤ 宣称：MIT 开源。**
**实际**：属实，但**机器读不出来**。GitHub 的 licensee 因为 LICENSE 末尾多了一段第三方声明指引而判定 NOASSERTION，自动定级会给出 L3/private 的错误结论，必须人工读 LICENSE 原文（1170 字节）才能纠正为 MIT / L1。企业引入时会被自动合规扫描拦下，需要人工出复核说明。
**来源**：GitHub license API 取原始文件，人工阅读全文。
第 ② 和 ④ 合起来看，是理解 OpenClaw 工程治理的钥匙：**388k star、10 个月 237 次迭代、巴士系数接近 1、默认无沙箱且出过 CVSS 8.8**——这是一个"现象级增长 + 个人英雄式维护 + 消费级安全默认"的组合。它迭代快，是因为创始人在猛冲；它安全事件多，是因为默认值没有为"普通人"设计（普通人才是最需要默认值的人）。2.0 的方向（信任边界、最小权限、RBAC、升级前备份提示）说明团队意识到了，但默认值尚未翻转。
---
## 7. 结论：什么人该用它
**该用：**
- 想让 AI **真正接管日常事务**（收件箱 / 日历 / 出行）且**愿意自己加固部署环境**的重度个人用户——你会配沙箱、不暴露 Gateway、强认证、管配对审批
- 数据敏感、拒绝 SaaS 托管私人助理的用户——Gateway 本地跑，模型可本地（llama-server，默认 64K 上下文）
- 想研究"非开发者向 agent 产品长什么样"的人——**七个样本里唯一的样本**，渠道入口 + 插件生态 + 跨端节点的结构值得逐层拆解
**不该用：**
- 把 **star 数当成生产就绪度**的人——388k star 不等于 388k 份 SLA，巴士系数接近 1，主力开发者一停，主路径就停
- 指望**沙箱开箱即保护**的人——默认无沙箱 + CVE-2026-25253 的前科，"访问一个恶意页面即可 RCE" 不是理论攻击
- 需要**可预测升级路径**的团队——版本号体系倒挂（v2026.9.1-beta.1 早于 v2026.8.1），2.0 自己承认"从 v2026.7.1 及更早版本升级时可能破坏原有 Agent 配置"，官方建议升级前先备份
- 希望助理**中立接入多个引擎**的人——它自己就是引擎，不接别人；想换引擎等于换掉整个助理
- 走**自动化开源合规流程**的企业——SPDX=NOASSERTION 会被扫描器自动拦下，需人工复核说明
**再看看：** 等四件事落地再评估——① **沙箱默认值是否翻转**（2.0 的信任边界 / RBAC 是否成为默认而非选配，这是它从"个人项目"走向"可托付"的单一最大变量）② 版本号体系是否恢复单调（能否从版本号判断新旧，决定它能不能被团队采用）③ 创始人加入 OpenAI 后的**赞助与治理稳定性**（非营利基金会是否有独立资金源，OpenAI 是否推出官方同类）④ 云端共享会话（2.0 新增）与"own your data"宣称的边界——哪些数据会经过云。
---
## 8. 追踪备注
- **数据日期**：2026-09-01（GitHub API 快照）
- **指标**：★ 388438（GitHub 星标最多的软件仓库）/ fork 81543 / open issues 5925 / subscribers 1754 / 3.3 GB / TypeScript 91% + Swift 4.6% + Kotlin 1.8%
- **最新版本**：v2026.8.1（2.0，2026-08-31 发布），节奏约 4 天/版本，10 个月 237 次迭代
- **源码镜像**：`gitinbox/openclaw`（**public，link-only——不镜像**，3.3 GB 撞两条硬约束：GitHub 链路约 50 KB/s 全量拉取需约 19 小时且无断点续传；Gitea 前置 nginx client_max_body_size 约 50 MB，超限两个数量级，连源码快照降级也远无法覆盖。许可证是 MIT 人工复核，无合规障碍，纯粹体积不可行）
- **结构化档案**：`data/projects/openclaw.yaml`
**下次跟进点：**
1. **沙箱默认值**：2.0 的信任边界 / 最小权限 / RBAC 是否从选配变默认（头号跟进项）
2. **版本号体系**：是否恢复单调可判断（倒挂是否继续恶化）
3. **治理结构**：OpenClaw Foundation 的独立资金与治理动作；OpenAI 是否推出官方同类产品
4. **安全事件**：CVE-2026-25253 的修复面是否覆盖"访问恶意页面"路径；有无新 CVE
5. **2.0 升级破坏面**：v2026.7.1 → 2.0 的"可能破坏原有 Agent 配置"实际影响面如何
---
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
articles/openwork.md
+239
View File
@@ -0,0 +1,239 @@
# openwork 深度拆解：把「能力」而不是「桌面」做成产品
> **速览**
>
> | 项 | 值 |
> | --- | --- |
> | 仓库 | [different-ai/openwork](https://github.com/different-ai/openwork) |
> | 一句话 | "The open-source alternative to Claude Cowork (powered by opencode)"——但它替代的不是 Cowork 本身，而是 Cowork 唤起的「能力复用」诉求 |
> | Star / Fork / Issues | 23253 / 2307 / 414 open（2026-09-01） |
> | 主语言 / 体积 | TypeScript 89.9% / ~291 MB |
> | 最新版本 / 节奏 | v0.18.40 / 约 1 天/版本 |
> | 许可证 | **目录切分许可（GitLab 式）**：ee/ 之外 MIT，ee/ 为 OpenWork EE License（SPDX=NOASSERTION，**L3**） |
> | 成熟度 | **0.x 活跃**（工程治理七家最规范，产品仍在 0.x） |
>
> **一句话结论**：七个样本里唯一不抢「桌面入口」、专做「能力分发」的项目——它把自己做成一个 MCP server 让别人来连，工程治理最好，但它和自称要替代的东西不是一个物种。
---
## 0. 先给结论
openwork 的 tagline 是 *"The open-source alternative to Claude Cowork (powered by opencode)"*，但真正定义它的是 README 里一句容易被忽略的话：**"The desktop app is there when you want a dedicated workspace, but it is not required"**——桌面端只是可选项，主体是 OpenWork MCP 与 Den 控制面。
它真正有意思的地方有三个：
1. **它是七个样本里唯一站在「能力分发层」的。** 别人卷的是桌面入口、引擎兼容、执行记录、个人助理，openwork 卷的是"一套 skills / MCP / 连接，怎么让组织里的人在不同工具里复用"。它的核心资产不是桌面 app，是 **OpenWork MCP** 和 **Den 控制面**——把 skills / MCP / 连接服务做成可跨工具、跨人、跨机器复用的组织级能力包。
2. **它用「反向注入」解决多引擎问题。** 七个样本里大多数项目的多引擎策略是「我去适配你的引擎」，openwork 反过来：**把自己做成 MCP server，让各引擎来连**。对外只暴露两个工具——`search_capabilities` 与 `execute_capability`。所有引擎都以同一个 MCP 客户端身份接入，拿到的是能力调用，不是执行控制。OpenWork 不接管 agent 的执行循环、不负责上下文管理、不做权限回调。
3. **它是七个项目里工程治理最规范的。** 强制 DCO sign-off（每个 commit 都要 Signed-off-by），ee/ 目录的改动还需额外 CLA；`evals/` 目录放可执行测试规格并要求 PR 附测试证据；`worlds/` 放声明式的开发与测试环境定义。SPDX 为 NOASSERTION 恰恰是「不够开源」的误读——它只是根目录 LICENSE 是混合声明文件，开放度分目录看（ee/ 之外纯 MIT）。
而它最大的问题也有三个：**形态与宣称错位**（Cowork 是桌面操控型 agent，openwork 是能力分发型 MCP 层，二者不是一个物种）、**「跨引擎」是能力面而非执行面**（对 OpenCode 是原生，对其余引擎只通过 2 个 MCP 工具对接）、**ee/ 目录生产使用需付费订阅**（5 人以下/30 天评估/开发测试豁免，但组织规模上来就要钱）。
---
## 1. 赛道定位：它站在哪一层
沿用本系列的分层法：
```text
┌──────────────────────────────────────────────────────────────┐
│ 编排 / 工作台层 │
│ 跨引擎、跨 worktree、跨交付物的调度与观测外壳 │
│ ── orca（执行编排）/ iPolloWork（桌面工作台）在这里 ── │
├──────────────────────────────────────────────────────────────┤
│ 能力分发层（openwork 占的一层） │
│ 把 skills / MCP / 连接做成可跨工具复用的组织级能力包 │
│ ── openwork 的 OpenWork MCP + Den 控制面在这里 ── │
├──────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
│ 嵌在 IDE / 编辑器里的交互层 │
├──────────────────────────────────────────────────────────────┤
│ 执行引擎层 │
│ 真正跑 agent loop 的地方 │
│ ── Codex / Claude Code / OpenCode / 各引擎在这里 ── │
└──────────────────────────────────────────────────────────────┘
```
**openwork 的站位在七个样本里是独一份**：它对**桌面入口**的争夺是零（桌面 app 明确标为可选），对**执行层**的争夺也是零（不接管任何引擎的 agent loop）。它抢的是中间那层——**「能力从哪来、谁能用、怎么分发」**。
这与 orca 和 iPolloWork 形成鲜明对照：orca 用 PTY 外壳把 30+ 引擎拉平到最薄的一层（执行编排），iPolloWork 用原生 adapter 给个别引擎做深（桌面工作台），openwork 直接不碰执行层和桌面入口——它想回答的问题不是"怎么接最多 agent"或"怎么做出最好用的工作台"，而是**"组织的能力怎么一次创建、处处复用"**。
风险也在这里：**「跨工具能力分发」是引擎厂商最容易原生化的一层**——一旦 Anthropic / OpenAI 官方的 skills 市场与组织管理后台做好跨工具分发，openwork 的价值窗口就关闭了。它的护城河（组织侧能力分发 + 工作流网络效应）建立在一个时间窗口上：**官方还没做好这件事**。这是它最该被盯住的地方。
---
## 2. 业务维度：它靠什么活着
**目标用户**三类，都很垂直：
- 已在使用 Codex / Claude Code / Cursor 且**不想换工具**的开发者
- 需要**统一管控 agent 能力**（谁能用什么模型、谁能拿到什么 skill）的中大型组织
- 想把自己搭好的工作流**分发给同事或朋友**的团队
**变现路径：Den 订阅（组织控制面）。** 免费额度写得很明确：5 人以下组织的非 Enterprise 功能全免、任意规模 30 天评估、开发测试永久免费。个人和小团队几乎不会触发付费条件，但组织规模上来就要订阅——这是典型的 open-core 模型。
**许可证**是目录切分许可（GitLab 式）：ee/ 之外为 MIT（L1 级），ee/ 为 OpenWork EE License（source-available，生产使用需订阅）。整体 SPDX=NOASSERTION，openness=L3。有一个值得单独说的机制：**ee/ 版本公开发布满两年后自动追加 MIT 授权**（Grant of Future License）——早期版本最终也会进入开源域，更早版本仍受原 FSL-1.1-MIT 约束，不自动升级。客户端侧资源（image / font / CSS / 编译产出的 JS）始终为 MIT。
**护城河**由两件事构成：**组织侧的能力分发与治理**（谁能用什么模型、谁能拿到什么 skill），以及**「一次创建、处处复用」带来的工作流网络效应**。一旦组织把内部 skills 都发布到 Den，迁移成本取决于是否有导出路径——README 未说明，这是一个未明的锁定风险。
**竞争风险**非常直接：最容易被 Anthropic / OpenAI 官方的 skills 市场与组织管理后台正面取代。openwork 的价值恰恰建立在「官方还没做好跨工具能力分发」这个时间窗口上——窗口一关，护城河就变成一张过期的门票。
---
## 3. 场景维度：它在什么场合被用
**人机协作是审批式**，但审批不在执行层而在**组织层**：能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。它不做工具越界审批（那是执行引擎的事），它管的是「谁有资格调用什么能力」。
**三端形态，MCP 是主体：**
| 形态 | 定位 | 成熟度 |
| --- | --- | --- |
| OpenWork MCP（远程服务） | **主体**——能力面，不是执行面 | 核心产品 |
| Den 控制面（Web） | 组织级管控：策略下发、配额、审计 | 付费层 |
| 桌面应用（Electron） | **可选**——专注工作区，非必需 | 0.x 活跃 |
**典型用例三类：**
- 团队写好一套内部 skill，通过 Den 发布到组织，成员在各自惯用的 agent（Codex / Claude Code / Cursor）里调 `search_capabilities` 直接用
- 管理员限制部分成员只能使用指定 model provider，并统一配置共享连接（Google Workspace / Microsoft 365）
- 个人把工作流分享给朋友，对方装一个 MCP 就能用
**交付物**是 **workflow、skill-package、capability**——三个都不是代码。这与 orca 的「code + diff」、maka 的「code + eval-report + execution-record」、iPolloWork 的「生成后可编辑的多形态交付物」完全不同：openwork 交付的是**能力本身**，而不是能力的执行结果。
---
## 4. 技术维度：它怎么做到的
### 架构：MCP 远程服务 + 可选桌面 + Web 控制面
openwork 的技术骨架一句话：**把自己做成 MCP server，让各引擎来连**。技术栈是 Electron + React + TypeScript + Node.js 24 + pnpm + MCP。
```text
┌─ Codex / Claude Code / Cursor / OpenCode / 任意 MCP client ─┐
│ │
│ 各引擎 ──MCP 客户端──> OpenWork MCP Server │
│ │ │
│ ├──> search_capabilities │
│ │ （发现可用能力） │
│ └──> execute_capability │
│ （调用能力，不接管执行循环） │
│ │
│ Den 控制面（Web）：策略下发 / 配额管控 / 访问审计 │
│ 桌面 app（可选）：OpenCode 生态，专属工作区 │
└─────────────────────────────────────────────────────────────┘
```
与 orca 的「我去适配你的引擎」完全相反：orca 是引擎抽象层（PTY 外壳把 30+ 引擎拉平），openwork 是**能力注入层**（把能力推给各引擎）。
### 引擎抽象：对等且都浅
| 维度 | openwork 的做法 |
| --- | --- |
| 兼容判据 | **MCP 客户端身份**（任何能连 MCP 的引擎都能接） |
| 抽象层 | OpenWork MCP（能力面，不是执行面） |
| 对外暴露 | **只两个工具**：search_capabilities + execute_capability |
| 执行控制 | **不接管**——不接管 agent loop、不管上下文、不做权限回调 |
| 真正深度绑定 | OpenCode（仓库描述 powered by opencode，桌面端属其生态） |
这是 `engine_neutral = 6` 的含义：**它接得住 4+ 引擎，但都只在能力面**。对外宣称的「跨引擎通用」与内部实际的主从关系存在落差——OpenCode 是原生，其余是 MCP 外挂。这与 iPolloWork 的「Codex 仅 MCP 控制面」是同一个问题的两种解法：iPolloWork 把 MCP 当补丁（主体是桌面），openwork 把 MCP 当主体（桌面是可选）。
### 多 agent：未强调，重心在能力共享与治理
openwork 不强调多 agent 编排——它不关心「agent 怎么协作完成一件事」，它关心的是「能力怎么在组织里流转」。这与 tutti（唯一把「多人」写进定位）也完全不同：tutti 的多人是**同一空间内的人与 agent 协作**，openwork 的多人是**跨工具的能力分发**。
### 本地优先：可本地跑，但核心服务在云端
`local_first_score = 6`。桌面 app 本身 BYO（自带模型，不绑定共享账号），skills 可以本地跑；但核心服务——Den 控制面、OpenWork MCP 远程端点（https://api.openworklabs.com/mcp/agent）——是**云端**的。组织管控、能力分发、审计追踪都依赖云服务。这决定了它不是 local-first 项目，而是 **cloud-anchored + local-optional** 项目。
### 扩展体系：skills 是一等公民
- **skills**：一等公民——可发布、可分配到组织/团队/个人；支持导入 Agent Plugins 与 Anthropic 兼容插件并转为 OpenWork MCP 能力
- **plugins**：通过 marketplace 发布与分配
- **MCP**：自身即以 MCP server 形态对外提供服务，同时也消费下游 MCP 连接
扩展体系的中心不是「插件市场」，是 **Den 的能力分发管道**——skill 不是装在本地的，是发布在 Den 上、由组织分配到具体成员/团队的。
### 观测性：观测「谁用了什么能力」，不是「agent 怎么把事做完的」
Den 提供推理配额管控与访问审计；桌面 app 侧未见 agent 执行轨迹的记录设计。openwork 的观测维度是**能力调用层**（谁、什么时候、调了什么能力、配额用了多少），不是**执行层**（agent 的 tool call 序列、上下文演化、终止事件）。这与 maka 的 append-only 执行记录、orca 的 diff/review 完全不同——它观测的是「能力的流转」，不是「执行的轨迹」。
---
## 5. 横向对比
> 说明：下表项目均已收录进本系列追踪库，数据来自各自档案（`data/projects/*.yaml`，2026-09-01 快照）。"引擎中立度 / 本地优先"取自档案 `chart.*`（1–10）。
| 维度 | openwork | orca | iPolloWork | maka | QwenPaw | Tutti | OpenClaw |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 站位层次 | **能力分发层（MCP 主体）** | 执行编排层（并行 fan-out） | 桌面工作台层 | 执行记录层 + 自带引擎 | 个人助理执行层 | 多人×多 agent 协作层 | 个人助理执行层（多渠道 Gateway） |
| 引擎中立度（1–10） | 6（能力面接 4+ 引擎） | **9（全场最高）** | 7 | 1（不参与该赛道） | 2（自身即引擎） | 8（ACP 双层） | 1（自身即引擎） |
| 本地优先（1–10） | 6（核心服务在云端） | 6 | 7 | **10（全场最高）** | 9 | 7 | 8 |
| 交付物 | **能力（MCP）+ workflow + skill-package** | code + diff + review-comment | 生成后可编辑的多形态交付物 | code + eval-report + execution-record | 个人助理任务 | 多人协作会话 | 个人助理任务 |
| 许可证 | L3（目录切分：ee/ 外 MIT / ee/ EE） | MIT（L1） | L3 source-available | Apache-2.0（L1） | Apache-2.0（L1） | Apache-2.0（L1） | MIT（L1，机器读不出） |
| 成熟度 | 0.x 活跃（工程治理最规范） | 原型期（一天一版） | beta（v0.50.x） | 孵化期（无正式 release） | beta 活跃 | 快速成长期 | 高速迭代（约 4 天/版本） |
| 观测维度 | **谁用了什么能力** | 执行轨迹 + diff | 生成结果 | 执行记录全落盘 | 五层安全审计 | 协作会话 | 多渠道日志 |
| 变现 | **Den 订阅（open-core）** | 无 | 无 | 无 | 无 | open-core | 无 |
openwork 在谱系里的位置，用一句话概括：**唯一站在「能力分发层」、不抢桌面入口、不碰执行层、把 MCP 当主体当产品的那个角落。** orca 卷的是「怎么接最多引擎」，iPolloWork 卷的是「怎么做出最好用的工作台」，maka 卷的是「agent 干了什么能不能证明」，openwork 卷的是「组织的能力怎么一次创建、处处复用」。七个样本里，只有它交付的是「能力」而不是「能力的执行结果」。
---
## 6. 宣称 vs 实测
这一节是本系列最看重的部分。openwork 项目方没有说谎——它的 README 在许可证和桌面定位上都做了明确披露——但「披露得充分」和「没有错位」是两回事。
**① 宣称：「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 本身**。用 tagline 里的「alternative」来理解产品形态，会得出错误预期。
**来源**：README 开篇与「Use OpenWork from any agent」段。
**② 宣称：跨 Codex / Claude Code / Cursor / OpenCode 多引擎通用。**
**实际**：对 OpenCode 是原生的（仓库描述 powered by opencode，桌面端属其生态）；对其余引擎只通过自己暴露的两个 MCP 工具对接。这是**能力调用面**，不是**引擎执行面**——openwork 不接管这些引擎的执行循环、上下文与权限。对外宣称的「跨引擎」与内部实际的主从关系存在落差：OpenCode 是亲儿子，其余是 MCP 外挂。
**来源**：README「It exposes two tools」段；仓库 description「powered by opencode」。
**③ 宣称：free, open-source（免费开源）。**
**实际**：需要分目录看：ee/ 之外确实 MIT 且免费；但 ee/（Den 组织控制面、MCP 网关、推理）属 source-available，生产使用需付费订阅，只有 **5 人以下组织、30 天评估、开发测试**三种情形豁免。个人免费，团队与企业要付费。这不是「开源变味」，而是标准的 open-core 模型——但「free, open-source」这个 tagline 没有把 open-core 的边界说清楚。
**来源**：README Licensing 段 + ee/LICENSE 原文 72 行。
**④ 宣称：（无明确宣称，但 SPDX 为 NOASSERTION，易被误读为「不够开源」）。**
**实际**：恰恰相反——它是七个项目里**工程治理最规范**的：强制 DCO sign-off（每个 commit 都要 Signed-off-by）、ee/ 目录改动需额外 CLA、`evals/` 目录放可执行测试规格并要求 PR 附测试证据、`worlds/` 放声明式的开发与测试环境定义。NOASSERTION 只因根目录 LICENSE 是混合声明文件，不代表开放度低——ee/ 之外是纯 MIT，且 ee/ 版本满两年自动追加 MIT（Grant of Future License）。
**来源**：README「Getting started (contributors)」与「Sending a pull request」段。
四条里有三条是 README **自己写出来的**——但披露方式和产品定位的错位是结构性的：tagline 说「Cowork 的替代品」，实际是「能力分发层」；tagline 说「free, open-source」，实际是 open-core；tagline 说「跨引擎通用」，实际是能力面通用。这不是欺骗，是**营销叙事与产品形态的错位**——用 Cowork 的品牌势能来给一个不同物种的产品引流。
---
## 7. 结论：什么人该用它
**该用：**
- 已固定在某款 agent 上（Codex / Claude Code / Cursor）、**不想换工具**、只想让团队能力跨工具复用的开发者
- 需要**统一管控 agent 能力与模型配额**的组织 IT——Den 的策略下发、配额管控、访问审计是七个样本里唯一把「组织能力治理」做成产品的
- 想把自己搭好的工作流**分发给同事或朋友**、对方装一个 MCP 就能用的团队
- 5 人以下小团队——免费额度覆盖所有非 Enterprise 功能，30 天评估期足够验证
**不该用：**
- 想要一个**开箱即用的桌面 agent 工作台**的人——桌面 app 是可选壳，不是主体；六个内置能力不如 orca / iPolloWork 的丰富
- 以为拿到的是**完整 Cowork 平替**的人——形态完全不同，它不操作你的电脑，它分发能力
- 需要**本地优先 / 数据不出机器**的团队——核心服务在云端（Den + OpenWork MCP 远程端点），local_first_score 只有 6
- 以为 **SPDX=NOASSERTION 代表开放度低**的许可证审查者——ee/ 之外是纯 MIT，ee/ 满两年自动转 MIT；开放度分目录看，不是整体看
**再看看：** 等四件事落地再评估——① Den 的**能力导出路径**是否出现（当前无导出说明，锁定风险未明）② 官方 skills 市场 / 组织管理后台是否开始做跨工具分发（这是它护城河的头号威胁，**每季度盯一次 Anthropic / OpenAI 的动作**）③ ee/ 第一批版本满两年后是否如期追加 MIT（Grant of Future License 的兑现记录）④ 桌面 app 是否会从「可选」变成「主体」——如果它开始卷桌面体验，定位会从能力分发层漂移回桌面工作台层，届时需要重新评估其在谱系中的位置。
---
## 8. 追踪备注
- **数据日期**：2026-09-01（GitHub API 快照）
- **指标**：★ 23253 / fork 2307 / open issues 414 / subscribers 89 / ~291 MB / TypeScript 89.9% + JavaScript 6.7%
- **最新版本**：v0.18.40，约 1 天/版本
- **源码镜像**：`gitinbox/openwork`（**public**，source-only 快照——排除 `ee/` 与 `LICENSES/LicenseRef-OpenWork-EE.txt` 后为纯 MIT，判 public；上游 291 MB，本机到 GitHub 实测 50 KB/s，拉取耗时较长）
- **结构化档案**：`data/projects/openwork.yaml`
**下次跟进点：**
1. Den 控制面：能力导出路径是否出现（当前无导出说明，锁定风险未明）
2. 官方威胁：Anthropic / OpenAI 的 skills 市场与组织管理后台是否开始做跨工具分发
3. 许可证兑现：ee/ 第一批版本满两年后是否如期追加 MIT（Grant of Future License 的兑现记录）
4. 定位漂移：桌面 app 是否从「可选」变成「主体」——如果开始卷桌面体验，需要重新评估其在谱系中的位置
---
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
articles/qwenpaw.md
+275
View File
@@ -0,0 +1,275 @@
# QwenPaw 深度拆解：安全默认值最完整、巴士系数最健康的个人助理——但没发过一个正式版
> **速览**
>
> | 项 | 值 |
> | --- | --- |
> | 仓库 | [agentscope-ai/QwenPaw](https://github.com/agentscope-ai/QwenPaw) |
> | 一句话 | "Your Personal AI Assistant"——常驻本地、多渠道触达、五层安全默认全开的私人 AI 助理 |
> | Star / Fork / Issues | 34758 / 3052 / 898 open（2026-09-01） |
> | 主语言 / 体积 | Python 59% + TypeScript 37.2% / ~112 MB |
> | 最新版本 / 节奏 | v2.2.0-beta.5（**至今全部为 prerelease**）/ 约 1 天/版本 |
> | 许可证 | Apache-2.0（**L1 · 真开源，可自由再分发，自带专利授权**） |
> | 成熟度 | **beta 活跃期**（巴士系数七家最健康，但发布纪律是短板） |
>
> **一句话结论**：七个样本里安全默认值最完整、工程治理最健康的个人助理——但至今没发过一个正式版，且 `--defaults` 安装路径会默认打开遥测。它和 OpenClaw 是同赛道的两个极端：一个靠生态规模取胜，一个靠安全确定性与本地可跑取胜。
---
## 0. 先给结论
QwenPaw 的 tagline 是 *"Your Personal AI Assistant; easy to install, deploy on your own machine or on the cloud; supports multiple chat apps with easily extensible capabilities"*。但真正定义它的是三件别家没有的事：
1. **五层安全体系全部默认开启。** 沙箱（Seatbelt / Bubblewrap+Landlock / AppContainer）、Tool Guard（YAML 规则引擎 + ShellEvasionGuardian）、File Guard（保护 ~/.ssh 等敏感路径）、Skill Scanner（第三方 skill 激活前扫描提示词注入与硬编码密钥）、Access Policy（声明式规则，工具级粒度）——**五层全部默认开**。同类项目里只有 OpenClaw 做了沙箱，但 OpenClaw 默认关；QwenPaw 是唯一把安全做成"出厂状态"的。
2. **巴士系数是七个样本里最健康的。** 最近 100 次提交去重 24 位作者，TOP1（yutai78786）仅占 15%，前八名分布在 15%–5% 之间，没有单点依赖。对比同赛道的 OpenClaw（steipete 最近 100 提交独占 64%，巴士系数≈1），差距是结构性的。
3. **无需 API key 即可跑。** 内置 llama.cpp 后端 + 自研 QwenPaw-Flash 模型系列（2B / 4B / 9B，Q4 / Q8 量化），ModelScope 与 Hugging Face 可下载，Web UI 点下载即用。这是七个样本里唯一的"零门槛本地可跑"能力——其他六家要么必须 BYO API key（orca / iPolloWork / openwork），要么自身即引擎但不提供本地模型（OpenClaw），要么本地模型是可选非主推（maka）。
而它最大的问题也有三个：**至今没有任何正式 release**（最近 8 个全是 prerelease）、**`--defaults` 安装路径会默认接受遥测**（与"数据归你"的核心叙事存在张力）、**改名导致历史检索断裂**（CoPaw→QwenPaw，2026 年 4 月前资料必须按旧名检索）。
---
## 1. 赛道定位：它站在哪一层
沿用本系列的分层法：
```text
┌──────────────────────────────────────────────────────────────┐
│ 编排 / 工作台层 │
│ 跨引擎、跨 worktree、跨交付物的调度与观测外壳 │
│ ── orca（执行编排）/ iPolloWork（桌面工作台）在这里 ── │
├──────────────────────────────────────────────────────────────┤
│ 编辑器内 Agent 层 │
│ 嵌在 IDE / 编辑器里的交互层 │
├──────────────────────────────────────────────────────────────┤
│ 个人助理执行层 │
│ 常驻本地、多渠道触达、长期记忆 │
│ ── QwenPaw（安全默认值最完整）/ OpenClaw（渠道覆盖最广）── │
├──────────────────────────────────────────────────────────────┤
│ 模型层 │
│ QwenPaw-Flash 自研本地模型（2B/4B/9B，Q4/Q8 量化） │
│ ── 14+ 云 provider + 本地 llama.cpp / Ollama / LM Studio ── │
└──────────────────────────────────────────────────────────────┘
```
**QwenPaw 的站位在七个样本里与 OpenClaw 正面对撞**——都是「个人助理执行层」，都是「自身即引擎」，都不接外部 agent。但立足点完全不同：
| 维度 | QwenPaw | OpenClaw |
| --- | --- | --- |
| 取胜逻辑 | 安全默认值 + 本地可跑 + 渠道覆盖国内 | 渠道覆盖 + 生态规模 + 社区 |
| 用户画像 | 开发者 + 数据敏感用户 | 非开发者（普通人） |
| 沙箱 | 五层全默认开 | 默认关 |
| 本地模型 | 自研 Flash 系列，无需 API key | 无自研模型，BYO |
| 巴士系数 | 24 作者，TOP1 15% | TOP1 独占 64% |
| 发布纪律 | 全是 beta | 有正式版（v2026.8.1） |
它是本项目在「个人助理」赛道里 OpenClaw 的**唯一正面对手**，但两者风险面完全相反：OpenClaw 的风险是"生态太大、治理跟不上"（CVE 8.8、默认无沙箱），QwenPaw 的风险是"治理很好、但产品没定型"（全是 beta、无正式版）。
---
## 2. 业务维度：它靠什么活着（答案是：不靠）
**目标用户**四类，都很垂直：
- 对**数据主权与隐私**有硬要求、希望助理完全跑在本地的个人用户
- 需要在**钉钉 / 飞书 / 微信 / QQ** 等国内渠道里用助理的团队
- 想**不买 API key** 就先跑起来的尝鲜用户（QwenPaw-Flash 本地模型）
- 愿意**用功能广度换安全确定性**的自用开发者
**变现路径：无。** Apache-2.0 全开源，未见收费层。提供 Docker / 阿里云 ECS / AgentScope 平台 / ModelScope 创空间等多条部署路径（云部署路径隐含云厂商导流）。与 OpenClaw 一样没有明示的变现路径——它要的是生态位（AgentScope 生态的个人助理入口）、是标准（安全默认值的行业标杆），不是营收。
**许可证**是 Apache-2.0，L1，七个样本里最干净的一档之一：可自由镜像与再分发、自带专利授权与反诉终止条款、修改需声明、NOTICE 须随分发保留、不授予 Qwen / 通义等商标使用权。
**护城河**由三层构成，且都是**难以快速复制**的：
1. **五层安全体系**（沙箱 / Tool Guard / File Guard / Skill Scanner / Access Policy）全部默认开启——同类里最完整的，安全是可以被快速抄的，但"默认开"这个产品决策不是
2. **自研 QwenPaw-Flash 模型系列**（2B / 4B / 9B，Q4 / Q8 量化）——把"先跑起来"的门槛降到零，无需 API key
3. **国内七大渠道覆盖**（钉钉 / 飞书 / 微信 / QQ / Discord / Telegram / iMessage）——钉钉 / 飞书 / 微信的对接是海外项目做不了的
**竞争风险**两面受敌：向上被 OpenClaw 的生态规模压制（388k vs 34.7k star，差一个数量级），向下被任何一家有本地模型的助理框架追赶（安全是可以被快速抄的）。真正的护城河可能是**渠道**——钉钉 / 飞书 / 微信的对接是地理性的壁垒，海外项目天然做不了。
---
## 3. 场景维度：它在什么场合被用
**人机协作是声明式审批**，且是工具级粒度：Access Policy 是声明式访问规则，可对每次能力调用设置 放行 / 拒绝 / 请求人工批准，粒度到工具级、可按来源匹配。Tool Guard 提供 STRICT / SMART / AUTO / OFF 四档。它不追求全自动——五层安全本身就是"人在环"的制度化表达。
**四端形态，服务端 + 多渠道：**
| 形态 | 定位 | 成熟度 |
| --- | --- | --- |
| Web 控制台 | 主工作环境（默认 127.0.0.1:8088） | beta |
| TUI | 终端工作区 | beta |
| 桌面应用 | 原生桌面 | **Beta** |
| Docker | 容器化部署 | 可用 |
**典型用例四类：**
- 每天自动抓小红书 / 知乎 / Reddit 热点生成摘要推到飞书
- 睡前描述目标，助理自动执行，醒来拿到原型
- 多个独立 agent 各自分角色（创意 / 写作 / 校对）协同产出内容
- 用本地 9B 模型处理敏感文档，全程不出本机、不花 API 费用
**交付物**是 **code（Coding Mode 三栏 IDE）、文档处理结果（PDF / Word / Excel / PowerPoint）、记忆条目（可读可编辑可搜索的 Markdown 记忆）、定时推送内容（资讯摘要 / 视频脚本）**——四项里两项（记忆条目、定时推送）是个人助理特有的，但都不是"可编辑交付物体系"（对比 iPolloWork 的生成后可编辑多形态交付物）。
---
## 4. 技术维度：它怎么做到的
### 架构：Python 包 + 多渠道，形态偏传统
QwenPaw 的技术骨架一句话：**Python 包（pip / 安装脚本）+ Web 控制台 + TUI + 桌面应用（Beta）+ Docker**。技术栈是 Python 59% + TypeScript 37.2% + Rust 1.0%（Rust 用于安全相关组件）。
```text
┌─ Web 控制台 / TUI / 桌面 / Docker ──────────────────────────┐
│ │
│ 四端 ──> QwenPaw 核心（自身即引擎） │
│ │ │
│ ├──> 五层安全（全部默认开启） │
│ │ ① Sandbox（内核级隔离） │
│ │ ② Tool Guard（规则引擎 + 逃逸检测） │
│ │ ③ File Guard（敏感路径保护） │
│ │ ④ Skill Scanner（第三方 skill 扫描） │
│ │ ⑤ Access Policy（声明式规则） │
│ │ │
│ ├──> 三层记忆 │
│ │ ① 当前会话工作上下文 │
│ │ ② 可搜索的完整对话历史 │
│ │ ③ 自进化的 Markdown 个人知识库 │
│ │ （建在 ReMe 个人知识框架上） │
│ │ │
│ ├──> 模型层（14+ provider + 本地） │
│ │ 云：OpenAI / Anthropic / DeepSeek… │
│ │ 本地：llama.cpp / Ollama / LM Studio│
│ │ 自研：QwenPaw-Flash（2B/4B/9B） │
│ │ │
│ └──> 多渠道（钉钉/飞书/微信/QQ/…） │
└─────────────────────────────────────────────────────────────┘
```
与 OpenClaw 的"本地守护进程 Gateway + 原生伴侣 App + 设备节点"相比，QwenPaw 的形态更**传统**——没有原生伴侣 App，没有设备节点，就是一个"服务端 + 多渠道"的标准架构。这是 form_depth=5 的含义。
### 引擎抽象：自身即引擎，模型层真中立
| 维度 | QwenPaw 的做法 |
| --- | --- |
| 兼容判据 | **不代理外部 agent 引擎** |
| 抽象层 | 无（自身即引擎）；模型层有统一 provider 抽象 |
| 模型层 | **14+ 云 provider + 本地 llama.cpp / Ollama / LM Studio 可混用** |
| 自研模型 | QwenPaw-Flash（2B / 4B / 9B，Q4 / Q8 量化） |
| 多 agent | 可派生带独立记忆的子 agent 并行处理 |
这是 `engine_neutral = 2` 的含义：**agent 引擎层不存在中立问题（它自己就是），模型层是真中立（14+ provider 可换）**。注意区分这两个"中立"——横向比较时不要混为一谈。它和 OpenClaw（engine_neutral=1）的区别在于：OpenClaw 连模型层都不中立（BYO 但不提供本地模型），QwenPaw 在模型层给了真选择。
### 多 agent：内生派生，各自独立记忆
可创建多个独立 agent、各自分角色，开启协作 skill 后 agent 间可互相通信；助理能**派生带独立记忆的子 agent** 并行处理任务。这是 OpenClaw 2.0 之前没有的内生能力——OpenClaw 的多 agent 靠外部编排（Gateway 路由到不同 channel），QwenPaw 的多 agent 是**引擎内生的**。
### 本地优先：无需 API key 即可跑，但有一个遥测暗礁
`local_first_score = 9`，七个样本里仅次于 maka（10）。内置 llama.cpp 后端 + 自研 QwenPaw-Flash 模型系列，**无需 API key 即可跑**——这是它相对所有竞品的硬差异。
但有一个细节必须单独说（见第 6 节 ①）：**`qwenpaw init --defaults` 会自动接受遥测**，且"每升级一个版本会重新收集一次"。而 `--defaults` 恰恰是快速上手文档推荐的默认路径。收集的是匿名环境数据、不影响功能，但"默认接受"与"数据归你"的叙事存在张力——尤其对把隐私当核心卖点的产品。
### 扩展体系：skills 文件系统 + 安全扫描
- **skills**：Skills 文件系统，自定义 skill 自动加载，明确宣称 no lock-in
- **plugins**：Skill Scanner 在激活前扫描第三方 skill（阻断 / 警告 / 关闭 + 白名单）
- **MCP**：README 标注 mcp 主题，支持浏览器工具抓取接口文档
扩展体系的中心不是"插件市场"，是**安全扫描**——每个第三方 skill 激活前都要过 Skill Scanner 的扫描（提示词注入、硬编码密钥、数据外泄检测）。这与 openwork 的"skill 发布到 Den 再分配"完全不同：QwenPaw 的 skill 是本地文件系统的，但每激活一次都要过安全闸。
### 观测性：三层记忆本身即审计轨迹
滚动式上下文管理 + 持久化轮次存储；三层记忆（当前会话工作上下文 / 可搜索的完整对话历史 / 自进化的 Markdown 个人知识库）本身即构成了可审计轨迹。与 maka 的 append-only 执行记录不同，QwenPaw 的记忆是**可读可编辑可搜索的 Markdown**——更友好，但不可篡改（maka 的 append-only 是防篡改的）。
---
## 5. 横向对比
> 说明：下表项目均已收录进本系列追踪库，数据来自各自档案（`data/projects/*.yaml`，2026-09-01 快照）。"引擎中立度 / 本地优先"取自档案 `chart.*`（1–10）。
| 维度 | QwenPaw | orca | iPolloWork | maka | openwork | Tutti | OpenClaw |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 站位层次 | **个人助理执行层（安全最完整）** | 执行编排层（并行 fan-out） | 桌面工作台层 | 执行记录层 + 自带引擎 | 能力分发层 | 多人×多 agent 协作层 | 个人助理执行层（渠道最广） |
| 引擎中立度（1–10） | 2（自身即引擎，模型层 14+ 中立） | **9（全场最高）** | 7 | 1（不参与该赛道） | 6（能力面） | 8（ACP 双层） | 1（自身即引擎） |
| 本地优先（1–10） | 9（无需 API key 即可跑） | 6 | 7 | **10（全场最高）** | 6（核心在云端） | 7 | 8 |
| 交付物 | code + 文档 + **记忆条目** + 定时推送 | code + diff + review-comment | 生成后可编辑的多形态 | code + eval-report + execution-record | 能力（MCP）+ workflow | 多人协作会话 | 个人助理任务（事务结果） |
| 许可证 | Apache-2.0（L1） | MIT（L1） | L3 source-available | Apache-2.0（L1） | L3（目录切分） | Apache-2.0（L1） | MIT（L1，机器读不出） |
| 安全默认 | **五层全默认开** | 无统一权限回调 | 沙箱 + 审批 | 越界审批 + 记录全落盘 | MCP 层控制面 | 沙箱边界 | **⚠️ 默认无沙箱 + CVE 8.8** |
| 巴士系数 | **24 作者，TOP1 15%（最健康）** | — | — | — | — | — | **TOP1 独占 64%（≈1）** |
| 成熟度 | beta 活跃（全是 prerelease） | 原型期（一天一版） | beta（v0.50.x） | 孵化期（无正式 release） | 0.x 活跃 | 快速成长期 | 高速迭代（有正式版） |
QwenPaw 在谱系里的位置，用一句话概括：**与 OpenClaw 同赛道、风险面完全相反的那个角落。** OpenClaw 的风险是"生态太大、治理跟不上"（CVE、默认无沙箱、巴士系数≈1），QwenPaw 的风险是"治理很好、但产品没定型"（全是 beta、无正式版、遥测默认开）。七个样本里，只有这两个是真正的"个人助理"——其他五家要么卷编排（orca）、要么卷能力分发（openwork）、要么卷执行记录（maka）、要么卷桌面体验（iPolloWork）、要么卷多人协作（tutti）。
---
## 6. 宣称 vs 实测
这一节是本系列最看重的部分。QwenPaw 项目方没有说谎——它的 README 在安全、遥测、本地模型上都做了明确披露——但"披露得充分"和"没有坑"是两回事。
**① 宣称：「数据归你、本地优先、不上传任何本地使用记录」。**
**实际**：主力诉求成立（本地模型可完全离线跑，遥测一键可关）。但 README 的 Telemetry 章节写明：**`qwenpaw init --defaults` 会自动接受遥测**，且"每升级一个版本会重新收集一次"。而 `--defaults` 恰恰是快速上手文档推荐的默认路径。收集的是匿名环境数据、不影响功能，但"默认接受"与"数据归你"的叙事存在张力——尤其对把隐私当核心卖点的产品。
**来源**：README Telemetry 章节原文（*"If you choose --defaults, telemetry is accepted automatically."*）。
**② 宣称：「34.7k star 的成熟个人助理」。**
**实际**：星标属实，但**至今没有任何正式 release**。查最近 8 个 release，v2.1.1-beta.1 到 v2.2.0-beta.5 全部 prerelease=True。也就是说它处在"高关注度 + 持续 beta"状态，与同赛道 OpenClaw（有 v2026.8.1 正式版）相比，发布纪律反而更松。
**来源**：GitHub releases API（per_page=8，全部返回 prerelease=true）。
**③ 宣称：「五层安全，内核级沙箱」。**
**实际**：五层的实现描述相当具体（Seatbelt / Bubblewrap+Landlock / AppContainer，ShellEvasionGuardian 检测命令注入与反弹 shell），可信度高。但 **Tool Guard 提供 OFF 档**，整层可以关掉；Access Policy 也是"可配置为放行"。安全强度取决于用户配置，不是不可绕过的硬边界。
**来源**：README Security Features 章节（列出 Tool Guard 的 STRICT / SMART / AUTO / OFF 四档）。
**④ 宣称：「无需 API key，本地模型即可跑」。**
**实际**：技术上成立：QwenPaw-Flash 2B / 4B / 9B（Q4 / Q8 量化）内置 llama.cpp 后端，在 Web UI 点下载即可用，并提供硬件感知推荐。但要清醒：**2B / 4B 量级的模型在复杂 agent 任务上的能力天花板很低**，"无需 key 跑起来"和"无需 key 好用"是两件事，重度任务仍要接云端 provider。
**来源**：README Local Models 章节（列出 2B/4B/9B 与 Q4/Q8 量化）。
**⑤ 宣称：「（历史）QwenPaw 是一个 2026 年 4 月后出现的全新项目」。**
**实际**：不是。它是 2026-02-24 以 **CoPaw** 之名建仓的项目，2026-04-12 才更名。检索 2026 年 4 月之前的社区讨论、issue 与技术文章时必须按 CoPaw 检索，否则会严重低估它的历史沉淀与已知问题。
**来源**：GitHub repo API（created_at=2026-02-24）+ README News 章节的更名公告。
**⑥ 宣称：「（检索风险）github.com/agentscope-ai/QwenPaw 是唯一官方仓库」。**
**实际**：存在同名仓库 `aqua88hn/qwenpaw`，README 内容与官方高度相似。以 star 数（官方 34.7k）与组织归属判断，官方仓库在 agentscope-ai 组织下；但同名仓库的存在会让"按名字搜仓库"直接得到错误结果。
**来源**：GitHub 搜索结果与 repo API 交叉核对（agentscope-ai/QwenPaw = 34758 star，非 fork）。
六条里有五条是 README **自己写出来的**——QwenPaw 的自我披露是七个样本里第二充分的（仅次于 maka）。但 ① 和 ② 合起来看是理解 QwenPaw 的钥匙：**「安全叙事最强、发布纪律最松」**——安全默认值做得最完整，但产品交付（正式版、稳定升级路径）一步未成；隐私叙事说得最响，但 `--defaults` 的默认路径会把遥测打开。
---
## 7. 结论：什么人该用它
**该用：**
- 把**数据与隐私**放第一位、希望助理完全跑在本地的个人与小团队——五层安全默认全开 + 自研本地模型无需 API key，是七个样本里"本地 + 安全"组合最完整的
- 需要在**钉钉 / 飞书 / 微信 / QQ** 渠道里用助理的国内团队——渠道覆盖是海外项目做不了的
- 想**不买 API key** 先把流程跑通的尝鲜者——QwenPaw-Flash 2B/4B/9B 是唯一的"零门槛本地可跑"
- 做**多 agent 协同内容创作**的团队——内生派生子 agent + 各自独立记忆，是 OpenClaw 之前没有的能力
**不该用：**
- 需要**正式版与稳定升级路径**的团队——它是 beta 活跃期，至今全部 prerelease
- 指望 **2B / 4B 本地模型扛复杂 agent 任务**的人——"无需 key 跑起来"和"无需 key 好用"是两件事
- 把「五层安全」当成**不可绕过硬边界**的人——Tool Guard 有 OFF 档，安全强度取决于配置
- 以为 **`--defaults` 安装路径不收集任何数据**的人——遥测默认接受，需手动关闭
- 在 **2026 年 4 月前资料**里按 QwenPaw 检索的人——那时它还叫 CoPaw
**再看看：** 等四件事落地再评估——① 第一个**正式 release**（prerelease → stable 的发布纪律转折）② **遥测默认值**是否从"默认接受"改为"默认关闭"（这是"数据归你"叙事能否自洽的关键）③ **OpenClaw 生态规模**是否继续碾压（388k vs 34.7k，差距是否还会扩大）④ **渠道护城河**是否被官方渠道能力稀释（钉钉 / 飞书 / 微信是否会官方集成 AI 助理，挤掉第三方）。
---
## 8. 追踪备注
- **数据日期**：2026-09-01（GitHub API 快照）
- **指标**：★ 34758 / fork 3052 / open issues 898 / subscribers 109 / ~112 MB / Python 59% + TypeScript 37.2%
- **最新版本**：v2.2.0-beta.5，约 1 天/版本（**全部 prerelease**）
- **源码镜像**：`gitinbox/qwenpaw`（**public**，source-only 快照 ~18 MB——109 MB 裸仓超 Gitea 50 MB 推送上限，剔除图片/音视频/字体后按快照提交；完整保真裸仓 281 MB 保留在本地 `.mirrors/qwenpaw.git`）
- **结构化档案**：`data/projects/qwenpaw.yaml`
**下次跟进点：**
1. 发布纪律：第一个正式 release 何时出（prerelease → stable）
2. 遥测默认值：`--defaults` 是否从"默认接受"改为"默认关闭"
3. 生态规模：与 OpenClaw（388k）的 star 差距是否继续扩大
4. 渠道护城河：钉钉 / 飞书 / 微信是否官方集成 AI 助理，挤掉第三方
5. 改名影响：CoPaw → QwenPaw 更名后，历史 issue 与社区讨论的检索断裂是否得到解决
---
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 `gitinbox/agent-radar`</sub>
articles/tutti.md
+258
View File
@@ -0,0 +1,258 @@
# Tutti 深度拆解：发布纪律最好的「多人 × 多 Agent」协作空间——但「多人」那部分全在闭源侧
> **一句话结论**：Tutti 是七个样本里**唯一把"多人"写进定位**的项目，也是**发布纪律最好**的——star 最少（3.6k）、建仓最晚（2026-06-12），却连续 8 个 release 全是正式版。它把"让多个 agent 在同一工作区里共享上下文、接力干活"做成了产品，用 ACP 协议层 + runtimeprep 运行时准备层的**双层架构**真真切切接了引擎（全仓 363 个文件引用 ACP）。但有两件事必须说透：第一，引擎接入深度**严重偏袒 Codex**（2170 行 vs Kimi 127 行，17 倍差距，且只有 Codex 做了 Windows 适配）；第二，宣传的"多人协作"七项功能（Group chat / 多人同屏 / 跨设备 / agent 借用 / 免部署分享……）**全部在闭源 VM 版**，开源版一格 ✓ 都没有，且 VM 版需邀请码。Apache-2.0 保证了你能自由改代码，不保证你能用到它宣传的完整体验。
| 维度 | 数据 |
|---|---|
| 仓库 | tutti-os/tutti |
| 一句话 | Where people and agents build in tune. |
| ★ / Fork / Open Issues | 3,660 / 371 / 185 |
| 主语言 | TypeScript 48.8% + Go 45.4% |
| 体积 | ~244 MB（8,291 文件） |
| 最新版本 | v0.2.31 + `stable` 滚动 tag |
| 节奏 | 约 3 天/版本，**8 个 release 全正式版** |
| 许可证 | Apache-2.0（L1） |
| 成熟度 | 快速成长期（建仓 2.5 个月） |
---
## 0. 先给结论
**三个有意思的点：**
1. **发布纪律是七个样本里最好的**——最近 8 个 release 全部 `prerelease=False`（v0.2.25 → v0.2.31），且维护了一个 `stable` 滚动 tag（始终指向最新稳定版）。对比：OpenClaw 版本号倒挂（9.1-beta 早于 8.1 正式）、QwenPaw 全是 beta、Maka 无 release。**star 数最少的 Tutti 反而是唯一持续发正式版的**——star 数与工程成熟度在本体系的七个样本里呈负相关。
2. **双层引擎架构是七个样本里没有的分层**——第 1 层 `acp_provider_*.go`（ACP 协议适配）负责"怎么和引擎对话"，第 2 层 `runtimeprep/`（运行时准备）负责"怎么让引擎跑起来"（配置注入、skill 装配、模型缓存、目录同步、Windows 兼容）。全仓 363 个文件引用 ACP，是真集成不是营销词。
3. **后端用 Go 而不是 Node**——守护进程 `tuttid` 和 CLI 都是 Go 写的（45.4%），这是它和其余 Electron 系样本的关键差异。Go 的并发模型和稳定性更适合做"多 agent 同时写同一批文件"的 daemon 层。
**三个最大的问题：**
1. **引擎接入深度严重不对等**——Codex 16 文件 2170 行，Kimi 1 文件 127 行，**17 倍差距**。且只有 Codex 有 Windows 变体文件（4 个 `_windows.go`），其余引擎在 Windows 上一个字都没写过。测试密度更反常：Codex 0.12（最低）vs OpenCode 0.56（最高），Kimi / ComputerUse / BrowserUse 测试为零。**投入最重的地方恰恰是保障最薄的地方。**
2. **宣传的"多人"全在闭源侧**——README 的 "Two Versions of Tutti" 对照表明确：Group chat / Work with others / Work with others' agents / Simultaneous editing / Agent borrowing / Across devices / No-deploy sharing，**七项全部是 VM 版专属，开源版一格 ✓ 都没有**。而 VM 版是 Early Access，创建 Room 需要邀请码。开源版里 Big @ 只能在"你自己的 agent 之间"引用，跨人引用要 VM 版。
3. **README 支持列表与代码对不上**——宣称"当前支持"的 Hermes，代码里没有 `hermes.go`（走的是 RTK Python 插件机制，不是原生 adapter）；宣称"in development"的 OpenClaw 确实只有 52 行零测试；但 Cursor / OpenCode / Kimi / ComputerUse / BrowserUse 在代码里都有完整实现，README 却一个字没提。**README 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。**
---
## 1. 赛道定位：七个样本里唯一把"多人"写进定位的
七个样本的赛道分层（按"它到底在解决什么问题"）：
```
个人助理层 OpenClaw（388k）· QwenPaw（34.8k）
↑ 一对一，人 ↔ 单个 agent
工作区层 iPolloWork（5.2k）· Maka（4.4k）· Orca（58.8k）
↑ 人 ↔ agent 在同一工作区，单人为主
能力分发层 OpenWork（23.3k）
↑ 不抢桌面入口，把 MCP 能力做成产品
协作空间层 Tutti（3.6k）← 唯一把"多人"写进定位的
↑ 人 + 多 agent 在同一空间协同
```
Tutti 的定位不是"再做一个 agent 桌面"，而是**"让你已有的 agent 订阅在同一个工作区里协同"**——Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。这是七个样本里**唯一站在"协作空间层"**的项目：它不造引擎、不卖模型，做的是"跨 agent 的上下文共享与接力"。
**它和 OpenWork 的关键差异**：OpenWork 是跨工具的**能力分发**（把自己做成 MCP server 让各引擎来连），Tutti 是同一空间内的**人与 agent 协作**（人 + 多 agent 同屏）。OpenWork 的"多"是引擎侧的多，Tutti 的"多"是参与者侧的多。
---
## 2. 业务维度
### 目标用户
- 同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者
- 需要 agent 之间共享上下文、接力同一件事的小团队
- 想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人
- 需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版）
### 变现路径
**Open-core 双轨**，是七个样本里变现路径最清晰的：
- **开源版**（Apache-2.0）：免费、自托管，单人 + 多 Agent
- **Tutti · VM**（Early Access，需邀请码）：多人 + 多设备 + 云同步
- Tutti 内置 Agent 在 Early Access 期免费，README 明示"后续可能按用量计费"
### 许可证
Apache-2.0（L1，最开放档）。但 NOTICE 写得极其规范——5 处第三方代码全部精确到文件路径、上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的。⚠️ 其中 VS Code Codicons 的 inspect 图标用的是 **CC-BY-4.0**（署名要求比 Apache-2.0 更严），再分发时漏掉署名即构成侵权。
### 护城河
① 双层引擎接入架构（ACP 协议层 + runtimeprep 运行时准备层）；② Workbench 节点模型 + 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊）；③ 多 Agent 实时文件协同编辑（daemon 负责落盘与冲突投影）。真正的壁垒在**多人协同的工程实现**（Cloud Room + DeviceLink 的 ICE/QUIC），而这部分恰好不在开源侧。
### 竞争风险
最容易被 Anthropic / OpenAI 官方的协作能力吃掉——Tutti 不拥有任何引擎与模型。更直接的威胁：它宣传的"agent 之间共享上下文"能力，各家引擎自己在做（Claude Code 的 subagent、Codex 的 session resume），Tutti 的跨引擎优势会随着引擎自身变强而稀释。
---
## 3. 场景维度
### 人在环
Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback（Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。执行过程可追溯性在七个样本里仅次于 Maka。
### 形态
- **桌面应用**（Electron）
- **TUI / CLI**（Go）
- **Workbench 节点**（Browser / Terminal / App Center）
- 【闭源 VM】Cloud Room 多人多设备
### 典型用例
- Claude 写完 PRD，让 agent 调设计 App 直接出视觉稿
- 描述一个目标，Tutti 拆成子任务后分派给最合适的 agent
- 用已有订阅额度驱动 Tutti 里的所有内置 App，不额外付费
- 【VM】本地跑的 localhost 站点直接在 Room 里给别人预览，不用部署
### 交付物
code / 设计稿（AI Canvas / UI-UX 原型）/ 文档 / PPT（Docs / AI PPT 内置 App）/ 会话回放（session-replay）
---
## 4. 技术维度
### 架构总览
```
┌─────────────────────────────────────────────────────────────┐
│ Electron 桌面端（TypeScript 48.8%） │
│ ├─ Agent Board（可视化调度） │
│ ├─ Workbench 节点（Browser / Terminal / App Center） │
│ └─ 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊） │
├─────────────────────────────────────────────────────────────┤
│ tuttid 守护进程（Go 45.4%） │
│ ├─ 文件落盘与冲突投影（多 agent 实时协同编辑） │
│ ├─ 活动复制 / 状态探针 / 会话回放 │
│ └─ workspace 级权限与 provision 流程 │
├─────────────────────────────────────────────────────────────┤
│ 双层引擎架构 │
│ ├─ L1: acp_provider_*.go（ACP 协议适配） │
│ └─ L2: runtimeprep/（运行时准备：配置/skill/模型/目录/Win） │
├─────────────────────────────────────────────────────────────┤
│ Go CLI（TUI） │
└─────────────────────────────────────────────────────────────┘
```
### 引擎抽象：双层架构是七个样本里没有的分层
**第 1 层 `packages/agent/daemon/runtime/acp_provider_*.go`** —— ACP 协议适配
**第 2 层 `packages/agent/runtimeprep/`** —— 运行时准备（配置注入、skill 装配、Windows 兼容、模型缓存、目录同步）
全仓 363 个文件引用 ACP，是真集成，不是营销词。
**⚠️ 接入深度极不对等**（runtimeprep/，非测试行数）：
| 引擎 | 文件数 | 实现行数 | 测试行数 | 测试密度 |
|---|---|---|---|---|
| Codex | 16 | 2170 | 261 | **0.12**（最低） |
| Tutti 内置 | 2 | 653 | 274 | 0.42 |
| Cursor | 2 | 446 | 187 | 0.42 |
| Claude | 3 | 410 | 136 | 0.33 |
| OpenCode | 2 | 392 | 218 | **0.56**（最高） |
| Kimi | 1 | 127 | 0 | 0.00 |
| ComputerUse | 1 | 43 | 0 | 0.00 |
| BrowserUse | 1 | 43 | 0 | 0.00 |
**Codex 是 Kimi 的 17 倍。** 且只有 Codex 有 Windows 变体文件（4 个 `_windows.go`），其余引擎在 Windows 上一个字都没写过——说明**只有 Codex 在 Windows 上被真正验证过**。
更反常的是**测试密度与实现规模成反比**：投入最重的 Codex（2170 行）恰恰是质量保障最薄弱的地方（0.12），因为它的边界情况最多（Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。另有 19 个通用测试文件共 7,851 行（preparer_test.go 单文件 2,906 行）覆盖跨引擎路径，部分弥补了单引擎测试的缺失。
### 多 Agent 协作
Agent Board 统一调度 + Big @ 跨 agent 引用 + 多 agent 实时文件协同编辑（daemon 落盘与冲突投影）+ 工作流与自动化规则 + Issue/Task/Run 工作流。会话回放（session-replay）与活动复制（activity-replication）是它的特色。
### 本地优先
开源版本地跑，但协作能力全在云端 VM 侧。
### 扩展体系
- **Skills**：provider_skill.go（655 行）+ stable_skill_bundle.go（308 行）+ codex_skill_roots.go
- **Plugins**：extension_runtime.go（735 行）——为 Hermes 提供 RTK Python 插件机制（命令重写）
- **MCP**：codex_mcp.go（65 行）——⚠️ MCP 实现挂在 Codex 名下，不是通用层
### 权限与沙箱
tutti_cli_policy.go（140 行）提供 CLI 策略控制；workspace 级权限与 provision 流程。相较 QwenPaw（五层安全默认开）与 OpenClaw（沙箱默认关），Tutti 的开源侧没有看到同等强度的执行隔离——它的安全边界更多落在 workspace 与 daemon 层，而非内核沙箱。
### 可观测性
**这是 Tutti 的强项**：Agent Board 看板 + 状态探针（agentstatus + account-usage）+ 会话回放 + 活动复制 + goal review / plan feedback。执行过程可追溯性在七个样本里仅次于 Maka。
---
## 5. 横向对比（七项目矩阵）
| 维度 | Tutti | OpenWork | QwenPaw | OpenClaw | Orca | Maka | iPolloWork |
|---|---|---|---|---|---|---|---|
| ★ | 3.6k | 23.3k | 34.8k | 388k | 58.8k | 4.4k | 5.2k |
| 建仓 | 2026-06 | 2026-01 | 2026-02 | 2025-12 | 2026-01 | 2026-01 | 2025-12 |
| 主语言 | TS+Go | TS | Py+TS | TS | TS | TS | TS |
| 许可证 | Apache-2.0 (L1) | 目录切分 (L3) | Apache-2.0 (L1) | MIT (L1) | MIT (L1) | MIT (L1) | MIT (L1) |
| 发布纪律 | **8 版全正式** | ~1 天/版 | 全 prerelease | 版本号倒挂 | 正式版 | 无 release | 正式版 |
| 引擎中立 | 8（协议层）/ 4（投入层） | 6 | 2 | 1 | 9 | 1 | 7 |
| 本地优先 | 7 | 6 | 9 | 8 | 6 | 10 | 7 |
| 形态深度 | 8 | 5 | 5 | 6 | 8 | 6 | 8 |
| 交付深度 | 7 | 5 | 4 | 2 | 3 | 6 | 7 |
| 多人协作 | **有（闭源侧）** | 无 | 无 | 无 | 无 | 无 | 无 |
Tutti 在**发布纪律**和**多人协作**两项上是七个样本里唯一拿到分的。代价是引擎接入投入严重偏科。
---
## 6. 宣称 vs 实测（claim_vs_reality）
### ① "Currently Claude Code, Codex, and Hermes；OpenClaw is in development"
**实际**：README 与代码对不上，两个方向都偏。
- 宣称"当前支持"的 **Hermes**，在 runtimeprep 里**没有 hermes.go**——它走的是 extension_runtime.go 的 RTK Python 插件机制（provider 标识 `acp:hermes`，用 Python 插件重写命令），只有测试文件 hermes_test.go(580) 与 hermes_verify_test.go(77)，没有原生 adapter。
- 宣称"in development"的 **OpenClaw**，确实只有 acp_provider_openclaw.go **52 行、零测试**（对比 OpenCode 的 301 行 + 540 行测试）——README 这处倒是诚实的。
- 反过来，**Cursor / OpenCode / Kimi / ComputerUse / BrowserUse** 在代码里都有完整实现，README 的支持列表却一个字没提。
**结论**：README 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。
**来源**：本地源码实测：runtimeprep 目录文件清单 + daemon/runtime/acp_provider_*.go 行数 + grep hermes 引用
### ② "多引擎中立"
**实际**：协议层中立（都走 ACP），**深度层远不中立**。Codex 2170 行 vs Kimi 127 行，17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高），Kimi / ComputerUse / BrowserUse 测试为零。所谓"中立"是**接入方式的中立**，不是**投入与保障的中立**。
**来源**：本地源码 wc -l 实测（实现文件与测试文件分别统计）
### ③ "Where people and agents build in tune（多人 × 多 Agent）"
**实际**：开源版里只有 "agents"，**"people" 那部分在闭源侧**。README 的 Two Versions 对照表明确：Group chat / Work with others / Work with others' agents / Simultaneous editing / Agent borrowing / Across devices / No-deploy sharing——七项全部是 VM 版专属，开源版一格 ✓ 都没有。而 VM 版是 Early Access，**创建 Room 需要邀请码**。Big @ 在开源版里只能在"你自己的 agent 之间"引用，跨人引用要 VM 版。
**来源**：README "Two Versions of Tutti" 与 "Tutti vs Tutti · VM" 两张对照表原文
### ④ "Apache-2.0 开源"
**实际**：许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半，核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码，不保证你能用到它宣传的完整体验。
**来源**：本地源码 NOTICE 全文 + README 版本对照表
### ⑤ "（隐含）体量小 = 成熟度低"
**实际**：反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的，但**发布纪律最好**：8 个 release 全是正式版，且维护 `stable` 滚动 tag。工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程）明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。**star 数与工程成熟度在本体系的七个样本里呈负相关。**
**来源**：GitHub releases API + 本地源码 NOTICE 与测试文件实测
---
## 7. 结论
### 该用
- 手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者
- 想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人
- 看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人
- 单人 + 多 Agent 的"接力"场景（开源版够用了）
### 不该用
- 指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）
- 主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）
- Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）
- 想用一个"开源版"体验完整产品的人（功能完整度约一半）
### 再看看
- OpenClaw 的 ACP 接入（52 行零测试，"in development"是诚实的，但别指望）
- Hermes 是否会有原生 adapter（目前走 Python 插件机制）
- 引擎接入深度会不会向 Kimi / OpenCode 倾斜（目前 Codex 一国独大）
- VM 版的定价与开放策略（Early Access 期免费，后续"可能按用量计费"）
---
## 8. 追踪备注
- **数据日期**：2026-09-01
- **★ / Fork / Issues**：3,660 / 371 / 185
- **最新版本**：v0.2.31 + `stable` 滚动 tag（2026-09-01 同日）
- **源码镜像**：gitinbox/tutti（public，source-only，2026-09-01 同步）
- **结构化档案**：`data/projects/tutti.yaml`
- **下次跟进点**：
- OpenClaw ACP 接入从 52 行增长到多少？有没有测试？
- Hermes 是否出现原生 adapter（hermes.go）？
- VM 版是否开放注册 / 公布定价？
- 引擎接入深度是否会向 Kimi / OpenCode 倾斜？
- `stable` 滚动 tag 的历史追溯问题会不会被解决？
<sub>本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar</sub>
data/projects/maka.yaml
+3 -3
View File
@@ -223,6 +223,6 @@ mirror:
sync_note: "depth=1 浅仓被 Gitea 拒绝（shallow update not allowed），脚本自动 --unshallow 补齐完整历史后达 147 MB，超过 nginx 约 50 MB 的 client_max_body_size，遂降级为源码快照（12 MB，剔除 png/gif/mp4/字体等非源码素材）。完整保真裸仓保留在本地 .mirrors/maka.git（163 MB）。服务器放开 nginx 上限后可推送完整版。"
mode: source-only
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 105
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=105"
data/projects/openclaw.yaml
+3 -3
View File
@@ -244,6 +244,6 @@ mirror:
连"源码快照"降级（通常能压到 1/4）也远无法覆盖。
许可证是 MIT（人工复核），不存在合规障碍——纯粹是体积不可行。
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 106
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=106"
data/projects/openwork.yaml
+3 -3
View File
@@ -245,6 +245,6 @@ mirror:
- "LICENSES/LicenseRef-OpenWork-EE.txt"
sync_note: "已镜像（source-only 快照，2026-09-01）。上游 291 MB，本机到 GitHub 实测 50 KB/s，拉取耗时较长且 git clone 无断点续传。许可证为目录切分（根 LICENSE 原文：/ee 之外为 MIT，/ee 为 OpenWork EE License）——镜像时排除 ee/ 与 LICENSES/LicenseRef-OpenWork-EE.txt，排除后为纯 MIT 故判 public。未排除的完整镜像会被脚本在推送前拒绝（public 目标 + 有 excludes 声明 + full 模式）。"
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 107
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=107"
data/projects/orca.yaml
+3 -3
View File
@@ -233,6 +233,6 @@ mirror:
mode: source-only
sync_note: "已镜像（source-only 快照）。本环境 github.com 经沙箱代理返回 502 封死 git clone，改用 codeload.github.com tarball 路线（~111 KB/s）下载工作树，剔除非源码素材（png/webp/mp4/ttf/mp3 等）后 196M → 104M 裸仓，2026-09-02 推送至 gitinbox/orca（public）。无完整历史，仅最新 main 快照。"
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 104
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=104"
data/projects/qwenpaw.yaml
+3 -3
View File
@@ -251,6 +251,6 @@ mirror:
109 MB 裸仓超 Gitea 50 MB 推送上限，故剔除图片/音视频/字体等素材后按快照提交：
推送 18 MB；完整保真裸仓（281 MB）保留在 .mirrors/qwenpaw.git，增量更新重跑脚本即可。
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 108
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=108"
data/projects/tutti.yaml
+3 -3
View File
@@ -299,6 +299,6 @@ mirror:
技术维度分析基于本地浅克隆 /Users/figmarlite/.../tutti_repo（8291 文件），
与本镜像是两份独立的检出，改动不同步。
article:
emlog_id: 0 # emlog 文章 ID，发布后回写
published_at: ""
url: ""
emlog_id: 109
published_at: 2026-09-03
url: "https://blog.apescale.com/?post=109"