搜索文章、关键词... ⌘K
AI工程 2026-04-29 0 阅读 8 分钟
#OpenClaw#Agent#AI Gateway#架构设计#自动化

OpenClaw 整体架构：为什么它不是普通 Bot

OpenClaw 表面上像一个聊天机器人，底层却更接近一个本地优先的多渠道 Agent Gateway。本文从架构角度拆解它和普通 Bot 的根本区别。

最近在研究 OpenClaw。刚开始看，它很容易被误解成“一个可以接入 WhatsApp、Telegram、Slack、Discord、飞书、iMessage 的聊天机器人”。

但如果只把它理解成 Bot，其实会漏掉它最有价值的地方。

OpenClaw 更准确的定位是：一个本地优先、多渠道接入、可扩展工具调用、支持会话隔离和自动化任务的 Agent Gateway。

换句话说，它不是“用户发一句，模型回一句”的普通聊天机器人，而是一个可以长期运行在你自己机器上的 AI 操作入口。

普通 Bot 解决的是“怎么回复消息”；OpenClaw 解决的是“怎么让 AI 安全、持续、可控地接入真实世界”。

系列阅读顺序

这篇是 OpenClaw 系列的第一篇，重点放在整体架构和心智模型。后面两篇会继续拆：

  1. Gateway 架构：一个本地控制平面如何接管多渠道
  2. Agent Loop 原理拆解：一次消息如何变成模型调用和工具调用

一、普通 Bot 的典型结构

传统 Bot 的结构通常比较简单：

用户消息
  ↓
平台 Webhook
  ↓
Bot 服务
  ↓
调用模型或业务接口
  ↓
返回消息

比如你写一个企业微信 Bot、Telegram Bot、飞书 Bot，大部分时候是在做三件事：

  1. 接收平台消息；
  2. 根据消息内容调用模型或接口；
  3. 把结果发回去。

这种模式适合简单问答、通知提醒、菜单交互、固定流程自动化。

但它有几个明显限制：

  • 每个平台都要单独接入；
  • 会话上下文容易混乱；
  • 工具权限和执行边界不清晰；
  • 并发消息容易互相干扰；
  • 很难把“聊天入口”扩展成“真实操作入口”；
  • 很多 Bot 没有长期记忆、任务队列、沙箱、安全策略这些基础设施。

所以普通 Bot 更像一个“消息响应器”。

它可以接话，但不一定能稳定做事。

二、OpenClaw 的核心不是 Bot，而是 Gateway

OpenClaw 官方文档里对 Gateway 的定位很清楚：Gateway 是 OpenClaw 的 WebSocket server，负责 channels、nodes、sessions、hooks 等能力。也就是说，它不是某一个聊天平台的适配器，而是整个系统的控制平面。(GitHub)

这就是 OpenClaw 和普通 Bot 的第一个根本区别。

普通 Bot 通常是：

一个平台 = 一个 Bot 服务

OpenClaw 更像是：

多个平台
  ↓
统一 Gateway
  ↓
统一 Agent Runtime
  ↓
统一工具、会话、安全、插件、自动化能力

可以把它理解成一个“AI 助手的中控台”。

Telegram、WhatsApp、Slack、Discord、iMessage、飞书这些只是入口。真正的核心在 Gateway 后面：Agent 如何运行、上下文如何组装、工具如何调用、消息如何排队、session 如何隔离、权限如何控制。

这套设计的重点不是“支持多少聊天软件”，而是把不同入口统一到同一套 Agent 执行体系里。

三、一条消息在 OpenClaw 里不是简单问答

普通 Bot 收到消息后，可能直接调用一次 LLM，然后返回结果。

OpenClaw 的 Agent Loop 要复杂得多。

官方文档把 Agent Loop 定义为一次完整的 agentic run：intake、context assembly、model inference、tool execution、streaming replies、persistence。也就是从接收输入、组装上下文、模型推理、执行工具、流式回复，到最终持久化，形成一条完整链路。(OpenClaw)

可以简化成这样：

用户消息
  ↓
Channel 接收
  ↓
Gateway 路由
  ↓
解析 session
  ↓
加载上下文、skills、配置
  ↓
调用模型
  ↓
模型决定是否调用工具
  ↓
