从用户消息到行动:OpenClaw 完整工作流程解析

本文用一个完整的例子，带你走通 OpenClaw 从接收消息到执行行动的每一步。

—

先看一张图：整体流程概览

下面这个流程是一个用户通过 WhatsApp 向 OpenClaw Agent 发送消息的完整链路：

这个图展示了完整闭环。下面按照时间顺序，详细拆解每一步发生了什么。

—

按时间线拆解

第 1 步：用户发送消息

你通过 WhatsApp 向 OpenClaw 发送了一条消息：

“帮我查一下北京的天气，然后整理成文本文件保存到桌面。”

这条消息进入 WhatsApp 服务器，然后被推送到 OpenClaw 的 WhatsApp Channel 插件。

第 2 步：Channel 插件接收消息

执行者：Channel 插件（如 WhatsApp Channel Plugin）

Channel 插件的职责是适配不同消息平台的差异：

接收 WhatsApp 的 Webhook 回调
验证消息来源（防止伪造）
将 WhatsApp 特有的消息格式标准化为 OpenClaw 内部统一格式
提取关键信息：发送者 ID、消息内容、消息类型（文本/图片/语音）、时间戳等

标准化后的消息大致长这样：

{  "channel": "whatsapp",  "sender": "+8613800000000",  "message": "帮我查一下北京的天气，然后整理成文本文件保存到桌面。",  "type": "text",  "timestamp": 1743321600}

然后，Channel 插件把这个标准化消息发送给 Gateway 网关。

如果消息不是文本（比如是语音），Channel 插件或后续流程可能需要调用 Speech Provider 进行语音转文字。

第 3 步：Gateway 网关处理

执行者：Gateway 网关

Gateway 是整个 OpenClaw 的中枢神经系统，它不负责“思考”，但负责“调度”。它的工作包括：

Gateway 是一个长期运行的后台进程，通常绑定在 127.0.0.1:18789。它维护着所有活跃会话的状态。

在这一步，Gateway 会：

识别出发送者 +8613800000000
找到这个用户对应的会话 ID（如果没有就创建新会话）
加载该会话的历史摘要和长期记忆
将这些上下文连同当前消息一起打包，交给 Agent Runtime
第 4 步：Agent Runtime 组装上下文
执行者：Agent Runtime
Agent Runtime 是 Agent 的“工作记忆区”，它负责把“思考”所需的所有材料整理好，然后发给 LLM。
组装什么内容：

System Prompt：系统级指令，定义了 Agent 的角色、行为准则、可用工具和 Skill
Skill 内容：注入的 SKILL.md 文件内容，告诉 Agent “在什么场景下用什么工具”
会话历史：最近 N 轮对话记录（如果过长会被压缩成摘要）
长期记忆：从向量存储中检索到的相关记忆片段
当前用户消息：你刚发的那条消息

这就是为什么 Skill 和工具注册如此重要——在这一步，只有那些在配置中启用的工具和 Skill 才会被注入到上下文

第 5 步：Provider 插件调用 LLM

执行者：Provider 插件（如 OpenAI Provider、Anthropic Provider 等）
Agent Runtime 将组装好的上下文，通过 Provider 插件发送给大语言模型（LLM）。
Provider 插件的职责是：
例如，如果你配置的默认模型是 openai/gpt-5.4，那么 OpenClaw 会调用 OpenAI Provider 插件，向 OpenAI API 发送请求。
LLM 收到上下文后，会“理解”你的需求，然后做出决策。它会输出类似这样的内容：

将 OpenClaw 的内部请求格式转换为目标 LLM API 的格式
处理认证（添加 API Key 或 OAuth Token）
发送 HTTP 请求
接收 LLM 的响应，转换回 OpenClaw 内部格式

{  "role": "assistant",  "content": null,  "tool_calls": [    {      "name": "get_weather",      "arguments": { "city": "北京" }    }  ]}

这条响应表示：LLM 决定先调用 get_weather 工具，而不是直接回复你。

第 6 步：Tool 插件执行操作

执行者：Tool 插件

Agent Runtime 解析 LLM 的响应，发现有 tool_calls，于是开始执行工具调用。

get_weather 是你之前通过某个插件注册的工具（或内置工具）。它的执行逻辑可能是：

调用某个天气 API（如 api.weatherapi.com）
解析返回的 JSON 数据
提取温度、湿度、天气状况等信息
返回格式化的结果

Tool 执行完成后，返回结果：

{  "content": [    {      "type": "text",      "text": "北京当前天气：25°C，晴，湿度45%"    }  ]}

第 7 步：模型接收工具结果，继续推理

Agent Runtime 将工具执行结果追加到对话上下文中，然后再次调用 LLM（通过 Provider 插件）。

这一次，LLM 看到的是：

原始用户请求：“查天气 + 保存到桌面”
第一次工具调用结果：“北京当前天气：25°C，晴，湿度45%”
系统提示中关于“如何写文件”的指导（可能来自 Skill）

LLM 据此决定下一步：调用 write_file 工具。

LLM 输出：

{  "role": "assistant",  "content": null,  "tool_calls": [    {      "name": "write_file",      "arguments": {        "path": "~/Desktop/weather.txt",        "content": "北京当前天气：25°C，晴，湿度45%"      }    }  ]}

Agent Runtime 再次执行工具——这次是 write_file，将内容写入桌面文件。

第 8 步：生成最终回复

write_file 执行成功后，结果再次被送回 LLM。LLM 看到任务已经完成，于是生成最终回复：

{  "role": "assistant",  "content": "已为您查询北京的天气（25°C，晴），并将结果保存到桌面文件 weather.txt 中。"}

这次没有 tool_calls，只有 content。

第 9 步：Channel 插件发送回复

Agent Runtime 将最终回复交给 Gateway，Gateway 根据原始消息的来源（WhatsApp），将回复路由给 WhatsApp Channel 插件。

Channel 插件负责：

将 OpenClaw 内部格式转换为 WhatsApp 消息格式
调用 WhatsApp API 发送消息
处理发送失败的重试逻辑

最终，你在 WhatsApp 上收到 Agent 的回复：

“已为您查询北京的天气（25°C，晴），并将结果保存到桌面文件 weather.txt 中。”

第 10 步：更新记忆与状态

任务完成后，Agent Runtime 会更新会话状态：

短期记忆：将本轮对话追加到会话历史中
长期记忆：如果有值得长期保留的信息（比如你告诉 Agent 你喜欢 Celsius 而非 Fahrenheit），会被编码并存入向量存储
会话压缩：如果会话历史过长，触发摘要压缩

这一步确保了 Agent 在下一次与你对话时，能“记得”之前发生过什么。

—

完整流程中的概念关系图

把上面 10 个步骤浓缩成概念之间的关系：

关键理解：

—

一个更简洁的心智模型

可以用这个三层模型来记忆：

或者更简单地：

Channel 是嘴（接收和发送消息）Provider 是大脑的“外接计算器”（调用 LLM 进行推理）Skill 是“说明书”（告诉大脑在什么场景下怎么做）Tool 是“手脚”（执行具体动作）Gateway 是“神经中枢”（协调一切）