2025年到2026年，AI应用领域发生了一件微妙但意义深远的事：人们开始不再把AI助手当作简单的"聊天机器人"或工具，而是当作真正的数字器官。AI助手正在变成我们处理信息、做出决策、管理生活的核心枢纽。

OpenClaw（原名ClawdBot）正是在这个转折点上横空出世的。它在GitHub上收获了超过14.9万颗Star和2.25万次Fork，成为开源AI助手领域的现象级项目。它到底是怎么做的，和传统的AI应用相比有什么不同之处呢？

传统的AI助手要么被困在浏览器标签页里（ChatGPT、Claude），要么被困在某种特定生态中（Cursor Agent等应用内的agent），但OpenClaw打破了这些边界。它可以生活在你的通讯软件（如WhatsApp、Telegram等）里，生活在你的macOS菜单栏、iOS和Android设备上，甚至能通过浏览器控制你的Chrome实例。从设计上看，Clawdbot不是"一个应用"，而是一个分布式的智能层，渗透在数字生活的每个角落。

为什么Clawdbot如此火爆？我认为可能和方便的多模态交互有关。OpenClaw不只是一个对话助手，还能做到：

  • Voice Wake（语音唤醒）：在macOS/iOS/Android上，你可以像唤醒Siri一样唤醒OpenClaw，但区别在于它后续会接入你配置的强大语言模型（Claude Opus 4.5、GPT-5.2等），而不是被限制在预设技能里。
  • Talk Mode（对话模式）：支持连续的语音对话，ElevenLabs的语音合成让回复听起来像真人一样自然。
  • Live Canvas（实时画布）：这是OpenClaw最具前瞻性的功能之一。Agent可以在一个实时的HTML画布上渲染内容、执行代码、展示可视化——你甚至可以和它一起协作编辑这个画布。
  • 浏览器自动化：OpenClaw可以控制一个专门的Chrome/Chromium实例，执行搜索、填写表单、截取网页快照等操作。这不是简单的"打开网页"，而是深度的CDP（Chrome DevTools Protocol）控制。

这些功能单独看都不新鲜，但OpenClaw的创新在于把它们整合进了一个统一的、跨平台的、本地优先的架构中。你可以在通讯软件上说"帮我查一下明天的航班"，OpenClaw会自动在浏览器中搜索、截屏、分析，然后把结果发送到对话中，全程自动化。

Clawdbot在通讯软件中

解剖OpenClaw

那么，OpenClaw是怎么实现此等能力的呢？让我们深入OpenClaw的代码仓库具体分析一下吧。整个项目采用TypeScript构建，同时通过Swift处理macOS/iOS原生功能、Kotlin处理Android端，是一个典型的跨平台混合架构。纵观整个代码库，不难发现以下模块：

Gateway（网关）

image.png

Gateway的代码位于src/gateway/目录下，是整个仓库最复杂的模块。OpenClaw的核心架构可以用一句话概括：Gateway是控制平面，其他一切都是客户端。这种设计借鉴了分布式系统的最佳实践，把状态管理和业务逻辑集中在单一的网关服务中，而让各种"节点"（手机、电脑、浏览器）成为无状态的能力延伸。让我们看看它的关键组件吧：

WebSocket控制平面

Gateway暴露了一个WebSocket API（默认端口18789），这是所有客户端、节点、工具与核心系统通信的唯一通道。之所以选择可以建立长连接的WebSocket，是为了实现关键的双向实时通信。在OpenClaw中，交互不是传统的"用户发起请求 - AI响应"这么简单，而是需要服务器主动推送事件（例如有新消息到达、系统状态变化等等），也需要客户端随时发送指令。WebSocket的全双工特性完美契合这种需求。

Gateway的协议设计非常严谨，所有消息都是JSON格式，分为三类：

  • Request（req，请求）：{type:"req", id, method, params}
  • Response（res，响应）：{type:"res", id, ok, payload|error}
  • Event（事件）：{type:"event", event, payload, seq?, stateVersion?}
