OpenClaw 架构解析:313K Star 背后的工程与争议

公众号：AIGC 生活实验室简介：探索 AI 如何改变工作与生活作者：皮皮鲁呀鲁西西

2 周 31 万 Star。史上增长最快的开源项目。

但翻了一圈国内媒体报道，标题几乎清一色是小心你的数据被删、AI 助手清空了我的桌面文件夹。

一、OpenClaw 是什么？

一句话定义：开源、自托管、本地优先的个人 AI 助手平台。

核心定位很明确 - Your assistant. Your machine. Your rules

不是 SaaS，不是云端服务，而是运行在你自己设备上的 AI 助手。对话数据不经过第三方服务器，API Key 在你本地，会话文件也在你本地。

创始人 Peter Steinberger（PSPDFKit 创始人）2025 年 11 月开始做的周末项目，原名 Clawd（Claude 的谐音梗），后来因为 Anthropic 商标投诉改名叫 Moltbot，再后来定名 OpenClaw - Open（开源）+ Claw（龙虾钳）。

GitHub 地址：https://github.com/openclaw/openclaw官网：https://openclaw.ai/

支持哪些平台？

15+ 消息渠道：WhatsApp、Telegram、Slack、Discord、Google Chat、Signal、iMessage、BlueBubbles、IRC、Microsoft Teams、Matrix、飞书、LINE、Mattermost、Nextcloud Talk、Nostr、Synology Chat、Tlon、Twitch、Zalo、WebChat...

核心工具系统：

•Browser：专用 Chrome/Chromium 控制

•Canvas：A2UI 客户端渲染

•Nodes：macOS/iOS/Android 设备能力

•Cron：定时任务

•Webhooks：外部触发器

技术栈：TypeScript + Node.js >= 22，WebSocket 协议，JSONL 会话存储。

二、四层架构：多入口、单内核

OpenClaw 采用多入口、单内核的运行时架构。

