OpenClaw 的工具：它的强项到底在哪里

引言

留住一个 Agent 的，不是它说了什么，而是它手里能做什么。OpenClaw 的“手”是一套完整的工具系统——浏览器、终端、文件、消息通道、定时任务、子智能体——它决定了从“问一句答一句”到“独立跑活儿”之间所有能力的差别。

本文把这套工具按类别拆开，说明每一类是什么、强在哪里、弱在哪里，以及“组合起来”之后和别的 Agent 有什么区别。

一　一个 Gateway，三类“手”

OpenClaw 的官方文档把能力界面分成三层：

• 工具（Tools）——智能体可以调用的类型化函数：exec、browser、read、write、message 等。这是“手”。
• 技能（Skills）——加载进提示词的 SKILL.md 指令包，教智能体“什么时候做什么、怎么做”。这是“工作方式”。
• 插件（Plugins）——可以添加新的工具、渠道、模型提供商、钩子等运行时能力的包。这是“脚手架”。

这三层是分开的：工具决定“能做什么”，技能决定“按什么流程做”，插件决定“还能长出什么新胳膊”。这个分离本身就是开源项目的设计哲学——核心不动，能力挂在外面。

二　内置工具：AI 的“手脚”清单

官方把内置工具分成十一个类别，下面按“干什么活”来数一遍。

2.1　运行时类：跑命令、管进程

exec、process、terminal、code_execution 这一组是“手”。exec 跑一条 shell 命令，process 管理后台进程，terminal 对接交互式 CLI，code_execution 跑模型支持语言（如 Python）的片段。这一组的边界是“能碰宿主机的进程和文件”。

2.2　文件类：读写工作区

read、write、edit、apply_patch。前三个是单文件操作，apply_patch 是多文件 diff 式修改。文件操作默认在沙箱范围内工作区，跨出要去掉沙箱策略。

2.3　Web 类：联网

web_search、x_search、web_fetch。搜网页、搜 X（推特）帖子、抓可读的页面内容。注意，这一类和“浏览器”是两回事——web_fetch 拿的是“文档”，browser 拿的是“活的网页”（操作 DOM、截图、多标签页）。

2.4　浏览器类：操作活的网页

browser 工具可以让智能体开一个独立的 Chrome/Brave/Chromium 配置文件，通过本地控制服务（只走 loopback）操作：导航、点击、填表、截图、多标签页切换。关键点是“独立 profile + loopback 隔离”——它不碰使用者日常的浏览器，也不会把使用者的个人 Cookie 带进自动化里。

2.5　消息与渠道类：把话说出去

message 工具让智能体往已配置的渠道（Telegram、WhatsApp、Discord 等）发回复、执行渠道操作。一个 Gateway 同时服务所有已协商好的渠道插件，这是“多通道”的具体落地。

2.6　会话与智能体类：多脑协作

sessions_*、subagents、agents_list、session_status 以及 create_goal/update_goal。sessions_* 让你查看、向其他会话发信；subagents 在当前会话内派生子任务、隔离地跑完；Swarm 则允许用代码编排多个智能体并发。这一组是把“一个虾”变成“一队虾”的那层。

2.7　自动化类：定时与事件

cron、heartbeat_respond。cron 负责“定时”——跑 cron 表达式、一次性 at、固定间隔、事件触发器脚本；heartbeat_respond 让智能体参与 Gateway 的心跳唤醒。这是全天 7 乘 24 小时干活的关键——用户不用守在边上，虾自己会到点起床。

2.8　Gateway 与节点类：看自己的状态

gateway、nodes。gateway 工具给智能体看当前 Gateway 的运行状态、配置；nodes 看已配对的 iOS/Android 设备、执行 Canvas、相机等节点能力。

2.9　媒体类：输入输出都带上

image、image_generate、music_generate、video_generate、tts。能读图、生图、生音乐、生视频、把文字转语音，反向也可以。多模态这一组让“虾”不只是打字机器，还能发声音、发图、发文件。

2.10　工具搜索与代码模式：大 catalog

当工具数量上来之后，所有 schema 直接塞进提示词代价很高。tool_search 让智能体在大型工具目录里“找工具”，code_mode 让智能体在一个紧凑程序里写代码然后组合调用多个工具。这两组是给未来“几十上百个工具都装着”用的。