Client-Gateway时序图

这种设计的好处是强类型、可验证、可追踪。OpenClaw使用TypeBox定义所有协议 schema，自动生成JSON Schema，甚至能生成Swift端的模型代码。这在大型分布式项目中至关重要——当你有TypeScript、Swift、Kotlin三种语言在通信时，一个统一的Schema是防止"类型地狱"的唯一解药。

会话管理：记录Agent记忆

Gateway最重要的职责之一是会话管理。在src/sessions/目录下，你会发现一个精心设计的会话系统：

  • Session模型：每个对话都有一个唯一的session key，包含消息历史、元数据、配置状态。Session分为main（主会话，用于一对一私聊）和群组会话（每个群组有独立的session）。
  • 上下文压缩：当对话历史太长时，OpenClaw会自动压缩旧消息，生成摘要，这个没什么好说的。
  • Session Pruning（会话修剪）：为了防止内存无限增长，Gateway会根据配置策略自动清理不活跃的会话。你可以设置保留最近N个会话，或者保留M天的历史。
  • 跨会话通信：OpenClaw支持sessions_list、sessions_history、sessions_send等工具，让不同会话的Agent可以相互发现和通信。这开启了多Agent协作的可能性——你可以有一个"研究Agent"专门查资料，一个"写作Agent"专门生成文档，它们通过session工具协调工作。

通讯软件集成

Gateway的另一个核心能力是多渠道接入。在src/channels/目录下，可以发现对各种消息平台的适配器。每个渠道适配器都需要处理：

  • 消息格式转换：把各平台的富文本、媒体、回复结构，映射到OpenClaw内部的标准消息格式。
  • 群组路由：在群组中，需要区分"提到Bot的消息"、“回复Bot的消息”、“普通消息”，决定是否触发Agent。
  • DM配对策略：对于私聊，默认使用"配对模式"（pairing mode）——未知发送者会收到一个配对码，必须被显式批准后才能与Bot对话。这是为了防止垃圾信息和未授权访问。

频道适配器的设计体现了开闭原则：新增一个频道只需要实现标准接口，不需要修改Gateway核心代码。如果我们想新增对飞书/微信/QQ渠道的支持，只要新增对应的标准接口即可。

AI Agent（智能体）

只有一个网关肯定是不够的，OpenClaw的核心是一个强大的AI Agent。OpenClaw的Agent运行时位于src/agents/目录，这是整个系统最"智能"的部分。它基于Pi（Personal Intelligence）框架（一个由Mario Zechner开发的AI Agent运行时），采用经典的ReAct循环：

  1. 感知（Perceive）：接收用户输入、系统提示、工具结果、历史上下文。
  2. 思考（Think）：LLM基于当前状态生成思考过程，决定下一步行动。
  3. 行动（Act）：执行工具调用（bash、browser、canvas等），或生成最终回复。
  4. 观察（Observe）：收集行动结果，反馈给LLM，进入下一轮循环。

这个循环在src/agents/pi-embedded-runner/中实现。

Agent工具系统

