今天的 OpenClaw 已经把很多能力做成了 first-class tools。官方文档里直接写到：这些 tools replace the old `openclaw-*` skills。所以要进入扩展阶段，第一步不该是到处找 Skill，而是先看系统原生到底已经会哪些动作。
先用一句话理解 Tools
Tools 是 OpenClaw 原生暴露给 agent 的 typed tools，也就是系统可以直接调用的动作接口。它们不是“教程型说明书”，而是系统本身的能力面。
官方文档里最重要的两个结论
- 当前内置工具已经覆盖 browser、canvas、nodes、cron 等核心能力。
- 工具可以通过
tools.profile、tools.allow、tools.deny、tools.byProvider等配置做精细限制。
先看 4 个最容易理解的能力面
Browser
打开页面、点击、输入、截图、导出 PDF，很多“网页类需求”的第一入口。
Canvas
偏可视化和画布工作面，适合需要结构化展示和画布操作的场景。
Nodes
把某些动作路由到外部节点主机执行，更偏复杂执行流。
Cron
做定时和周期性自动化，是“让它自己按时做事”的关键一层。
更实用的是“工具组”这层
官方配置参考里给出了按功能归类的工具组：
group:runtime：exec、processgroup:fs：read、write、edit、apply_patchgroup:sessions：会话查询、发送、派生、状态group:memory：记忆搜索与读取group:web：web_search、web_fetchgroup:ui：browser、canvasgroup:automation：cron、gatewaygroup:messaging：messagegroup:nodes：nodesgroup:openclaw：所有内置工具
官方内置的 4 个工具 profile
minimal
- 只保留
session_status - 最克制
- 适合极简场景
coding
- 文件、运行时、会话、记忆和图片能力
- 很适合本地项目和开发环境
messaging / full
messaging以消息和会话相关能力为主full不做基础限制- 别默认一上来就开 full
这也是为什么“开全部工具”从来不是最稳的做法。很多场景其实先用 coding 或 messaging 就够了。
Tools 还有一层安全和策略意义
官方的工具策略是分层收紧的：先设基础 tools.profile，再按 provider / model 用 tools.byProvider 继续收窄，最后再用 tools.allow 和 tools.deny 做显式放行或禁止。
也就是说，Tools 不只是功能列表，它本身就是一层安全和策略面。
什么时候优先看 Tools，而不是先装 Skill
- 你需要的是动作能力，而不是流程模板。
- 你想先确认系统到底能不能读网页、发消息、跑命令、读写文件。
- 你遇到的是权限和工具边界问题，而不是“任务方法”问题。