别只盯着源码！一张图带你拆解 OpenClaw 的 Agent 架构全貌

2026年4月17日 · 2835 字 · 6 分钟 · OpenClaw AI Agent 技术架构 开源项目 TypeScript Node.js

OpenClaw拆解 封面

很多人第一次看到 OpenClaw，会以为它只是一个 AI 聊天工具。

但如果你顺着它的 README、docs 和扩展目录往下看，会发现它根本不是一个“聊天壳”。

它更像一个本地优先的 AI 助手平台。

一边接消息渠道，一边跑 Agent，一边调工具，还能把 Web、桌面端、移动端 and 设备节点都接进来。

所以理解 OpenClaw，关键不是记住多少功能，而是先看清它到底由哪些模块组成。

这篇我就不做过深源码分析，只做一件事：

把 OpenClaw 按**“模块职责”和“技术栈”**两条线拆开，帮你快速建立整体认知。

一句话看懂 OpenClaw

如果只用一句话概括：

OpenClaw = Agent Runtime + Gateway 控制平面 + 工具系统 + 多消息渠道 + 多端节点能力。

它的重点不是某一个单独功能，而是把这些能力放在同一个系统里统一调度。

也就是说，OpenClaw 想做的不是“再造一个聊天窗口”，而是做一个真正能接入环境、调用工具、连接设备、长期运行的个人 AI 助手底座。

核心模块：拆开看看有哪些

下面这几个模块，基本可以覆盖你理解 OpenClaw 的主干。

Gateway：整个系统的中枢

这是 OpenClaw 最核心的模块。

它本质上是一个常驻守护进程，负责把客户端、消息渠道、节点设备、Web 界面都接进来。

你可以把它理解成 OpenClaw 的**“大脑中枢”**。

它主要做几件事：

  • 管理 WebSocket 和 HTTP 接入
  • 负责请求转发和事件推送
  • 管理连接状态、鉴权、配对和心跳
  • 承接 Agent 请求、工具调用和系统事件

为什么这个模块重要？

因为 OpenClaw 不是每个入口各自跑一套逻辑，而是把控制权收敛到 Gateway 上。这样不管 you 从 Web、CLI、消息渠道还是设备节点进入，最后都会回到同一个控制面。

Agent Runtime：真正的执行层

如果 Gateway 是中枢，那 Agent Runtime 就是执行层。

它负责接收消息、组装上下文、调用模型、调工具、维护 session，并把结果返回出去。

这个模块决定了 OpenClaw 不只是“能聊天”，而是**“能完成任务”**。

它关心的事情包括：

  • 当前会话上下文怎么组织
  • memory 和历史记录怎么召回
  • 哪些工具可以调用
  • 多个 agent 怎么协作 or 路由
  • 不同 workspace 的 prompt 和规则怎么注入

简单说，Agent Runtime 解决的是**“AI 怎么真正跑起来”**。

Tools：OpenClaw 的能力总线

很多项目会把工具调用做成附属能力，但 OpenClaw 明显把 Tools 当成一等公民。

从文档里能看到，它内置了不少核心工具，比如：

  • exec / read / write / edit
  • browser / canvas / cron
  • message / memory_* / sessions_*

这说明它的设计方向很明确：

不是让 Agent 只能“说”，而是让 Agent 可以通过标准化工具去“做”。

更重要的是，这些工具不是野生调用，而是带 schema、权限控制和策略配置的。

这也是 OpenClaw 跟很多 demo 级 Agent 项目拉开差距的地方。

Messaging：多平台统一接入

这是 OpenClaw 很有辨识度的一层。

它不是只做 Web Chat，而是接入了大量消息平台，比如：

  • WhatsApp / Telegram / Slack / Discord
  • 飞书 / 钉钉 / 企业微信 / WeChat

你可以把这一层理解成“消息适配器”。

不同平台的协议、鉴权、线程机制、附件格式都不一样，但 OpenClaw 试图把它们统一抽象成可收发消息的 surface。

这样做的价值很大：

同一个 AI 助手，不必被锁在某个单一界面里，而是可以直接进入你已经在使用的沟通渠道。

Extensions：从产品进化为平台

如果只看核心能力，OpenClaw 已经不小了。

但它真正的扩展性，来自插件和扩展系统。

