OpenClaw 核心框架拆解：从用户发消息到 AI 动手干活，中间发生了什么？
🏗️ OpenClaw 核心框架拆解：从用户发消息到 AI 动手干活，中间发生了什么？
本文是 OpenClaw研究系列第 2 篇。
上篇我介绍了我用OpenClaw 作为我的日程助理，他内部究竟是如何工作的？这篇我将深入它的骨架——用一个个真实场景，带你走通从"你发消息"到"AI 动手干活"的完整链路。
一、先讲个故事：你的消息经历了什么？
想象这样一个场景：你在微信上给 OpenClaw 发了一条消息：“帮我看看服务器是不是挂了？”
这条消息从发出到 AI 真正去检查服务器，中间经历了什么？
你发微信 → 微信服务器 → OpenClaw Gateway(网关)
→ 找到对应的 AI 会话(Session)
→ AI 开始"思考"(ReAct 循环)
→ AI 决定"执行一条 Shell 命令检查服务器"
→ 命令在 Docker 沙箱中安全执行
→ 结果返回给 AI
→ AI 组织语言回复你
→ 回复通过微信推送给你
整个过程发生在 几秒钟内，但背后是一整套精心设计的架构在协同工作。下面我们一层层拆开来看。
二、整体架构：四层模型
OpenClaw 的整体架构由四个逻辑层构成，每一层都有清晰的职责：
你（微信 / Telegram / Web 等任何渠道）
│
▼
┌───────────────────────────────────────────────┐
│ 🏛️ 网关层 (Gateway Layer) │
│ 职责：接住你的消息，找到对应的 AI，把回复送回 │
│ 就像：公司的前台 + 总机接线员 │
├───────────────────────────────────────────────┤
│ 🧠 推理层 (Reasoning Layer) │
│ 职责：AI 的决策大脑，思考、规划、决定下一步 │
│ 就像：公司的项目经理 │
├───────────────────────────────────────────────┤
│ ⚡ 执行层 (Execution Layer) │
│ 职责：真正动手干活——执行命令、操作浏览器、读写文件 │
│ 就像：公司的执行员工 │
├───────────────────────────────────────────────┤
│ 💾 存储层 (Storage Layer) │
│ 职责：记住一切——你的偏好、AI 的经验、历史对话 │
│ 就像：公司的档案室 + 每个人的工作笔记 │
└───────────────────────────────────────────────┘
用"公司"来理解这四层
想象 OpenClaw 是一家 24 小时营业的数字服务公司：
- 网关层 = 前台 + 总机：你打电话进来，前台接听、确认你的身份、转接给对应的项目经理。前台还管着所有对外沟通渠道——微信、WhatsApp、Telegram 都是不同的"电话线"
- 推理层 = 项目经理：项目经理听完你的需求，开始思考"这事该怎么做"，然后分派任务给具体执行的员工
- 执行层 = 执行员工：真正动手干活的人——有的会写代码（Shell 命令），有的会操作电脑（浏览器自动化），有的会整理文件
- 存储层 = 档案室 + 工作笔记：记录所有历史信息——你的偏好、项目背景、之前踩过的坑
三、网关层（Gateway）：公司的前台 + 总机
3.1 前台在干什么？
网关层是 OpenClaw 的"神经中枢"，核心代码在 src/gateway/ 目录下。它负责以下几件事：
① 接电话（身份验证）
你从微信发消息过来，网关先确认"你是谁"——通过 auth.ts 验证你的身份。就像前台确认"您是预约过的张先生吗？"
② 转接（会话路由）
确认身份后，网关找到你对应的 AI 会话（Session）。每个用户/每个渠道都有一个独立的会话，就像每个人都有专属的项目经理。
③ 监听多条电话线（渠道管理）
网关同时监听多条"电话线"——微信、Telegram、WhatsApp、Discord、Slack……通过 server-channels.ts 动态管理每个渠道的接入和断开。
④ 保证通话质量（WebSocket 实时推送）
通过 server-ws-runtime.ts，网关和 AI 之间建立了一条实时通道。AI 的回复像流水一样源源不断地推送到你的聊天窗口，而不是等全部想好了再一次性发过来。
3.2 一个具体例子：你发了一条微信
你： "帮我看看服务器是不是挂了？"
│
▼
微信服务器 → OpenClaw 微信渠道适配器
│
▼
auth.ts 验证你的身份 → 通过
│
▼
server-chat.ts 找到你的 Session → 把消息发给 AI
│
▼
AI 开始处理...（推理层接手）
│
▼
AI 回复 → 网关收到 → 推送到微信
你： "服务器正常运行，CPU 使用率 23%，内存剩余 6.2GB"
3.3 server.impl.ts：网关的启动流程
这是整个 OpenClaw 运行时的核心编排文件。想象公司每天早上开门营业的流程：
① 子系统初始化
→ 打开档案室（子代理注册表）
→ 启动各个部门（技能引擎、插件中心）
→ 打开监控系统（健康检查、心跳监控）
② 加载配置
→ 查看今天的排班表（config.json）
→ 检查有没有新员工入职（Schema 校验）
③ 安全管理
→ 检查所有钥匙和门禁卡（Auth Token、API Key）
④ 建立通信
→ 开通电话线路（HTTP 服务器）
→ 开通内部对讲系统（WebSocket）
→ 开通远程专线（Tailscale 隧道）
⑤ 启动后台任务
→ 启动定时提醒服务（Cron 调度器）
→ 启动巡逻机器人（心跳循环）
四、推理层（Reasoning）：AI 的决策大脑
4.1 ReAct 循环：AI 的"思考-行动-观察"闭环
这是 OpenClaw 最核心的机制。AI 不是一次性回答你的问题，而是通过一个循环来完成任务：
思考 (Thought)
│
▼
行动 (Action) ───→ 调用工具
│ │
▼ ▼
观察 (Observation) ←─── 工具返回结果
│
▼
再思考 (Thought)
│
▼
... 循环直到任务完成
4.2 用例子理解 ReAct 循环
场景：你让 AI “帮我查一下这周的天气，然后安排一下户外活动”
第1轮循环：
Thought: "用户想知道本周天气，我需要先查天气数据"
Action: 调用 web_search 工具，搜索"本周天气预报"
Observation: 获取到天气数据——周二晴、周三雨、周四多云...
第2轮循环：
Thought: "周二晴天适合户外，周三下雨只能室内"
Action: 调用 write_file 工具，生成一份活动安排表
Observation: 文件写入成功
第3轮循环：
Thought: "任务完成，可以回复用户了"
Action: 生成最终回复
整个过程 AI 会循环 Thought → Action → Observation，直到它认为任务完成。你看到的是最终结果，但 AI 内部可能已经循环了好几轮。
4.3 System Prompt：AI 的"入职培训手册"
每次 AI 开始处理你的消息之前，系统都会给它一份"入职培训手册"——这就是 System Prompt。
这份手册不是固定的，而是动态组装的，包含：
① 你是谁 → IDENTITY.md + SOUL.md（AI 的身份和性格）
② 用户是谁 → USER.md（你的偏好和习惯）
③ 你在哪运行 → 操作系统、Shell 类型、当前时间
④ 你该怎么做 → AGENTS.md（操作规范和避坑指南）
⑤ 你能用什么 → 当前可用的工具列表
⑥ 现在什么情况 → 今日待办、最近对话摘要
为什么每次都要重新组装？ 因为你的偏好可能会变，AI 的经验会积累，环境也会变化。动态组装确保 AI 始终使用最新的"手册"。
4.4 三种"思考模式"
| 模式 | 什么时候用 | 效果 |
|---|---|---|
| full（全量） | 你直接和 AI 对话时 | AI 完整阅读所有手册，认真思考 |
| minimal（精简） | AI 派"实习生"去干活时 | 只给核心指令，省 Token 省时间 |
| none（最小化） | 极度紧急/简单任务 | 只告诉 AI 当前环境，其他全靠它自己 |
五、执行层（Execution）：真正动手干活的员工
推理层负责"想"，执行层负责"做"。这是 OpenClaw 区别于普通聊天机器人的关键——它真的能操作你的电脑。
5.1 六种执行能力
| 能力 | 技术实现 | 举个栗子 🌰 |
|---|---|---|
| 💻 执行 Shell 命令 | bash-tools |
ping 8.8.8.8 检查网络、df -h 查看磁盘 |
| 🐳 Docker 隔离执行 | Docker 沙箱 | 运行有风险的脚本，防止搞坏系统 |
| 🌐 浏览器自动化 | Playwright | 自动登录网站、抓取数据、截图 |
| 📁 文件系统操作 | 内置工具 | 读写文件、创建目录、编辑代码 |
| ✋ 审批流 | exec-approval | 删文件前先问你"确定吗？" |
| 🔒 沙箱隔离 | Sandbox 目录 | 动态代码在隔离区运行，不影响主系统 |
5.2 一个完整的执行例子
场景：AI 要检查你的服务器是否在运行
AI 的 Thought: "用户让我检查服务器，我需要执行一条 ping 命令"
│
▼
AI 的 Action: 调用 exec 工具，参数是 "ping -c 3 192.168.1.100"
│
▼
执行层判断：这条命令风险低 → 直接执行（不需要你确认）
│
▼
Shell 执行 ping 命令 → 返回结果
│
▼
AI 的 Observation: "ping 成功，服务器在线，延迟 12ms"
│
▼
AI 的 Thought: "服务器正常，回复用户"
│
▼
AI 回复你："服务器正常运行，延迟 12ms 👍"
5.3 安全机制：不是所有事 AI 都能直接干
OpenClaw 有三道安全防线：
第一道：工具白名单
AI 只能用 Prompt 中明确列出的工具。没列出来的，AI 根本不知道它的存在，更不会去调用。
第二道：Profile + Policy 双层过滤
Profile（能力方案）→ 决定 AI 属于哪个"工种"
├── minimal：只能读文件、写文件（安全受限环境）
├── coding：可以执行命令、搜索网页（开发环境）
├── messaging：侧重发消息、管理会话（客服场景）
└── full：全部权限（本地高权限模式）
Policy（用户策略）→ 你可以在配置中额外限制
├── Allow 列表：显式允许某些工具
└── Deny 列表：禁止某些工具（如禁止 exec）
第三道：审批流（exec-approval）
高风险操作（如删除文件、修改系统配置）会通过聊天窗口向你发送确认请求：
AI: "我想执行这条命令：rm -rf /project/cache
需要你的批准才能执行，可以吗？"
你: "批准" 或 "拒绝"
六、存储层（Storage）：AI 的"记忆"是怎么存的？
6.1 四层记忆体系
OpenClaw 的记忆分为四层，从"刚说的"到"很久以前的"：
⚡ 瞬时记忆（RAM）
你刚才说了什么？AI 几秒前做了什么？
→ 存在内存里，对话结束就清空
📋 短期总结（Compaction）
聊了很久，Token 快不够了怎么办？
→ AI 自动把前面的对话"压缩"成摘要
📅 情节记忆（Markdown 文件）
昨天 AI 做了什么？上周处理了什么任务？
→ 存在 memory/2026-03-10.md 这样的文件里
🧠 长期记忆（工作区文件）
AI 是什么性格？你有什么偏好？踩过什么坑？
→ 存在 AGENTS.md、SOUL.md、USER.md 等文件里
6.2 用例子理解记忆层级
场景：你问 AI “还记得上次我们讨论的数据库方案吗？”
① AI 先查"瞬时记忆"——当前对话里有没有提到？
没有，今天第一次聊这个话题
② AI 查"短期总结"——刚才压缩的摘要里有吗？
没有，这是很久以前的事了
③ AI 调用 memory_search 工具（RAG 检索）
→ 在 sqlite-vec 向量数据库中搜索"数据库方案"
→ 找到匹配结果：MEMORY.md#L34 记录了那次讨论
→ 精准读取那一段内容
④ AI 回复你：
"记得！上次我们决定用 PostgreSQL，
因为你的数据量预计会超过 100 万条。
来源：MEMORY.md#L34"
6.3 自我进化：AI 会自己记笔记
OpenClaw 最酷的设计之一是：AI 会主动更新自己的记忆。
每次任务结束后，AI 会自动判断"这次学到了什么"，然后写入对应的文件：
任务：你让 AI 部署一个 Node.js 应用
结果：部署失败，因为服务器没装 Node.js 18+
AI 自动记录到 AGENTS.md：
- [2026-03-11] 部署前必须先检查 Node.js 版本
- 如果版本低于 18，先执行 nvm install 18
下次你再让 AI 部署，它就不会再踩这个坑了。
这就是为什么说 OpenClaw 的 AI 是"自我进化"的——它每次工作都在积累经验。
七、多代理系统：AI 也会"找帮手"
7.1 为什么需要多代理？
有些任务太复杂，一个 AI 搞不定。比如：
你："帮我分析一下这个项目里所有的代码质量问题，
然后生成一份报告，再发到我的邮箱"
这个任务涉及：读代码 → 分析质量 → 生成报告 → 发邮件。如果让一个 AI 从头做到尾，效率很低。
OpenClaw 的做法是：主 AI 可以派"实习生"去干具体的活。
7.2 三种协作模式
模式 A：派实习生（父子协作）
主 AI（项目经理）：
"这个项目有 1000 个文件要审查，
我派 3 个子 AI 去并行审查，
每个负责 300 多个文件。"
子 AI-1 → 审查 src/gateway/ → 返回结果
子 AI-2 → 审查 src/agents/ → 返回结果
子 AI-3 → 审查 src/channels/ → 返回结果
主 AI 汇总三份结果 → 生成最终报告 → 发邮件
模式 B：跨部门沟通（跨会话通信）
你（在微信上）：
"帮我问一下服务器监控 AI，最近有没有异常？"
个人助理 AI（微信 Session）：
调用 sessions_send 工具 → 发给服务器监控 AI
服务器监控 AI（独立 Session）：
查询监控数据 → 返回结果
个人助理 AI：
"服务器监控说：最近一周一切正常，没有异常告警 👍"
模式 C：换人（动态身份切换）
你在聊天窗口输入：/agent coder
网关立即加载 coder 的 SOUL.md + AGENTS.md
→ 后续消息由 coder AI 接手
→ 它变成了一个专业的代码审查助手
7.3 子代理的生命周期
① 注册：主 AI 说"帮我审查这个文件"
→ 系统创建一个子会话，记录任务描述
② 执行：子 AI 独立工作
→ 主 AI 可以同时做其他事
③ 完成：子 AI 干完活了
→ 结果自动"冻结"保存
④ 通报：系统主动通知主 AI
→ "你派的实习生回来了，这是他的报告"
⑤ 清理：默认删除子会话
→ 也可以保留供后续查看
类比：一家现代化公司
Session 是办公室（提供工作的物理空间），Agent 是员工（负责具体业务）。一个办公室内通常只有一名员工接待用户，但他可以随时拨打电话向其他办公室的专家请教，或者指派实习生去新办公室完成专项任务并带回简报。
八、心跳机制：让 AI 真正"活着"
8.1 传统 AI 的问题
传统 AI 助手的工作模式是：你问 → 它答 → 你不再问 → 它睡觉。
但如果你想让 AI 主动帮你做事呢？比如：
- 每天早上 7 点推送今日待办
- 监控服务器，出问题时主动通知你
- 每周五自动生成周报
这就需要"心跳机制"。
8.2 心跳是怎么工作的
每隔一段时间（比如 1 小时）：
│
▼
系统向 AI 发送一个"隐藏的心跳提示词"
（你看不到这个提示，它是在后台悄悄发生的）
│
▼
AI "苏醒"，扫描当前状态：
├── 有没有到期的任务？
├── 有没有监控到异常？
└── 有没有预设的提醒要触发？
│
▼
AI 判断：
├── 一切正常 → 回复 HEARTBEAT_OK
│ （网关静默丢弃，你完全无感知）
│
└── 发现异常 → 生成真实通知
（网关推送到你的手机）
8.3 两个场景对比
场景 A：无事发生
凌晨 3 点，心跳触发
AI 扫描：一切正常
回复：HEARTBEAT_OK
网关：丢弃，记录日志
你：完全不知道（在睡觉 😴）
场景 B：服务器挂了
下午 2 点，心跳触发
AI 扫描：发现服务器 ping 不通！
回复："⚠️ 检测到服务器 192.168.1.100 无法访问，
已自动尝试重启，请确认。"
网关：推送到你的微信
你：收到告警，及时处理 ✅
8.4 Cron vs Heartbeat 的区别
| Cron（定时任务） | Heartbeat（心跳） | |
|---|---|---|
| 工作方式 | 死板的定时器 | 灵活的"苏醒点" |
| 例子 | “每天 8 点运行备份脚本” | “每小时醒一次，看看有没有事” |
| 灵活性 | 固定执行，不管有没有必要 | AI 自主判断要不要行动 |
| 适用场景 | 确定性的重复任务 | 需要情境感知的主动行为 |
九、ACP 通讯协议：AI 的"通用语言"
ACP（Agent Client Protocol）是 OpenClaw 内部通讯的核心标准，基于 JSON-RPC 2.0。
9.1 为什么需要 ACP？
想象一下：OpenClaw 需要和很多"外部设备"通信——VS Code 插件、终端工具、Raycast 插件、Web 界面……每个设备都需要一种标准化的"语言"来和 OpenClaw 对话。ACP 就是这种语言。
9.2 关键"对话"方法
| 方法 | 翻译 | 说明 |
|---|---|---|
initialize |
“你好，我是 XX 客户端” | 协商协议版本和能力集 |
newSession |
“帮我开个新会话” | 创建新的对话 |
loadSession |
“继续上次的对话” | 恢复历史会话 |
prompt |
“用户说：…” | 发送用户输入 |
requestPermission |
“这个操作需要你批准” | 高风险操作的审批流程 |
9.3 工具调用的安全审批流
① AI 想执行一条命令
→ 在回复中嵌入工具调用请求
② 客户端判断风险等级
→ 低风险：自动通过
→ 高风险：弹出确认框等你批准
③ 你点击"批准"
→ 通过 requestPermission 回告网关
④ AI 执行工具
→ 在安全边界内执行
⑤ 结果返回
→ AI 看到结果，继续下一步
十、工具管理：AI 的能力边界
10.1 三种工具来源
| 来源 | 说明 | 例子 |
|---|---|---|
| 核心内置工具 | 系统自带的"基本功" | 读写文件、执行命令、搜索记忆 |
| 插件/技能工具 | 第三方扩展的能力 | 发微信、操作 GitHub、查天气 |
| MCP 工具 | 通过标准协议接入的外部工具 | 数据库查询、API 调用 |
10.2 工具分配流程
① 看 Profile → 这个 AI 是什么"工种"？
（minimal / coding / messaging / full）
② 筛选工具 → 从工具目录中选出对应的工具集
③ 应用 Policy → 用户有没有额外限制？
（Allow 列表 / Deny 列表）
④ 注入 Prompt → 把最终工具列表告诉 AI
第一道安全防线： AI 知道自己能用什么，是因为 Prompt 中明确授权了这些工具。如果一个工具未出现在 Prompt 中，AI 就不会尝试调用它。这就是最小权限原则。
十一、全渠道与模型支持
11.1 你可以在任何地方用
OpenClaw 支持 12+ 个通讯渠道：微信、Telegram、WhatsApp、Discord、Slack、飞书、iMessage、Signal、GitHub、Jira、Web UI、Webhook/REST API
不同渠道可以绑定不同的 AI：
- Slack → 绑定 coder AI，专门处理代码问题
- WhatsApp → 绑定 life AI，帮你订餐、查天气
- 微信 → 绑定 personal AI，你的私人助理
11.2 你可以用任何模型
| 类别 | 模型 |
|---|---|
| 🌍 国际主流 | Claude、GPT-4o、Gemini、Mistral、Grok |
| 🏠 本地离线 | Ollama（Llama 3、Qwen）、LM Studio |
| 🇨🇳 国内大模型 | 豆包、Kimi、Minimax、DeepSeek |
切换模型只需修改一行配置，无需改动任何业务逻辑。
十二、核心架构总结
┌─────────────────────────────────────────────────────────────┐
│ 七大核心模块协同工作 │
├───────────────┬─────────────────────┬───────────────────────┤
│ 模块 │ 核心职责 │ 设计亮点 │
├───────────────┼─────────────────────┼───────────────────────┤
│ Gateway 网关 │ 系统指挥中心 │ 双协议 · 动态自愈 │
│ 记忆系统 │ 跨 Session 认知连续 │ Markdown 文件 · RAG │
│ 多代理系统 │ 任务分发与并行执行 │ 指数退避 · 自动通报 │
│ ACP 协议 │ 标准化双向通讯 │ JSON-RPC · 安全审批 │
│ Prompt 引擎 │ 动态构建指令大脑 │ 六层组装 · 闭环进化 │
│ 心跳机制 │ 主动感知与定时唤醒 │ 情境感知主动推送 │
│ 工具管理 │ 动态分配能力边界 │ Profile+Policy 双层过滤│
└───────────────┴─────────────────────┴───────────────────────┘
核心价值： OpenClaw 不是一个封闭的 AI 产品，而是一个开放的、本地优先的 AI 编排基础设施。任何开发者都可以通过 Plugin SDK 接入新渠道，通过 ACP 协议构建自定义客户端，通过 ClawHub 分享与使用技能包。
下期预告
第3篇：OpenClaw 的"小帮手"——主代理与子代理
本文由 代码牧星人 原创
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
12
0- 0
已为社区贡献6条内容
所有评论(0)