执行工具
  ↓
流式返回
  ↓
写入会话记录

这里有一个关键点：模型不是简单生成一段文本，而是在一个可控循环里推理、调用工具、接收结果、继续推理。

这也是 Agent 和普通 Chatbot 的区别。

普通 Chatbot 的目标是“回答”；Agent 的目标是“完成任务”。

四、OpenClaw 把多渠道消息统一成 Agent 输入

OpenClaw 的核心概念里，包含 Gateway、Agents、Sessions、Memory、Channels。文档中的简化流程是：User Message → Channel → Gateway → Agent → Model → Response。(openclaw.cc)

这个流程表面看和 Bot 类似，但重点在于抽象层级不一样。

普通 Bot 经常把“渠道逻辑”和“业务逻辑”混在一起：

Telegram 消息怎么解析
Slack 消息怎么解析
飞书消息怎么解析
每个平台各写一套

OpenClaw 更倾向于把渠道变成适配层：

Telegram / WhatsApp / Slack / Discord / Feishu / iMessage
  ↓
统一消息协议
  ↓
Gateway
  ↓
Agent

这带来的好处是：

  • 同一个 Agent 可以服务多个入口；
  • 同一套工具能力可以被多个渠道复用；
  • 同一套 session / memory / queue 机制可以统一管理；
  • 后续新增渠道时，不需要重写 Agent 主逻辑。

这就是平台型设计和脚本型 Bot 的区别。

脚本型 Bot 是“一个场景写一段逻辑”。

平台型 Agent Gateway 是“先把入口、执行、上下文、工具、安全都抽象出来，再让不同场景复用”。

五、Session 是 OpenClaw 的关键设计

很多人做 Bot 时，会低估 session 的复杂度。

简单问答时，session 似乎只是聊天记录。但一旦 Agent 能调用工具、读文件、发消息、执行命令，session 就不只是上下文了，它还关系到：

  • 当前是谁在说话；
  • 这个消息来自哪个渠道；
  • 是私聊还是群聊；
  • 是否绑定到某个 workspace；
  • 是否允许访问某些工具；
  • 之前执行过什么任务；
  • 当前有没有正在运行的任务。

OpenClaw 的 Agent Loop 文档强调，loop 是每个 session 内独立且序列化的 run，用来保持 session state 一致。(OpenClaw)

这点非常重要。

如果同一个会话里同时跑多个 Agent 任务，可能出现这些问题：

用户：帮我总结这个文件
用户：顺便把结果发给张三

如果两条消息并发处理，第二条可能在第一条总结完成前就开始执行，Agent 不知道“结果”指的是什么。

所以 Agent 系统不能简单地“来了消息就并发跑”。

它需要 session 级别的串行控制。

这也是 OpenClaw 比普通 Bot 更工程化的地方。

六、Command Queue 解决连续消息和并发问题

OpenClaw Agent Loop 的说明里提到，runEmbeddedPiAgent 会通过 per-session 和 global queues 对 run 进行序列化。(OpenClaw)

这说明 OpenClaw 没有把并发问题留给模型自己解决，而是在工程层面做了队列控制。

可以理解为两层队列：

Session Queue：保证同一个会话内任务有序
Global Queue：控制整个 Gateway 的任务并发

为什么这很重要？

因为真实聊天环境里，用户不会像 API 调用那样严格等待。用户可能连续发三句话：

帮我查一下今天销售额
按品牌拆一下
再发到群里

这三句话对用户来说是一个连续意图，但对系统来说是三条独立消息。

普通 Bot 很可能三条消息分别触发三次模型调用，结果上下文错乱。

Agent Gateway 必须识别：哪些消息要合并，哪些消息要排队，哪些消息要打断，哪些消息要作为 follow-up。

所以 Command Queue 不是锦上添花，而是 Agent 系统走向真实使用场景的基础设施。

七、Tools 让 OpenClaw 不只是“会说话”

如果一个系统只能调用 LLM，那它最多是一个聊天助手。

OpenClaw 真正变成 Agent 的关键，是工具系统。

工具让模型可以做事，比如：

  • 浏览网页；
  • 读取文件；
  • 发送消息；
  • 调用外部接口；
  • 操作浏览器；
  • 执行命令；
  • 创建定时任务；
  • 查询历史会话；
  • 调用 MCP 服务。

