OpenClaw 这类浏览器能力，如果只是当成“让 AI 打开网页”的插件，很快就会遇到两个问题。第一，Agent 每次都在临时描述任务，边界不稳定。第二，浏览器能做的动作太多，读页面、搜索、点击、输入、下载、提交都混在一起，权限很难管。更稳的做法，是把 OpenClaw 能力拆成几个小工具，再用 MCP 这类协议接给 Agent。这样 Agent 看到的不是一个大而全的浏览器，而是一组边界清楚的工具：读网页、找链接、展开内容、提取字段、生成待确认清单。先不要把“控制浏览器”做成一个工具很多人接 MCP 工具时，会想做一个万能工具：browser_control(action, url, selector, text)看起来灵活，实际很危险。因为这个工具几乎什么都能做：打开页面、点按钮、填输入框、提交表单、下载文件，甚至在登录状态里改配置。对 Agent 来说，工具越万能，越容易乱用。它可能为了完成任务自己推断 action，也可能在 selector 不稳定时继续尝试别的按钮。最后你很难判断问题出在模型、工具参数、页面状态，还是任务本身写得太宽。我更建议把浏览器能力拆小：工具允许做什么不允许做什么fetch_page读取公开网页正文不执行登录态动作search_web搜索候选页面不把结果当事实inspect_page读取页面标题、链接、按钮、表单结构不点击提交类按钮extract_fields按字段表提取可见内容不补全没看到的信息expand_readonly点击 FAQ、折叠面板、目录跳转不保存、不发布、不发送这样做的好处是：每个工具都能单独测试，也能单独限权。Agent 想做高风险动作时，工具层本身就不会给它入口。MCP 工具参数要窄，不要让模型自由发挥MCP 工具最容易踩坑的地方，是参数写得太宽。比如你给 Agent 一个参数：{"instruction":"你想怎么操作都写在这里"}这等于把安全边界交还给自然语言。模型当然能理解很多指令，但它也会误解、漏看、补全，尤其是在网页状态变化后。我更喜欢把参数设计成这种结构：{"url":"https://example.com/docs","mode":"read