夜雨聆风一张图看懂你的小龙虾🦞：OpenClaw这个AI助手系统是怎么设计的？
OpenClaw 🦞 入门 3 · 架构全景，从宏观到微观理解系统
前两篇聊了OpenClaw是什么、为什么选自托管。这篇我们来点硬核的——拆解它的架构设计。
理解架构不是为了背概念，而是为了知道：当你配置某个功能时，你知道它在系统的哪个位置，出了问题该去哪里排查。
极简解释 -- 12岁小孩也能懂
你在微信发了一条消息，几秒后 AI 回复了。 这几秒里，系统做了什么？
理解架构，是为了出现问题时知道去哪找。
架构链路
你（微信 / 飞书 / Discord） ↓Gateway —— 统一接入，识别平台 ↓Agent —— 采集干活，调用工具 ↓Provider —— AI 大脑（GPT / Claude / Gemini）四个角色
Gateway · 前台
接收各种平台的消息，统一整理后送交给哪个 Agent 处理。它把回复送回对应渠道。它内用 WebSocket 保持实时连接——不是“客户端一直问有没有消息”，而是“有消息主动推过来”。
Agent · 干活的人
拿到任务后，反应是「嗯 → 盘一盘 → 再想」的循环，直到任务完成。它可以调用搜索、浏览器、代码执行等工具，也记得你们之前聊过什么。
Channel · 翻译
微信有微信的格式，Discord 有 Discord 的格式，Channel 把它们都翻译成系统内部统一的样子，Agent 就不用管消息从哪个 app 来的了。
Provider · AI 的脑子
Agent 本身不会思考，它调用 GPT、Claude、Gemini 这类模型。换哪个模型，改配置就行，其他不动。
只有一个配置文件
所有设置都在 openclaw.json 里：Gateway 监听哪个端口、飞书的 Key 是什么、用哪个 AI 模型、消息默认发给哪个 Agent、改配置就是在调整这张图里的某一块。
出问题去哪找
• 收不到消息 → Channel 配置、Webhook、Token • 收到消息没回复 → Gateway 超时重连、Agent 状态 • 回复很慢 → Provider 网络或模型响应 • 多轮对话断掉 → 会话管理或上下文长度 • 工具调用失败 → 工具配置、权限、超时
技术解释 -- 先上一张总览图
如果把OpenClaw比作一个餐厅，它的架构大概长这样：
┌─────────────────────────────────────┐ │ 顾客（你） │ │ 微信/飞书/Discord/iMessage/... │ └─────────────┬───────────────────────┘ │ 发消息 ▼┌─────────────────────────────────────────────────────────────────────┐│ 前台（Gateway） ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ 渠道接入 │ │ 消息路由 │ │ 会话管理 │ ││ │ (Channel) │ │ (Routing) │ │ (Session) │ ││ └──────────────┘ └──────────────┘ └──────────────┘ │└──────────────────────────────────┬──────────────────────────────────┘ │ 分发任务 ▼┌─────────────────────────────────────────────────────────────────────┐│ 后厨（Agent） ││ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ││ │ 大脑思考 │ │ 工具使用 │ │ 记忆存储 │ ││ │ (LLM推理) │ │ (Tools) │ │ (Memory) │ ││ └──────────────┘ └──────────────┘ └──────────────┘ │└──────────────────────────────────┬──────────────────────────────────┘ │ 调用 ▼┌─────────────────────────────────────────────────────────────────────┐│ 食材供应商（Providers） ││ OpenAI Claude Gemini Deepseek Ollama ... │└─────────────────────────────────────────────────────────────────────┘这个比喻不太严谨，但能帮你快速建立直觉。下面我们来正经拆解。
四大核心组件
OpenClaw的架构可以抽象为四个核心组件：
1. Gateway（网关）——系统的入口
Gateway是做什么的？
想象你是一个客服主管，手下有20多个渠道（微信、飞书、Discord、邮件...），每个渠道都有客户在发消息。Gateway就是那个统一的接待台——它接收所有渠道的消息，决定消息该交给哪个Agent处理，再把回复送回对应的渠道。
Gateway的核心职责：
channels | ||
routing | ||
auth | ||
关键概念：WebSocket控制平面
Gateway内部有一个WebSocket服务器，这是整个系统的中枢神经。简单说，WebSocket让Gateway能实时推送消息，而不是让客户端一直轮询"有没有新消息"。所有渠道连接、Agent连接、状态同步，都通过这个通道进行。
2. Agent（代理）——AI的大脑
Agent是做什么的？
如果说Gateway是接待台，Agent就是实际干活的员工。它接收Gateway分派过来的任务，调用AI模型进行推理，决定用什么工具、怎么回复。
Agent的核心循环（Agent Loop）：
Agent接到任务后，会不断重复这个思考-行动循环，直到任务完成：
1. 观察：看当前有什么信息（用户消息、工具结果） 2. 思考：分析需要做什么，要不要用工具 3. 行动：调用工具或生成回复 4. 判断：任务完成了吗？没完成就继续循环
这就像你接到一个复杂任务时，会先想想怎么做，然后动手做，看看效果，不行再调整，直到做完为止。
Agent的核心模块：
3. Channel（渠道）——连接器
Channel是做什么的？
Channel是Gateway和外部通讯平台之间的适配器。每个平台（微信、飞书、Discord等）都有自己的协议和数据格式，Channel负责把这些转换成OpenClaw内部的标准格式。
Channel的两面：
外部平台协议 ←→ Channel适配器 ←→ OpenClaw内部标准格式 (WhatsApp) (whatsapp-channel) (统一消息对象) (Discord) (discord-channel) (统一消息对象) (Feishu) (feishu-channel) (统一消息对象)支持的渠道（部分）：
4. Provider（模型提供商）——AI能力源
Provider是做什么的？
Agent需要调用AI模型进行推理，Provider就是连接各种AI模型的接口。OpenClaw不绑定任何特定模型，你可以自由切换。
支持的Provider（部分）：
数据流向：一条消息的生命周期
理解了四大组件，我们来看一条消息从发送到回复的完整旅程：
阶段1：消息进入（Channel → Gateway）
1. 用户在飞书发送消息："帮我查一下今天的AI新闻" 2. 飞书服务器推送消息到OpenClaw的飞书Channel 3. Channel把飞书格式转换成OpenClaw标准消息格式 4. Gateway接收消息，创建/继续会话
阶段2：任务分发（Gateway → Agent）
5. Gateway根据路由规则，决定把这个消息发给哪个Agent 6. Gateway通过WebSocket把任务推送给Agent 7. Agent接收任务，开始处理
阶段3：AI处理（Agent → Provider → Agent）
8. Agent把消息历史发送给配置的AI模型（如GPT-4） 9. 模型返回思考结果："用户要查AI新闻，我应该用搜索工具" 10. Agent调用搜索工具，获取结果 11. 模型基于搜索结果生成回复
阶段4：回复返回（Agent → Gateway → Channel）
12. Agent把最终回复发给Gateway 13. Gateway找到对应的会话和渠道 14. Gateway通过飞书Channel发送回复 15. 用户在飞书看到回复
整个过程通常在几秒内完成。
扩展性设计：Plugin系统
除了四大核心组件，OpenClaw还有一个重要的设计——Plugin（插件）系统。
三种类型的插件：
配置入口：openclaw.json
所有架构组件的配置都集中在 openclaw.json 文件中：
{ "gateway": { "port": 8080, "auth": { "token": "xxx" } }, "channels": { "feishu": { "appId": "xxx", "appSecret": "xxx" }, "discord": { "botToken": "xxx" } }, "providers": { "openai": { "apiKey": "sk-xxx" } }, "agents": { "main": { "model": "openai/gpt-4", "tools": ["search", "browser"] } }, "routing": { "defaultAgent": "main" }}理解架构有助于理解配置：
• gateway部分控制Gateway行为• channels配置各个渠道接入• providers配置AI模型• agents定义Agent行为• routing设置消息路由规则
故障排查思路
理解架构后，排查问题的思路会更清晰：
总结
OpenClaw的架构设计遵循几个核心原则：
1. 网关模式：统一入口，隔离外部复杂性 2. 插件化：核心精简，能力通过插件扩展 3. 多模型：不绑定单一AI，自由选择 4. 多渠道：同时接入多个平台，统一管理 5. 自托管：数据和控制权在用户手中
理解这个架构，你就掌握了OpenClaw的"地图"——知道每个功能在哪个位置，如何相互协作，出了问题去哪里找。
参考链接：
• OpenClaw架构文档：https://docs.openclaw.ai/concepts/architecture.html • Gateway配置指南：https://docs.openclaw.ai/gateway/configuration.html • Plugin开发文档：https://docs.openclaw.ai/plugins/development.html
