从架构视角全面拆解OpenClaw

OpenClaw（小龙虾）是怎么工作的？

很多人知道龙虾能干活，

但它背后的架构，到底是怎么支撑这一切的？

今天小艾老师就从架构的视角来聊聊这个话题。

一、不是"一个聊天AI"，而是一套"四层网关"

普通聊天AI的架构很简单：

用户发消息 → 调大模型 → 返回文本。

OpenClaw 不一样。它的架构至少分四层：

入口层：连接微信、Discord、Web、CLI 等用户入口

网关层（Gateway）：判断消息来自谁、是否可信、去哪个工作空间

工作空间层：隔离不同任务的上下文（个人助理 vs 开发助手 vs 运营助手）

能力层：大模型 + 记忆 + 技能（Skills）+ 工具

关键洞察：Gateway 不是简单的"消息转发"，而是一个策略执行点。

它会在消息进入的第一时间做身份校验、权限预判、路由分发。

这才是OpenClaw 和普通AI的本质区别：它不是"聊天"，而是"操控"。

二、一条消息如何变成一个可执行的任务？

用户说："帮我查一下明天的日程，然后把会议纪要发给团队。"

在OpenClaw 内部，这条消息会经历至少 6 个步骤：

入口接收：识别用户身份和渠道

网关解析：判断该用户属于哪个工作空间，是否有权访问日历和邮件

上下文注入：工作空间把之前的相关对话、文件、记忆一起打包

LLM 意图拆解：大模型不直接回答，而是输出一个"任务计划"

技能调度：依次调用日历工具、文档生成工具、邮件发送工具

结果聚合：将每一步的执行结果汇总，再通过原入口回复

重点：大模型在这里的角色不是"生成答案"，而是任务规划器。

它输出的不是自然语言，而是一系列可执行的指令序列。

这就是 OpenClaw 能"做事"的根本原因。

三、Skills 机制：让AI从"会说"变成"能做"

OpenClaw 真正值得研究的，是 Skills 的设计。

Skills 不是简单的 API 调用，而是一套可注册、可授权、可审计的工具封装。

每个 Skill 包含三部分：

权限声明：需要访问什么资源（文件、日历、浏览器、终端）

执行逻辑：具体怎么操作

审计钩子：每次调用都会记录谁、什么时间、做了什么

普通 API 调用：程序写死，AI 不能动态选择。

OpenClaw Skills：AI 根据用户指令，动态组合多个 Skills，像一个"工作流编译器"。

举个例子："整理会议纪要并发送" → AI 自动拆解为 read_file → summarize → send_email，并按顺序执行。这种动态任务编排能力，才是 OpenClaw 的核心价值。

四、安全风险的本质：不是功能，而是"执行边界"

很多人说 OpenClaw 有安全风险，但说不清风险来自哪里。

从架构角度看，风险集中在四个点：

入口信任：如果外部群聊里任何人都能触发任务，就会有人注入恶意指令

工具权限：一个 Skill 如果既能读文件又能删文件，权限过宽

隔离缺失：个人工作空间和生产环境混用，AI 可能误删配置

审计缺失：没有日志，出了问题不知道谁调用了什么

真正的问题：OpenClaw 这类系统把 AI 从"只读"变成了"读写执行"。一旦可以写、可以执行，就必须有最小权限、操作隔离、完整审计。

这不是一个功能，而是一整套安全架构。

五、从架构师视角，怎么设计一个安全的"小龙虾"？

如果你要自己搭建类似小龙虾的系统，建议至少考虑5条原则：

入口隔离：信任的入口（私聊）和半信任入口（群聊）分开处理

工具分级：查询类工具可自动，写入/执行类工具必须人工确认

工作空间硬隔离：不同项目、不同用户的数据和权限不能互通

审计日志结构化：记录 who when what result，且不可篡改

默认拒绝：没有明确授权的操作，一律禁止

一句话总结：让 AI 做事不难，让 AI 只做该做的事，才是真正的架构挑战。

写在最后

OpenClaw 代表的是一种趋势：

AI 从"聊天工具"变成"生产力工具"。

这种转变，对架构的要求完全是另一个量级。

你不再只需要一个会调 API 的程序。

你需要的是：

• 网关级的权限判断
• 工作空间级的上下文隔离
• 技能级的动态编排
• 操作级的可审计性

理解 OpenClaw，不是去争论它安不安全。

而是看清一个事实：

当 AI 开始动手，架构的复杂性就转移到了安全边界上。

而这，正是未来所有"小龙虾（执行型 AI）"都要过的关。