OpenClaw 里最容易被混着用的三类工具，就是 Web、Browser 和 Exec。很多新手以为“能做的越多越好”，于是本来只需要读一段网页文本，也直接开浏览器或执行命令；结果不是成本变高，就是权限开得过大。
真正稳的做法不是先问“哪个最强”，而是先问“这次任务到底属于哪一层”。
一个最简单的记忆方法
你可以先记住这一句：
Web：读网页Browser：操作网页Exec：操作系统
这三类能力并不是平级替代关系，而是从轻到重、从低风险到高风险逐层升级的。
先用任务目标来选工具，而不是用习惯来选
很多人选错工具，不是因为不知道名字，而是没先拆任务。判断时可以按下面这三个问题走：
- 我只是要读取公开信息吗
- 我需要像真人一样点击、输入和跳转吗
- 我需要碰本地文件、命令行或宿主机环境吗
如果答案分别对应“是”，那大概率就分别落在 Web、Browser、Exec 上。
Web：适合读取公开网页和文档
Web 更适合做轻量读取，例如：
- 查看官方文档
- 抽取网页正文
- 获取公开页面信息
- 做快速搜索、引用和比对
它的几个优势很明显：
- 成本低
- 速度快
- 交互简单
- 风险相对更小
如果你的目标只是“知道页面写了什么”，通常先用 Web 就够了。比如查 API 文档、确认产品定价页内容、汇总一篇博客的重点，这些都没必要一上来就开浏览器。
Web 不适合做什么
Web 很适合读，但不擅长“真实交互”。下面这些情况它通常就不够用了：
- 页面内容需要登录后才能看到
- 数据依赖前端脚本动态加载
- 需要点击分页、下拉菜单、弹窗
- 需要填写表单再拿结果
这时候不是 Web 坏了，而是任务已经从“读取”升级成“交互”。
Browser：适合需要真实交互的网页场景
Browser 比 Web 更重，但也更接近真人操作。它适合：
- 点击按钮
- 输入表单
- 滚动页面
- 处理多步 UI 流程
- 在真实浏览器上下文里查看页面状态
典型场景包括：
- 登录后的页面操作
- 后台管理台点击流程
- 需要连续 UI 交互的网页自动化
- 需要确认页面元素是否真实出现
也就是说，当“读页面”不够，你真的要“操作页面”时，才值得上 Browser。
Browser 的常见代价
Browser 好用，但不是没有成本。它通常会带来：
- 更慢的启动与执行时间
- 更高的失败敏感度
- 更多状态问题，比如登录态、弹窗、重定向
- 更复杂的调试过程
所以只有在交互确实不可避免时，用 Browser 才是赚的。
Exec：适合命令、脚本和系统层动作
Exec 是这三者里风险最高的一类，因为它不再停留在网页，而是直接进入执行环境。它更适合：
- 跑命令
- 调脚本
- 使用系统工具
- 修改文件
- 做目录、环境变量或构建级操作
这类能力的价值非常大，但它依赖审批、沙箱和允许列表，不能只靠“模型会不会乖”来约束。
什么任务才算真的需要 Exec
下面这些情况，通常就已经进入 Exec 的职责范围：
- 你要读写本地文件
- 你要运行
npm、python、git之类命令 - 你要调用本机二进制程序
- 你要检查进程、端口、目录或环境变量
如果任务结果必须来自操作系统本身，而不是网页，那就是 Exec 的场景。
为什么很多问题都来自“选错工具”
如果只是看网页内容，却直接上 Browser 或 Exec，通常会带来几个连锁问题：
- 成本和复杂度不必要地上升
- 排错路径变长
- 安全边界被放得太大
- 审批次数变多，使用体验变差
例如：
- 查官方文档，用
Web就够了 - 填网页表单，才需要
Browser - 修改本地文件或跑脚本，才应该考虑
Exec
很多“工具不好用”的抱怨，最后发现其实不是工具本身有问题，而是任务一开始就选错了层级。
一个推荐顺序
绝大多数任务都应该优先尝试：
- 先
Web - 不够再
Browser - 只有必须碰系统层时再
Exec
这个顺序非常重要，因为它天然对应：
- 复杂度递增
- 权限递增
- 风险递增
如果团队里每个人都遵守这个顺序，后面审批策略和排错流程都会轻松很多。
三个常见场景，怎么判断最省事
场景一：查 SDK 文档
目标只是确认参数、错误码或示例。
- 选
Web - 不需要
Browser - 更不需要
Exec
场景二：登录后台点一遍配置流程
目标是完成真实网页操作。
- 优先考虑
Browser - 只有涉及下载文件、解压或运行本地脚本时，才继续引入
Exec
场景三：修改项目配置并运行测试
目标已经进入本地工程和命令行。
- 选
Exec - 如果还要顺便查官方文档，可以把
Web作为辅助
这个判断方式很朴素，但特别实用。
什么时候一定不要直接上 Exec
下面这些情况下，直接上 Exec 通常都不是好习惯：
- 只是想看网页内容
- 只是想确认某个公开文档里写了什么
- 只是需要简单的站内读取
- 只是为了“图省事”把一切都丢给命令行
如果你把 Exec 当成通用入口，后面很容易把很多本来低风险的问题，硬生生抬成高风险操作。
什么时候 Browser 比 Web 更值得
如果你遇到下面这些情况，通常就说明该上 Browser 了：
- 需要登录后页面
- 需要点击菜单或按钮
- 页面内容是动态加载的
- 需要提交表单或多步交互
- 需要观察页面上某个元素有没有真正出现
这时 Web 往往只能读到静态层，而 Browser 才能完整模拟用户操作。
什么时候 Exec 才真正必要
真正适合 Exec 的，通常是这类任务：
- 修改文件
- 执行 CLI 命令
- 调用本地脚本
- 使用系统工具完成动作
- 构建、测试、部署或诊断工程环境
这时它的价值不在于“更强”，而在于它终于进入了网页之外的真实执行层。
一个避免走弯路的检查清单
每次动手前，你可以快速过一遍：
- 我要的是信息，还是动作
- 如果是动作，是网页动作还是系统动作
- 有没有更轻、更低权限的工具可以先试
- 这一步是否会触发审批或更高风险权限
只要这四个问题想清楚，工具选择通常就不会偏得太离谱。
一条很好用的经验
以后你不确定该用哪种工具时，先问自己一句：
“我现在是要读信息、操作网页，还是操作系统？”
这个问题一回答出来，工具选择通常就清楚了。真正成熟的使用习惯，不是默认上最强工具，而是始终选刚刚够用的那一个。