diff --git a/articles/00-comparison-2.md b/articles/00-comparison-2.md new file mode 100644 index 0000000..6daf593 --- /dev/null +++ b/articles/00-comparison-2.md @@ -0,0 +1,340 @@ +# 七个 Agent 项目，三种「开源」：当 star 数开始说反话 + +> **速览** +> +> | 项 | 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 个：赛道裂成了三层 + +原先四个样本可以塞进「开发者工具链」这一层。加入新样本后，至少是三层： + +```text +┌─ 个人助理执行层 ─────────────────────────────────────────────────┐ +│ 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 数与工程纪律负相关 + +这是本批样本最刺眼的一条。把「工程纪律」拆成三个可核实的指标来看： + +| 项目 | Star | 最近 100 次提交 TOP1 占比 | release 形态 | 安全默认值 | +| --- | --- | --- | --- | --- | +| OpenClaw | **388,438** | 64%（steipete） | **版本号倒挂** | **默认无沙箱** | +| Orca | 58,771 | **79%**（nwparker） | 节奏稳定 | 强人在环 | +| QwenPaw | 34,758 | **15%**（最健康） | **全是 beta** | 五层默认开 | +| OpenWork | 23,253 | 52% | v0.18.40 | 浏览器登录授权 | +| iPolloWork | 5,201 | 39% | 一天多版 | 需审批 | +| Maka | 4,373 | 23% | 无正式 release | 沙箱边界审批 | +| Tutti | **3,660** | 59% | **全部正式版** | workspace 级 | + +三个观察： + +**① 版本号最能说明问题。** 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 则是五层默认全开：** + +| 层 | 实现 | +| --- | --- | +| Sandbox | 内核级隔离：macOS Seatbelt / Linux Bubblewrap + Landlock / Windows AppContainer | +| Tool Guard | YAML 规则引擎 + ShellEvasionGuardian，执行前检查每次工具调用，识别命令注入、路径穿越、反弹 shell、混淆攻击 | +| File Guard | 独立于 Tool Guard，默认保护 `~/.qwenpaw.secret/`、`~/.ssh` 等敏感路径 | +| Skill Scanner | 第三方 skill 激活前扫描提示词注入、硬编码密钥、数据外泄 | +| Access Policy | 声明式规则，工具级粒度的放行 / 拒绝 / 人工批准 | + +**但两边都有各自的坑，别急着下结论：** + +- 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（真） | 法律上完全自由 | **机器读不出来**：SPDX 判为 NOASSERTION | +| **QwenPaw** | Apache-2.0 | 代码自由，但无正式版 | 全是 beta；`--defaults` 默认开遥测 | +| **Tutti** | Apache-2.0 | 代码自由，功能砍半 | 核心协作能力在闭源 VM 侧，需邀请码 | + +**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 版 | +| --- | --- | --- | +| Group chat | — | ✓ | +| Work with others | — | ✓ | +| Work with others' agents | — | ✓ | +| Simultaneous editing | — | ✓ | +| Agent borrowing | — | ✓ | +| Across devices | — | ✓ | +| No-deploy sharing | — | ✓ | + +而 VM 版是 Early Access，**创建一个 Room 就要邀请码**（waitlist）。 +也就是说：宣传语 "Where people and agents build in tune" 里的 "people" 那部分， +开源版里是不存在的。**Apache-2.0 保证你能自由改代码，不保证你能用到它宣传的完整体验。** + +--- + +## 5. 代码级实测：Tutti 的引擎接入深度有多不对等 + +Tutti 是唯一能读到完整源码的样本（本地浅克隆 8291 个文件）， +所以这一节的每个数字都是 `wc -l` 实测，不是转述。 + +它的引擎接入是**双层架构**，这是七个样本里分层最清楚的： + +```text +第 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 上被真正验证过。** + +**② 测试密度与投入规模成反比。** + +| 引擎 | 实现行 | 测试行 | 测试密度 | +| --- | --- | --- | --- | +| OpenCode | 392 | 218 | **0.56**（最高） | +| Cursor | 446 | 187 | 0.42 | +| Claude | 410 | 136 | 0.33 | +| **Codex** | **2170** | 261 | **0.12**（最低） | +| Kimi | 127 | 0 | 0.00 | +| ComputerUse / BrowserUse | 43 | 0 | 0.00 | + +**投入最重的 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 次提交）： + +| 项目 | Star | TOP1 占比 | 去重作者 | 备注 | +| --- | --- | --- | --- | --- | +| Orca | 58,771 | **79%** | — | nwparker 一人独大 | +| OpenClaw | 388,438 | 64% | 27 | steipete | +| Tutti | 3,660 | 59% | **10** | jomeswang | +| OpenWork | 23,253 | 52% | **3** | **只有 3 人在提交** | +| iPolloWork | 5,201 | 39% | 7 | zjy-web222 | +| Maka | 4,373 | 23% | 27 | Astro-Han（Apache 孵化，人多） | +| QwenPaw | 34,758 | **15%** | 24 | 最健康 | + +**两个需要修正此前判断的地方：** + +- **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 的适配情况 | +| --- | --- | --- | +| 形态纵深 | 单点工具 → 统一工作台 | 统一入口（Gateway + 8 渠道），但不是可视化工作台 → 勉强 6 | +| 引擎立场 | 绑定单引擎 → 多引擎中立 | **不适用**：它自己就是引擎，不代理任何外部 agent | +| 本地优先 | 强云依赖 → 完全本地 | 本地 Gateway + 支持本地模型 → 8 | +| 交付物纵深 | 只出代码 → 多模态可编辑 | **不适用**：它产出"事儿办完了"，不是文件型交付物 | + +关键点在于「引擎立场」这一项：**给 OpenClaw 打 1 分，含义不是"被绑定了"，而是"不需要中立"。** +这两者在用户侧的风险完全不同： + +- 「绑定单引擎」= 想换换不了（Maka 属于此类） +- 「自身即引擎」= 压根不用换（OpenClaw、QwenPaw 属于此类） + +把它们混在同一根轴上会得出误导性结论。本系列的做法是**照实标注而不是强行打分**—— +在档案里把该项标记为「自身即引擎」，并在象限图脚注里说明。 +同理，QwenPaw 的「引擎立场」也不适用，但要注意区分：**它的模型层是真中立的** +（14+ provider 可换），只是 agent 引擎层不存在中立问题。 + +象限图上还出现了一个新的技术性处理：7 个点里有两组坐标完全重合 +（视图 A 里 Maka 与 OpenClaw 都是 6/1，视图 B 里 iPolloWork 与 Tutti 都是 7/7）。 +完全重合的点会被后画的那个整个盖住，读者会以为少收录了一个项目， +所以脚本现在会把重合组沿一个小圆散开，并在图下注明。 + +--- + +## 8. 选型建议 + +按"你要解决什么问题"来选，而不是按 star 数： + +| 你的情况 | 建议 | 不要选 | +| --- | --- | --- | +| 想让 AI 接管日常事务（邮件/日历/出行） | OpenClaw（渠道最全）或 QwenPaw（安全默认最强） | 其余五个（都是开发者工具） | +| 把隐私和数据主权放第一位 | QwenPaw（本地模型无需 API key、五层安全默认开） | OpenClaw（沙箱默认关） | +| 有多个 agent 订阅，想让它们接力干活 | Tutti | Orca（它只做并行，不做上下文共享） | +| 想让 agent 产出 PPT / 设计稿 / 网页 | iPolloWork、Tutti | 其余（交付物只有代码） | +| 需要 agent 的执行过程可审计、可复现 | Maka（唯一自带评测框架） | Orca（治理还是草稿） | +| 团队已在用某款 agent，只想让能力跨工具复用 | OpenWork | — | +| 想同时跑多个方案横向比对 | Orca（兼容面最广） | 需要稳定 SLA 的团队别选它 | + +**通用提醒（对七个项目都成立）：** + +- 别把 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 快照，所有代码行数均为本地源码实测。 diff --git a/articles/00-comparison-2.meta.yaml b/articles/00-comparison-2.meta.yaml new file mode 100644 index 0000000..6a60128 --- /dev/null +++ b/articles/00-comparison-2.meta.yaml @@ -0,0 +1,5 @@ +# 发布元数据（由 scripts/publish_emlog.py 维护） +# 本文不属于单个项目，ID 不落在 data/projects/ 下 +emlog_id: 100 +url: "https://blog.apescale.com/?post=100" +last_published: "2026-09-01" diff --git a/articles/00-overview.md b/articles/00-overview.md index 84a439c..d1641f6 100644 --- a/articles/00-overview.md +++ b/articles/00-overview.md @@ -71,8 +71,11 @@ 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 | +| **OpenClaw** | 站在「个人助理执行层」，而且是**唯一一个不面向开发者的样本**。 它不接入别的 agent，自己就是 agent；不产出代码交付物，产出的是"事儿办完了"—— 邮件发了、日程改了、值机办了。入口是用户已经在用的聊天软件，不是 IDE 也不是桌面工作台。 这一条把它和本体系其余 6 个样本彻底分开：**它们的用户是开发者，OpenClaw 的用户是普通人。** | 想让 AI 接管日常事务（收件箱、日历、出行）的非技术用户、重度聊天软件用户（WhatsApp / Telegram / iMessage / Signal）、想在自己机器上跑私人助理、拒绝 SaaS 托管的数据敏感用户 | 免费开源 + 赞助（README 有 Sponsors 段）。创始人 2026-02 加入 OpenAI 后， OpenAI 承诺在保持 MIT 的前提下继续赞助，项目转由独立基金会运营。 这是四个样本里唯一"没有商业变现路径"的——目前看不到收费层。 | MIT（SPDX 误判，人工复核确认） | 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 | +| **QwenPaw** | 与 OpenClaw 同处「个人助理执行层」，是本项目在本体系中唯一的正面对手。 但立足点不同：OpenClaw 靠**渠道覆盖与生态规模**取胜，QwenPaw 靠**安全默认值与 本地可跑**取胜。它把自己定位成"能长期记住你、数据不离开你机器的私人助理"， 而不是功能最全的助理。 团队背景决定了差异化：背靠 AgentScope（AgentScope / AgentScope Runtime / ReMe）， 记忆系统直接建在 ReMe 个人知识框架上。 | 对数据主权与隐私有硬要求、希望助理完全跑在本地的个人用户、需要在钉钉 / 飞书 / 微信 / QQ 等国内渠道里用助理的团队、想不买 API key 就先跑起来的尝鲜用户（QwenPaw-Flash 本地模型）、愿意用功能广度换安全确定性的自用开发者 | Apache-2.0 全开源，未见收费层；提供 Docker / 阿里云 ECS / AgentScope 平台 / ModelScope 创空间等多条部署路径（云部署路径隐含云厂商导流）。 与 OpenClaw 一样**没有明示的变现路径**。 | Apache License 2.0 | L1 | +| **Tutti** | 站在「多人 × 多 Agent 的实时协作空间层」，是七个样本里**唯一把"多人"写进定位的**。 它不造引擎、不卖模型，做的是"让你已有的 agent 订阅在同一个工作区里协同"： Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。 但它的商业模式是清晰的 open-core：**开源版只给"单人 + 多 Agent"， "多人 + 多设备 + 云同步"全在闭源的 Tutti · VM 侧**（Early Access，需邀请码）。 | 同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者、需要 agent 之间共享上下文、接力同一件事的小团队、想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人、需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版） | **Open-core 双轨**：开源版（Apache-2.0）免费且自托管；Tutti · VM 为 Early Access 商业版，需邀请码创建 Cloud Room。Tutti 内置 Agent 在 Early Access 期免费， README 明示"后续可能按用量计费"。 这是七个样本里**变现路径最清晰的一个**。 | Apache License 2.0 | L1 | ### 场景维度 @@ -80,8 +83,11 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出 | --- | --- | --- | --- | | **iPolloWork** | desktop-app | approval-gated | code、doc、ppt、website、design、video | | **maka** | 桌面应用、TUI / CLI、评测框架 | 强：工具越过沙箱边界必须审批；运行可中止；失败被分类。 | code、artifact、eval-report、execution-record | +| **OpenClaw** | 聊天软件频道（主要入口）、本地守护进程 Gateway（控制面）、Web Control UI / CLI / TUI、桌面与移动端伴侣 App（macOS / Windows / iOS / Android） | 配对审批：支持 DM 的频道**默认会配对未知发送者**，需人工 `openclaw pairing approve` 确认。 2.0 新增私密凭据请求（遮罩输入，敏感信息不进聊天记录与模型上下文）与插件安装前能力展示。 | 事务结果（邮件 / 日程 / 预订 / 消息）——不是文件型交付物、文件与本地系统操作、Canvas / 语音 / 图像（伴侣 App 侧） | | **openwork** | MCP 远程服务、桌面应用（可选）、浏览器登录授权 | 能力调用需人工在浏览器登录并选择组织；企业侧由管理员通过策略管控。 | workflow、skill-package、capability | | **orca** | 桌面应用、移动端伴随、CLI、SSH 远程 | 强人在环：需人工比并结果、批注 diff、批准合并。 但 5000 个自开 issue 说明产品自身也在被 AI 自动改进。 | code、diff、review-comment | +| **QwenPaw** | Web 控制台（默认 127.0.0.1:8088）、Terminal UI（TUI）、IM 渠道（钉钉 / 飞书 / 微信 / QQ / Discord / Telegram / iMessage）、桌面应用（Beta） | Access Policy 是声明式访问规则，可对每次能力调用设置 放行 / 拒绝 / 请求人工批准， 粒度到工具级、可按来源匹配。Tool Guard 提供 STRICT / SMART / AUTO / OFF 四档。 | code（Coding Mode 三栏 IDE）、文档处理结果（PDF / Word / Excel / PowerPoint）、记忆条目（可读可编辑可搜索的 Markdown 记忆）、定时推送内容（资讯摘要 / 视频脚本） | +| **Tutti** | 桌面应用（Electron）、TUI / CLI（Go）、Workbench 节点（Browser / Terminal / App Center）、【闭源 VM】Cloud Room 多人多设备 | Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback （Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。 | code、设计稿（AI Canvas / UI-UX 原型）、文档 / PPT（Docs / AI PPT 内置 App）、会话回放（session-replay） | ### 技术维度 @@ -89,8 +95,11 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出 | --- | --- | --- | --- | --- | --- | | **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"）。 | 是 | +| **OpenClaw** | 本地守护进程（Gateway）为控制面 + 多渠道接入。注意它**没有 IDE 形态**， 也不是传统意义的桌面工作台——Control UI 只是 Gateway 的一个 Web 前端。 | 无（自身即引擎） | 把 OpenClaw 和"多引擎中立"放在一起比较会得出误导性结论。 横向对比时应把它的引擎立场标记为「自身即引擎」而非「绑定单引擎」， 两者在用户侧的风险完全不同：绑定单引擎是"换不了"，自身即引擎是"不用换"。 | 不绑定：支持 hosted 与 local model providers。2.0 默认 GPT-5.6， 本地模型方面把 node-llama-cpp 换成托管 llama-server，默认上下文提到 64K。 | 是 | | **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 的订阅与额度 | 是 | +| **QwenPaw** | Python 包（pip / 安装脚本）+ Web 控制台 + TUI + 桌面应用（Beta）+ Docker。 形态偏"服务端 + 多渠道"，与 OpenClaw 的"本地守护进程 Gateway"思路接近， 但更传统——没有 OpenClaw 那套原生伴侣 App 与设备节点。 | 无（自身即引擎）；模型层有统一 provider 抽象 | 注意区分两个"中立"：模型层是真中立（14+ provider 可换）， agent 引擎层不存在中立问题（它自己就是）。横向比较时不要混为一谈。 | 不绑定。本地侧主推自研 QwenPaw-Flash（2B / 4B / 9B，Q4 / Q8 量化， ModelScope 与 Hugging Face 可下载），云侧 14+ provider。 **"无需 API key 即可跑"是它相对所有竞品的硬差异。** | 是 | +| **Tutti** | pnpm + Go Workspace 混合 monorepo；桌面端 Electron；守护进程 tuttid（Go）； CLI（Go）；Agent 运行时基于 **ACP（Agent Client Protocol）** + uv / npm / pnpm 托管运行时。语言构成 TypeScript 48.8% / Go 45.4% —— **后端用 Go 而不是 Node， 这是它和其余 Electron 系样本的关键差异**（守护进程的稳定性与并发模型更好）。 | ACP（Agent Client Protocol）+ runtimeprep 准备层 | ⚠️ **接入深度极不对等，实测数据如下**（packages/agent/runtimeprep/，非测试行数）： Codex 16 文件 2170 行 ← 一国独大 Tutti 内置 2 文件 653 行 Cursor 2 文件 446 行 Claude 3 文件 410 行 OpenCode 2 文件 392 行 Kimi 1 文件 127 行 ComputerUse 1 文件 43 行 BrowserUse 1 文件 43 行 **Codex 是 Kimi 的 17 倍。** 且只有 Codex 有 Windows 变体文件 （codex_directory_windows.go 149 行、codex_file_windows.go、 codex_models_cache_windows.go 等 4 个），其余引擎一个 Windows 变体都没有 ——说明**只有 Codex 在 Windows 上被真正验证过**。 更有意思的是**测试密度与实现规模成反比**： OpenCode 392 行实现 / 218 行测试 = 0.56（密度最高） Cursor 446 / 187 = 0.42 Tutti 内置 653 / 274 = 0.42 Claude 410 / 136 = 0.33 Codex 2170 / 261 = **0.12（投入最大，保障最薄）** Kimi 127 / 0 = 0.00 ComputerUse / BrowserUse 43 / 0 = 0.00 即：**投入最重的 Codex 恰恰是质量保障最薄弱的地方**，因为它的边界情况最多 （Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。 另有 19 个通用测试文件共 7851 行（preparer_test.go 单文件 2906 行） 覆盖跨引擎路径，部分弥补了单引擎测试的缺失。 | 不绑定模型，但**绑定 agent 订阅**：README 明确"用你已有的 Claude / Codex / 其他订阅"。没有订阅的用户可用 Tutti 内置 Agent（Early Access 期免费）。 | 是 | ### 生态与风险 @@ -98,8 +107,11 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出 | --- | --- | --- | --- | --- | --- | --- | --- | | **iPolloWork** | 5201 | 976 | 80 | v0.50.12 | 一天多版 | beta | 2026-09-01 | | **maka** | 4373 | 406 | 398 | v0.2.0-dev.9.20260831 | 一天多版 | 孵化期 | 2026-09-01 | +| **OpenClaw** | 388438 | 81543 | 5925 | v2026.8.1 | 约 4 天/版本 | 高速迭代期 | 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 | +| **QwenPaw** | 34758 | 3052 | 898 | v2.2.0-beta.5 | 约 1 天/版本 | beta 活跃期 | 2026-09-01 | +| **Tutti** | 3660 | 371 | 185 | stable | 约 3 天/版本 | 快速成长期 | 2026-09-01 | **成熟度详解** @@ -107,11 +119,22 @@ Codex Harness 开放、DeepSeek Harness 开放，一个个执行引擎被拆出 - **maka**：治理成熟度最高（ASF 流程 + 评测框架 + 文档契约）， 产品成熟度最低（无正式 release、平台只支持 arm64 macOS、功能默认保守）。 属于「地基打得最实，房子盖得最慢」。 +- **OpenClaw**：功能面极广、迭代极快（10 个月 237 次版本迭代），但**版本号体系失序**、 +安全默认值偏松、巴士系数接近 1。适合愿意自己加固环境并接受高频变更的个人， +不适合需要可预测升级路径与稳定 SLA 的团队——尤其考虑到 2.0 自己都承认 +"从 v2026.7.1 及更早版本升级时可能破坏原有 Agent 配置"，官方建议升级前先备份。 - **openwork**：工程成熟度最高：有可执行测试规格（evals/）、声明式环境（worlds/）、 明确的贡献契约与许可边界。但仍处 0.x 主版本（v0.18.40）， API 与数据格式可能变动。 - **orca**：功能广度第一，工程治理末位。一天多版（v1.4.194）说明迭代极快， 但 issue 只进不出、巴士系数为 1，属于「高速原型期」而非「可托付生产期」。 +- **QwenPaw**：工程治理（巴士系数最健康、安全分层最完整）明显强于它的星标邻居们， +但**发布纪律是短板**——所有 release 都是 beta，且一天能发多个 beta。 +功能面广、迭代快，适合自用与尝鲜；不适合作为团队关键链路的基础设施。 +- **Tutti**：建仓仅 2.5 个月，处在快速成长期。发布纪律是七个样本里最好的（全部正式版 + +stable 滚动 tag），工程规范度高（NOTICE 精确到 revision hash、通用测试 7851 行、 +Go 守护进程），但引擎接入深度严重向 Codex 倾斜、开源版功能完整度约一半。 +适合自用与"多 agent 接力"场景，不适合指望开源版承担团队协同。 ### 宣称 vs 实测 @@ -129,6 +152,11 @@ API 与数据格式可能变动。 | **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」段 | +| **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） | +| **OpenClaw** | 3001 名贡献者 / 933 人共建 2.0（项目方与媒体反复引用） | 数字属实，但不能推导出"去中心化"。抽样最近 100 次提交：创始人 steipete 独占 64 次（64%），第二名 vincentkoc 仅 4 次，去重作者 27 人。 **巴士系数接近 1** —— 贡献者基数和实际决策集中度是两回事。 | GitHub commits API（2026-09-01 取 main 分支最近 100 次提交的 author.login 分布） | +| **OpenClaw** | 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） | +| **OpenClaw** | 跑在你自己的设备上、own your data | 前半句属实（Gateway 是本地控制面，支持本地模型）。 但**安全默认值偏松**：README 原文承认工具默认跑在宿主机上、除非你配置沙箱； 支持 DM 的频道默认配对未知发送者（需人工 approve）。 历史上出过 CVE-2026-25253（CVSS 8.8）：访问一个恶意页面即可窃取令牌、 禁用沙箱、在宿主机执行任意代码。"本地运行"不等于"默认安全"。 | README Security 章节原文；CVE-2026-25253（媒体报道，CVSS 8.8） | +| **OpenClaw** | MIT 开源 | 属实，但**机器读不出来**。GitHub 的 licensee 因为 LICENSE 末尾多了一段 第三方声明指引（THIRD_PARTY_NOTICES.md）而判定 NOASSERTION。 自动定级会给出 L3/private 的错误结论，必须人工读 LICENSE 原文才能纠正。 （本体系第二次遇到这类误判，前一次是 OpenWork 的目录切分许可。） | GitHub license API 取原始文件，人工阅读全文 1170 字节 | | **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 行 | @@ -138,6 +166,17 @@ API 与数据格式可能变动。 | **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 段 | +| **QwenPaw** | 数据归你、本地优先、不上传任何本地使用记录 | 主力诉求成立（本地模型可完全离线跑，遥测一键可关）。 但 README 的 Telemetry 章节写明：**`qwenpaw init --defaults` 会自动接受遥测**， 且"每升级一个版本会重新收集一次"。而 `--defaults` 恰恰是快速上手文档 推荐的默认路径。收集的是匿名环境数据、不影响功能，但"默认接受" 与"数据归你"的叙事存在张力——尤其对把隐私当核心卖点的产品。 | README Telemetry 章节原文（'If you choose --defaults, telemetry is accepted automatically.'） | +| **QwenPaw** | 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） | +| **QwenPaw** | 五层安全，内核级沙箱 | 五层的实现描述相当具体（Seatbelt / Bubblewrap+Landlock / AppContainer， ShellEvasionGuardian 检测命令注入与反弹 shell），可信度高。 但 **Tool Guard 提供 OFF 档**，整层可以关掉；Access Policy 也是"可配置为放行"。 安全强度取决于用户配置，不是不可绕过的硬边界。 | README Security Features 章节（列出 Tool Guard 的 STRICT / SMART / AUTO / OFF 四档） | +| **QwenPaw** | 无需 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** | （历史）QwenPaw 是一个 2026 年 4 月后出现的全新项目 | 不是。它是 2026-02-24 以 **CoPaw** 之名建仓的项目，2026-04-12 才更名。 检索 2026 年 4 月之前的社区讨论、issue 与技术文章时必须按 CoPaw 检索， 否则会严重低估它的历史沉淀与已知问题。 | GitHub repo API（created_at=2026-02-24）+ README News 章节的更名公告 | +| **QwenPaw** | （检索风险）github.com/agentscope-ai/QwenPaw 是唯一官方仓库 | 存在同名仓库 `aqua88hn/qwenpaw`，README 内容与官方高度相似。 以 star 数（官方 34.7k）与组织归属判断，官方仓库在 agentscope-ai 组织下； 但同名仓库的存在会让"按名字搜仓库"直接得到错误结果。 | GitHub 搜索结果与 repo API 交叉核对（agentscope-ai/QwenPaw = 34758 star，非 fork） | +| **Tutti** | （README）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 引用 | +| **Tutti** | 多引擎中立 | 协议层中立（都走 ACP），**深度层远不中立**。Codex 2170 行 vs Kimi 127 行， 17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。 而且测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高）， Kimi / ComputerUse / BrowserUse 测试为零。 所谓"中立"是**接入方式的中立**，不是**投入与保障的中立**。 | 本地源码 wc -l 实测（实现文件与测试文件分别统计） | +| **Tutti** | 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' 两张对照表原文 | +| **Tutti** | Apache-2.0 开源 | 许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、 上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。 但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半， 核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码， 不保证你能用到它宣传的完整体验。 | 本地源码 NOTICE 全文 + README 版本对照表 | +| **Tutti** | （隐含）体量小 = 成熟度低 | 反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的， 但**发布纪律最好**：8 个 release 全是正式版，且维护 `stable` 滚动 tag。 工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程） 明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。 **star 数与工程成熟度在本体系的七个样本里呈负相关。** | GitHub releases API + 本地源码 NOTICE 与测试文件实测 | ### 一句话结论 @@ -145,8 +184,11 @@ API 与数据格式可能变动。 | --- | --- | --- | --- | | **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作——方向踩在点上，但三种引擎的接入深度并不齐整，且许可证决定了它暂时只适合个人或极小团队试用 | 想在同一个界面管理多引擎项目、并希望 agent 产出的 PPT / 网页 / 设计 / 视频之后还能继续手工修改的个人开发者，或少于 3 人的极小团队 | 3 人以上需要正式落地的团队（许可证要求书面授权）、期待 Codex 原生级集成的用户（目前只有 MCP 控制面）、以及追求稳定的生产环境（v0.50.x、一天多版、DSH 集成未进稳定版） | | **maka** | 四个里唯一把「执行记录」当地基的项目——治理与可复现性最强，产品成熟度最弱。 | 对审计、数据主权、可复现评测有硬要求的团队； 做 agent 横向对比研究的工程团队。 | 要开箱即用、要 Windows / Linux、要丰富第三方集成的人； 以为 ASF 品牌等于生产可用的决策者。 | +| **OpenClaw** | 388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动—— 但沙箱默认关闭、版本号已经乱到读不懂发布节奏、关键提交仍系于一人之手。 | 想让 AI 真正接管日常事务且愿意自己加固部署环境的重度个人用户； 想研究"非开发者向 agent 产品长什么样"的人（本体系里唯一的样本）。 | 把 star 数当成生产就绪度的人；指望沙箱开箱即保护的人； 需要可预测升级路径的团队；希望助理"中立接入多个引擎"的人（它自己就是引擎，不接别人）。 | | **openwork** | 把「能力」而不是「桌面」做成产品——工程治理最好的一个，但它和自称要替代的东西不是一个物种。 | 已固定在某款 agent 上、只想让团队能力跨工具复用的开发者； 需要统一管控 agent 能力与模型配额的组织 IT。 | 想要一个开箱即用的桌面 agent 工作台的人； 以为拿到的是完整 Cowork 平替的人。 | | **orca** | 兼容面最广的并行 agent 编排外壳——广度做到极致，深度与治理都还是草稿。 | 已在重度使用 CLI agent、想同时跑多个方案横向比对的个人开发者与小团队。 | 需要稳定 SLA、指望社区 triage 与多人维护保障的团队； 指望它统一各引擎能力（结构化调用、统一权限、一致口径）的架构选型者。 | +| **QwenPaw** | 七个样本里安全默认值最完整、巴士系数最健康的个人助理—— 但至今没有发过一个正式版，且 `--defaults` 安装路径会默认打开遥测。 | 把数据与隐私放第一位、希望助理完全跑在本地的个人与小团队； 需要在钉钉 / 飞书 / 微信 / QQ 渠道里用助理的国内团队； 想不买 API key 先把流程跑通的尝鲜者。 | 需要正式版与稳定升级路径的团队（它全是 beta）； 指望 2B / 4B 本地模型扛复杂 agent 任务的人； 把"五层安全"当成不可绕过硬边界的人（Tool Guard 有 OFF 档）。 | +| **Tutti** | 把「多 agent 共享上下文、接力干活」做成了产品，且是七个里发布纪律最好的—— 但接入深度严重偏袒 Codex（17 倍差距），而宣传的「多人协作」全在闭源 VM 版。 | 手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者； 想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人； 看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人。 | 指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）； 主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）； Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）。 | 视图 A · 形态纵深 × 引擎立场 @@ -163,12 +205,19 @@ API 与数据格式可能变动。 多引擎中立 iPolloWork - -maka + +maka + +OpenClaw openwork orca + +QwenPaw + +Tutti +※ 坐标完全重合的项目已沿小圆散开以便区分：maka、OpenClaw 视图 B · 本地优先 × 交付物纵深 @@ -183,14 +232,21 @@ API 与数据格式可能变动。 完全本地 只出代码 多模态可编辑 - -iPolloWork - -maka + +iPolloWork + +maka + +OpenClaw openwork orca + +QwenPaw + +Tutti +※ 坐标完全重合的项目已沿小圆散开以便区分：iPolloWork、Tutti @@ -206,14 +262,18 @@ API 与数据格式可能变动。 | --- | --- | --- | | **iPolloWork** | 把多个 Agent 引擎收进同一个可编辑工作台的野心之作 | [已发布](https://blog.apescale.com/?post=97) | | **maka** | 四个里唯一把「执行记录」当地基的项目 | 待发布（见下方横评） | +| **OpenClaw** | 388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动 | 待发布（见下方横评） | | **openwork** | 把「能力」而不是「桌面」做成产品 | 待发布（见下方横评） | | **orca** | 兼容面最广的并行 agent 编排外壳 | 待发布（见下方横评） | +| **QwenPaw** | 七个样本里安全默认值最完整、巴士系数最健康的个人助理 | 待发布（见下方横评） | +| **Tutti** | 把「多 agent 共享上下文、接力干活」做成了产品，且是七个里发布纪律最好的 | 待发布（见下方横评） | **跨项目文章** - [四个 Agent 工作台的路线分野：把「多引擎中立」拆开看](https://blog.apescale.com/?post=99) — 2026-09-01 +- [七个 Agent 项目，三种「开源」：当 star 数开始说反话](https://blog.apescale.com/?post=100) — 2026-09-01 -> 待补深度文：maka、openwork、orca。当前可先读上方跨项目文章，其中已包含这些项目的完整分维度对比。 +> 待补深度文：maka、OpenClaw、openwork、orca、QwenPaw、Tutti。当前可先读上方跨项目文章，其中已包含这些项目的完整分维度对比。 --- diff --git a/data/projects/openclaw.yaml b/data/projects/openclaw.yaml new file mode 100644 index 0000000..b18d2e9 --- /dev/null +++ b/data/projects/openclaw.yaml @@ -0,0 +1,249 @@ +# openclaw · 项目档案 +# 生成于 2026-09-01 · 由 scripts/new_project.py 从 schema 生成 +# 人工补完重点：business / scenario / tech / risk.claim_vs_reality / verdict +# 字段规范见 schema/project.schema.yaml + +id: openclaw +name: "OpenClaw" +repo: "openclaw/openclaw" +homepage: "https://openclaw.ai" +added_at: "2026-09-01" +status: active +identity: + tagline: "Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞" + vendor: "OpenClaw Foundation（非营利基金会）" + vendor_type: "foundation" + region: "奥地利（创始人 Peter Steinberger）/ 基金会独立运营" + first_seen: "2025-11-24" + name_history: # 三个月两次改名，检索历史资料时容易漏 + - "Clawdbot（2025-11 创始）" + - "Moltbot" + - "OpenClaw（2026-01-30 定名）" +business: + + positioning: |- + 站在「个人助理执行层」，而且是**唯一一个不面向开发者的样本**。 + 它不接入别的 agent，自己就是 agent；不产出代码交付物，产出的是"事儿办完了"—— + 邮件发了、日程改了、值机办了。入口是用户已经在用的聊天软件，不是 IDE 也不是桌面工作台。 + 这一条把它和本体系其余 6 个样本彻底分开：**它们的用户是开发者，OpenClaw 的用户是普通人。** + target_users: + - 想让 AI 接管日常事务（收件箱、日历、出行）的非技术用户 + - 重度聊天软件用户（WhatsApp / Telegram / iMessage / Signal） + - 想在自己机器上跑私人助理、拒绝 SaaS 托管的数据敏感用户 + monetization: |- + 免费开源 + 赞助（README 有 Sponsors 段）。创始人 2026-02 加入 OpenAI 后， + OpenAI 承诺在保持 MIT 的前提下继续赞助，项目转由独立基金会运营。 + 这是四个样本里唯一"没有商业变现路径"的——目前看不到收费层。 + # ⚠️ 自动定级把本项目判为 L3/private，**人工复核后推翻**。 + # SPDX=NOASSERTION 的原因：LICENSE 末尾多了一段 + # "Third-party notices for incorporated or adapted code are recorded in + # THIRD_PARTY_NOTICES.md." + # GitHub 的 licensee 检测器见到正文之外的附加段落就判定为 NOASSERTION。 + # 但原文主体是完整无改动的 MIT（Copyright 2026 OpenClaw Foundation）， + # 附加段落只是指向第三方声明文件，不构成许可条款变更 → 实为 L1 / MIT / 可自由再分发。 + # 这是继 OpenWork 之后第二个「SPDX 不可信，必须读原文」的判例。 + license: + spdx: "NOASSERTION" + name: "MIT（SPDX 误判，人工复核确认）" + openness: L1 + redistributable: true + manual_review: true + manual_review_reason: "SPDX=NOASSERTION 系检测器误判；LICENSE 原文为完整 MIT，仅末尾附带第三方声明指引" + key_restrictions: + - 无实质性使用限制 + - MIT 不含商标许可，OpenClaw 名称与龙虾 Logo 未单独授权 + - ⚠️ 自动化合规扫描工具（如 licensee、FOSSology）会把它识别为 NOASSERTION 并告警， + 需要人工出具复核说明才能过企业的开源合规流程 + moat: |- + 聊天渠道覆盖面（WhatsApp / Telegram / Slack / Discord / Google Chat / Signal / iMessage + 等 8+ 通道）+ 3001 名累计贡献者的插件生态 + ClawHub 市场 + 跨端伴侣 App（macOS / Windows / + iOS / Android 节点）。**网络效应在"渠道"和"插件"两侧同时成立**，这是它真正的壁垒。 + competitive_risk: |- + 创始人已在 OpenAI，OpenAI 随时可能推出官方同类产品直接覆盖。 + 更现实的风险是：**它的价值建立在"替用户操作真实账号"之上，而这个能力任何一家 + 操作系统厂商（Apple Intelligence / 微软 Copilot）都能在系统层直接拿走。** + +scenario: + + primary: + - 在 WhatsApp / Telegram 里一句话让助理处理收件箱、改日程、办登机 + - 用手机语音或照片触发本机的助理执行任务（ companion app 提供语音 / 摄像头 / 屏幕 / Canvas） + - 把助理常驻在家里的机器上，通过聊天软件远程使唤 + - 2.0 起：把一条会话授权给同事，多人带着完整上下文接力 + typical_use_cases: + - 发一张后院蛇的照片给助理，它识别物种、给出当地动物救助电话、建议怎么抓 + - 让助理每天早上把行业资讯摘要推到 Telegram + - 2.0 起：在 Mac 上开始一件事，交给云端 worker 继续跑完 + industries: + - 个人事务 / 生活助理 + - 小团队共享助理（2.0 新增） + interaction_mode: + - 聊天软件频道（主要入口） + - 本地守护进程 Gateway（控制面） + - Web Control UI / CLI / TUI + - 桌面与移动端伴侣 App（macOS / Windows / iOS / Android） + human_in_the_loop: |- + 配对审批：支持 DM 的频道**默认会配对未知发送者**，需人工 `openclaw pairing approve` 确认。 + 2.0 新增私密凭据请求（遮罩输入，敏感信息不进聊天记录与模型上下文）与插件安装前能力展示。 + deliverables: + - 事务结果（邮件 / 日程 / 预订 / 消息）——不是文件型交付物 + - 文件与本地系统操作 + - Canvas / 语音 / 图像（伴侣 App 侧） + +tech: + + form_factor: |- + 本地守护进程（Gateway）为控制面 + 多渠道接入。注意它**没有 IDE 形态**， + 也不是传统意义的桌面工作台——Control UI 只是 Gateway 的一个 Web 前端。 + stack: + - TypeScript 91% + - Swift 4.6%（macOS / iOS 原生） + - Kotlin 1.8%（Android 原生） + - JavaScript / Shell / CSS 各约 1% + engine_abstraction: + supported: [] # 不接入外部 agent 引擎 + mechanism: |- + **本字段对 OpenClaw 不适用，这是它区别于其余 6 个样本的根本点。** + 它不代理任何第三方 agent —— 它自己就是 agent，跑自己的执行循环。 + 可扩展性走的是 tools / skills / plugins 三条路（ClawHub 市场），不是"接别人的引擎"。 + abstraction_layer: "无（自身即引擎）" + depth_notes: |- + 把 OpenClaw 和"多引擎中立"放在一起比较会得出误导性结论。 + 横向对比时应把它的引擎立场标记为「自身即引擎」而非「绑定单引擎」， + 两者在用户侧的风险完全不同：绑定单引擎是"换不了"，自身即引擎是"不用换"。 + extension_system: + skills: "Skills 系统 + ClawHub 市场（clawhub.ai）" + plugins: "第三方插件机制；2.0 起安装前展示能力、来源、版本；来自可执行来源的插件需强制参数确认" + mcp: "通过 tools / plugins 体系扩展（README 未强调 MCP，与其余样本的依赖程度不同）" + model_binding: |- + 不绑定：支持 hosted 与 local model providers。2.0 默认 GPT-5.6， + 本地模型方面把 node-llama-cpp 换成托管 llama-server，默认上下文提到 64K。 + local_first: true + multi_agent: |- + 2.0 新增共享云端会话：一个会话可授权给多名成员，完整上下文保留、可接力与实时协作； + 会话能在本地设备、配对机器、云端 worker 之间迁移。底层存储从文件系统迁到 SQLite。 + permission_sandbox: |- + ⚠️ **默认无沙箱**。README Security 章节原文： + "Tools run on the host for the main session unless you configure sandboxing." + 即不显式配置则工具直接跑在宿主机上。官方另建议：不要暴露 Gateway 到开放互联网、 + 维持强认证。2.0 补齐了信任边界、最小权限、基于角色的权限分配与提示词滥用防护。 + observability: |- + Gateway 提供事件流；Control UI 可实时观看正在执行的任务、查看组件仪表盘。 + 2.0 新增会话精确搜索（可按词句回跳到上下文消息）。 + +ecosystem: + metrics: + stars: 388438 + forks: 81543 + open_issues: 5925 + subscribers: 1754 + created_at: 2025-11-24 + pushed_at: 2026-09-01 + size_kb: 3354345 + languages: {TypeScript: 91.0, Swift: 4.6, Kotlin: 1.8, JavaScript: 1.0, Shell: 0.6, CSS: 0.4} + latest_release: v2026.8.1 + release_cadence: 约 4 天/版本 + data_date: 2026-09-01 + stale: false + community: |- + GitHub 上星标最多的软件仓库（388k），累计 3001 名贡献者，README 的致谢段 + 有 649 个头像。2.0 由 933 名贡献者完成（其中 569 名首次参与）。 + 但贡献高度集中：最近 100 次提交中创始人 steipete 独占 64%，去重仅 27 人。 + standards: [] + notable_events: + - "2025-11：Peter Steinberger 创建，初名 Clawdbot" + - "2026-01-30：更名 OpenClaw" + - "2026-01：曝出 CVE-2026-25253 远程代码执行漏洞（CVSS 8.8，访问恶意页面即可窃取认证令牌、禁用沙箱、宿主机执行任意代码）" + - "2026-02：创始人加入 OpenAI，项目转由独立非营利基金会运营，OpenAI 承诺保持 MIT 并继续赞助" + - "2026-08-31：2.0 发布（v2026.8.1），重构安装、会话、记忆、权限、密钥、云端执行与团队协作" + +risk: + license_risk: |- + 法律上无风险（纯 MIT）。**工程上有风险**：SPDX 与主流合规扫描工具会识别为 + NOASSERTION，企业引入时会被自动拦下，需要人工出复核说明。 + 这个"机器读不懂"的成本，比许可证本身的限制更影响落地。 + vendor_lockin: |- + 许可证层面零锁定（MIT + 本地运行）。真正的锁定在**账号与渠道**： + 它替你操作的是真实邮箱、日历、聊天账号，迁移成本不在代码而在配置与凭据。 + claim_vs_reality: + - claim: "停更 7 周（多家媒体转述，指 7 月中旬 v2026.7.1 之后断更）" + actual: |- + 失真。查 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）。 + 多线并行导致版本号与实际时间顺序倒挂。 + source: "GitHub releases API（2026-09-01 取最近 12 个 release 的 published_at）" + - claim: "3001 名贡献者 / 933 人共建 2.0（项目方与媒体反复引用）" + actual: |- + 数字属实，但不能推导出"去中心化"。抽样最近 100 次提交：创始人 steipete + 独占 64 次（64%），第二名 vincentkoc 仅 4 次，去重作者 27 人。 + **巴士系数接近 1** —— 贡献者基数和实际决策集中度是两回事。 + source: "GitHub commits API（2026-09-01 取 main 分支最近 100 次提交的 author.login 分布）" + - claim: "PR 已经泛化成 Prompt Requests，AI 批量灌水（多家媒体报道）" + actual: |- + 我抽样最新 60 条 open PR，**不支持**这个说法：标题全部是规范的 + conventional commits（fix(memory-core)、refactor(sessions)、perf(media)）， + 去重 22 位作者，未见灌水特征。 + 但另一组数字确实异常：60 条**全部创建于 2026-09-01 同一天**， + 说明日 PR 量超过 60 条——流量压力真实存在，只是"质量崩坏"缺乏证据。 + 媒体报道的"必须附对话记录/截图/测试证据才能过审"是维护方的应对动作， + 从这批样本看，它似乎有效。 + source: "GitHub pulls API（state=open, sort=created, direction=desc, per_page=60）" + - claim: "跑在你自己的设备上、own your data" + actual: |- + 前半句属实（Gateway 是本地控制面，支持本地模型）。 + 但**安全默认值偏松**：README 原文承认工具默认跑在宿主机上、除非你配置沙箱； + 支持 DM 的频道默认配对未知发送者（需人工 approve）。 + 历史上出过 CVE-2026-25253（CVSS 8.8）：访问一个恶意页面即可窃取令牌、 + 禁用沙箱、在宿主机执行任意代码。"本地运行"不等于"默认安全"。 + source: "README Security 章节原文；CVE-2026-25253（媒体报道，CVSS 8.8）" + - claim: "MIT 开源" + actual: |- + 属实，但**机器读不出来**。GitHub 的 licensee 因为 LICENSE 末尾多了一段 + 第三方声明指引（THIRD_PARTY_NOTICES.md）而判定 NOASSERTION。 + 自动定级会给出 L3/private 的错误结论，必须人工读 LICENSE 原文才能纠正。 + （本体系第二次遇到这类误判，前一次是 OpenWork 的目录切分许可。） + source: "GitHub license API 取原始文件，人工阅读全文 1170 字节" + maturity: |- + 功能面极广、迭代极快（10 个月 237 次版本迭代），但**版本号体系失序**、 + 安全默认值偏松、巴士系数接近 1。适合愿意自己加固环境并接受高频变更的个人， + 不适合需要可预测升级路径与稳定 SLA 的团队——尤其考虑到 2.0 自己都承认 + "从 v2026.7.1 及更早版本升级时可能破坏原有 Agent 配置"，官方建议升级前先备份。 + maturity_level: "高速迭代期" + +chart: + # ⚠️ 四个维度对 OpenClaw 的适配度都有限——它不在"Agent 工作台"这条赛道上。 + # 坐标只是为了让它在同一张图里可比，解读时务必结合上方 engine_abstraction 的说明。 + form_depth: 6 # 统一入口（Gateway + 多渠道），但不是可视化工作台 + engine_neutral: 1 # 自身即引擎，不代理任何外部 agent；这不等于"绑定单引擎" + local_first_score: 8 # 本地 Gateway + 支持本地模型；2.0 推云端共享会话故未给满分 + deliverable_depth: 2 # 产出"事务结果"而非可编辑交付物体系 + chart_note: "本样本撑破了现有坐标系——四个维度均非为其设计，坐标仅作同图可比之用" +verdict: + one_liner: |- + 388k star 的个人 AI 助理，常驻你自己的机器、从聊天软件驱动—— + 但沙箱默认关闭、版本号已经乱到读不懂发布节奏、关键提交仍系于一人之手。 + who_should_use: |- + 想让 AI 真正接管日常事务且愿意自己加固部署环境的重度个人用户； + 想研究"非开发者向 agent 产品长什么样"的人（本体系里唯一的样本）。 + who_should_not: |- + 把 star 数当成生产就绪度的人；指望沙箱开箱即保护的人； + 需要可预测升级路径的团队；希望助理"中立接入多个引擎"的人（它自己就是引擎，不接别人）。 +mirror: + gitea_repo: "gitinbox/openclaw" + visibility: public + upstream: "https://github.com/openclaw/openclaw" + last_sync: "" + mode: "link-only" + sync_note: |- + **不镜像，仅存链接与元数据。** 仓库体积 3276 MB，撞上本体系两条硬约束： + ① GitHub 链路约 50 KB/s，全量拉取需约 19 小时且中途失败无断点续传； + ② Gitea 前置 nginx 的 client_max_body_size 约 50 MB，超限两个数量级， + 连"源码快照"降级（通常能压到 1/4）也远无法覆盖。 + 许可证是 MIT（人工复核），不存在合规障碍——纯粹是体积不可行。 +article: + emlog_id: 0 # emlog 文章 ID，发布后回写 + published_at: "" + url: "" diff --git a/data/projects/qwenpaw.yaml b/data/projects/qwenpaw.yaml new file mode 100644 index 0000000..d938ad1 --- /dev/null +++ b/data/projects/qwenpaw.yaml @@ -0,0 +1,255 @@ +# qwenpaw · 项目档案 +# 生成于 2026-09-01 · 由 scripts/new_project.py 从 schema 生成 +# 人工补完重点：business / scenario / tech / risk.claim_vs_reality / verdict +# 字段规范见 schema/project.schema.yaml + +id: qwenpaw +name: "QwenPaw" +repo: "agentscope-ai/QwenPaw" +homepage: "http://qwenpaw.agentscope.io/" +added_at: "2026-09-01" +status: active +identity: + 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" + vendor: "AgentScope 团队（阿里巴巴通义实验室）" + vendor_type: "vendor" + region: "中国" + first_seen: "2026-02-24" + name_history: # ⚠️ 2026-04-12 改名，检索 4 月前的资料必须按 CoPaw + - "CoPaw（2026-02-24 建仓）" + - "QwenPaw（2026-04-12 更名）" + name_note: |- + 更名官方理由是"更深融入 Qwen 开源生态、更聚焦模型层"，原名 CoPaw 的仓库 + `agentscope-ai/CoPaw` 与现名仓库指向同一项目。 + 另注意到 GitHub 上存在同名仓库 `aqua88hn/qwenpaw`（README 内容与官方高度相似）， + **检索时容易认错本体**——本档案锁定的是 agentscope-ai 组织下的官方仓库。 +business: + + positioning: |- + 与 OpenClaw 同处「个人助理执行层」，是本项目在本体系中唯一的正面对手。 + 但立足点不同：OpenClaw 靠**渠道覆盖与生态规模**取胜，QwenPaw 靠**安全默认值与 + 本地可跑**取胜。它把自己定位成"能长期记住你、数据不离开你机器的私人助理"， + 而不是功能最全的助理。 + 团队背景决定了差异化：背靠 AgentScope（AgentScope / AgentScope Runtime / ReMe）， + 记忆系统直接建在 ReMe 个人知识框架上。 + target_users: + - 对数据主权与隐私有硬要求、希望助理完全跑在本地的个人用户 + - 需要在钉钉 / 飞书 / 微信 / QQ 等国内渠道里用助理的团队 + - 想不买 API key 就先跑起来的尝鲜用户（QwenPaw-Flash 本地模型） + - 愿意用功能广度换安全确定性的自用开发者 + monetization: |- + Apache-2.0 全开源，未见收费层；提供 Docker / 阿里云 ECS / AgentScope 平台 / + ModelScope 创空间等多条部署路径（云部署路径隐含云厂商导流）。 + 与 OpenClaw 一样**没有明示的变现路径**。 + license: + spdx: "Apache-2.0" + name: "Apache License 2.0" + openness: L1 + redistributable: true + key_restrictions: + - Apache-2.0 含明确的专利授权条款（对使用者是加分项） + - 需保留 NOTICE 文件与版权声明 + - 商标条款：不授予 Qwen / 通义等商标使用许可 + moat: |- + 三层：① 五层安全体系（沙箱 / Tool Guard / File Guard / Skill Scanner / Access Policy） + 全部默认开启，这是同类里最完整的；② 无需 API key 即可跑的自研 QwenPaw-Flash + 模型系列（2B/4B/9B，Q4/Q8 量化），把"先跑起来"的门槛降到零； + ③ 覆盖国内七大渠道（钉钉 / 飞书 / 微信 / QQ / Discord / Telegram / iMessage）。 + competitive_risk: |- + 两面受敌：向上被 OpenClaw 的生态规模压制（388k vs 34.7k star，差一个数量级）， + 向下被任何一家有本地模型的助理框架追赶（安全是可以被快速抄的）。 + 真正的护城河可能是**渠道**——钉钉 / 飞书 / 微信的对接是海外项目做不了的。 + +scenario: + + primary: + - 常驻本地的私人助理，通过钉钉 / 飞书 / 微信 / QQ 等 IM 渠道随时触达 + - 本地文档与知识库：读 PDF / Office 提取信息进长期记忆，随时从 IM 调取 + - 定时任务自动化：每日资讯摘要推送、邮件与日历整理、周报生成 + - Coding Mode：三栏 Web IDE（文件树 / diff 预览 / 结构化代码搜索） + typical_use_cases: + - 每天自动抓小红书 / 知乎 / Reddit 热点生成摘要推到飞书 + - 睡前描述目标，助理自动执行，醒来拿到原型 + - 多个独立 agent 各自分角色（创意 / 写作 / 校对）协同产出内容 + - 用本地 9B 模型处理敏感文档，全程不出本机、不花 API 费用 + industries: + - 个人事务 / 知识管理 + - 内容创作与自媒体 + - 小团队办公自动化 + interaction_mode: + - Web 控制台（默认 127.0.0.1:8088） + - Terminal UI（TUI） + - IM 渠道（钉钉 / 飞书 / 微信 / QQ / Discord / Telegram / iMessage） + - 桌面应用（Beta） + human_in_the_loop: |- + Access Policy 是声明式访问规则，可对每次能力调用设置 放行 / 拒绝 / 请求人工批准， + 粒度到工具级、可按来源匹配。Tool Guard 提供 STRICT / SMART / AUTO / OFF 四档。 + deliverables: + - code（Coding Mode 三栏 IDE） + - 文档处理结果（PDF / Word / Excel / PowerPoint） + - 记忆条目（可读可编辑可搜索的 Markdown 记忆） + - 定时推送内容（资讯摘要 / 视频脚本） + +tech: + + form_factor: |- + Python 包（pip / 安装脚本）+ Web 控制台 + TUI + 桌面应用（Beta）+ Docker。 + 形态偏"服务端 + 多渠道"，与 OpenClaw 的"本地守护进程 Gateway"思路接近， + 但更传统——没有 OpenClaw 那套原生伴侣 App 与设备节点。 + stack: + - Python 59% + - TypeScript 37.2% + - Less 1.5% + - Rust 1.0% + - JavaScript / CSS 各约 0.3% + engine_abstraction: + supported: [] # 不代理外部 agent 引擎 + mechanism: |- + 与 OpenClaw 相同：**自身即引擎**，不接入第三方 agent。 + 但它能"派生子 agent"——多 agent 协同时各子体带独立记忆并行处理， + 这是 OpenClaw 2.0 之前没有的内生能力。 + 模型层不绑定：14+ 云厂商（OpenAI / Anthropic / DeepSeek / Kimi 等） + 与本地后端（内置 llama.cpp / Ollama / LM Studio）可混用。 + abstraction_layer: "无（自身即引擎）；模型层有统一 provider 抽象" + depth_notes: |- + 注意区分两个"中立"：模型层是真中立（14+ provider 可换）， + agent 引擎层不存在中立问题（它自己就是）。横向比较时不要混为一谈。 + extension_system: + skills: "Skills 文件系统；自定义 skill 自动加载，明确宣称 no lock-in" + plugins: "Skill Scanner 在激活前扫描第三方 skill（阻断 / 警告 / 关闭 + 白名单）" + mcp: "README 标注 mcp 主题（topics 含 mcp），支持浏览器工具抓取接口文档" + model_binding: |- + 不绑定。本地侧主推自研 QwenPaw-Flash（2B / 4B / 9B，Q4 / Q8 量化， + ModelScope 与 Hugging Face 可下载），云侧 14+ provider。 + **"无需 API key 即可跑"是它相对所有竞品的硬差异。** + local_first: true + multi_agent: |- + 可创建多个独立 agent、各自分角色，开启协作 skill 后 agent 间可互相通信； + 助理能派生带独立记忆的子 agent 并行处理任务。 + permission_sandbox: |- + ⚠️ 这是 QwenPaw 最强的维度，也是与 OpenClaw 分道扬镳之处——**默认开启**： + ① Sandbox：内核级隔离，macOS 用 Seatbelt、Linux 用 Bubblewrap / Landlock、 + Windows 用 AppContainer，shell 命令跑在受限文件系统视图里； + ② Tool Guard：YAML 规则引擎 + ShellEvasionGuardian，执行前检查每次工具调用， + 识别命令注入、路径穿越、反弹 shell、混淆攻击； + ③ File Guard：独立于 Tool Guard，默认保护 ~/.qwenpaw.secret/、~/.ssh 等敏感路径； + ④ Skill Scanner：第三方 skill 激活前扫描提示词注入、硬编码密钥、数据外泄； + ⑤ Access Policy：声明式规则，工具级粒度的放行 / 拒绝 / 人工批准。 + 但注意：Tool Guard 提供 **OFF 档**，可以整层关掉。 + observability: |- + 滚动式上下文管理 + 持久化轮次存储；三层记忆（当前会话工作上下文 / + 可搜索的完整对话历史 / 自进化的 Markdown 个人知识库）本身即构成了可审计轨迹。 + +ecosystem: + metrics: + stars: 34758 + forks: 3052 + open_issues: 898 + subscribers: 109 + created_at: 2026-02-24 + pushed_at: 2026-09-01 + size_kb: 112038 + languages: {Python: 59.0, TypeScript: 37.2, Less: 1.5, Rust: 1.0, JavaScript: 0.3, CSS: 0.3} + latest_release: v2.2.0-beta.5 + release_cadence: 约 1 天/版本 + data_date: 2026-09-01 + stale: false + community: |- + 34.7k star、3k fork，活跃度高（约 1 天一个 beta）。 + **巴士系数是七个样本里最健康的**：最近 100 次提交去重 24 位作者， + TOP1（yutai78786）仅占 15%，前八名分布在 15%–5% 之间，没有单点依赖。 + 对比同样在"个人助理"赛道的 OpenClaw（TOP1 独占 64%），差距显著。 + standards: [] + notable_events: + - "2026-02-24：以 CoPaw 之名建仓" + - "2026-04-12：正式更名 QwenPaw，官方称将更深融入 Qwen 开源生态" + - "2026-08-31：v2.2.0-beta.5（至今所有 release 均为 prerelease）" + +risk: + license_risk: |- + Apache-2.0，无实质风险，且含专利授权条款（对企业用户是加分）。 + 需注意保留 NOTICE 与版权声明，以及商标不授权。 + vendor_lockin: |- + 模型层无锁定（14+ provider + 本地后端）。隐性锁定在两处： + ① 记忆系统建在 ReMe 框架上，沉淀的个人知识库不易整体迁出； + ② 云部署路径与阿里云 ECS / ModelScope 绑定，国内合规场景下迁移成本上升。 + claim_vs_reality: + - claim: "数据归你、本地优先、不上传任何本地使用记录" + actual: |- + 主力诉求成立（本地模型可完全离线跑，遥测一键可关）。 + 但 README 的 Telemetry 章节写明：**`qwenpaw init --defaults` 会自动接受遥测**， + 且"每升级一个版本会重新收集一次"。而 `--defaults` 恰恰是快速上手文档 + 推荐的默认路径。收集的是匿名环境数据、不影响功能，但"默认接受" + 与"数据归你"的叙事存在张力——尤其对把隐私当核心卖点的产品。 + source: "README Telemetry 章节原文（'If you choose --defaults, telemetry is accepted automatically.'）" + - claim: "34.7k star 的成熟个人助理" + actual: |- + 星标属实，但**至今没有任何正式 release**。查最近 8 个 release， + v2.1.1-beta.1 到 v2.2.0-beta.5 全部 prerelease=True。 + 也就是说它处在"高关注度 + 持续 beta"状态，与同赛道 OpenClaw + （有 v2026.8.1 正式版）相比，发布纪律反而更松。 + source: "GitHub releases API（per_page=8，全部返回 prerelease=true）" + - claim: "五层安全，内核级沙箱" + actual: |- + 五层的实现描述相当具体（Seatbelt / Bubblewrap+Landlock / AppContainer， + ShellEvasionGuardian 检测命令注入与反弹 shell），可信度高。 + 但 **Tool Guard 提供 OFF 档**，整层可以关掉；Access Policy 也是"可配置为放行"。 + 安全强度取决于用户配置，不是不可绕过的硬边界。 + source: "README Security Features 章节（列出 Tool Guard 的 STRICT / SMART / AUTO / OFF 四档）" + - claim: "无需 API key，本地模型即可跑" + actual: |- + 技术上成立：QwenPaw-Flash 2B / 4B / 9B（Q4 / Q8 量化）内置 llama.cpp 后端， + 在 Web UI 点下载即可用，并提供硬件感知推荐。 + 但要清醒：**2B / 4B 量级的模型在复杂 agent 任务上的能力天花板很低**， + "无需 key 跑起来"和"无需 key 好用"是两件事，重度任务仍要接云端 provider。 + source: "README Local Models 章节（列出 2B/4B/9B 与 Q4/Q8 量化）" + - claim: "（历史）QwenPaw 是一个 2026 年 4 月后出现的全新项目" + actual: |- + 不是。它是 2026-02-24 以 **CoPaw** 之名建仓的项目，2026-04-12 才更名。 + 检索 2026 年 4 月之前的社区讨论、issue 与技术文章时必须按 CoPaw 检索， + 否则会严重低估它的历史沉淀与已知问题。 + source: "GitHub repo API（created_at=2026-02-24）+ README News 章节的更名公告" + - claim: "（检索风险）github.com/agentscope-ai/QwenPaw 是唯一官方仓库" + actual: |- + 存在同名仓库 `aqua88hn/qwenpaw`，README 内容与官方高度相似。 + 以 star 数（官方 34.7k）与组织归属判断，官方仓库在 agentscope-ai 组织下； + 但同名仓库的存在会让"按名字搜仓库"直接得到错误结果。 + source: "GitHub 搜索结果与 repo API 交叉核对（agentscope-ai/QwenPaw = 34758 star，非 fork）" + maturity: |- + 工程治理（巴士系数最健康、安全分层最完整）明显强于它的星标邻居们， + 但**发布纪律是短板**——所有 release 都是 beta，且一天能发多个 beta。 + 功能面广、迭代快，适合自用与尝鲜；不适合作为团队关键链路的基础设施。 + maturity_level: "beta 活跃期" + +chart: + # 与 OpenClaw 同为"个人助理"，但安全默认值与本地能力都更强，形态更传统。 + form_depth: 5 # Web 控制台 + TUI + 桌面 beta，形态传统，无原生设备节点 + engine_neutral: 2 # 自身即引擎（不代理外部 agent），但模型层 14+ provider 真中立 + local_first_score: 9 # 内置 llama.cpp + 自研 Flash 模型，无需 API key 即可跑 + deliverable_depth: 4 # Coding Mode 三栏 IDE + 文档处理 + 定时推送，但非可编辑交付物体系 + chart_note: "与 OpenClaw 同赛道对照看：形态略浅、本地优先更强、安全默认值显著更高" +verdict: + one_liner: |- + 七个样本里安全默认值最完整、巴士系数最健康的个人助理—— + 但至今没有发过一个正式版，且 `--defaults` 安装路径会默认打开遥测。 + who_should_use: |- + 把数据与隐私放第一位、希望助理完全跑在本地的个人与小团队； + 需要在钉钉 / 飞书 / 微信 / QQ 渠道里用助理的国内团队； + 想不买 API key 先把流程跑通的尝鲜者。 + who_should_not: |- + 需要正式版与稳定升级路径的团队（它全是 beta）； + 指望 2B / 4B 本地模型扛复杂 agent 任务的人； + 把"五层安全"当成不可绕过硬边界的人（Tool Guard 有 OFF 档）。 +mirror: + gitea_repo: gitinbox/qwenpaw + visibility: public + upstream: "https://github.com/agentscope-ai/QwenPaw" + last_sync: 2026-09-01 + mode: source-only + sync_note: |- + 109 MB，理论可行（约 36 分钟拉完），但超过 Gitea 50 MB 推送上限， + 需走 mirror_sync.sh 的 source-only 快照降级。尚未执行，待带宽窗口。 +article: + emlog_id: 0 # emlog 文章 ID，发布后回写 + published_at: "" + url: "" diff --git a/data/projects/tutti.yaml b/data/projects/tutti.yaml new file mode 100644 index 0000000..1a9bdbe --- /dev/null +++ b/data/projects/tutti.yaml @@ -0,0 +1,302 @@ +# tutti · 项目档案 +# 生成于 2026-09-01 · 由 scripts/new_project.py 从 schema 生成 +# 人工补完重点：business / scenario / tech / risk.claim_vs_reality / verdict +# 字段规范见 schema/project.schema.yaml +# +# ⚠️ 本档案的技术维度基于**本地源码实测**（/Users/figmarlite/.../tutti_repo， +# Apache-2.0 浅克隆 8291 文件），不是从 README 转述。所有行数均为 wc -l 实测。 + +id: tutti +name: "Tutti" +repo: "tutti-os/tutti" +homepage: "https://tutti.sh/" +added_at: "2026-09-01" +status: active +identity: + tagline: "Where people and agents build in tune." + vendor: "Nexight（tutti.sh）" + vendor_type: "vendor" + region: "未公开（NOTICE 声明 'developed at Nexight'）" + first_seen: "2026-06-12" + name_note: |- + 本体系里**最年轻的样本**（建仓至今 2.5 个月），也是 star 最少的（3.6k）， + 但工程规范度排在前列——见下方 risk 与 tech 的实测数据。 +business: + + positioning: |- + 站在「多人 × 多 Agent 的实时协作空间层」，是七个样本里**唯一把"多人"写进定位的**。 + 它不造引擎、不卖模型，做的是"让你已有的 agent 订阅在同一个工作区里协同"： + Claude 写了一半的活儿交给 Codex 接着干，中间不用重新讲一遍背景。 + 但它的商业模式是清晰的 open-core：**开源版只给"单人 + 多 Agent"， + "多人 + 多设备 + 云同步"全在闭源的 Tutti · VM 侧**（Early Access，需邀请码）。 + target_users: + - 同时用多个 agent 订阅（Claude Code + Codex + Hermes）的重度开发者 + - 需要 agent 之间共享上下文、接力同一件事的小团队 + - 想让 agent 产出不止代码（设计稿 / 文档 / PPT）的人 + - 需要多人 × 多 Agent 同屏协作的团队（但这类需求会被引流到闭源 VM 版） + monetization: |- + **Open-core 双轨**：开源版（Apache-2.0）免费且自托管；Tutti · VM 为 Early Access + 商业版，需邀请码创建 Cloud Room。Tutti 内置 Agent 在 Early Access 期免费， + README 明示"后续可能按用量计费"。 + 这是七个样本里**变现路径最清晰的一个**。 + license: + spdx: "Apache-2.0" + name: "Apache License 2.0" + openness: L1 + redistributable: true + key_restrictions: + - 需保留 NOTICE 文件——且本项目的 NOTICE 内容相当长（见 tech 备注） + - 商标条款：不授予 Tutti / Nexight 商标使用许可 + - ⚠️ NOTICE 中有一处 **CC-BY-4.0**（VS Code Codicons 的 inspect 图标）， + 这是比 Apache-2.0 更严格的署名要求，再分发时必须保留署名 + moat: |- + ① 双层引擎接入架构（ACP 协议层 + runtimeprep 运行时准备层），把"接引擎" + 拆成了协议适配与运行时准备两件事，这是其余样本没有做的分层； + ② Workbench 节点模型 + 内置 Apps（AI Canvas / UI 原型 / Docs / AI PPT / 群聊）； + ③ 多 Agent 实时文件协同编辑（daemon 负责落盘与冲突投影）。 + 真正的壁垒在**多人协同的工程实现**（Cloud Room + DeviceLink 的 ICE/QUIC）， + 而这部分恰好不在开源侧。 + competitive_risk: |- + 最容易被 Anthropic / OpenAI 官方的协作能力吃掉——Tutti 不拥有任何引擎与模型。 + 更直接的威胁：它宣传的"agent 之间共享上下文"能力，各家引擎自己在做 + （Claude Code 的 subagent、Codex 的 session resume），Tutti 的跨引擎优势 + 会随着引擎自身变强而稀释。 + +scenario: + + primary: + - 同一 workspace 里并行驱动多个 agent，共享文件与上下文 + - agent 之间接力：Codex 接着 Claude 写了一半的活儿继续，无需重述背景 + - 用 Big @ 跨 agent / 跨会话引用产出与上下文，用 + 快速引用文件 + - 多 agent 实时协同编辑同一批文件，daemon 负责落盘与冲突投影 + - 通过内置 Apps 让 agent 直接产出设计稿 / 文档 / PPT（不只是代码） + - 【闭源 VM 版】多人同屏、跨设备、借用他人 agent、免部署分享 + typical_use_cases: + - Claude 写完 PRD，让 agent 调设计 App 直接出视觉稿 + - 描述一个目标，Tutti 拆成子任务后分派给最合适的 agent + - 用已有订阅额度驱动 Tutti 里的所有内置 App，不额外付费 + - 【VM】本地跑的 localhost 站点直接在 Room 里给别人预览，不用部署 + industries: + - 软件研发 + - 产品与设计协作 + - 内容生产 + interaction_mode: + - 桌面应用（Electron） + - TUI / CLI（Go） + - Workbench 节点（Browser / Terminal / App Center） + - 【闭源 VM】Cloud Room 多人多设备 + human_in_the_loop: |- + Agent Board 可视化所有 agent 的任务与状态，统一调度；goal review / plan feedback + （Tutti Mode 执行）。活动复制与状态探针（agentstatus + account-usage）提供过程可见性。 + deliverables: + - code + - 设计稿（AI Canvas / UI-UX 原型） + - 文档 / PPT（Docs / AI PPT 内置 App） + - 会话回放（session-replay） + +tech: + + form_factor: |- + pnpm + Go Workspace 混合 monorepo；桌面端 Electron；守护进程 tuttid（Go）； + CLI（Go）；Agent 运行时基于 **ACP（Agent Client Protocol）** + uv / npm / pnpm + 托管运行时。语言构成 TypeScript 48.8% / Go 45.4% —— **后端用 Go 而不是 Node， + 这是它和其余 Electron 系样本的关键差异**（守护进程的稳定性与并发模型更好）。 + stack: + - TypeScript 48.8% + - Go 45.4%（守护进程 tuttid + CLI） + - JavaScript 4.2% + - CSS 0.9% + - Kotlin 0.3%（Android） + - Shell 0.1% + engine_abstraction: + supported: + - Codex（接入最深） + - Claude Code + - Cursor + - OpenCode + - Kimi Code + - Hermes + - OpenClaw（in development） + - Computer Use + - Browser Use + - Tutti 内置 Agent + mechanism: |- + **双层架构**，这是 Tutti 在引擎接入上最值得记的一笔： + 第 1 层 `packages/agent/daemon/runtime/acp_provider_*.go` —— ACP 协议适配 + 第 2 层 `packages/agent/runtimeprep/` —— 运行时准备（配置注入、skill 装配、 + Windows 兼容、模型缓存、目录同步） + 全仓有 363 个文件引用 ACP，**是真集成，不是营销词**。 + abstraction_layer: "ACP（Agent Client Protocol）+ runtimeprep 准备层" + depth_notes: |- + ⚠️ **接入深度极不对等，实测数据如下**（packages/agent/runtimeprep/，非测试行数）： + Codex 16 文件 2170 行 ← 一国独大 + Tutti 内置 2 文件 653 行 + Cursor 2 文件 446 行 + Claude 3 文件 410 行 + OpenCode 2 文件 392 行 + Kimi 1 文件 127 行 + ComputerUse 1 文件 43 行 + BrowserUse 1 文件 43 行 + **Codex 是 Kimi 的 17 倍。** 且只有 Codex 有 Windows 变体文件 + （codex_directory_windows.go 149 行、codex_file_windows.go、 + codex_models_cache_windows.go 等 4 个），其余引擎一个 Windows 变体都没有 + ——说明**只有 Codex 在 Windows 上被真正验证过**。 + + 更有意思的是**测试密度与实现规模成反比**： + OpenCode 392 行实现 / 218 行测试 = 0.56（密度最高） + Cursor 446 / 187 = 0.42 + Tutti 内置 653 / 274 = 0.42 + Claude 410 / 136 = 0.33 + Codex 2170 / 261 = **0.12（投入最大，保障最薄）** + Kimi 127 / 0 = 0.00 + ComputerUse / BrowserUse 43 / 0 = 0.00 + 即：**投入最重的 Codex 恰恰是质量保障最薄弱的地方**，因为它的边界情况最多 + （Windows 兼容、模型缓存、配置依赖、skill roots、用户指令），测试却没跟上。 + 另有 19 个通用测试文件共 7851 行（preparer_test.go 单文件 2906 行） + 覆盖跨引擎路径，部分弥补了单引擎测试的缺失。 + extension_system: + skills: "provider_skill.go（655 行）+ stable_skill_bundle.go（308 行）+ codex_skill_roots.go；支持 personal skill" + plugins: "extension_runtime.go（735 行）：为 Hermes 提供 RTK Python 插件机制（命令重写）" + mcp: "codex_mcp.go（65 行）—— 注意：MCP 实现挂在 Codex 名下，不是通用层" + model_binding: |- + 不绑定模型，但**绑定 agent 订阅**：README 明确"用你已有的 Claude / Codex / + 其他订阅"。没有订阅的用户可用 Tutti 内置 Agent（Early Access 期免费）。 + local_first: true + multi_agent: |- + Agent Board 统一调度 + Big @ 跨 agent 引用 + 多 agent 实时文件协同编辑 + （daemon 落盘与冲突投影）+ 工作流与自动化规则 + Issue/Task/Run 工作流。 + 会话回放（session-replay）与活动复制（activity-replication）是它的特色。 + permission_sandbox: |- + tutti_cli_policy.go（140 行）提供 CLI 策略控制；workspace 级权限与 provision 流程。 + 相较 QwenPaw（内核级沙箱默认开）与 OpenClaw（沙箱默认关）， + Tutti 的开源侧没有看到同等强度的执行隔离——它的安全边界更多落在 + workspace 与 daemon 层，而非内核沙箱。 + observability: |- + 这是 Tutti 的强项：Agent Board 看板 + 状态探针（agentstatus + account-usage）+ + 会话回放 + 活动复制 + goal review / plan feedback。执行过程可追溯性 + 在七个样本里仅次于 Maka。 + +ecosystem: + metrics: + stars: 3660 + forks: 371 + open_issues: 185 + subscribers: 115 + created_at: 2026-06-12 + pushed_at: 2026-09-01 + size_kb: 248635 + languages: {TypeScript: 48.8, Go: 45.4, JavaScript: 4.2, CSS: 0.9, Kotlin: 0.3, Shell: 0.1} + latest_release: stable + release_cadence: 约 3 天/版本 + data_date: 2026-09-01 + stale: false + community: |- + 3.6k star、371 fork、185 issue，规模是七个里最小的，但**发布纪律是七个里最好的**： + 最近 8 个 release 全部 prerelease=False（v0.2.25 → v0.2.31，约 3 天一版）。 + 另维护一个名为 `stable` 的**滚动 tag**（始终指向最新稳定版，会随发版移动）—— + 方便用户固定引用，代价是该 tag 的历史不可追溯。 + 对比：OpenClaw 版本号倒挂（9.1-beta 早于 8.1 正式）、QwenPaw 全是 beta， + star 数最少的 Tutti 反而是唯一持续发正式版的。 + standards: + - "ACP（Agent Client Protocol）——363 个文件引用，深度采纳" + notable_events: + - "2026-06-12：建仓" + - "2026-07-23：docs/specs/2026-07-23-hermes-agent-extension-acceptance.md（Hermes 以扩展方式接入的验收规格）" + - "2026-09-01：v0.2.31 与滚动 tag stable 同日发布" + +risk: + license_risk: |- + Apache-2.0 本身无风险，但**NOTICE 必须完整保留**：它记录了 5 处第三方代码， + 且其中 VS Code Codicons 的 inspect 图标用的是 **CC-BY-4.0**（署名要求 + 比 Apache-2.0 更严），再分发时漏掉署名即构成侵权。 + vendor_lockin: |- + **锁定在"协作"而非"代码"**：开源版能跑，但 Group chat / 多人协作 / + 同时编辑 / 跨设备 / agent 借用 / 免部署分享这六项功能全在闭源 VM 侧， + 且创建 Room 需要邀请码（waitlist）。一旦团队依赖上协作能力，就上了商业版的船。 + 这是七个样本里 open-core 切分最干脆的一个。 + claim_vs_reality: + - claim: "（README）Currently Claude Code, Codex, and Hermes；OpenClaw is in development" + actual: |- + **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 的支持列表更像"营销优先级排序"，不是代码覆盖的如实反映。 + source: "本地源码实测：runtimeprep 目录文件清单 + daemon/runtime/acp_provider_*.go 行数 + grep hermes 引用" + - claim: "多引擎中立" + actual: |- + 协议层中立（都走 ACP），**深度层远不中立**。Codex 2170 行 vs Kimi 127 行， + 17 倍差距；只有 Codex 有 Windows 变体，其余引擎在 Windows 上未验证。 + 而且测试密度反常：Codex 0.12（最低）vs OpenCode 0.56（最高）， + Kimi / ComputerUse / BrowserUse 测试为零。 + 所谓"中立"是**接入方式的中立**，不是**投入与保障的中立**。 + source: "本地源码 wc -l 实测（实现文件与测试文件分别统计）" + - claim: "Where people and agents build in tune（多人 × 多 Agent）" + actual: |- + 开源版里只有 "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 版。 + source: "README 'Two Versions of Tutti' 与 'Tutti vs Tutti · VM' 两张对照表原文" + - claim: "Apache-2.0 开源" + actual: |- + 许可证属实且 NOTICE 写得极其规范（5 处第三方代码全部精确到文件路径、 + 上游 revision hash 与适配说明，是七个样本里 NOTICE 质量最高的）。 + 但"开源"不等于"功能完整"——结合上一条，开源版的功能完整度约一半， + 核心价值（协作）在闭源侧。Apache-2.0 保证了你能自由改代码， + 不保证你能用到它宣传的完整体验。 + source: "本地源码 NOTICE 全文 + README 版本对照表" + - claim: "（隐含）体量小 = 成熟度低" + actual: |- + 反例。它是七个样本里 star 最少（3.6k）、建仓最晚（2026-06-12）的， + 但**发布纪律最好**：8 个 release 全是正式版，且维护 `stable` 滚动 tag。 + 工程规范度（NOTICE 精度、测试投入 7851 行通用测试、Go 守护进程） + 明显超过 star 数比它高一个数量级的 OpenClaw 与 QwenPaw。 + **star 数与工程成熟度在本体系的七个样本里呈负相关。** + source: "GitHub releases API + 本地源码 NOTICE 与测试文件实测" + maturity: |- + 建仓仅 2.5 个月，处在快速成长期。发布纪律是七个样本里最好的（全部正式版 + + stable 滚动 tag），工程规范度高（NOTICE 精确到 revision hash、通用测试 7851 行、 + Go 守护进程），但引擎接入深度严重向 Codex 倾斜、开源版功能完整度约一半。 + 适合自用与"多 agent 接力"场景，不适合指望开源版承担团队协同。 + maturity_level: "快速成长期" + +chart: + form_depth: 8 # Electron + Workbench 节点 + 内置 Apps，形态最完整之一 + engine_neutral: 8 # ACP 协议层真统一（363 文件），但深度极不对等（见 depth_notes） + local_first_score: 7 # 开源版本地跑，但协作能力全在云端 VM 侧 + deliverable_depth: 7 # 内置 Apps 出设计稿 / 文档 / PPT，不止代码 + chart_note: "引擎中立项给的是协议层统一；若按投入对等度重评，该项应下调至 4 左右" +verdict: + one_liner: |- + 把「多 agent 共享上下文、接力干活」做成了产品，且是七个里发布纪律最好的—— + 但接入深度严重偏袒 Codex（17 倍差距），而宣传的「多人协作」全在闭源 VM 版。 + who_should_use: |- + 手里已有多个 agent 订阅、想让它们在同一工作区里接力与共享上下文的开发者； + 想让 agent 产出设计稿 / 文档 / PPT 而不只是代码的人； + 看重发布纪律与工程规范（NOTICE 精度、正式版节奏）的人。 + who_should_not: |- + 指望开源版做团队多人协作的人（那七项功能全在闭源 VM 侧，且需邀请码）； + 主要用 Kimi / ComputerUse / BrowserUse 的人（这三个接入最薄、测试为零）； + Windows 用户且主力引擎不是 Codex 的人（只有 Codex 做了 Windows 适配）。 +mirror: + gitea_repo: "gitinbox/tutti" + visibility: public + upstream: "https://github.com/tutti-os/tutti" + last_sync: "" + mode: "pending" + sync_note: |- + 243 MB。本地已有浅克隆（/Users/figmarlite/.../tutti_repo，8291 文件）， + 技术维度分析即基于此，可直接复用做快照，无需重新下载。 + 仍需 unshallow 补全历史后走 source-only 降级（超 Gitea 50 MB 上限）。尚未执行。 +article: + emlog_id: 0 # emlog 文章 ID，发布后回写 + published_at: "" + url: "" diff --git a/data/registry.yaml b/data/registry.yaml index 6f8a03f..6f34e9a 100644 --- a/data/registry.yaml +++ b/data/registry.yaml @@ -27,3 +27,24 @@ projects: added_at: 2026-09-01 license_level: L1 mirror_visibility: public + - id: openclaw + repo: openclaw/openclaw + status: active + added_at: 2026-09-01 + license_level: L1 # ⚠️ 自动判定 L3（SPDX=NOASSERTION），人工复核推翻 + mirror_visibility: public # LICENSE 原文是完整 MIT，NOASSERTION 系末端第三方声明段致检测器误判 + mirror_mode: link-only # 体积 3276 MB：超带宽(50KB/s→19h)与 Gitea 推送上限(50MB)两个数量级，不镜像 + - id: qwenpaw + repo: agentscope-ai/QwenPaw + status: active + added_at: 2026-09-01 + license_level: L1 + mirror_visibility: public + mirror_mode: pending # 109 MB，超 50 MB 推送上限，需 source-only 快照降级 + - id: tutti + repo: tutti-os/tutti + status: active + added_at: 2026-09-01 + license_level: L1 + mirror_visibility: public + mirror_mode: pending # 243 MB，本地已有浅克隆可复用，仍需 unshallow + source-only 降级 diff --git a/data/snapshots/openclaw.jsonl b/data/snapshots/openclaw.jsonl new file mode 100644 index 0000000..dbff946 --- /dev/null +++ b/data/snapshots/openclaw.jsonl @@ -0,0 +1 @@ +{"stars": 388438, "forks": 81543, "open_issues": 5925, "subscribers": 1754, "created_at": "2025-11-24", "pushed_at": "2026-09-01", "size_kb": 3354345, "languages": {"TypeScript": 91.0, "Swift": 4.6, "Kotlin": 1.8, "JavaScript": 1.0, "Shell": 0.6, "CSS": 0.4}, "latest_release": "v2026.8.1", "release_cadence": "约 4 天/版本", "data_date": "2026-09-01", "stale": false} diff --git a/data/snapshots/qwenpaw.jsonl b/data/snapshots/qwenpaw.jsonl new file mode 100644 index 0000000..c0c2a92 --- /dev/null +++ b/data/snapshots/qwenpaw.jsonl @@ -0,0 +1 @@ +{"stars": 34758, "forks": 3052, "open_issues": 898, "subscribers": 109, "created_at": "2026-02-24", "pushed_at": "2026-09-01", "size_kb": 112038, "languages": {"Python": 59.0, "TypeScript": 37.2, "Less": 1.5, "Rust": 1.0, "JavaScript": 0.3, "CSS": 0.3}, "latest_release": "v2.2.0-beta.5", "release_cadence": "约 1 天/版本", "data_date": "2026-09-01", "stale": false} diff --git a/data/snapshots/tutti.jsonl b/data/snapshots/tutti.jsonl new file mode 100644 index 0000000..160eb7e --- /dev/null +++ b/data/snapshots/tutti.jsonl @@ -0,0 +1 @@ +{"stars": 3660, "forks": 371, "open_issues": 185, "subscribers": 115, "created_at": "2026-06-12", "pushed_at": "2026-09-01", "size_kb": 248635, "languages": {"TypeScript": 48.8, "Go": 45.4, "JavaScript": 4.2, "CSS": 0.9, "Kotlin": 0.3, "Shell": 0.1}, "latest_release": "stable", "release_cadence": "约 3 天/版本", "data_date": "2026-09-01", "stale": false} diff --git a/scripts/build_matrix.py b/scripts/build_matrix.py index 08934b7..2358101 100755 --- a/scripts/build_matrix.py +++ b/scripts/build_matrix.py @@ -19,6 +19,7 @@ from __future__ import annotations import argparse +import math import re import sys from pathlib import Path @@ -27,6 +28,7 @@ sys.path.insert(0, str(Path(__file__).resolve().parent)) from _common import ARTICLES, PROJECTS, load_yaml # noqa: E402 QUAD_THRESHOLD = 4 +SPREAD = 11 # 重合点沿小圆散开的半径（px），需大于点的直径(14)的一半才看得出分离 BEGIN, END = "", "" IDX_BEGIN, IDX_END = "", "" OVERVIEW_AID = "00-overview" @@ -185,6 +187,12 @@ def collect_cross_articles() -> list[dict]: "url": d.get("url") or f"https://blog.apescale.com/?post={d['emlog_id']}", "last_published": d.get("last_published", ""), }) + # 按 emlog_id 升序排 = 按发布先后排 = 阅读顺序。 + # 这一步不能省：靠文件名 sorted() 排是碰运气——"00-comparison-2.meta.yaml" + # 恰好排在 "00-comparison.meta.yaml" 前面只是因为 '-'(0x2D) < '.'(0x2E)， + # 换个命名（如 10-comparison）顺序就反了。系列文章要按发出来的先后读， + # 不能让 ASCII 码表来决定。 + out.sort(key=lambda a: a["emlog_id"]) return out @@ -295,17 +303,43 @@ def quadrant_svg(items: list[dict]) -> str: svg.append(f'{xhi}') svg.append(f'{ylo}') svg.append(f'{yhi}') - # 点 + # ---- 重合点处理 ---- + # 样本一多，必然出现坐标完全相同的项目。本体系加到第 7 个样本时首次撞上： + # 视图 A 里 Maka 与 OpenClaw 都是 (6,1)，视图 B 里 iPolloWork 与 Tutti 都是 (7,7)。 + # 完全重合的点会被后画的那个整个盖住——读者会以为少收录了一个项目， + # 这种"静默丢信息"比图难看严重得多，所以必须在这里兜住。 + # 做法：把重合组沿一个小圆均匀散开，并在图下加一行说明交代清楚。 + pts = [] for d in items: c = d.get("chart") or {} xv, yv = c.get(xk), c.get(yk) if xv is None or yv is None: continue - cx = px + pw * max(0, min(10, float(xv))) / 10 - cy = py + ph * (1 - max(0, min(10, float(yv))) / 10) + pts.append({"d": d, "xv": float(xv), "yv": float(yv)}) + groups: dict[tuple, list] = {} + for p in pts: + groups.setdefault((p["xv"], p["yv"]), []).append(p) + overlapped = [g for g in groups.values() if len(g) > 1] + for g in overlapped: + n = len(g) + for i, p in enumerate(g): + ang = 2 * math.pi * i / n + p["dx"] = SPREAD * math.cos(ang) + p["dy"] = SPREAD * math.sin(ang) + + # 点 + for p in pts: + d = p["d"] + cx = px + pw * max(0, min(10, p["xv"])) / 10 + p.get("dx", 0.0) + cy = py + ph * (1 - max(0, min(10, p["yv"])) / 10) + p.get("dy", 0.0) + # 散开后别顶出绘图区 + cx = max(px + 4, min(px + pw - 4, cx)) + cy = max(py + 4, min(py + ph - 4, cy)) name = d.get("name", "") + # 重合组用更高的不透明度，让读者一眼看出"这里挤了不止一个" + op = "0.9" if len(groups[(p["xv"], p["yv"])]) > 1 else "0.75" svg.append(f'') + f'fill-opacity="{op}" stroke="#fff" stroke-width="1.5"/>') # 标签默认画在点右侧，但满分点会顶到绘图区右边界（cx == px+pw）， # 文字就会溢出画布被裁掉。靠右时翻到点的左侧。 # 估算文字宽度：中文按 12px、其余按 7px，够用且不依赖字体度量。 @@ -316,6 +350,12 @@ def quadrant_svg(items: list[dict]) -> str: else: svg.append(f'{name}') + + if overlapped: + # 如实交代散开这件事，别让读者以为点的位置就是精确坐标 + who = "；".join("、".join(x["d"].get("name", "") for x in g) for g in overlapped) + svg.append(f'' + f'※ 坐标完全重合的项目已沿小圆散开以便区分：{who}') svg.append("") return "\n".join(svg)