2.11　人工输入类：停下来问人

ask_user 让智能体在中间停下、向用户要一个结构化决定（选择题、多选、文本）。这是 Agent 和人类的“咳嗽点”——重要的岔路口让人拍板，而不是让模型自作主张。

三　浏览器工具：最常见的“能说”场景

在工具篇里，“会做”是用户感知最强的一类，因为它是“回答并解决了问题”的直接证明。浏览器自动化在公开资料里也最被讨论。

3.1　架构

OpenClaw 的浏览器不是“去连使用者正在用的浏览器”，而是在 Gateway 里跑一个独立的 Chrome/Brave/Edge/Chromium 配置文件，由一个小控制服务接管，只走 loopback（127.0.0.1）。它和使用者个人浏览器完全隔离，不共享 Cookie、不共享历史、不共享书签。

3.2　能干什么

公开资料里反复出现的几条典型能力：导航到指定页面、点击/填写表单、跑 JS 注入、全页截图与元素截图、多标签页切换、等待选择器出现、抓取页面文本。这条链组合起来，是“打开一个网站 → 登录 → 抓取数据 → 发回消息”这种线性任务的标准件。

3.3　三种 CDP 模式

CDP（Chrome DevTools Protocol）是浏览器自动化的地基，OpenClaw 提供了三种模式：默认模式（自动管理）、attach 模式（附着到用户已打开的浏览器）、无头模式（只跑、不显示窗口）。三种模式按“隔离需要”和“速度需要”取舍，实战里按具体任务挑。

3.4　边界

浏览器工具“能做什么”并不等于“什么都能做”。重 JS 渲染的 SPA、验证码、需要登录态的页面，仍然是 Agent 的软肋；安全上，执行 JS 注入的能力也意味着一旦提示词被污染，潜在风险是实打实的。这些边界是使用者和设计者都要知道的。

四　定时任务：让虾自己到点起床

定时任务这类，在退潮论文第五章 5.2 里提过（30 天使用报告、新会话位置），工具篇这里补上一层“实现机制”。

4.1　表达式与触发器

cron 工具支持四种调度：一次性 at（某时刻）、固定间隔 every（N 毫秒一次）、cron 表达式（本地时区或 IANA 时区）、触发器脚本（每次到点执行一个脚本，返回 { fire: true } 才真正跑）。触发器脚本是最灵活的一档：你可以先跑个 Python 查天气，等“温差 >20 度”才唤醒 Agent，而不是“每天固定 8 点”。

4.2　会话侧绑定

定时任务的输出可以走“主会话事件”（systemEvent），也可以走“隔离会话”（isolated agentTurn），还可以绑到当前会话、或者独立命名会话。每种绑定对代价和可见性不同：主会话最方便但会污染主线；隔离会话干净但需要 delivery 配置。任务写得越早、底下的会话选择越清楚。

4.3　为什么不是“到点就乱跑”

一个常见的痛点是“定时任务跑飞了”。OpenClaw 的设计里，cron 只能建任务、不能自己改配置；任务外观变化（如失败告警、暂停）必须走另一个 channel（如 message 工具）通知到，而不是 Agent 自己换脑子。这是“自动化编排”和“Agent 自主决策”的边界线——前者套路固定，后者要跑循环。

五　多通道：从“放在那儿”到“随时叫得回”

退潮论文里，我把“多通道”当留存的关键特性，这里把它的实现机制写清楚。

5.1　Gateway 是唯一的接入点

用户的设备（Mac mini、家里的 VPS、办公室的 Node）只跑一个 Gateway 进程。这个 Gateway 同时挂着所有渠道插件——Telegram、WhatsApp、Discord、Signal、Slack、飞书 等等。消息从任何一个渠道进来，都会被路由到同一个 Agent。这意味着：不用为了“下班路上看一眼”再部署一个，所有设备、所有渠道，全部汇到同一个 Gateway 上。

5.2　入口其实是 5 种

除聊天渠道外，还可以从：CLI、Web Control UI、macOS 菜单栏应用、移动端节点（iOS/Android）进入同一个 Agent。对一个维护多设备的中大型项目来说，“在哪台机器上都能喊它干活”是被反复验证过的价值。

