OpenClaw 的工具调用流程

1. 读取上下文

当用户发来请求，模型会先看到：

• system 指令
• developer 指令
• workspace 上下文
• 当前聊天上下文
• 可用工具列表

2. 选择执行路径

模型通常会在下面几种路径里选一种：

• 直接回答
• 发起一个工具调用
• 发起多个工具调用
• 先简短说明，再发起工具调用
• 遇到复杂任务时创建子代理

3. commentary 通道调用工具

工具调用通常放在 commentary 通道。这样中间态不会直接发给用户。

4. OpenClaw 执行工具

执行时会受具体工具定义影响，例如：

• read/write 针对文件
• exec 跑 shell 命令
• process 管后台进程
• sessions_spawn 启动子会话或 ACP harness

5. 工具结果回注

工具输出会回到模型侧，模型继续决定：

• 是否还要下一步工具调用
• 是否要修正前一步失败
• 是否可以直接向用户总结

6. final 通道回复

最后真正发给用户的内容才走 final。

一个典型例子

用户说：“帮我查一下这个仓库最近失败的 CI，然后总结原因。”

可能的调用链是：

1. 读取 GitHub skill 说明
2. 调用 GitHub 相关能力拉取 PR / run / log
3. 如需长时间分析则派生子代理
4. 汇总失败原因
5. 给出 final 答复

为什么这个流程比裸 API 更复杂

因为 OpenClaw 要处理的不只是 tool schema，还要处理：

• 工具权限
• 多 channel 回复语义
• 子代理生命周期
• 平台消息路由
• 会话记忆