扒开龙虾源码：OpenClaw 架构与设计拆解读后

OpenClaw 在 GitHub 上星星数已经超过 Linux 和 React，登顶全球榜首，火得不行。能火成这样，跟它的多终端、多 IM 适配能力和「自我进化」那一套分不开——钉钉、飞书、QQ、Teams、Slack、Telegram 都能接，以后这种「一个 AI 多端同服」的模式大概率会成为助手类 Agent 的标配。我啃了一篇万字拆解文，把架构里最关键的几块：终端接入、分层、连接方式、插件抽象、Gateway、消息路由、三种 Agent 模式、Skills 加载，按自己的理解整理成这篇读后，只比原文长不短，配图用原文的。

一、终端与 IM 接入：Any OS, Any Platform

OpenClaw 的设计理念是「Any OS. Any Platform.」——跨设备、跨平台接同一个 AI。实现上靠伴侣应用（Companion Apps）和节点（Nodes）：设备节点管硬件终端，IM 通道管通信平台。核心内置了 8 个高频 IM：Telegram、WhatsApp、Discord、IRC、Google Chat、Slack、Signal、iMessage；扩展层通过插件又接了 50+ 通道，包括 Teams、Mattermost、国内飞书等。所以你用 QQ 还是飞书，本质都是「一个网关 + 多路 IM 插件」，消息进来先到网关，再路由到 Agent 和 Skills。

二、分层架构与连接方式

架构上分层很清晰：最上层是各 IM 的适配器，中间是网关（Gateway），下面是 Agent 和模型调用。连接方式常见三种：WebSocket + 长轮询（Polling）、WebHook（被动推送）、以及 CLI 等。WebSocket 实时性好，但要维持连接；WebHook 省资源，依赖对方服务器回调；CLI 适合本地调试。原文对每种利弊都有展开，选型时看你是要实时性还是省事、有没有公网回调条件。

三、插件的标准抽象与注册

各 IM 接入方式不一，所以需要统一的插件接口：你实现一套标准抽象，网关只认这一套，具体是 QQ 还是飞书由插件内部适配。这样加新通道就只加插件，不用改网关核心。接口会约定消息入参/出参、鉴权方式、可选能力（如文件、富文本），插件注册进网关后，网关按配置加载。原文里有代码示例，核心就是「统一接口 + 插件注册表」。

四、Gateway 与消息路由

Gateway 负责鉴权、会话、把消息从 IM 转到 Agent 再往回写。消息路由的核心是 Session Key：同一会话（比如同一个 QQ 私聊）用同一个 key，这样多轮对话、记忆、上下文都绑在这条会话上。私聊（DM）的路由策略原文里有配置示例，一般是按 channel + user 或 thread 生成 key。实际代码里会看到 Gateway 读配置、解析消息来源、决定往哪个 Agent 丢、再根据 Session 做缓存和续写。

五、三种 Agent 运行模式

Agent 怎么跑有三种：Embedded PI（内嵌代理，最常用）、CLI Agent（本地 Claude CLI）、ACP（Agent Control Plane，远程代理）。Embedded 就是和你当前进程跑在一起，延迟低、调试方便；CLI 是调起本地 Claude 命令行；ACP 是连到远程的 Agent 服务，适合多机部署。实际执行时会按配置或策略选一种，原文里有选择逻辑的说明。日常用 OpenClaw 养 QQ 机器人，多半是 Embedded 模式。

六、Skills 的加载与管理

Skills 从哪来、怎么加载、按什么优先级，原文拆得很细。Skills 有固定结构目录和定义格式（如 SKILL.md），网关会做 Eligibility Check（资格检查）：当前会话/任务是否需要这个 skill，需要再加载，避免一股脑全上。加载条件按优先级来，还支持 skillFilter 手动指定；Session 会做缓存，识别出需求后再渐进式加载。这样既保证「能干活的都有」，又不会每次请求都背一堆用不到的 skill。机制总结一下就是：按需、分层、可配。

# 配置里指定 skillFilter 示例（以官方文档为准）
# skillFilter: ["coding", "fs"]

整篇万字拆解看下来，OpenClaw 能火的核心就是：多端统一接入、分层清晰、插件化扩展、会话与 Skills 按需加载。想深挖的可以直接翻原文「吃龙虾咯！万字拆解 OpenClaw 的架构与设计」，照着目录把终端、分层、连接方式、插件、Gateway、路由、Agent 模式、Skills 几块顺一遍，比只看博客摘要强很多。