这类能力一旦接入，系统的性质就变了。

它不再是：

输入文本 → 输出文本

而是：

输入任务 → 推理计划 → 调用工具 → 观察结果 → 继续执行 → 返回结果

这也是为什么 OpenClaw 不能只按 Bot 来理解。

Bot 的主要能力是“回复”。

Agent 的主要能力是“行动”。

八、Skills 负责教 Agent 怎么用能力

OpenClaw 还有一个值得单独研究的点：Skills。

工具本身只描述“能做什么”，但并不一定告诉模型“什么时候该用、怎么用、有哪些约束”。

Skills 更像是给 Agent 的操作手册。

比如同样有一个浏览器工具，模型需要知道：

  • 什么场景应该搜索；
  • 搜索后如何筛选信息；
  • 什么时候需要引用来源；
  • 页面打不开时如何降级；
  • 不应该访问哪些敏感内容。

这类内容不适合全部写死在核心系统 prompt 里，也不适合散落在业务代码中。

所以 Skills 的价值在于：把某类能力的使用方法模块化、可维护化。

对我们做企业内部 AI 能力平台也很有参考价值。

在企业场景里，一个“查询销售数据”的工具只是函数；但“如何判断销售异常”“如何解释 GMV 波动”“如何按运营口径输出结论”，这些更像 Skill。

九、Plugins 让 OpenClaw 可以持续扩展

从仓库结构看，OpenClaw 有大量 extension，包括模型提供商、渠道、浏览器、记忆、语音、媒体、诊断等不同能力模块。GitHub 仓库的 extensions/ 目录承载了这些插件式能力。(GitHub)

这说明 OpenClaw 不是把所有能力硬编码在核心里，而是采用插件化扩展。

插件化的好处是：

  • 核心系统保持稳定；
  • 新渠道可以独立扩展；
  • 新模型可以独立接入；
  • 工具能力可以按需安装；
  • 第三方生态有扩展空间；
  • 不同部署可以按需裁剪能力。

这对 AI Agent 系统非常关键。

因为 Agent 的能力边界变化太快了。今天接 OpenAI，明天接 Claude，后天接 Qwen、DeepSeek、本地模型；今天接 Telegram，明天接飞书、Slack、企业微信；今天需要浏览器，明天需要数据库、BI、CRM、ERP。

如果没有插件化，核心代码会很快变成一团乱麻。

十、安全边界是 OpenClaw 的硬问题

OpenClaw 不是普通 Bot 的另一个原因，是它涉及真实操作权限。

普通 Bot 即使出错，可能只是回复错一句话。

但 Agent 如果有工具权限，出错的后果可能是：

  • 读错文件；
  • 发错消息；
  • 执行危险命令；
  • 泄露敏感信息；
  • 被陌生人通过私聊诱导执行操作。

OpenClaw README 明确提醒：真实消息入口要视为不可信输入；默认情况下，Telegram、WhatsApp、Signal、iMessage、Microsoft Teams、Discord、Google Chat、Slack 等入口的未知私聊发送者会进入 pairing 流程，bot 不会直接处理其消息。(GitHub)

这说明 OpenClaw 把“谁可以跟 Agent 说话”当成系统安全的一部分。

这点非常重要。

很多人做 AI Bot 时，只关注模型效果，但真正上线后，第一优先级应该是：

谁能触发 Agent？
Agent 能做什么？
哪些工具需要审批？
哪些消息必须拒绝？
出了问题如何追踪？

Agent 越强，安全边界越重要。

十一、OpenClaw 的本地优先不是口号

OpenClaw 的一个核心原则是 local-first。文档里也提到，它强调本地运行、隐私优先、可扩展、多平台。(openclaw.cc)

这和很多 SaaS Bot 平台不一样。

SaaS Bot 的典型逻辑是：

你的消息
  ↓
平台服务器
  ↓
第三方 Bot 服务
  ↓
模型 API
  ↓
返回结果

OpenClaw 的思路更像：

你的消息入口
  ↓
你自己的 Gateway
  ↓
你自己配置的模型和工具
  ↓
你自己控制的数据和执行环境

