OpenClaw 深度解析：从架构原理到安全漏洞与替代方案选型

然后 PowerShell 里 wsl --shutdown 重启，否则守护进程起不来。

VPS 部署用 Docker Compose，这是我更推荐的方式，天然隔离：

yaml
services:
  gateway:
    image: openclaw/gateway:latest
    restart: always
    ports:
      - '18789:18789'
    volumes:
      - ./data:/root/.openclaw

跑起来后 docker exec -it openclaw-cli openclaw onboard 初始化。

频道接入：WhatsApp 用 openclaw channels login whatsapp 扫二维码；Telegram 去找 @BotFather 创建 Bot 拿 Token；iMessage 仅限 macOS，需要给终端完全磁盘访问权限（读 chat.db）。

常用诊断命令：openclaw doctor 自动检查所有配置，openclaw status 看连接状态，端口默认 18789。

原理解析

Gateway：控制平面，不含业务逻辑

Gateway 是整个系统的神经中枢，本质是一个基于 Node.js 的 WebSocket 长连接服务器，默认监听 127.0.0.1:18789。它的职责边界划得很清楚：只负责消息的接收、标准化、路由和工具编排，不跑任何业务推理逻辑。

Channel Adapters 是 Gateway 的第一道处理层。WhatsApp 来的消息带着 JID（Jabber ID）、iMessage 来的带着手机号 hash、Telegram 来的带着 bot update object——格式完全不同。Adapter 层把这些异构消息统一转换成内部事件流，格式类似：

json
{
  "channel": "whatsapp",
  "sender_id": "hash:xxx",
  "group_id": null,
  "text": "帮我查一下 main.go 里的 TODO",
  "attachments": []
}

Session Routing 是第二层。Gateway 维护一张路由表，根据 sender_id 和 group_id 的组合决定把请求打给哪个 Agent 实例。这意味着你可以给不同的联系人配置不同的 Agent——给开发同事的是代码助手，给家人的是日历管理员，互不干扰。

Tool Loop 是最核心的机制，也是 OpenClaw 真正能"做事"的原因。完整流程是这样的：

1. 用户发来请求，Gateway 构建 System Prompt（含记忆、工作空间上下文）并调用 LLM API
2. LLM 返回工具调用（tool_use block），比如 { "name": "bash", "input": { "cmd": "cat main.go | grep TODO" } }
3. Gateway 拦截这个 tool_use，在本地执行命令，拿到 stdout/stderr
4. 把执行结果作为 tool_result 注回对话上下文
5. 再次调用 LLM，让它基于执行结果继续推理
6. 重复步骤 2-5，直到 LLM 输出纯文本回复（不再有 tool_use）

这个循环可以跑很多轮。一个"帮我把这个 Python 脚本改成 Go 并跑通测试"的任务，Tool Loop 可能会经历：读文件 → 写文件 → 跑测试 → 看报错 → 修代码 → 再跑测试，整个链路全自动。

Pi 引擎：嵌入式 Agent 运行时

Pi 引擎不是独立进程，是以动态库形式直接链接进 Gateway 宿主进程的。这个设计选择很关键——省掉了进程间通信（IPC）的序列化和网络开销，官方 benchmark 是 1000 QPS 下 P99 延迟低于 2ms。

Pi 暴露四类原语给 Gateway 调用：

数据操作：对本地文件系统的增删改查。权限由 allowlist 控制，默认只能访问 ~/clawd/workspace/ 目录内的内容。

代码执行：在受控的 Bash 或 Python 子进程里跑脚本，捕获 stdout/stderr 返回给 Gateway。子进程有超时限制（默认 30 秒），防止 LLM 生成死循环代码把机器跑满。

状态管理（Checkpoint）：Pi 引擎会在每次 Tool Loop 迭代完成后，把当前会话状态序列化写入磁盘。意义是：哪怕 Gateway 进程崩了，重启后能从上一个 checkpoint 恢复任务，不需要重跑整个链路。

