你在任何聊天窗口给它发一条消息，它就能帮你操作电脑——执行命令、读写文件、浏览网页、操控桌面应用、管理定时任务，甚至语音对话。

和常见的 AI 聊天机器人不同，OpenClaw 运行在你自己的电脑上，不依赖云端服务器。它支持 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等海外主流平台，也通过插件支持飞书、企业微信、qq等国内渠道。除了消息平台，还有 macOS / iOS / Android 原生应用，以及终端命令行和 Web 控制台。

简单说：20+ 种入口，一个本地 AI 大脑，一套工具集。

工具集

用户入口

Agent 运行时

Pi SDK agent loop

Provider 路由

Model Failover

Context Engine

Gateway 网关

消息路由

消息队列

会话管理

Cron 调度

Hook 系统

Plugin 注册

消息渠道
WhatsApp · Telegram · Discord
Slack · Signal · iMessage
飞书 · LINE · Matrix ...

原生应用
macOS · iOS · Android

终端与 Web
TUI 命令行 · Control UI

系统操作
exec · read · write · cron

网络与感知
browser · web_search · memory

多媒体与 GUI
peekaboo · canvas · tts

---

演化史

OpenClaw 历经 Warelay → Clawdis → Clawdbot → OpenClaw 四次更名，我们看看每次更名时的架构变化。

Warelay："一条管道"

项目名 warelay = WA Relay（WhatsApp 中继）。用户通过 WhatsApp 或短信给 AI 发消息，收到文字回复。没有 Gateway、没有 Agent、没有会话管理——就是一个 webhook 脚本。

Twilio / Baileys
接收消息

Express 路由

AI API
生成回复

原路返回

关键选择：用 Baileys（开源 WhatsApp 协议库）而非商业 API 收发 WhatsApp。好处是免费且不依赖第三方服务，代价是 Baileys 要求每台机器只能维持一个 WhatsApp 会话。

Clawdis：最关键的跃迁

这是变化最剧烈的阶段——三件大事同时发生：

引入 Pi SDK：Pi 是一个外部 agent 框架，提供了"消息 → prompt → 调大模型 → 解析工具调用 → 执行 → 循环"的核心 agent 循环（架构详见后文 Pi Agent Runtime 一节）。OpenClaw 从此不再是"收到消息调一次 API"，而是一个真正的 AI agent。

2 周内接入 5 个渠道：Telegram、Discord、Signal、iMessage、WhatsApp——每个平台的消息格式、API 风格、群组概念都不同。多渠道的差异催生了 Adapter 模式和 Channel Dock（统一注册中心），每个渠道只实现它需要的接口子集（详见后文通道适配器一节）。

Gateway 诞生：从一个 CLI 命令行工具变为常驻后台服务，所有客户端通过 WebSocket 统一接入，内含消息路由、队列、会话管理、Cron 调度、Hook 系统和 Plugin 注册。

Clawdbot → OpenClaw：生产化与平台化

核心思路是让新功能通过插件生长，核心代码库不再膨胀。为此落地了三层扩展机制：

插件系统：Plugin SDK + jiti

社区开发插件时，导出一个 register(api) 函数即可声明能力——可注册的类型包括：

• 渠道（registerChannel）—— 接入新的消息平台
• 工具（registerTool）—— 给 AI 新的操作能力
• 钩子（registerHook）—— 在消息流水线的特定节点插入逻辑
• HTTP 路由 / CLI 子命令 / 后台服务 —— 扩展 Gateway 和命令行

Node.js 生态的模块格式分裂（ESM vs CJS）是插件加载的主要障碍。OpenClaw 用 jiti（运行时 TypeScript 编译加载器）统一处理：插件不需要预编译，写完直接安装即可运行。目前 40+ 个扩展（飞书、LINE、Matrix、Twitch、语音通话……）都以插件形式存在。

本地记忆：sqlite-vec

让 AI 拥有跨会话的长期记忆。文本切片后转为向量，存入本地 SQLite，用 sqlite-vec 扩展做余弦相似度检索。搜索采用混合策略——向量语义匹配 + BM25 关键词匹配——兼顾"意思相近"和"关键词命中"。所有数据留在本地磁盘，也可通过 MCP 桥接对接外部知识库。

