OpenClaw以独特的「小龙虾」形象和「EXFOLIATE!」口号破圈，成为2026年最值得关注的开源AI助手项目。它通过单Gateway架构实现跨IM平台的无缝对话，嵌入式Agent技术与自研系统提示词体系，为追求隐私可控的用户提供了全新的AI交互范式。本文将深度解析其技术架构与核心设计理念。

一、为什么叫「小龙虾」？为什么火？

项目名 OpenClaw 直译是「开放的爪子」—— logo 是一只 小龙虾，slogan 是 「EXFOLIATE! EXFOLIATE!」（剥壳、剥壳），和「open」谐音，又带点梗。

在 2026 年初，它之所以被频繁讨论，大致有这几类原因：

• 定位清晰：不和你抢「手机里的另一个聊天 App」，而是接进你已经在用的 IM（WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Teams、WebChat 等），你从哪个 App 发消息，助手就从哪个 App 回你。
• 本地优先：Gateway 跑在你自己的机器上（本机或你控制的服务器），会话与配置都在你手里，适合在意隐私和可控性的用户。
• 技术栈现代：TypeScript/Node 核心 + Pi 嵌入式 Agent + 多端（macOS 菜单栏、iOS/Android、Web 管理端），既有 CLI 又有图形界面，还有语音唤醒、Live Canvas 等玩法。
• 开源可扩展：MIT 协议，渠道和技能都可扩展，社区有 Discord、文档齐全，适合二次开发和学习 Agent 架构。

所以「火」不一定是体量最大，而是切中了「个人 AI 助手 + 多渠道 + 自托管」 这个需求，并且工程上足够完整、可拆可学。

二、一句话：OpenClaw 是什么？

OpenClaw 是一个以「Gateway」为中心的个人 AI 助手系统：

• 你在本机（或自己的服务器）跑一个 Gateway 进程；
• Gateway 负责：连接各种 IM 渠道、管理会话、调用大模型、把回复发回对应渠道；
• 你通过 WhatsApp / Telegram / Slack / … 发消息，助手在同一个对话里用你选的模型（如 Claude、GPT）回复你；
• 还支持语音唤醒、Talk 语音对话、Canvas 可视化、技能（Skills）、多 Agent 路由等。

换句话说：一个 Gateway = 一个控制面；产品形态 = 你在各个 App 里对话的那个「助手」。

三、整体架构长什么样？

下面这张图概括了「谁连谁、谁管谁」。

要点可以记三句：

1. 所有渠道都只连这一个 Gateway，没有「每个渠道一个独立服务」的分散架构。
2. 控制端（macOS 应用、CLI、Web） 通过 WebSocket 和 Gateway 通信，不直接连 IM。
3. 大模型 由 Gateway 内的 Agent 通过 Pi 等抽象统一调用，支持多 Provider、多模型、OAuth/API Key。

四、一条消息从「发」到「回」的完整路径

用时序图看更直观：用户在某渠道发一句话，到助手回复，中间经历了什么。

对应到「人话」：

1. 入站：用户在某个 App（比如 Telegram、WhatsApp）里发了一条消息，这条消息会先送到 OpenClaw 的「中心」（Gateway）。系统根据「是谁、从哪个 App、哪个群或私聊」判断这条消息属于哪一段对话，再检查这个人是否被允许和助手聊天。通过检查后，这条消息会进入一个「待处理队列」，等着被回复。
2. 排队：同一段对话在同一时间只会处理一条消息、跑一轮回复，这样不会出现顺序错乱或抢话。同时，整个系统也会限制「最多同时在进行多少轮回复」（比如最多 4 轮），避免一下子处理太多、卡顿或超载。
3. Agent 循环：轮到这条消息时，系统会准备好「这段对话之前说了什么」「工作区里有哪些文件可以参考」「助手要遵守的规则和说明」，然后交给内部的 AI 引擎。引擎会反复做两件事：先让大模型根据当前内容想一轮（可能还会决定要执行什么操作，比如查文件、发消息），再按模型的要求去执行这些操作，把结果塞回对话里，再让模型想下一轮……直到模型觉得「可以收尾了」，给出最终要发给用户的那段回复。
4. 出站：最后这段回复（以及可能的图片、文件等）会按照「这条消息当初是从哪个 App、哪段对话来的」原路发回去，用户就会在自己原来用的 Telegram、WhatsApp 等里看到助手的回复。

五、Agent 循环里具体在干什么？

「Agent 循环」指的是：一次「用户消息 → 模型推理 → 工具执行 → 再推理 → … → 最终回复」的完整过程。OpenClaw 里这一步是在 Gateway 进程内 用 Pi 完成的，不是起一个单独的子进程。

• 系统提示 由 OpenClaw 自己拼（工具列表、安全条款、技能说明、工作区、心跳与静默回复规则等），再通过 applySystemPromptOverrideToSession 灌进 Pi，所以模型看到的行为边界是OpenClaw 定义的。
• 工具 包括：读写信件、执行命令、发消息、管理 cron、调浏览器、Canvas、会话/子 Agent 等，按策略过滤后注入 Pi。
• 会话历史 存在本地的 JSONL 里（按 Session 一份），Pi 的 SessionManager 读同一份文件，保证「上下文连续」。

六、技术栈与亮点速览

亮点可以概括成几句便于传播的话：

• 一个 Gateway 管所有渠道，架构简单、易部署、易排查。
• Pi 嵌入式：不另起进程，会话与工具全在同一个进程内，控制力强、扩展方便。
• 系统提示完全自研：工具说明、安全条款、技能与记忆规则、心跳与静默回复等都在 OpenClaw 侧拼好再注入，方便做产品化和合规。
• 多端一致：CLI、macOS 菜单栏、Web、iOS/Android 都通过同一套 Gateway 协议交互，体验统一。

七、适合谁？可以用来做什么？

• 个人用户：想有一个「只服务自己、跑在自己设备上」的 AI 助手，并且希望用微信以外的 IM（如 Telegram、Slack）当入口。
• 团队/自托管：希望把对话与配置放在自己的服务器上，用现有 IM 做入口，做内部助手或客服原型。
• 开发者：想学习「多渠道 + 多模型 + Agent 编排 + 提示词工程」的完整实现，OpenClaw 的代码结构和文档都适合做参考。
• 产品/架构：关心「个人 AI 助手」的形态、本地优先、以及如何把「一个助手」接到「多个渠道」而不变成多个孤立的 bot。

典型用法包括：在 Telegram 里问日程、在 Slack 里让助手执行脚本、用语音唤醒问天气、用 Canvas 做可视化、用 Skills 做 PR 审查/Changelog 审计等。

八、小结与资源

OpenClaw 用「单 Gateway + 多渠道 + Pi 嵌入式 Agent + 自研系统提示」把「个人 AI 助手」做成一个可自托管、可扩展的开源产品。

• 官网与文档：https://openclaw.ai ，https://docs.openclaw.ai
• 仓库：https://github.com/openclaw/openclaw
• 部署参考文档：https://ncn0ce21tpw7.feishu.cn/wiki/T7NDwSx7piruZHkXckDcwujQnTh

最后分享「一句话架构」：

希望这篇拆解能帮你快速抓住 OpenClaw 的架构与原理，也欢迎在评论区聊聊你更想深挖的部分。