速览

项	值
仓库	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 的站位需要单独处理：

┌──────────────────────────────────────────────────────────────┐
│  编排 / 工作台层                                              │
│  ── 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 新增私密凭据请求（遮罩输入，敏感信息不进聊天记录与模型上下文）与插件安装前能力展示。

形态是"本地守护进程 + 多渠道前端"：

典型用例三类：

• 发一张后院蛇的照片给助理，它识别物种、给出当地动物救助电话、建议怎么抓
• 让助理每天早上把行业资讯摘要推到 Telegram
• 2.0 起：在 Mac 上开始一件事，交给云端 worker 继续跑完；一条会话授权给同事，多人带完整上下文接力

交付物是事务结果（邮件 / 日程 / 预订 / 消息）而非文件型交付物，外加文件与本地系统操作、Canvas / 语音 / 图像（伴侣 App 侧）。这是 deliverable_depth = 2 的由来——它的"交付"是状态改变，不是工件。

4. 技术维度：它怎么做到的

架构：本地 Gateway 为控制面，多渠道为前端

┌─ 聊天渠道（主要入口）─────────────────────────────────────┐
│  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 在谱系里的位置，用一句话概括：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 配置"实际影响面如何

_{本文为「全球智能体开源应用追踪」系列之一 · 总纲见系列索引 · 数据与脚本开源于 gitinbox/agent-radar}