OpenClaw的工具比较全面，在src/agents/tools/目录下可以找到从Bash到Canvas的全能工具箱。其中包括：

  • 系统工具
    这个没什么好说的：

    • bash：执行shell命令，支持工作目录、环境变量、超时控制。
    • read/write/edit：文件系统操作，edit支持基于diff的精确修改。
    • process：启动长期运行的进程，与bash的一次性命令区分开。

  • 浏览器工具（src/browser/）
    类似Manus，该类工具可以进行一系列浏览器操作，浏览器工具的背后是一个**CDP（Chrome DevTools Protocol）**包装器。

    • browser.navigate：导航到URL。
    • browser.snapshot：获取当前页面的可交互元素快照（用于Agent理解页面结构）。
    • browser.click/type/select：模拟用户操作。
    • browser.upload：文件上传。
    • browser.close：关闭浏览器实例。

  • Canvas工具（src/canvas-host/）
    Canvas是OpenClaw最具创新性的功能之一。它是一个Agent驱动的可视化工作空间，可以渲染图表、展示数据、甚至运行交互式应用。A2UI（Agent-to-User Interface）协议定义了Agent如何与这个画布交互，创造出一种全新的"可视化对话"体验。

    • canvas.push：向Canvas发送HTML/JS内容。
    • canvas.reset：清空Canvas。
    • canvas.eval：在Canvas上下文中执行JavaScript。
    • canvas.snapshot：获取Canvas当前状态的截图。

  • Node工具（src/node-host/）
    Node工具通过Node Registry（src/gateway/node-registry.ts）管理。iOS/Android/macOS设备以role: node连接到Gateway，暴露自己的能力。当Agent调用camera.snap时，Gateway会路由到已配对的移动设备执行。

    • camera.snap/clip：拍照、录视频。
    • screen.record：屏幕录制。
    • location.get：获取设备位置。
    • system.run/notify：执行系统命令、发送通知（macOS专属）。
Agent系统

隔离沙箱

OpenClaw默认在主机环境执行工具（bash、write等），这意味着Agent拥有与你登录用户相同的权限。这对于个人使用是高效的，但也带来安全风险。

为了应对这个问题，OpenClaw提供了沙箱模式（src/agents/sandbox/）：

  • Docker沙箱：可以为非主会话（群组、频道）配置Docker沙箱，工具在隔离容器中执行。
  • 权限白名单：可以配置allowlist和denylist，精确控制哪些工具可用。
  • 执行审批：敏感操作（如bash、write）可以配置为需要用户显式批准。

安全模型在src/security/目录中有更深入的实现，包括：

  • SSRF防护：防止Agent访问内部网络资源。
  • 路径限制：限制Agent可以访问的文件系统路径。
  • Token管理：API密钥、OAuth令牌的安全存储和轮换。

多模型支持

这也没什么好说的，OpenClaw的模型配置在src/gateway/server-model-catalog.ts中实现。它支持使用多个兜底模型：

1
2
3
4
5
6
7
8
9
10
// 示例配置
{
  agent: {
    model: "anthropic/claude-opus-4-5",
    fallbackModels: [
      "openai/gpt-5.2",
      "anthropic/claude-sonnet-4"
    ]
  }
}

故障转移逻辑（src/agents/auth-profiles/）会在模型不可用时自动切换到备用模型，确保服务不会因为某个API提供商的故障而导致瘫痪。

自动化与扩展：Cron、Webhook、Skills

OpenClaw的自动化能力在src/cron/和src/web/中实现：

Cron作业：

  • 基于node-cron实现，支持标准cron表达式。
  • Agent可以调度一次性或循环定时任务，比如"每天早上8点给我发送日程摘要"。
  • 任务状态持久化，Gateway重启后自动恢复。

Webhook：

  • 接收外部HTTP触发，比如GitHub webhook、Zapier集成。
  • 可以触发Agent运行，或者执行预定义的动作。
  • 支持签名验证，确保请求来源可信。

Skills系统（src/agents/skills/、skills/）：

  • Bundle Skills：内置于OpenClaw的核心技能。
  • Managed Skills：从ClawHub（技能仓库）下载的第三方技能。
  • Workspace Skills：用户自定义的私有技能，存储在工作区目录。

每个技能是一个包含SKILL.md的文件夹，定义了技能的描述、工具、配置。Skills系统让OpenClaw可以像VS Code插件一样扩展能力，而不需要修改核心代码。

但在我实际用下来，claw对skill的存在感知较弱。

核心实现原理

理解了架构之后，让我们深入几个关键技术点，看看OpenClaw是如何解决实际问题的。

WebSocket协议的可靠性设计