从仓库结构就能看出来，extensions/* 是一等工作区成员，这意味着扩展不是外挂脚本，而是正式架构的一部分。

插件大致可以扩什么？

  • 新消息渠道 / 新工具
  • Gateway 路由和 HTTP 接口
  • CLI 命令 / 认证能力
  • 后台服务 / memory 后端

这背后其实是一个很重要的信号：

OpenClaw 不是把功能越做越重，而是在做“平台化能力沉淀”。

核心负责调度，扩展负责生长。

Memory：让 AI 具备长期记忆

如果一个 Agent 系统只有即时回复，那它更像聊天机器人。

OpenClaw 明显在往“持续使用”方向走，所以 session 和 memory 是单独成层的。

它解决的是这些问题：

  • 会话历史管理与上下文压缩
  • 长期记忆检索与知识沉淀
  • Workspace 级别的记忆隔离

从扩展目录看，还支持像 LanceDB 这样的长期记忆后端。

这意味着它不是只关注“这一轮说什么”，而是在考虑**“这个助手怎么长期连续工作”**。

Nodes：连接真实设备能力

这是 OpenClaw 跟很多纯软件 Agent 项目很不一样的地方。

它不只连接消息渠道，还连接设备节点。

比如：

  • macOS / iOS / Android
  • Headless Node Host

而且这些节点不是简单展示界面，而是可以暴露设备能力，比如：

  • 相机 / 屏幕 / 定位
  • Canvas / 系统通知

换句话说，OpenClaw 想把真实设备也纳入 Agent 的可调用边界。

这会让它从“软件里的 AI”进一步走向**“环境中的 AI”**。

UI & CLI：多入口共用底座

OpenClaw 还有几个很关键的表层入口：

  • CLI 命令行
  • WebChat / Control UI
  • Canvas 可视化层

这些入口看起来不同，但它们背后并不是各自独立的一套系统，而是共用 Gateway 和 Agent Runtime。

这也是为什么 OpenClaw 会给人一种“不是工具堆砌，而是系统工程”的感觉。

表面很多，底层很收敛。

工程视角：OpenClaw 的 5 层架构

理解完模块之后，再往上抽一层，其实会更清楚。

我会把 OpenClaw 粗略分成 5 层：

1. 核心运行层 (Runtime)

  • Gateway / Agent Runtime / Session / Tools Runtime
  • 负责调度、执行和上下文管理。

2. 接入层 (Access)

  • CLI / WebChat / Messaging Channels / API
  • 解决“从哪里进来”的问题。

3. 设备层 (Devices)

  • macOS / iOS / Android / Node Host
  • 解决“能连接哪些真实终端”的问题。

4. 扩展层 (Ecosystem)

  • Extensions / Plugins / Skills / Memory backends
  • 决定了它是不是一个可持续扩展的平台。

5. 基础设施层 (Infra)

  • Schema / Build / Test / Lint / Packaging
  • 决定了项目是否能长期维护和工程化。

技术栈：不只是 TypeScript

很多人看到这类项目，第一反应会是：哦，一个 Node.js 项目。

但 OpenClaw 其实是一个跨端系统工程，主技术栈虽然是 TypeScript + Node.js，但外围远不止这些。

核心语言与运行时

  • TypeScript + Node.js + ESM
  • 承接了 Gateway、CLI、Agent Runtime 和大部分插件系统。

协议与类型系统

  • WebSocket / HTTP / TypeBox / JSON Schema
  • 重点在于把协议、配置和工具输入输出都类型化，这对大型 Agent 系统至关重要。

Monorepo 组织方式

  • pnpm workspace
  • 核心模块、前端、扩展一起协同开发，架构更像平台而非单应用。

前端与交互层

  • Vite + React (WebChat / Control UI / Canvas)
  • 前端是独立工作区，作为正式的交互层而非附属页面。

跨端技术栈

  • Swift (macOS / iOS)
  • Kotlin + Gradle (Android)
  • 这是一个真正的 Node.js + Swift + Kotlin 跨端项目。

增强能力

  • LanceDB (长期记忆) / OpenTelemetry (可观测性) / node-llama-cpp (本地模型)
  • 补齐了长期记忆、监控诊断和本地推理能力。

工程质量工具

  • Vitest / oxlint / oxfmt / swiftlint / knip
  • 说明项目已经开始认真处理多端代码质量和工程化问题。

一张表看懂 OpenClaw

维度关键信息
项目定位本地优先的个人 AI 助手平台
核心中枢Gateway & Agent Runtime
关键能力Tools、Session、Memory
外部接入消息渠道、Web、CLI、设备节点
技术栈TS/Node + Swift + Kotlin
工程组织pnpm workspace (Monorepo)
延展能力LanceDB、OTel、本地模型、Canvas

一灯短评

很多人看 AI Agent 项目，容易只盯着模型层。

但像 OpenClaw 这种项目，真正值得看的，往往不是“它接了哪个模型”，而是它怎么把这些能力组织成一个能长期运行的系统。

本质上，OpenClaw 做的不是一个功能点，而是一套 Agent 基础设施。

如果你是开发者，想研究本地优先 Agent、消息接入型 AI 助手、或者可扩展的多端 Agent 架构，OpenClaw 是很值得拆的项目。

因为它提供的不是一个小技巧，而是一整套系统化思路。

公众号二维码

如果你也在关注 AI Agent、开源项目拆解、自动化工作流和开发者效率工具，欢迎关注我。

后面我会继续用这种“先讲清结构，再讲清价值”的方式，拆更多值得研究的项目。