1. 本期目标上一期我们分析了 OpenClaw 的消息队列、去重、防抖和输出投递机制。到这里外部消息已经能够稳定进入 Agent run。但 Agent 真正“能做事”靠的不是单纯聊天而是Tools 工具系统。官方文档对 Tool 的定义很直接Tool 是 Agent 可以调用的类型化函数例如exec、browser、web_search、message、image_generate等模型只能看到经过 profile、allow/deny policy、provider 限制、sandbox 状态、channel 权限和 plugin 可用性过滤后的工具。(OpenClaw)本期重点分析1. Tool、Skill、Plugin 的区别 2. OpenClaw 内置工具分类 3. createOpenClawCodingTools 如何组织工具集合 4. Tool policy 如何决定模型能看到哪些工具 5. sandbox、tool policy、elevated 三层控制的区别 6. tools.catalog、tools.effective、tools.invoke 三个 Gateway 方法 7. Tool Search 如何解决大工具目录问题2. Tool、Skill、Plugin 的区别学习 OpenClaw 时最容易混淆的是这三个概念Tool Skill Plugin它们的职责不同。Tool Agent 可以调用的动作函数。 Skill 告诉 Agent 如何使用工具的说明书。 Plugin 给 OpenClaw 增加新能力的扩展包。官方文档也给出了类似划分Tool 是 callable actionSkill 是SKILL.md指令包Plugin 可以添加 tools、skills、channels、model providers、speech、media generation、web search、hooks 等运行时能力。(OpenClaw)举个例子用户说帮我检查这个项目有没有 TypeScript 编译错误。 Tool exec用来执行 npm run build。 Skill 告诉 Agent 检查 TypeScript 项目时应该先看 package.json再运行构建命令再分析报错。 Plugin 如果 OpenClaw 原本没有某个平台或外部服务能力Plugin 可以注册新的工具或 Channel。所以三者关系可以画成Plugin 提供能力 ↓ Tool 暴露动作 ↓ Skill 指导怎么用 ↓ Agent 组合工具完成任务一句话概括Tool 解决“能不能做”Skill 解决“怎么做得更规范”Plugin 解决“如何扩展新能力”。3. OpenClaw 内置工具分类OpenClaw 的工具不是一个平铺列表而是按能力类型组织。官方文档列出了代表性工具分类例如 runtime、files、web、browser、messaging、sessions、automation、gateway、media、large catalogs 等。(OpenClaw)可以整理成Runtime exec、process、code_execution Files read、write、edit、apply_patch Web web_search、x_search、web_fetch Browser browser Messaging message Sessions and agents sessions_list、sessions_history、sessions_send、sessions_spawn、 sessions_yield、subagents、agents_list、session_status Automation cron、heartbeat_respond Gateway and nodes gateway、nodes Media image、image_generate、music_generate、video_generate、tts Tool Search tool_search_code、tool_search、tool_describe、tool_call这些工具覆盖了 Agent 运行中的几类典型动作读取信息 修改文件 执行命令 搜索网络 操作浏览器 发送消息 管理会话 生成媒体 调用插件能力。所以 OpenClaw 的工具系统本质上是把“聊天模型”连接到“真实操作系统和外部服务”的能力层。4. 为什么 Tool 系统是 Agent 的核心没有工具时Agent 只能回答你应该运行 npm install。 你可以查看日志。 你可以打开浏览器搜索。有工具后Agent 可以直接执行读取 package.json 运行 npm install 查看错误日志 修改代码 生成 diff 发送消息 调用浏览器 搜索文档 创建定时任务。所以 Tool 系统承担了两个关键职责第一把模型输出的“意图”转化为可执行动作。 第二把动作结果重新写回上下文让模型继续推理。可以画成用户消息 ↓ LLM 规划 ↓ 选择 Tool ↓ 执行 Tool ↓ 返回 Tool result ↓ LLM 根据结果继续推理 ↓ 生成最终回复这也是 Tool-Augmented Agent 和普通 Chatbot 的核心差异。5. Tool 的基本结构从源码角度看一个 Tool 通常包含几个部分name 工具名称例如 exec、read、message。 label 展示名称。 description 告诉模型这个工具做什么。 parameters 工具参数 schema。 execute 真正执行工具逻辑的函数。可以抽象成type Tool { name: string; label?: string; description: string; parameters: object; execute: (args, context) PromiseToolResult; };模型并不会直接看到 TypeScript 函数实现它看到的是工具的结构化描述和参数 schema。真正执行时OpenClaw 会把模型生成的 tool call 交给 Gateway / runtime再由对应的execute函数执行。所以 Tool 的核心是给模型一个可理解、可调用、可约束的动作接口。6.createOpenClawCodingTools工具集合构造入口源码中建议重点看src/agents/pi-tools.ts这个文件负责组织 Agent 可用的工具集合。源码中可以看到OpenClawCodingToolConstructionPlan这类结构它把工具构造拆成几个开关是否包含基础 coding tools、shell tools、channel tools、OpenClaw tools、plugin tools 等随后createOpenClawCodingTools会根据 agent、session、sandbox、channel、provider、workspace、abortSignal 等上下文生成最终工具集合。(GitHub)可以简化理解为createOpenClawCodingTools(options) ↓ 根据当前 Agent / Session / Channel / Sandbox / Provider ↓ 创建基础工具 ↓ 创建文件工具 ↓ 创建命令工具 ↓ 创建 OpenClaw 工具 ↓ 加载 Plugin 工具 ↓ 应用工具策略过滤 ↓ 返回模型最终能看到的工具列表这说明工具集合不是静态写死的而是动态构造的。同一个 OpenClaw 实例中不同 session 可能看到不同工具主用户私聊 可以看到 exec、read、write、web_search。 群聊访客 只能看到 message、session_status。 sandbox 子 Agent 只能看到 sandbox 允许的工具。 某个 provider 可能因为模型兼容性被过滤部分工具。 插件未启用 对应 plugin tools 不出现。这就是 OpenClaw 工具系统的动态性。7.openclaw-tools.ts内置 OpenClaw 工具注册另一个重要文件是src/agents/openclaw-tools.ts从源码导入关系可以看到它会创建多种 OpenClaw 工具例如createMessageTool、createCronTool、createGatewayTool、createImageGenerateTool、createSessionsListTool、createSessionsSendTool、createSubagentsTool、createWebSearchTool、createWebFetchTool等。(GitHub)这类工具和普通 coding 工具有区别。普通 coding tools 更偏向本地项目操作比如 read、write、edit、exec。 OpenClaw tools 更偏向 Gateway 能力比如 message、sessions、cron、gateway、nodes、tts、image_generate。可以理解为coding tools 让 Agent 能操作项目 OpenClaw tools 让 Agent 能操作 OpenClaw 自己的运行环境。例如message 向当前 Channel 发送消息。 sessions_list 查看当前有哪些会话。 sessions_send 向另一个 session 发送消息。 cron 创建或管理定时任务。 subagents 把任务分派给子 Agent。 gateway 读取或操作 Gateway 状态。 tts 把文字转语音。这部分是 OpenClaw 从“代码助手”扩展成“个人 AI 助手”的关键。8. Tool policy模型能看到哪些工具工具多并不代表模型都能随便调用。OpenClaw 会通过 Tool policy 决定当前 turn 中哪些工具可见、哪些工具被禁止。官方文档明确说明工具策略会在模型调用前执行如果 policy 移除了某个工具模型本轮就不会收到这个工具的 schema。(OpenClaw)也就是说不是模型看到工具后再被拦截 而是在模型请求前工具列表已经被裁剪。这个设计很重要因为它能减少两类问题第一模型误选危险工具。 第二模型在提示词中“知道”某些不该知道的能力。工具过滤链路可以理解为所有候选工具 ↓ tools.profile 基础工具配置 ↓ tools.allow / tools.deny ↓ tools.byProvider ↓ tools.toolsBySender ↓ sandbox tool policy ↓ channel/runtime policy ↓ plugin availability ↓ 最终暴露给模型9.tools.profile基础工具画像OpenClaw 支持通过tools.profile设置基础工具集合。官方配置文档中列出了几个 profileminimal、coding、messaging、full。例如minimal只包含session_statuscoding包含文件、运行时、Web、sessions、memory、cron、image 等能力messaging偏向消息和会话工具full则基本不做限制。(OpenClaw)可以理解为minimal 只允许最小状态查询。 coding 适合代码修改、命令执行、网页搜索。 messaging 适合聊天转发、会话管理。 full 适合本地可信主用户的完整能力。示例配置{ tools: { profile: coding } }profile 是第一层粗粒度配置适合快速定义 Agent 的能力边界。10. Tool groups工具组简写为了避免配置太长OpenClaw 支持工具组例如group:runtime group:fs group:web group:sessions group:memory group:messaging group:media group:plugins官方配置中说明group:runtime包含exec、process、code_executiongroup:fs包含read、write、edit、apply_patchgroup:web包含web_search、x_search、web_fetchgroup:plugins表示已加载插件拥有的工具。(OpenClaw)例如{ tools: { allow: [group:fs, group:web, session_status], deny: [exec, process] } }这表示允许文件和 Web 工具 但禁止命令执行类工具。这里要注意一个原则deny 优先级更高。官方文档也明确写到global tool allow/deny 是全局工具策略deny wins并且支持大小写不敏感和通配符。(OpenClaw)11.tools.allow和tools.denytools.allow和tools.deny是最直接的工具控制方式。{ tools: { allow: [group:web, read, session_status], deny: [write, edit, apply_patch, exec] } }可以理解为allow 白名单。非白名单工具不可见。 deny 黑名单。命中的工具不可见。 deny wins 只要 deny 命中即使 allow 中出现也会被移除。尤其要注意文件工具。官方文档特别提醒write和apply_patch是不同工具 ID要阻止所有文件修改应该 denygroup:fs或者显式列出write、edit、apply_patch等可变更工具。(OpenClaw)这点很关键。因为只禁用write并不一定等于彻底禁止所有文件修改。12.tools.byProvider按模型提供商限制工具不同模型提供商对工具调用格式、工具数量、参数 schema 的支持程度不同。因此 OpenClaw 支持按 provider 或 provider/model 进一步限制工具。官方配置说明中给出了tools.byProvider并说明顺序是base profile → provider profile → allow/deny也就是说可以为某个模型单独设置更小的工具集合。(OpenClaw)示例{ tools: { profile: coding, byProvider: { google-antigravity: { profile: minimal }, openai/gpt-5.4: { allow: [group:fs, sessions_list] } } } }这适合几种场景某些模型不适合复杂工具 schema 某些 provider 不支持特定工具形态 某些模型只用于轻量查询 某些模型只允许读不允许写。所以 provider policy 本质上是模型兼容性和安全边界的结合。13.tools.toolsBySender按发送者限制工具在聊天平台中同一个 Agent 可能面对不同用户。例如主人私聊 Agent 同事在 Slack 群里 Agent 访客在 Discord 中提问 外部用户通过 WebChat 访问。这些人不应该拥有同样的工具权限。OpenClaw 提供tools.toolsBySender可以按 sender identity 限制工具。官方文档说明它是 channel access control 之外的 defense-in-depthsender 值必须来自 channel adapter而不是消息文本。(OpenClaw)示例{ tools: { toolsBySender: { channel:discord:1234567890123: { alsoAllow: [group:fs] }, id:guest-user-id: { deny: [group:runtime, group:fs] }, *: { deny: [exec, process, write, edit, apply_patch] } } } }这段配置表达的是特定 Discord 用户可以额外使用文件工具 guest 用户不能使用 runtime 和 fs 默认所有人都不能执行命令或修改文件。这对多 Channel、多用户环境非常重要。14. Sandbox、Tool policy、Elevated 的区别OpenClaw 中还有一组三个容易混淆的概念sandbox tool policy elevated官方文档把它们区分得很清楚Sandbox 决定工具在哪里运行是在 sandbox 后端还是 host。 Tool policy 决定哪些工具可用、可调用。 Elevated 只针对 exec在 sandboxed 情况下提供一个可配置的“逃出 sandbox 到 host 执行”的通道。(OpenClaw)可以这样理解sandbox 管执行环境 tool policy 管工具可见性 elevated 管 exec 是否允许在 host 上执行。三者关系如下模型想调用 exec ↓ Tool policy 判断 exec 是否允许 ↓ Sandbox 判断 exec 在哪里跑 ↓ Elevated 判断是否允许从 sandbox 切到 host ↓ Exec approvals 判断是否需要审批 ↓ 真正执行命令注意一点Elevated 不能绕过 Tool policy。官方 Elevated 文档也说明如果exec被 tool policy denyelevated 无法覆盖elevated 只是改变 sandboxed exec 的执行位置并不赋予额外工具权限。(OpenClaw)15. Elevated mode危险但必要的能力Elevated mode 的目标是解决一个现实问题Agent 在 sandbox 中运行时很多命令只能看到 sandbox 内的环境 但某些任务确实需要访问 host 环境。例如重启本机服务 读取宿主机上的项目 执行本机部署脚本 调用宿主机已有 CLI 操作某个本地应用。OpenClaw 支持通过 slash command 控制 elevated/elevated on /elevated ask /elevated full /elevated off官方文档说明on/ask会在配置的 host 路径上运行但保留 approvalsfull会跳过 exec approvalsoff回到 sandbox-confined execution。(OpenClaw)所以 elevated 是高风险能力应该满足三个原则只给可信发送者 只在需要时打开 优先保留 approval。16. Exec approvals 与工具安全exec是最危险也最强大的工具之一。它可以做安装依赖 运行测试 修改环境 启动服务 访问文件 执行脚本 调用系统命令。所以 OpenClaw 不只靠 tool policy还需要 exec approvals 控制命令执行风险。前面提到的tools.exec配置中官方示例包含backgroundMs timeoutSec cleanupMs notifyOnExit applyPatch.enabled applyPatch.allowModels同时OpenClaw 还提供 loop detection 配置用来检测重复工具调用、无进展轮询、ping-pong 等模式。(OpenClaw)可以理解为Tool policy 决定 exec 是否出现 Exec approvals 决定具体命令是否需要批准 Loop detection 防止 Agent 在工具调用中陷入死循环。这三层一起构成工具安全边界。17. Gateway 层的工具接口tools.catalog除了 Agent 内部使用工具OpenClaw Gateway 也暴露了一些工具相关方法。第一个是tools.catalog官方协议文档说明operator 可以调用tools.catalog获取某个 Agent 的 runtime tool catalog响应中包含 grouped tools 和 provenance metadata例如source: core 或 plugin pluginId optional(GitHub)源码中对应文件src/gateway/server-methods/tools-catalog.ts从源码看tools.catalog会构造 core groups也会在需要时构造 plugin groups插件工具会带上source: plugin、pluginId、optional、risk、tags、defaultProfiles等元信息。(GitHub)可以理解为tools.catalog 告诉你系统里“理论上有哪些工具”。它更像工具目录。18. Gateway 层的工具接口tools.effective第二个是tools.effective官方协议文档说明tools.effective用于获取某个 session 的 runtime-effective tool inventory它要求sessionKey并且 Gateway 会从 session 服务端推导 trusted runtime context而不是接受调用者随意传入 auth 或 delivery context。(GitHub)源码中对应src/gateway/server-methods/tools-effective.ts从源码看它会加载 session entry解析 session agent读取 delivery context、model provider、model id、message provider、channel、thread、group 等上下文然后调用resolveEffectiveToolInventory返回当前会话实际可用的工具。(GitHub)可以理解为tools.effective 告诉你当前这个 session “现在真正能用哪些工具”。它和tools.catalog的区别是tools.catalog 全局目录视角。 tools.effective 当前会话视角。例如catalog 里有 exec 但当前 session 是 guest toolsBySender deny 了 exec sandbox policy 又屏蔽了 runtime 所以 effective 里可能没有 exec。这也是排查“为什么模型看不到某个工具”的关键方法。19. Gateway 层的工具接口tools.invoke第三个是tools.invoke官方协议文档说明tools.invoke可以通过同一套 Gateway policy path 调用一个可用工具参数包括name、args、sessionKey、agentId、confirm、idempotencyKey等返回是带有ok、toolName、output或 typed error 的 SDK-facing envelope。(GitHub)源码中对应src/gateway/server-methods/tools-invoke.ts从源码可以看到tools.invoke会校验参数检查工具名然后调用invokeGatewayTool如果工具调用成功返回ok: true、toolName、output、source如果被策略拦截或需要批准则返回ok: false和错误结构。(GitHub)另外OpenClaw 也提供 HTTP 形式的/tools/invokeendpoint。官方文档说明它使用 Gateway auth 加 tool policy并且和 WebSocket Gateway 复用同一端口。(OpenClaw)可以理解为tools.invoke 让外部 operator / SDK 通过 Gateway 直接调用工具但仍然走策略、审批和错误封装。20.tools.catalog、tools.effective、tools.invoke的区别这三个方法可以这样区分tools.catalog 看工具目录。 tools.effective 看当前 session 真正可用工具。 tools.invoke 调用一个工具。对应流程想知道系统有哪些工具 ↓ tools.catalog 想排查当前会话为什么看不到某工具 ↓ tools.effective 想从外部直接调用工具 ↓ tools.invoke这三个接口对应了工具系统的三个维度发现 诊断 执行。21. Tool Search大工具目录的解决方案当工具数量很少时可以把所有工具 schema 都发给模型。但当 OpenClaw 接入很多插件、MCP server、客户端工具时工具目录会变得很大。如果每次都把所有工具 schema 塞进模型上下文会产生几个问题请求变大 规划变慢 成本增加 模型更容易误选工具 无关工具污染上下文。OpenClaw 提供 Tool Search 来解决这个问题。官方文档说明Tool Search 的思路是模型不需要一开始看到每个完整 schema而是先搜索 compact descriptors再 describe 某个具体工具获取完整 schema最后 call 该工具。(OpenClaw)可以画成大工具目录 ↓ 压缩成 compact descriptors ↓ 模型调用 tool_search ↓ 找到候选工具 ↓ 调用 tool_describe ↓ 拿到精确 schema ↓ 调用 tool_call ↓ 执行真实工具这是一种“按需加载工具 schema”的设计。22. Tool Search 的运行过程官方文档把 Tool Search 的运行过程分为几步1. 解析当前 Agent、profile、sandbox、session 的有效工具策略。 2. 列出 eligible OpenClaw 和 plugin tools。 3. 列出 eligible MCP tools。 4. 加入当前 run 的 client tools。 5. 建立 compact descriptors 索引。 6. 向模型暴露 code bridge 或 structured fallback tools。真实工具调用最终仍然回到 OpenClaw Gateway并继续走正常的 policy、approval、hook、logging 和 result handling。(OpenClaw)这点很重要。Tool Search 并不是绕过工具策略而是改变工具暴露方式直接暴露 模型一次性看到所有工具 schema。 Tool Search 模型先看到搜索接口再按需加载工具 schema。所以 Tool Search 更适合MCP 工具很多 插件工具很多 一个 session 可能访问多个外部系统 工具 schema 很长 模型经常误选无关工具。23. 一次工具调用的完整链路可以用一个例子串起来。用户说帮我看一下这个项目为什么启动失败必要时修改配置文件。OpenClaw 中可能发生用户消息进入 session ↓ Agent run 启动 ↓ createOpenClawCodingTools 构造候选工具 ↓ 读取 tools.profile coding ↓ 应用 tools.allow / tools.deny ↓ 应用 provider policy ↓ 应用 sender policy ↓ 应用 sandbox tool policy ↓ 最终模型看到 read、exec、edit 等工具 ↓ 模型调用 read 读取 package.json ↓ 模型调用 exec 运行启动命令 ↓ exec 可能触发 approval ↓ 命令输出返回 tool result ↓ 模型分析错误 ↓ 模型调用 edit 修改配置 ↓ 模型再次 exec 验证 ↓ 生成最终回复这条链路说明工具系统不是简单的函数调用 它同时包含工具构造、工具过滤、权限控制、执行环境、审批、日志和结果回传。24. 初学者容易混淆的几个点24.1 Tool 不是 SkillTool 是动作 Skill 是指导动作的说明。例如exec 是 Tool “如何调试 Node 项目”是 Skill。24.2 Plugin 不等于 ToolPlugin 可以注册 Tool 但 Plugin 还可以注册 Channel、Provider、Hook、Skill 等。24.3 catalog 不等于 effectivecatalog 表示工具目录 effective 表示当前会话真实可用工具。一个工具出现在 catalog 中不代表当前 session 能调用。24.4 sandbox 不等于 tool policysandbox 决定在哪里运行 tool policy 决定能不能看到和调用。即使 sandbox 关闭tool policy 仍然可以禁用工具。24.5 elevated 不是万能权限elevated 只影响 sandboxed exec 的执行位置 它不能绕过 tool policy 它也不直接授予其他工具能力。25. 源码阅读建议这一期建议重点看这些文件第一组工具集合构造 src/agents/pi-tools.ts src/agents/openclaw-tools.ts src/agents/pi-tools.types.ts src/agents/pi-tools.schema.ts 第二组工具策略 src/agents/tool-policy.ts src/agents/tool-policy-shared.ts src/agents/tool-policy-pipeline.ts src/agents/pi-tools.policy.ts src/agents/sender-tool-policy.ts src/agents/pi-tools.message-provider-policy.ts 第三组文件与命令工具 src/agents/pi-tools.read.ts src/agents/tools/exec-tool.ts src/agents/tools/process-tool.ts 第四组OpenClaw 内置工具 src/agents/tools/message-tool.ts src/agents/tools/cron-tool.ts src/agents/tools/gateway-tool.ts src/agents/tools/sessions-list-tool.ts src/agents/tools/sessions-send-tool.ts src/agents/tools/subagents-tool.ts src/agents/tools/web-tools.ts 第五组Gateway 工具接口 src/gateway/server-methods/tools-catalog.ts src/gateway/server-methods/tools-effective.ts src/gateway/server-methods/tools-invoke.ts src/gateway/tools-invoke-shared.ts 第六组Tool Search src/agents/tool-search.ts docs/tools/tool-search.md阅读时可以带着这些问题1. createOpenClawCodingTools 接收了哪些上下文参数 2. 基础工具、OpenClaw 工具、Plugin 工具分别在哪里创建 3. tools.profile 是在哪里转换成具体工具列表的 4. allow / deny 的优先级在哪里体现 5. provider policy 如何影响工具集合 6. sender policy 如何识别不同用户 7. sandbox tool policy 在什么阶段生效 8. tools.catalog 和 tools.effective 返回内容有什么区别 9. tools.invoke 如何复用 Gateway policy path 10. Tool Search 如何避免把所有 schema 一次性发给模型26. 我的理解我认为 OpenClaw 的 Tool 系统有三个值得学习的设计点。第一它没有把“工具列表”设计成静态配置而是根据当前 agent、session、channel、sender、provider、sandbox、plugin 状态动态生成。这样可以让同一个 Gateway 支持多用户、多会话、多平台、多权限场景。第二它把工具权限前置到模型调用之前。模型只能看到被允许的工具 schema这比“模型先看到工具调用时再拒绝”更安全也能减少误选工具。第三它把工具能力分成多个层次Tool profile 定义基础能力范围。 Tool policy 定义允许和拒绝规则。 Sandbox 定义执行环境边界。 Elevated 定义 exec 的受控逃逸能力。 Approval 定义高风险命令是否需要人工确认。 Tool Search 定义大规模工具目录的暴露方式。所以 OpenClaw 的工具系统不是一个简单的 function calling wrapper而是一套完整的 Agent capability control plane。27. 本期重点理解这一期可以总结为五点第一Tool 是 Agent 可调用的动作函数Skill 是使用工具的说明Plugin 是扩展 OpenClaw 能力的模块。 第二OpenClaw 内置工具覆盖 runtime、fs、web、browser、messaging、sessions、automation、gateway、media 等多个能力面。 第三createOpenClawCodingTools 会根据 agent、session、channel、sandbox、provider 和 plugin 状态动态构造工具集合。 第四Tool policy 决定模型能看到哪些工具deny 优先于 allowprofile 和 group 用来简化工具配置。 第五tools.catalog、tools.effective、tools.invoke 分别对应工具发现、当前会话诊断和外部调用。一句话概括OpenClaw 的工具系统本质上是一个动态能力控制层它决定 Agent 在当前上下文中“能做什么、在哪里做、由谁批准、如何记录结果”。28. 本期小结本期主要分析了 OpenClaw 的 Tools 工具系统。OpenClaw 通过 Tool 把模型连接到文件、命令、浏览器、消息、会话、自动化、媒体生成和插件能力。工具集合不是静态暴露给模型而是由createOpenClawCodingTools根据当前 Agent、Session、Channel、Provider、Sandbox 和 Plugin 状态动态构造。随后Tool policy 会根据 profile、allow/deny、provider policy、sender policy、sandbox policy 等规则过滤工具最终只把允许的工具 schema 暴露给模型。Gateway 侧还提供tools.catalog、tools.effective和tools.invoke分别用于工具目录查看、当前会话可用工具诊断和外部工具调用。对于大型工具目录Tool Search 通过搜索、描述、调用三阶段机制避免一次性暴露所有工具 schema。这一期可以用一句话总结Tool 让 Agent 具备行动能力Tool policy 让这种行动能力可控Tool Search 让大规模工具能力可管理。下一期可以继续分析OpenClaw 源码解析十二Skills 技能系统与 Agent 行为约束下一期重点看SKILL.md的加载机制、技能目录结构、frontmatter 配置、技能过滤条件、技能如何进入 Agent prompt以及 Skill 和 Tool 如何配合形成稳定的工作流。