5.3　路由和隔离

同一个 Gateway 里，不同渠道、不同发送者、不同群聊，都可以映射到不同的会话（sessions_*）。这是多智能体路由：一个主 Agent 服务个人 chat，另一个佐 Agent 群聊 @ 时才触发，所有的事都不串。

六　子智能体：一队虾，而不是一个虾

6.1　为什么要子智能体

一个任务拆不开、不许串上下文的场景，需要子智能体。比如“10 家供应商报价抓完，再做一轮比较”——十个抓点开子会话并行，主会话等结果、做汇总。在 OpenClaw 里，sessions_spawn 负责派生，sessions_yield 负责等回，subagents 负责实时可见性。

6.2　隔离与约束

子智能体可以带 lightContext（少一些上下文，少一点内存占）、spawn 时指定工作区、模型、鉴权源。更紧的约束来自“按 Agent 配置的沙箱 + 工具限制”——你可以给一个子 Agent 只开 read/web_fetch 工具、不给写文件。这样“抓 10 个报价”的子会话不可能误改主工作区。

6.3　Swarm 模式

Swarm 是用代码写“编排脚本”，“程序化地”调起 n 个 Agent，然后决定后续的循环。和 sessions_spawn 的“对话式派生”不同，Swarm 面向的是“已知形状、规模明确”的并行任务。两者不冲突，按任务的形状二选一。

七　把工具组合起来：为什么“会干活的虾”是别的 Agent 给不了的

前几章拆了单件工具，这一章把几个组合写出来。组合出来的东西，才是“留存用户”实际在用的形态。

7.1　定时任务 + 浏览器 + 消息 = 全天 7 乘 24 小时站岗

每天早上 8 点 → cron 唤醒 → 用浏览器登录一个后台系统、抓某个页面 → 用 web_fetch 读页面 → 用 message 工具把摘要发到 Telegram。这条链不需要用户在边上，也不需要为每条任务单独写脚本。

7.2　子智能体 + 文件 + 代码执行 = “并行工作流”

一个任务拆 5 个子会话 parallel 跑 → 结果写进工作区的 .json → 主会话用 code_execution 跑 Python 做合并 → 把最终的 Markdown 发回去。这是“一个虾干一个小团队活”的标准件。

7.3　多通道 + 多 Agent + 隔离会话 = “桥”

一个 Gateway 同时挂着五个渠道、三个 Agent → 每个 Agent 有工作在时区上的偏差，会话按 Agent 隔离、数据也按 Agent 隔离。这类组合是 OpenClaw 在 5 月被叫做“自托管 AI 网关”的核心含义。

结语　工具篇的结论

把上面全部长起来，OpenClaw 的“工具篇”能给到用户三句话：

• 它的工作方式不是“聊天 + 插件”，而是“Gateway + 工具 + 多通道”。这是和其他 LLM 套壳产品的本质区别——它不只是“会打字”，它是“真的会做事”。
• 它每一次“手能伸多长”，都取决于给它的三个鉴权：exec（碰宿主能不能）、file（工作区之外的文件能不能写）、browser（独立 profile 能不能打开）。这三个边界心里有数，虾的上下限心里就有数。
• 它的组合能力（Sub-Agent + Cron + 浏览器 + 多通道）通过了“能不能真干活”的校验。退潮论第六章写的那一类“留下来的虾”，用的是这一组合。

参考来源

• OpenClaw 官方文档——工具概览（zh-CN）
  https://docs.openclaw.ai/zh-CN/tools
• OpenClaw 官方文档——浏览器工具（en）
  https://docs.openclaw.ai/tools/browser
• OpenClaw 官方首页（英文）
  https://openclaw.ai/
• 腾讯云开发者社区《OpenClaw 内置工具详解》（2026-05-08）
  https://cloud.tencent.com/developer/article/2666020
• CSDN《NAS 上部署 Openclaw：用 Agent 打造浏览器自动化与智能任务管家》（2026-08-31）
  https://blog.csdn.net/weixin_32306957/article/details/164237597
• Aurora LHL《A Deep Dive into OpenClaw》（2026-03-22，架构详解）
  https://auroralhl.github.io/blog/2026/openclaw-deep-research/