这带来的价值是：

  • 数据更可控；
  • 工具权限更可控；
  • 部署方式更灵活；
  • 可以接入本地文件、本地应用、本地浏览器；
  • 更适合个人长期助手或企业内部私有助手。

当然，这也意味着它的部署、配置、安全要求更高。

所以 OpenClaw 不是一个“开箱即用的玩具 Bot”，而是一个偏工程化的 Agent 基础设施。

十二、用一张图理解 OpenClaw

可以把 OpenClaw 简化成五层：

第一层：入口层
WhatsApp / Telegram / Slack / Discord / Feishu / iMessage / CLI / Webhook / Cron

第二层：Gateway 层
统一接入、认证、路由、事件、节点连接、Hook

第三层：Agent Runtime 层
Agent Loop、模型调用、上下文组装、流式输出、任务状态

第四层：能力层
Tools、Skills、Plugins、MCP、Browser、Files、Memory、Canvas

第五层：安全与状态层
Session、Queue、Sandbox、Allowlist、Pairing、Persistence、Workspace

如果是普通 Bot，通常只有：

入口层
业务逻辑
模型调用
回复

而 OpenClaw 多出来的，正是 Agent 系统真正需要的工程层：

  • Gateway；
  • Session；
  • Queue；
  • Tools；
  • Skills；
  • Plugins；
  • Security；
  • Memory；
  • Workspace；
  • Automation。

这些东西看起来不如模型本身“炫”，但决定了一个 Agent 能不能长期稳定使用。

十三、对后端研发的启发

从后端工程角度看，OpenClaw 最值得学习的不是某个具体功能，而是它的抽象方式。

1. 把入口和执行解耦

不要让 Telegram、飞书、Slack 这些渠道直接决定业务逻辑。

更合理的方式是：

渠道只负责接入
Gateway 负责统一路由
Agent Runtime 负责执行
Tools 负责具体能力

这个思路适合所有企业 AI 平台。

2. 把工具和使用说明分开

工具是函数，Skill 是说明书。

比如：

query_sales_report 是工具
“什么时候查销售额、怎么解释波动、怎么输出运营结论”是 Skill

这比把所有逻辑塞进一个大 prompt 里更可维护。

3. 把会话隔离当成基础设施

多用户、多渠道、多任务环境里，session 不能随便拼。

必须明确：

  • session key 怎么生成；
  • 私聊和群聊怎么区分；
  • 定时任务和人工对话是否共用上下文；
  • 不同 agent 是否共享 workspace；
  • 历史消息如何持久化。

这些问题不解决，Agent 越强，系统越容易乱。

4. 把队列作为 Agent 系统的默认设计

传统接口服务追求并发吞吐。

Agent 系统不能简单照搬这个思路。

因为同一个 session 下，很多消息存在上下文依赖。该串行的必须串行，该合并的要合并，该打断的要打断。

这就是 Command Queue 的价值。

5. 把安全放在架构层，而不是功能层

Agent 能调用工具后，安全就不是“后面再加”的功能。

它必须进入架构设计：

入口鉴权
发送者 allowlist
工具权限
沙箱执行
敏感操作审批
日志追踪
错误隔离

否则 Agent 的能力越强，风险越大。

十四、总结

OpenClaw 表面上像一个聊天机器人，但它的底层目标明显不是“做一个更会聊天的 Bot”。

它真正想做的是：

把多个聊天入口、多个模型、多个工具、多个 Agent、多个自动化触发器，
统一接入一个本地优先的 Gateway，
再通过会话、队列、插件、技能、安全策略，
让 AI 可以持续、可控地执行真实任务。

所以，OpenClaw 值得研究的地方不只是“它支持哪些平台”，而是它背后的架构判断：

  • 为什么需要 Gateway；
  • 为什么 Agent Loop 要序列化；
  • 为什么 session 要隔离；
  • 为什么工具要插件化；
  • 为什么 Skills 和 Tools 要分层；
  • 为什么安全策略必须默认开启；
  • 为什么本地优先适合个人 Agent 和企业内部 Agent。

如果说普通 Bot 是一个“消息自动回复器”，那么 OpenClaw 更像是一个“AI 任务执行操作系统”的雏形。

这也是它最值得学习的地方。

你可能还感兴趣