开源项目研究
OpenClaw 不是 2025 年突然出现：五个名称、Gateway 架构与安全边界
以 2026 年 1 月 30 日 OpenClaw 主更名提交和首个功能包为事件，恢复 Warelay、Clawdis、Clawdbot、Moltbot 到 OpenClaw 的完整名称链，并审计个人 Agent 的 Gateway、宿主执行、沙箱与商业化边界。
时间与证据
本文研究的不是“项目最早创建”，而是 OpenClaw 品牌与可运行功能包在 2026 年 1 月 30 日形成这一事件。代码主线更名提交 9a716078 的 author time 是 2026-01-30T02:15:10Z；npm 的首个实际功能 beta 包随后在 02:20:55Z 发布。信息截止按 UTC 日历日固定为 2 月 1 日，本文选用 7aeabbab 的 README、安全文档和 LICENSE 作为 T+2 可复核快照；这里的 T+2 是“事件日加两个 UTC 日历日”，不是严格滚动 48 小时。文章发布日期与更新日期见页首。
npm 在 1 月 29 日存在 openclaw@0.0.1，但元数据明确写着 Empty placeholder package，只有占位文件。把包名被占用的时间当成产品发布会提前事件日期；因此本站采用主更名和首个功能包共同成立的 1 月 30 日。
名称链也必须完整：
| 日期 | 名称 | 决定性证据 | 不能误写成什么 |
|---|---|---|---|
| 2025-11-24 | Warelay | 16dfc1a5 首次加入可运行 CLI、package.json 与 warelay bin |
初始提交只有 LICENSE，不能称完整产品发布 |
| 2025-12-03 | Clawdis | a27ee236 的 author time 为 2025-12-03T15:45:32Z，该提交首次把 README 主品牌从 Warelay 改为 CLAWDIS；5949ef0e 仅在 12 月 5 日修改 package.json 包名 |
不能把 12 月 5 日包更名误写为品牌首次出现，也不能从 Warelay 直接跳到 Clawdbot |
| 2026-01-04 | Clawdbot | 246adaa1 主更名提交 |
不是最初项目名 |
| 2026-01-27 | Moltbot | 6d16a658 主更名提交 |
这是短暂中间品牌 |
| 2026-01-30 | OpenClaw | 9a716078 主更名与随后功能 npm 包 |
不能写成“OpenClaw 于 2025 年 11 月首发” |
其中，a27ee236 同时修改 README 并新增多份 CLAWDIS 文档，是目前用于确定 README 品牌首次出现的决定性提交；5949ef0e 的补丁只有 package.json 一行包名变化，不能承担 12 月 3 日品牌起点的证据职责。
本文证据等级是 sourced。我逐项核验了固定提交、包注册记录和 T+2 文档，但没有在本文部署 OpenClaw 或执行真实渠道、浏览器和设备任务。因此功能与安全机制写成“文档和代码显示”，不写成本站运行结果。
当时发生了什么
它首先是个人单用户 Agent
T+2 README 将 OpenClaw 定义为运行在自己设备上的 personal AI assistant，并明确使用场景是 personal、single-user、local、always-on。它把 WhatsApp、Telegram、Slack、Discord、Signal、iMessage 和 WebChat 等消息入口连接到同一个 Gateway，再由 Gateway 管理会话、渠道、工具、事件和设备 Nodes。
这一定义很重要。项目具备多 Agent 路由、分工作区和 per-agent tool policy，不等于它已经是企业 SaaS 的多租户系统。T+2 文档明确指出 workspace 只是默认工作目录，不是硬安全边界；沙箱未开启时，绝对路径仍可能访问宿主其他位置。企业多租户还需要组织、角色、租户数据隔离、配额、审计归属、管理员审批和合规删除等契约；T+2 文档没有证明这些能力已经完整交付。
Gateway 不是普通聊天代理
Gateway 是控制面，不只是反向代理。它持有渠道连接、模型认证、会话路由、Agent 工作区、工具策略和设备配对；还可以把浏览器、Canvas、摄像头、屏幕录制、通知和 system.run 连接到 Agent。
T+2 README 同时说明：Gateway 宿主机默认运行 exec 工具和渠道连接，设备动作在配对 Node 上执行。也就是说，一条消息可能沿着以下路径产生真实副作用：
外部消息 / 网页 / 附件
→ Gateway 身份与会话路由
→ 模型决定调用工具
→ 宿主 Shell、浏览器登录态或设备 Node
→ 文件、账户、摄像头、通知等真实状态变化
这种设计让个人 Agent 很有价值，也让 Gateway 成为高价值安全边界。它保存或能够访问渠道 token、模型 OAuth/API key、pairing allowlist、会话 transcript、浏览器 profile 和插件代码；“部署在自己机器上”不等于这些数据天然安全。
默认安全措施与剩余风险必须同时写
OpenClaw 对常见消息渠道默认使用 DM pairing。未知发送者只能获得短配对码，消息不会直接交给 Agent；公共 DM 需要显式把策略改为 open 并加入通配 allowlist。这个默认值能降低陌生人直接触发工具的风险。
但安全文档也直接写明：Prompt Injection 没有被解决，系统提示只是软约束。即使只有本人能发消息，Agent 阅读的网页、邮件、文档、附件和日志仍可能包含恶意指令。真正的硬边界来自 tool policy、明确配置的 exec approval、sandbox、渠道 allowlist 和最小化的文件与网络访问。
T+2 文档还说明沙箱是 opt-in。main session 默认工具在宿主运行；host exec 也不会仅因为项目支持审批就自动等待确认，必须把执行主机和 exec approvals 按文档显式配置，审批才会成为该路径上的硬门。系统可以把非 main 或全部会话放进 Docker 沙箱，并设置工作区为 none、read-only 或 read-write。浏览器控制同样需要单独治理，因为已登录的 profile 等价于一组可操作账户，远程浏览器控制应视为 operator access。
任务判断
假设一位跨境电商负责人希望部署个人助理：从 WhatsApp 与 Slack 接收任务，查看后台订单，调用浏览器处理退款草稿，每天生成销售摘要，并允许家人偶尔发送查询。这个需求看起来适合 OpenClaw，但“能连渠道”不是验收标准。
上线前至少要回答：
- 哪些发送者、群组和渠道可以触发 Agent，未知 DM 是否默认拒绝。
- 个人、家人和工作消息是否进入不同 session、workspace 和 Agent。
- 哪些 Agent 可以读取订单、控制浏览器、执行 Shell 或调用设备 Node。
- 写操作是否需要审批，退款是否只能生成草稿而不能提交。
- 网页、邮件与附件经过什么不可信内容处理，能否触达带凭据的工具。
- Gateway、浏览器 profile、渠道 token、会话和日志如何备份、加密、轮换与删除。
- 宿主失败、模型失控或插件升级后如何停止任务、撤销操作和恢复状态。
对于单用户、低风险、可人工观察的自动化，OpenClaw 可以进入受控原型验证。对于公众开放的机器人、多人共享主会话、自动支付或没有审批的高风险操作，仅靠默认安装不够。它需要额外身份层、租户隔离、策略引擎、审批队列和审计存储。
工程影响
用爆炸半径设计权限，而不是只按工具名授权
一个实用策略矩阵可以这样定义：
| Agent | 输入信任 | 工作区 | Shell | 浏览器 | 写操作 | 审批 |
|---|---|---|---|---|---|---|
reader |
网页、邮件、附件均不可信 | none | 禁止 | 独立无登录 profile | 禁止 | 不适用 |
personal |
仅已配对本人 | read-only | 沙箱内 allowlist | 独立工作 profile | 草稿级 | 每次确认 |
operator |
仅内部系统事件 | 独立 workspace | 沙箱内固定命令 | 专用账号 | 有限写入 | 高风险双确认 |
public |
任意外部用户 | none | 禁止 | 禁止 | 禁止 | 不适用 |
关键不是给某个 Agent “browser=true”，而是限制它能打开哪个 profile、访问哪些域名、执行哪些动作，以及能否从不可信内容直接跨到高权限执行面。
把身份、内容与工具分成三道门
第一道门检查 谁在请求：pairing、allowlist、群组 mention、渠道账号和设备配对。第二道门检查 内容是否可信：网页、附件和消息都视为数据，不允许它们修改系统策略。第三道门检查 动作是否允许：工具 allow/deny、参数约束、沙箱、审批与速率限制。
三道门缺一不可。DM pairing 只能证明发送者身份，不能证明发送者转发的网页安全；Prompt 提醒只能影响模型选择，不能替代 exec policy；Docker 沙箱可以限制宿主访问，但如果仍挂载敏感目录或允许公网凭据操作，风险依然存在。
状态和升级也属于供应链
OpenClaw 在两个多月内至少经历五个名称，说明项目迭代非常快。生产环境必须固定 npm 版本和 Git commit，保存升级前后的配置 schema、数据库或状态迁移、插件清单和回滚点。不能因为仓库现名稳定，就默认历史包名、环境变量、目录和服务名都一致。
插件与 skills 也应视为代码依赖。安全文档提醒 npm 插件安装会执行生命周期脚本；企业环境应使用精确版本、来源 allowlist、离线审查和哈希锁定，而不是让 Agent 从公共注册表自动安装并立即运行。
商业价值
OpenClaw 的商业价值来自“把用户已经使用的渠道和设备接到持续运行的 Agent”，而不是模型本身。潜在购买者包括需要个人运营助理的创业者、小型团队、顾问和需要跨渠道响应的服务人员。可收费部分更可能是托管部署、渠道集成、专用工作流、权限策略、监控、备份和支持。
一个可检验的单任务期望价值模型是：
单任务期望净价值
= 成功率 ×（节省的人工分钟 × 单位时间价值 + 响应改善价值）
- 单次模型、渠道与运维摊销
- 审批分钟 × 人工单位成本
- 错误率 × 平均恢复或损失成本
只有当自动化任务具有相对稳定的输入、可限制动作和可核验结果，并且实测成功率与错误损失落在可接受区间时，这个价值才可能成立。公开社交机器人、复杂支付、共享个人浏览器和未经审批的宿主 Shell 会提高错误概率与单次损失；在高损失或低任务量场景中，作者判断其错误成本可能超过节省的时间，但仍需用真实任务数据验证。
可证伪的采用窗口应先固定为 90 天：前 30 天只验证三到五个只读或草稿任务，后 60 天才允许少量可逆写入，并以权威业务状态而非模型回复作为结果。若出现任何未授权写入，或固定任务成功率低于 95%、人工复核时间没有低于原人工流程、单任务期望净价值连续四周不为正，就结束试点而不是扩大渠道、设备或宿主权限。这是未来试点的进入与退出条件，不是本文已经运行 OpenClaw 的结果。
更可能形成壁垒的是任务模板、企业连接器、最小权限策略、审批记录、故障恢复和用户反馈，前提是这些资产能持续提高任务成功率或降低集成与风险成本。如果竞争者可以低成本复制同一流程和数据，仅仅封装开源项目或更换模型就难以形成长期差异化。
局限与风险
第一，本文没有运行 OpenClaw，不能把文档中的功能写成稳定成功率。渠道协议、移动设备权限、浏览器兼容性和长期 daemon 可靠性都需要独立实验。
第二，T+2 快照只代表快速演进项目在 2026 年 2 月 1 日的状态。今天的 README、包名、命令和安全默认值可能已经变化，生产采用必须重新固定当前版本，不能直接照抄本文配置。
第三，Prompt Injection 仍是开放问题。模型更强可以降低部分风险，但不能替代 sandbox、allowlist、审批和凭据隔离。任何能读取不可信内容又能操作真实账户的 Agent 都需要按高风险系统设计。
第四，MIT License 只覆盖项目代码许可，不覆盖 WhatsApp、Slack、Discord、模型服务、浏览器扩展和插件的独立条款，也不证明企业数据处理与合规要求已经满足。
第五，单用户定位与多人场景存在张力。多 Agent routing 和 per-agent policy 是有用隔离原语，但没有证据证明它们等价于企业 RBAC、租户数据隔离和管理员治理。
面试表达
30 秒结论： OpenClaw 不是 2025 年以现名突然发布，完整链条是 Warelay、Clawdis、Clawdbot、Moltbot，再到 2026 年 1 月 30 日的 OpenClaw。它的核心不是某个模型，而是把消息渠道、Agent、工具、浏览器和设备连接到 Gateway。这个控制面很有产品价值，也集中持有凭据和执行权限，所以必须用 pairing、工具策略、审批、沙箱和独立浏览器 profile 控制爆炸半径。
3 分钟展开： 我会先区分项目起点、品牌更名和功能包，再画三层信任边界：外部输入、Gateway 控制面、真实执行面。main session 默认可在 Gateway 宿主执行，沙箱和 host exec 审批都需要明确配置，而不是天然隔离或默认硬门；Prompt Injection 官方也明确没有解决。单用户原型可以验证，但多人、公开入口和高风险写操作需要额外身份、策略、审批、审计与恢复系统。
如果追问“DM pairing 是否解决安全问题”，答案是否定的。它解决谁能发消息，不解决已授权用户转发的恶意网页或附件，也不限制模型调用高风险工具。身份、内容和动作必须分别设门。
如果追问“为什么不直接把 Gateway 放公网”，答案是 Gateway 连接真实渠道、凭据、会话和工具；网络暴露相当于扩大控制面攻击面。应保持 loopback 或私网入口、强认证，并把浏览器和设备 Node 的配对视为管理员权限。
复盘
站在 2026 年 7 月回看，OpenClaw 最强的信号是个人 Agent 正从单次对话变成长期运行的渠道与设备控制面。最容易被忽视的则是：更长期的状态、更丰富的工具和更多真实入口，会让权限、凭据、供应链和恢复问题比 Prompt 本身更重要。
这次名称链复原也说明，开源项目研究不能只看当前 README。仓库创建日、首个可运行提交、包发布、品牌更名和正式 release 是不同事件；不固定 commit，就会把后续能力和现名倒灌到早期历史。
下一步实验应固定一个 OpenClaw 版本，在隔离环境中验证四类失败：未知 DM、恶意网页指令、越权 Shell 参数和带登录态浏览器误操作。只有公开策略、日志、失败样本和恢复结果后，证据等级才能从 sourced 升级为 reproduced。
方法披露
本文使用 AI 工具协助提交历史整理、安全文档反查和图表草拟；名称日期、固定提交、一手来源、最终文字与判断由作者逐项复核并负责。
修订记录
2026-02-03：初版发布；核验 Warelay 至 OpenClaw 的五个名称、1 月 30 日功能包、T+2 README、安全文档与许可证；以a27ee236的2025-12-03T15:45:32Zauthor time 及 README 改动确定 Clawdis 品牌首次出现，并明确5949ef0e仅是 12 月 5 日的package.json包更名；同时说明 T+2 的 UTC 日历日口径以及 workspace 与 host exec approval 边界。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
- refactor: rename to openclaw
- openclaw@0.0.1 placeholder package metadata
- openclaw@2026.1.29-beta.1 functional package metadata
- OpenClaw T+2 README snapshot
- OpenClaw T+2 security guide snapshot
- Warelay first runnable CLI commit
- Clawdis first appears as the README brand
- Rename npm package from warelay to clawdis
- Rename Clawdis to Clawdbot
- Rename Clawdbot to Moltbot
- MIT License present in the OpenClaw T+2 snapshot
讨论