为什么 Tools 很难一下讲明白
因为它混在了三个层次里：一层是“模型会不会调用”，一层是“系统允不允许它调用”，还有一层是“就算允许，调用到什么范围为止”。大多数误解，都出在把这三层混成一句话：“这个 Agent 有没有工具能力？”
第一层：模型层
模型知道有哪些工具，什么时候应该调用它们，参数怎么组织。
第二层：权限层
OpenClaw 的策略决定这些工具当前是否可用，是否要审批，是否只允许某些路径或某些命令。
第三层：运行边界
即使工具打开了，它也可能只能在工作区里读文件，只能访问 allowlist 命令，或者只能在沙箱里跑。
第四层：任务方法
Skill 决定的是“怎么用这些工具把事做对”，不是简单给一个按钮。
Tool 和 Skill 到底有什么区别
一句话说清：Tool 是手，Skill 是手法。
- Tool：原子能力接口，比如
read、exec、web_search、browser、message。 - Skill：围绕某类任务的一整套工作方法，比如网页诊断、文档生成、天气查询、长任务管理。
- 同一个 Skill 往往会调多个 Tool；而同一个 Tool 可以被不同 Skill 复用。
最常见的 Tools，可以这样理解
文件类
read / write / edit：读写工作区文件，是最基础也最容易被忽视的生产力能力。
命令类
exec / process：真正去跑 shell 命令、查看后台进程、管理长任务，是高风险能力。
联网类
web_search / web_fetch：搜索与抓取网页，适合做外部信息补充，但同样要防注入与误导。
浏览器类
browser / canvas：直接操作网页和可视界面，能力强，但暴露面也更大。
通信类
message：发消息、回消息、反应、线程回复。它不是“输出文本”而是“真正触达外部世界”。
平台集成类
如 Feishu doc/drive/wiki、Bitable、memory、session orchestration 等，往往带有具体平台语义。
为什么安全上默认要收紧
因为 Tools 一旦打开，不再只是“聊天”。它会把模型的判断延伸到命令执行、文件改写、浏览器操作、外部发送、真实系统状态改变。OpenClaw 官方安全文档明确把它定义为个人助理信任模型：一个网关默认服务一个信任边界，而不是给互不信任的人共用一套强工具权限。
结合 OpenClaw 文档和当前版本设计，可以把默认收紧理解成三层：
- 入口收紧：DM pairing、allowlist、groupPolicy，不是谁都能直接叫醒 Agent。
- 工具收紧：高风险工具需要审批、allowlist、沙箱或宿主策略配合，尤其是
exec。 - 环境收紧：推荐一个 trust boundary 一个 gateway/host，不鼓励混合信任的大共享部署。
从安全角度看，当前版本默认会收紧哪些东西
这里我不写成“绝对所有版本都完全一致”的口吻，而是按当前官方文档能确认的方向说明：
exec不是只改tools.exec.*就万事大吉。主机侧还有单独的~/.openclaw/exec-approvals.json作为可执行来源约束，主机 approvals file 才是最终可执行真相的一部分。- Node / host exec 是最高风险能力之一。官方形式化安全模型明确把 node exec pipeline 作为最高风险路径来建模，要求命令 allowlist、声明命令以及审批令牌协同工作。
- 群组与 DM 默认更偏向 allowlist / pairing。例如 Feishu、IRC、Slack、BlueBubbles 等文档里，大量默认项都是 allowlist 或 pairing，而不是完全开放。
- 一些交互能力默认关闭。例如 Slack 原生 interactive reply controls 默认关闭；某些 channel-native approvals 或高级交互能力也需要显式启用。
- workspace hooks 默认关闭。CLI 文档明确写了 workspace hooks 默认 disabled，避免一上来就让文件变化自动触发复杂动作。
- OpenClaw 鼓励最小权限与安全审计。
openclaw security audit会专门检查开放 group policy、开放 gateway auth、过宽 exec approvals、开放工具暴露等常见脚枪。
需要时怎么打开，才算相对稳妥
1）先看策略，不要只看页面开关
尤其是 exec，很多人看到 dashboard 或配置里设成 security: full、ask: off，以为就结束了。实际上根据官方 approvals 文档，主机上的 approvals file 仍然会参与最终生效结果。
2）先做审计，再做放开
这一步不是形式主义。它能帮你先看到：是不是 group policy 开太大了、gateway auth 太松了、sandbox 没开、browser 暴露面太宽了、exec approvals 过于宽松了。
3）只对需要的能力做精确放开
- 要让本机命令更少弹审批：优先调
openclaw approvals或openclaw exec-policy，而不是粗暴全开所有工具。 - 要开放群聊：优先 allowlist 指定 sender / group，不要直接 open 给所有人。
- 要发本地媒体：优先配置明确的 local roots，而不是让任意绝对路径都能发。
- 要启用交互按钮：明确只在可信 DM 或指定群组里开。
4）如果一定要 YOLO，至少知道自己在牺牲什么
官方 approvals 文档确实提供了 full + off 的“never prompt / YOLO” 方式，但它的含义是：这个 host 基本不再因 exec 审批拦你。对单人、本机、可控环境可以接受；对共享环境、公开入口、高价值主机就不合适。
OpenClaw 首页里应该怎么说明 Tools
首页不该直接把 Tools 解释成“系统很多插件”。更合适的说法应该是：
最后总结
如果把 OpenClaw 比作一个人：
- Agent 是这个人；
- Memory / Workspace 是他的记忆与工作台；
- Skill 是他形成的方法论；
- Tools 则是他真正能拿起来干活的手和器具。
也正因此，Tools 既最强，也最需要被解释清楚、被单独管理清楚。