扩展加载：动态加载 .openclaw/skills/ 目录里的插件，不需要重启 Gateway。新技能上线即用。

Heartbeat：主动性的底层机制

Heartbeat 是 OpenClaw 和所有"聊天型 AI"最根本的架构差异。它让 Agent 从被动等待变成主动监控。

实现原理很简单，但效果是颠覆性的：Gateway 内置一个 cron-style 调度器，按 HEARTBEAT.md 里定义的规则周期性触发 Agent 运行。触发后，Agent 执行检查逻辑——可以是爬网页、查 API、读邮件——如果条件满足，通过对应的 Channel Adapter 主动向用户推消息。

markdown
# HEARTBEAT.md 示例

- schedule: "_/15 _ \* \* \*" # 每 15 分钟
  task: |
  检查 https://example.com/flights/NYC 的价格。
  如果往返低于 ¥3000，立即通过 Telegram 通知我并附上购买链接。

- schedule: "0 8 \* \* \*" # 每天 8:00
  task: |
  读取 Whoop API 的昨夜睡眠评分和今日天气预报。
  生成一份 100 字以内的早间简报发到 WhatsApp。

和 cron + 脚本的区别在于：你不需要写脚本，用自然语言描述任务，Agent 自己决定调用哪些工具、怎么组合结果。任务逻辑的变化不需要改代码，改 HEARTBEAT.md 就行。

两层记忆 + 混合搜索

OpenClaw 的记忆系统解决的是 LLM 的原生缺陷：上下文窗口有限，没有持久化存储。

短期记忆（Transcripts）：每次对话的完整消息历史以 .jsonl 格式存储在磁盘。每条记录包含 role、content、timestamp 和 token 计数。Gateway 在构建下一次请求的 System Prompt 时，会从 Transcripts 里拉最近 N 条（具体数量由 max_context_messages 配置控制，默认 50），保证短期上下文连贯。

长期记忆（MEMORY.md）：这是个持久化的 Markdown 文件，记录跨会话的用户偏好和知识条目。Agent 在推理过程中如果学到关于用户的新信息（"用户的生产数据库连接字符串前缀是 postgresql://prod..."、"用户不喜欢在回复里用 emoji"），会主动通过工具调用更新这个文件。下次对话时，MEMORY.md 的内容会作为 System Prompt 的一部分注入。

混合检索策略：记忆文件大了之后，全量注入不现实（token 成本高，也容易超窗口）。OpenClaw 用两种策略组合检索相关片段：

SQLite FTS5 做精确匹配——技术错误码（ECONNREFUSED）、人名（"张总"）、项目名（"auth-service"）这类关键词，必须百分之百找到，不能靠语义近似。FTS5 的倒排索引能保证这一点。

向量相似度搜索做语义召回——"认证失败"和"登录报错"是同一个问题，关键词匹配找不到，向量空间里距离很近能找到。OpenClaw 用 SQLite-vec 扩展存 embedding，支持 cosine similarity 查询，不需要单独跑 Chroma 或 pgvector 服务。

两者结果取并集，按 RRF（Reciprocal Rank Fusion）算法合并排序后，注入 System Prompt 的记忆区域。

上下文压缩（Compaction）：当历史消息接近模型上下文窗口上限时，Gateway 会触发压缩流程——先用 LLM 把旧消息总结成摘要，然后用摘要替换原始消息，释放 token 空间。压缩是有损的，但核心指令（System Prompt 里的规则）永远不会被压缩。

泳道策略（Lane Strategy）：解决异步竞态

Node.js 是单线程事件循环。多个用户同时发消息，或者一个 Heartbeat 任务还在跑的时候用户发来新消息，如果不做并发控制，Tool Loop 的执行结果会互相污染——A 的 bash 输出被插进 B 的上下文里。

