用户发一条改文件命令,OpenClaw 都经历了什么?

假设你安装完龙虾（OpenClaw）之后，当你在手机上给龙虾发现一条指令之后，OpenClaw到底是如何一步步处理你的指令的呢？这篇文章带你一起揭秘。

先上时序图：

步骤	发起方 → 接收方	消息通道	具体操作	关键点 / 目的
1	用户 (Chat App) → Channel-Adapter	外部通道（Websocket/HTTP 等）	用户以自然语言发送指令，如「把 /data/config.yml 里的 timeout 改成 30」	入口动作；此时还是非结构化的自然语言，未进入系统内部协议
2	Channel-Adapter → Gateway	外部通道 → 网关	Adapter 把用户消息标准化成系统内部统一的消息报文（含消息 ID、会话 ID、用户 ID、消息体、元数据等）	多通道（IM/Web/API）屏蔽差异的关键：不同入口进来后都变成同一种报文格式，网关才能统一处理
3	Gateway → Agent Runtime	RPC-REQ	网关把标准化报文作为一次 RPC 请求投递给 Agent Runtime，驱动其进入任务处理	RPC 语义：网关是客户端、Agent 是服务端。意味着网关会把请求挂起等待 Agent 的返回（同步语义），后续步骤 7 的 REPLY 与之对应
4	Agent Runtime → Memory-Engine	进程内 / 本地调用	Agent（Lobster-Loop）从记忆引擎加载会话上下文、人设记忆、历史消息等	为 LLM 推理准备完整上下文；属于 Agent 内部私有的准备工作，不经过网关
5	Agent Runtime → LLM 推理模块	进程内 / 本地调用	Agent 组装 Prompt（系统提示 + 人设 + 上下文 + 当前指令），提交给 LLM 进行任务规划	由 LLM 完成意图识别、任务拆解，并决策要调用哪个工具、传什么参数
6	LLM 推理模块 → Agent Runtime	进程内返回	LLM 返回结构化的工具调用 JSON（如 {tool: "file-write", args: {path: "/data/config.yml", ...}}）	关键点：LLM 只输出「调用意图」，不直接执行；Agent 拿到的是可被后续校验 / 审批的可解析结构，而非自由文本
7	Agent Runtime → Gateway	RPC-REPLY	Agent 把【工具调用请求】作为 RPC 响应回流给网关	与步骤 3 呼应，形成一次完整的 RPC 请求 - 应答闭环。此处是关键架构决策：工具调用必须回网关，而不是 Agent 直接执行，从而把安全管控收口到网关
8	Gateway → Gateway	本地（自处理）	网关执行 Security-Policy 校验：检查目标文件路径是否越权、是否在白名单 / 黑名单、是否有写入风险等	这是整套流程的安全闸门。校验失败则流程中止（图中未画失败分支，但隐含此语义）
9（可选分支）	Gateway → User（推送）→ Gateway	外部通道（审批通知 / 指令）	仅当策略判定需要人工审批时 ：网关推送审批请求给用户，任务挂起；用户回复 /approve 通过后流程继续	alt 分支表示条件执行。体现了「高风险操作必须人工介入」的治理原则；若无需审批则直接跳过此步
10	Gateway → Skill-Tool Runtime	非 RPC，网关本地调度	校验通过后，网关直接向工具执行器下发执行命令	图中特意标注「非 RPC」：说明工具调用属于网关本地内部调度，不再走 RPC 链路（因为此时已在本机、无跨进程 / 跨节点语义），与 3/7/14/17 的 RPC 形成对比
11	Skill-Tool Runtime → 宿主机 OS 文件系统	系统调用	工具执行器发起系统调用（open/write/rename 等）修改宿主机上的目标文件	真正落地的 IO 操作；写入目标可能是真实磁盘文件，也可能被沙箱 / 容器重定向
12	宿主机 OS 文件系统 → Skill-Tool Runtime	系统调用返回	文件系统返回 IO 执行结果码（0 成功 / 非 0 失败）、输出日志	原始、低层的结果，尚未经过格式化
13	Skill-Tool Runtime → Gateway	本地返回	工具执行器把原始执行结果（退出码、stdout/stderr 日志）回传给网关	网关在此汇总工具的真实执行状态，为后续统一封装做准备
14	Gateway → Agent Runtime	📡 RPC-REQ	网关把工具返回结果作为新一次 RPC 请求推送给 Agent	注意与步骤 3 是同一种 RPC-REQ 消息类型——RPC 是对称的：投递用户消息和投递工具结果都走同一通道，Agent 只认「收到一个需要处理的输入」
15	Agent Runtime → LLM 推理模块	进程内 / 本地调用	Agent 把「工具执行结果 + 原指令」重新提交给 LLM，让其校验任务是否成功完成，并据此生成自然语言回复	结果闭环校验：如果文件写入失败或结果不符合预期，LLM 会在这一步发现并生成失败说明或修正计划
16	LLM 推理模块 → Agent Runtime	进程内返回	LLM 返回回答文本（如「已修改完成，timeout 已改为 30」）	从结构化执行结果 → 人类可读的自然语言
17	Agent Runtime → Gateway	📡 RPC-REPLY	Agent 把最终应答报文封装后作为 RPC 响应回传给网关	与步骤 14 对应，完成第二次 RPC 请求 - 应答闭环
18	Gateway → Channel-Adapter	网关 → 外部通道	网关把最终回复下发到对应的通道 Adapter	网关负责按来源通道做路由，确保回复回到正确的会话
19	Channel-Adapter → 用户 (Chat App)	外部通道	Adapter 将应答展示给用户，任务闭环完成	用户感知到的唯一出入口：所有内部复杂交互（RPC、安全校验、LLM 推理）对用户透明