┌─────────────────────────────────────────────────────────┐│ 交互层（Ingress） ││ WhatsApp / Telegram / Slack / Discord / WebChat... │└────────────────────────┬────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────┐│ 网关层（Control Plane） ││ Gateway (ws://127.0.0.1:18789) ││ 会话管理 / 消息路由 / 工具调度 / 状态广播 │└────────────────────────┬────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────┐│ 智能体层（Execution Plane） ││ Agent Runtime (Pi Agent) ││ 思考决策 / 工具调用 / 上下文管理 / 流式响应 │└────────────────────────┬────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────┐│ 执行层（Capability） ││ Tools (Browser/Exec/Canvas/Nodes/Cron...) ││ Providers (Models + Failover) │└─────────────────────────────────────────────────────────┘

第一层：交互层（Ingress）

所有消息渠道的入口。不管是 Telegram 还是 Slack，消息进来后统一转换成 OpenClaw 内部格式，往下传给 Gateway。

每个渠道是一个独立的 Channel Plugin，统一实现 ChannelPlugin 接口，事件驱动。

第二层：Gateway（WebSocket 控制平面）

这是整个系统的核心。

Gateway 是一个单一长连接进程，管理所有消息渠道。客户端、工具、事件都通过 WebSocket 通信。

核心职责：

•会话管理：sessions.list / sessions.patch

•配置读写：config.get / config.set

•触发执行：agent.run

•设备能力调用：node.list / node.invoke

•状态广播：实时推送 agent/chat/presence/health 事件

消息验证用 TypeBox 强类型，配置文件在 ~/.openclaw/openclaw.json。

第三层：Agent Runtime（智能体层）

这是 AI 的大脑 - 负责思考、决策、调用工具、生成响应。

Agent Loop 的执行流程：

输入 → 队列(Queue) → 会话加载 → 提示词构建 → 模型调用 → 工具执行 → 流式响应 → 状态持久化

5 种输入类型：

1.Messages：用户消息

2.Heartbeats：心跳检测

3.Crons：定时任务

4.Hooks：内部钩子

5.Webhooks：外部触发

三层记忆系统：

•Session Memory：当前对话上下文（JSONL 文件）

•Daily Memory：每日摘要

•Long-term Memory：向量搜索（可选）

注入文件（在 ~/.openclaw/workspace）：

•AGENTS.md：操作指令 + 记忆

•SOUL.md：人设、边界、语气

•TOOLS.md：用户维护的工具说明

•BOOTSTRAP.md：首次运行仪式

•IDENTITY.md：智能体名称/风格/表情

•USER.md：用户档案 + 偏好称呼

你可能会问：为什么不是简单的 while(true) 循环？

因为 Agent Loop 需要处理：输入多样性、队列管理、状态持久化、流式响应、工具沙箱。这不是一个死循环能搞定的。

第四层：执行层（Capability）

具体干活的工具和模型。

核心工具：

•bash / process：命令执行

•read / write / edit：文件操作

•browser：网页控制

•canvas：可视化界面

•nodes：设备能力

•sessions_*：Agent 间通信

•web：HTTP 请求

三、9 层工具过滤策略

这是 OpenClaw 安全模型的关键部分。

工具调用不是模型说执行就执行，而是经过 9 层过滤：

1.默认允许列表：基础工具默认可用

2.会话级别覆盖：特定会话可以覆盖全局配置

3.沙箱模式过滤：非主会话在 Docker 容器中执行，工具受限

4.渠道策略：不同消息渠道可以有不同的工具权限

5.模型能力匹配：根据模型能力决定是否提供工具

6.用户显式允许：用户主动开启的工具

7.用户显式拒绝：用户主动禁止的工具

8.技能依赖：某些 Skill 需要特定工具

9.运行时检查：执行时的最终校验

权限控制配置示例：

{ "agents": { "defaults": { "sandbox": { "mode": "non-main", "allowlist": ["bash", "process", "read", "write", "edit"], "denylist": ["browser", "canvas", "nodes", "cron"] } } }}

说实话，这个设计挺 elegant 的 - 不是一刀切的黑白名单，而是分层次、可覆盖的权限系统。

四、安全模型与争议点

这部分是社区吵得最凶的地方。

致命三要素（Lethal Trifecta）

Cisco 的安全研究团队提出了一个概念：当 AI Agent 同时具备以下三点时，风险急剧上升：

1.持久化系统访问

2.自主决策能力

3.互联网连接

OpenClaw 三点全占。

官方的缓解措施

1.DM 配对机制：未知发件人收到配对码，管理员手动批准

2.沙箱模式：非主会话在 Docker 容器中执行

3.工具白名单：限制危险操作

4.本地绑定：默认 bind: loopback，不暴露公网

但现实情况...

30,000+ 实例暴露在公网。

Bitsight 的安全研究发现，大量用户把 Gateway 直接绑定到 0.0.0.0，甚至没设密码保护。

6 个已披露的 CVE，包括 CVE-2026-25253（1-click 远程代码执行）。

1,184 个恶意 Skills。ClawHavex 曝光了一批恶意插件，有的会窃取配置文件中的 API Key。

配置泄露风险。GitHub Issue #11468 指出，gateway config.get 会返回解析后的明文密钥。

真实用户反馈

Reddit 上有条高赞评论写得很直白：

OpenClaw is god-awful... costs you like 50 cents to do like one simple prompt... security is abysmal

国内媒体报道的案例更具体：

整理桌面上的发票照片，按月份分类... 五分钟后，桌面文件夹却被清空

**几句话就得花 3 元钱... 100 万 Token 就没了，还欠费了****

还有安装配置问题：

Setting it up was super time-consuming and took me 3-4 tries. NVM paths that systemd can't find...

甚至催生了付费安装/卸载服务 - 有开发者专门帮人配置 OpenClaw，收费 200-500 元不等。

核心争议：本地优先 ≠ 安全

这可能是最大的误区。

本地优先意味着数据主权在你手里，但不意味着系统本身是安全的。

就像把车钥匙放在门口地毯下 - 方便，但安全吗？

五、与 Dify、Coze 对比

OpenClaw vs Dify vs Coze 核心差异：

•定位：OpenClaw 是个人 AI 助手，Dify 是企业级 LLM 应用平台，Coze 是字节系 Bot 构建平台

•目标用户：OpenClaw 面向开发者/技术爱好者，Dify 面向产品经理/开发者，Coze 面向非技术用户/小团队

•部署方式：OpenClaw 自托管（本地/VPS），Dify 自托管或 SaaS，Coze 纯 SaaS

•开源协议：OpenClaw 用 MIT，Dify 用 Apache 2.0，Coze 闭源

•数据位置：OpenClaw 在用户设备，Dify 可选，Coze 在字节云端

•多 Agent：OpenClaw 原生支持，Dify 有限支持，Coze 不支持

•渠道接入：OpenClaw 接入 15+ IM 平台，Dify 用 API 集成，Coze 依赖字节生态

一句话总结：

•OpenClaw：像一个AI 操作系统，强调持续运行和自主执行

•Dify：像低代码平台，强调可视化和快速开发

•Coze：像Bot 商店，强调易用和生态

说到底，这三个东西不是同一类产品。

六、适合谁？不适合谁？

适合

1.技术爱好者：愿意折腾配置、调试问题、自己排查错误

2.隐私敏感用户：对话数据不能经过第三方服务器

3.多渠道需求：需要在 Telegram、Discord、WhatsApp 等多个平台统一接入

4.定制化需求高：需要深度定制 Agent 行为、工具、人设

Medium 上有用户反馈：

Took about twenty minutes to get a working agent inside my Telegram DMs... summarizing unread emails, pulling up my calendar...

不适合

1.企业生产环境：Meta、银行等已封杀，需要企业级支持、审计、合规

2.高安全要求场景：金融、医疗、政府，数据不能有任何泄露风险

3.非技术用户：安装配置复杂，需要专业人员协助

4.成本敏感场景：Token 消耗快，预算不可控

写在最后

OpenClaw 的 313K Star 不是因为技术创新 - WebSocket、Agent Loop、JSONL 这些都不新。

它火是因为把个人 AI 助手这个概念做成了生产级工程实现：320,000+ 行代码，540+ 贡献者，15+ 平台接入，完整的工具系统。

但这个设计本身也埋下了安全陷阱。

官方的定位很明确：个人 AI 助手，不是企业解决方案，不是低代码平台，是给技术爱好者的AI 操作系统。

相关资源

GitHub 仓库：https://github.com/openclaw/openclaw官方网站：https://openclaw.ai/Discord 社区：活跃的开发者社区

如果这篇文章帮到了你，点个在看👀吧，下次再见

AIGC 生活实验室

📮 投稿/合作：egretss.bai.it@gmail.com💬 交流群：回复加群✍️ 作者：皮皮鲁呀鲁西西🚀 关注我，一起探索技术的更多可能