OpenClaw 的解法是泳道策略：每个 session（由 sender_id + group_id 唯一标识）分配一条独立的执行队列（泳道）。同一 session 的所有操作严格串行，不同 session 的泳道可以并发。

实现上用 Promise 链实现 per-session 队列，新任务进来时追加到该 session 的 Promise 链尾部：

typescript
// 伪代码，简化后的泳道实现
const lanes = new Map<string, Promise<void>>()

function enqueue(sessionId: string, task: () => Promise<void>) {
  const prev = lanes.get(sessionId) ?? Promise.resolve()
  const next = prev.then(task).catch(handleError)
  lanes.set(sessionId, next)
}

好处是：开发者在写 Skills 插件时，完全不需要考虑加锁的问题。只需要声明哪些任务可以并行（不同 session），哪些必须串行（同一 session 内），Lane Strategy 自动保证正确性。

安全问题（这是核心）

OpenClaw 的安全问题不是小毛病，是架构级的。截至 2026 年 3 月，披露了 8 个 CVE，其中关键问题有这几个：

CVE-2026-25253（CVSS 8.8）：WebSocket origin 未校验，访问一个恶意网页就能触发 RCE。有公开 exploit。这不是理论漏洞，是实战可利用的。

ClawHavoc 供应链攻击：ClawHub（官方插件市场）上被发现 1184+ 个恶意 Skills，投递 AMOS macOS 窃密器。Cisco 验证了其中有 Skills 在悄悄把用户的 Discord 聊天记录以 Base64 分块形式发往未知端点。大约 20% 的 ClawHub 注册内容是恶意的。

大规模裸跑实例：Censys 扫描发现超过 42000 个 OpenClaw 实例暴露在公网，93.4% 没有任何认证。这是用户配置问题，也是 OpenClaw 默认配置没有足够阻止这种情况的设计问题。

架构级缺陷：所有 Agent 在同一个 Node.js 进程里共享内存，没有进程隔离。凭据以明文存储。没有 WebSocket origin 校验。没有速率限制。安全审计结论：512 个漏洞，8 个 critical。

根本原因：OpenClaw 的安全模型是"应用层权限控制"——allowlist、pairing code。这是配置性安全，不是架构性安全。一旦应用层被绕过，整台机器就暴露了。给 AI rm -rf 权限之前，你得想清楚这个链路上每个环节的信任边界。

替代品：*Claw 生态

OpenClaw 爆火之后的六周内，涌现出一整个替代品生态。每个项目都在攻击 OpenClaw 的某个具体弱点。

ZeroClaw

100% Rust，3.4MB 二进制，运行时内存 < 5MB（OpenClaw 是 1.52GB，差距 194 倍），启动时间 < 10ms（OpenClaw 约 6 秒，差距 400 倍）。

安全默认值比 OpenClaw 强得多：文件系统默认只能访问 workspace 目录，命令执行需要在显式 allowlist 里（默认只有 git、npm、cargo）。API key 加密存储。WebSocket 绑定 localhost。

支持 22+ LLM 提供商，包括 Ollama 本地模型。内置 zeroclaw migrate openclaw 命令直接导入 OpenClaw 的配置和记忆。

Trade-off：插件生态比 OpenClaw 小得多。贡献代码需要会 Rust，门槛比 TypeScript 高。编译需要约 1GB RAM，低配机器编译会失败。

适合谁：在 VPS 或树莓派跑常驻 Agent，在意内存成本，想要安全默认值而不是安全配置。

NanoClaw（安全优先）

700 行 TypeScript，整个 codebase 大约 8 分钟能读完。安全模型是 OS 级别的：每个 chat group 跑在独立的 Linux 容器里（macOS 用 Apple Container，其他用 Docker），各自有独立的文件系统，容器间完全隔离。

基于 Anthropic 的 Claude Agent SDK，直接用 Claude Code 驱动推理，代码能力强。支持 Agent Swarms——多个专门化 Agent 协作。