在分布式系统中，网络不可靠是基本假设。OpenClaw的WebSocket协议设计了多重机制来应对：

  • 心跳机制：客户端定期发送ping，服务器回复pong。如果超时未收到心跳，连接会被标记为不健康，客户端会尝试重连。
  • 幂等性（Idempotency）：所有有副作用的请求（send、agent）必须携带idempotencyKey。Gateway会缓存最近处理的key，防止重复执行。这在弱网环境下尤为重要——客户端可能没收到响应就断开了，重连后需要安全地重试。
  • 状态版本（State Version）：每个事件都携带stateVersion，客户端可以检测是否错过了事件，并决定是请求全量状态还是增量同步。
  • 优雅关闭：Gateway关闭前会发送shutdown事件，携带restartExpectedMs提示客户端何时可以重连。这避免了客户端盲目重试造成的雪崩。

媒体管道的流式处理

当用户发送图片、视频、语音给OpenClaw时，会经过src/media/和src/media-understanding/的处理：

  1. 接收与存储：各频道适配器接收媒体文件，存储在临时目录。
  2. 大小限制：可配置mediaMaxMb，超限的文件会被拒绝或压缩。
  3. 转录（Transcription）：语音文件通过Whisper等ASR模型转录为文本。
  4. 理解（Understanding）：图片/视频通过多模态模型（Claude 3.5 Sonnet、GPT-4V等）生成描述。
  5. 注入上下文：转录文本和图片描述被注入到Agent的上下文中，就像用户发送了文字一样。

整个管道是流式的——转录和理解可以并行进行，结果逐步推送给Agent，而不是等全部完成。

浏览器自动化

OpenClaw的浏览器控制（src/browser/）不是简单的Selenium风格自动化，而是基于Chrome DevTools Protocol的深度集成：

  • 快照（Snapshot）机制：当Agent需要"看"页面时，OpenClaw不只是截图，而是提取页面的可交互元素树（按钮、输入框、链接），并生成一个文本化的表示。这让LLM可以理解页面结构，决定点击哪里、填写什么。
  • Action Bridge：Canvas和浏览器之间有一个Action Bridge（src/gateway/server/server-browser.ts），允许Agent在浏览器和Canvas之间"穿梭"——比如在浏览器中搜索数据，然后在Canvas中可视化。
  • Profile隔离：每个浏览器实例使用独立的Chrome Profile，确保Cookie、LocalStorage、登录状态不会互相污染。

Canvas与A2UI：重新定义Agent交互

Canvas（src/canvas-host/）是OpenClaw最具前瞻性的功能。传统的AI对话是线性的——一条消息接着一条消息。但Canvas引入了空间维度：

  • Push/Reset模型：Agent可以push内容到Canvas（追加或覆盖），也可以reset清空。
  • Eval能力：Agent可以在Canvas中执行JavaScript，实现动态交互。
  • 双向绑定：用户在Canvas中的操作（点击、输入）可以触发事件回传给Agent。

A2UI（Agent-to-User Interface）协议定义了这种交互的标准。它不只是"渲染HTML"，而是创建了一个共享的数字工作空间——Agent和人类可以在同一块画布上协作。

想象一下这样的场景：

  1. 你说"帮我画一个水循环示意图"。
  2. Agent在Canvas中渲染一张水循环示意图，标注出水循环的各个阶段。
water_cycle.png

内存与上下文管理

我觉得openclaw默认的记忆系统很烂。

OpenClaw的内存系统（src/memory/）采用分层记忆，具体表现为：

  • 工作记忆（Working Memory）：当前对话的完整历史。
  • 短期记忆（Short-term Memory）：最近N轮对话的摘要。
  • 长期记忆（Long-term Memory）：通过嵌入向量（Embeddings）存储的关键信息，支持语义搜索。