技能市场：ClawHub

插件解决了渠道和工具的扩展，但 AI 的行为模式怎么共享？ClawHub（clawhub.ai）是公开的技能注册中心。技能本质是注入 system prompt 的声明文件，描述 AI 在特定场景下该怎么做（比如"操控 macOS 桌面"、"生成代码后自动运行测试"）。

• 安装：clawhub install <slug>
• 加载优先级：workspace > 本地 > 内置
• 社区治理：点赞、评论、举报，有独立审核机制

项目的 VISION.md 明确要求：新技能应先发布到 ClawHub，不要默认加入核心仓库。

---

核心子系统拆解

Pi Agent Runtime：OpenClaw 的大脑

OpenClaw 的 agent 能力不是从零自研——它站在 Pi SDK 的肩膀上。Pi 是一个 7 包 monorepo，从底向上分三层：

pi-coding-agent · SDK 层

createAgentSession()
工具 · 钩子 · 会话一站式初始化

SessionManager
JSONL 树形持久化
分支 · 恢复 · 压缩

Context 管线
transformContext 裁剪注入
convertToLlm 格式转换

pi-agent-core · Agent 运行时

Agent Loop
prompt → stream → parse
→ execute → loop

Tool 系统
TypeBox schema 校验
流式进度回调

事件总线
turn_start · message_update
tool_execution_end ...

Steering + FollowUp
运行中插入新指令
排队后续任务

pi-ai · LLM 抽象层

Provider 注册
Anthropic · OpenAI · Google
Mistral · Bedrock 等 16+

Model 注册表
340KB 自动生成
成本 · 窗口 · 能力

EventStream
统一流式协议
text / thinking / toolcall

pi-ai（LLM 抽象层） 把 16+ 家模型供应商统一成一个 stream(model, context) 调用。每个供应商实现一个 StreamFunction，把各家私有的流式响应转成标准事件序列（text_delta、thinking_delta、toolcall_start/end）。模型注册表是自动生成的，包含每个模型的成本、上下文窗口、支持的输入类型（文本/图片）和推理能力。

pi-agent-core（Agent 运行时） 提供核心循环：用户消息进入 → 流式调用 LLM → 解析工具调用 → 按序执行工具 → 结果返回 LLM → 继续循环直到 end_turn。工具用 TypeBox 定义参数 schema，运行时自动校验。。

pi-coding-agent（SDK 层） 提供 createAgentSession() 工厂方法，一次性组装工具集、上下文钩子和会话存储。SessionManager 用 JSONL 文件存储对话树（每条消息有 id + parentId），支持分支、恢复和压缩。上下文管线分两步：transformContext() 在 AgentMessage 层面裁剪/注入（比如删掉过旧的消息），convertToLlm() 再把自定义消息类型转成 LLM 能理解的标准格式。

OpenClaw 在 Pi 之上包了六部分，让它从一个通用 agent 框架变成多渠道 AI 助手：

OpenClaw 包装 — 接入层

OpenClaw 包装 — 调度层

Pi SDK

agent 循环引擎

LLM 流式推理

SessionManager
会话持久化

Provider 路由
适配不同 LLM 供应商

工具注册
exec / browser / memory ...

Model Failover
主模型挂了自动切备用

Context Engine
长对话不丢上下文

Prompt 构建
系统指令 + Skills

会话订阅
流式回调给渠道

消息全链路：从收到到回复

一条消息从进入系统到收到回复，经过这样的流水线：

8 回复调度

保证顺序

仿人打字间隔

7 Agent 执行

Pi SDK 循环

Steering 转向

6 入队策略

eager
立即处理

batch
短时间多条合并处理

debounce
等用户停止输入再处理

5 媒体理解

语音转文字

图片生成描述

4 Hook + 路由

触发插件钩子
如自动翻译、日志

路由解析
确定交给哪个 Agent

1 收到原始消息

2 归一化
不同渠道的消息统一成相同格式

3 去重

9 投递到渠道