Trade-off：需要懂容器怎么配，否则隔离保护形同虚设。支持的渠道比 OpenClaw 少。功能集也更精简，它的哲学是"你 fork 了自己改"而不是靠配置文件。

适合谁：在意安全审计、用 WhatsApp 做主力渠道、想跑 Claude 最新模型能力、愿意 fork 代码自定义。

Nanobot（可读性最强）

香港大学数据科学实验室出品，Python 写的，约 4000 行核心代码。读完整个 codebase 一个下午够了。支持 Ollama 本地模型，树莓派 3B+ 上能用 191MB 内存跑起来。

MCP 工具服务器支持是 2026 年 2 月 14 日加的，接入外部工具不用重新造轮子。

Trade-off：没有内置认证中间件，没有沙盒执行，没有集中日志。作为学习项目或个人玩具没问题，直接暴露在生产环境和裸跑 OpenClaw 差不多危险。

适合谁：想理解 AI Agent 架构是怎么工作的，想改代码但 Rust/TypeScript 功底不够，用 Ollama 本地模型。

PicoClaw（嵌入式首选）

Sipeed（嵌入式硬件公司）出品，Go 写的，目标内存 < 10MB，启动 1 秒，能跑在 $10 的 RISC-V 板子上。有趣的是，95% 的核心 Go 代码是 AI 从 Nanobot Python 版本重构生成的。

Trade-off：企业级功能基本没有，observability 需要自己搭，不适合复杂工作流。

适合谁：家庭自动化、IoT 场景、用最便宜的硬件跑 24/7 Agent。

IronClaw（合规场景）

WASM 沙盒执行 + TEE 可信执行环境，工具代码在沙盒里跑，原始凭据永远不进沙盒（Secrets Injection 机制）。安全级别最高，也是部署最复杂的。

Trade-off：安全架构复杂，实现成本高，社区比其他几个小。

适合谁：处理敏感数据、受监管行业、需要向审计方证明隔离边界的场景。

选哪个

想要最多功能和最大插件生态：OpenClaw，但安全加固是前提。至少要：Docker 隔离部署、更新到最新版、关掉 ClawHub 自动安装、WebSocket 不暴露公网。有时间做这些配置，OpenClaw 的生态优势是其他项目短期内追不上的。

想要开箱安全、省心运维：ZeroClaw 或 NanoClaw，根据自己的侧重选。在意资源占用、要跑在低配 VPS 或树莓派上选 ZeroClaw（Rust，< 5MB 内存）；在意安全架构、主要用 Claude 模型和 WhatsApp 选 NanoClaw（容器级隔离，700 行代码可审计）。

想学习 Agent 架构 / 用 Ollama 本地模型：Nanobot。Python，4000 行，一个下午读完。

IoT / 嵌入式 / $10 板子：PicoClaw，目前唯一的选项。

合规场景 / 处理敏感数据：IronClaw，或者直接找有 SOC 2 认证的商业方案。

总结

OpenClaw 用三个月证明了"本地 AI Agent"这个品类有真实市场，211000 颗 GitHub star 是真实需求投票，不是炒作。但它同时也验证了一件老道理：功能驱动的快速迭代和安全架构是天然对立的，OpenClaw 选了前者，后果就是 8 个 CVE 和 4 万个裸跑实例。

替代品生态在六周内从零变成了六个方向各异的成熟选项，这个速度本身就说明了问题：开发者不是要放弃这个品类，他们要的是同样的能力加上可接受的安全模型。

下一步：

• 在用 OpenClaw 且没做过安全加固的，今天把它迁到 Docker 里并更新到最新版，WebSocket 确认只绑定 localhost
• 还没上的，根据上面的场景表对号入座，ZeroClaw 和 NanoClaw 都有完善的迁移/初始化文档
• ClawHub 的 Skills 在安全局势稳定前谨慎安装，等社区扫描机制完善