gitea-publish
de6cf8f3c0
- 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 重算矩阵 + 回填总纲
229 lines
22 KiB
Markdown
229 lines
22 KiB
Markdown
# 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>
|