OpenClaw使用本地嵌入模型（如all-MiniLM）把消息转换为向量，存储在本地向量数据库。当用户提问时，系统会检索相关的历史记忆，注入到当前上下文中。当对话过长时，OpenClaw会触发compaction，把旧消息总结为摘要，释放token空间。这不是简单的截断，而是语义压缩——确保关键信息不会丢失。

对AI应用开发者的启发

OpenClaw的成功不是偶然，它代表了一种**AI原生应用（AI-Native Apps）**的设计范式。对于开发者来说，有几个关键启示：

"Gateway + Node"架构：从单体到分布式

传统的AI应用往往是单体架构——前端、后端、AI逻辑都耦合在一起。OpenClaw展示了另一种可能：Gateway作为控制平面，各种Node作为能力提供方。

这种架构的优势：

  • 跨平台：同一套Gateway可以服务Web、移动端、桌面端。
  • 可扩展：新增设备类型只需要实现Node协议，不需要修改Gateway。
  • 容错：单个Node断开不影响整体服务。
  • 本地优先：敏感操作可以在本地Node执行，不需要上传到云端。

对于开发者来说，这意味着：不要把所有逻辑都放在服务器上，让客户端也成为智能的参与者。

协议优先：TypeBox与Schema驱动开发

OpenClaw使用TypeBox定义所有协议 schema，这是值得借鉴的实践：

  • 类型安全：TypeScript类型和JSON Schema同源，避免"类型漂移"。
  • 代码生成：从Schema生成Swift、Kotlin模型，确保跨平台一致性。
  • 文档即代码：Schema就是最好的API文档。

在AI应用中，协议往往比实现更重要——因为你可能有多个客户端（Web、iOS、Android、桌面）在和同一个后端通信。一个严谨的协议可以避免大量的bug和沟通成本。

渐进式权限：在安全与便利间找平衡

OpenClaw的安全模型体现了渐进式权限的思想：

  • 默认安全：DM配对、执行审批、沙箱隔离，默认都是开启的。
  • 用户选择：用户可以选择放宽限制（比如设置dmPolicy: "open"），但需要显式配置。
  • 上下文感知：主会话（私聊）可以比群组会话拥有更高权限，因为"一对一"的信任度通常更高。

对于AI应用开发者，这是一个重要教训：不要假设用户知道安全风险，用默认配置保护他们，同时给高级用户选择权。

多模态不是"锦上添花"，而是"核心能力"

OpenClaw把语音、图像、浏览器、Canvas都作为一等公民对待，而不是"附加功能"。这反映了AI应用的一个趋势：多模态不是可选功能，而是基础能力。

用户不会说"打开语音模式"或"切换到视觉模式"——他们只会自然地说话、拍照、指屏幕。AI应用需要无缝地理解这些输入，而不需要用户切换"模式"。

愿景

OpenClaw是一个令人印象深刻的项目，但它也揭示了AI助手领域的早期状态：

  • 配置复杂性：安装OpenClaw需要Node.js、配置API密钥、配对设备、设置频道——这对普通用户来说门槛太高。
  • 稳定性挑战：作为一个快速发展的开源项目，Breaking Change频繁，文档有时滞后于代码。
  • 生态成熟度：虽然Skills系统有潜力，但目前可用的第三方Skills还很少。
  • 安全不可控：目前已经发生多起因openClaw权限过高造成个人财产损失的案例，各类注入攻击也屡见不鲜。

但这些问题都是可以解决的。回顾智能手机的发展：iPhone在2007年发布时也没有App Store、没有3G、不能复制粘贴——但它定义了方向。OpenClaw可能正在做类似的事情：定义AI原生应用的架构范式。一个开放的、可扩展的、本地优先的、多模态的AI助手，渗透在数字生活的每个角落，但又牢牢掌控在用户自己手中。

这或许就是AI的"个人计算机时刻"——从大型机（云端AI）到个人电脑（本地AI），从分时租赁（API调用）到完全拥有（开源自托管）。OpenClaw不是终点，但它可能是这个转折点的重要标志。

参考资料：