OpenClaw 和 MCP 怎么接：把浏览器能力做成 Agent 可控工具

OpenClaw 这类浏览器能力，如果只是当成“让 AI 打开网页”的插件，很快就会遇到两个问题。

第一，Agent 每次都在临时描述任务，边界不稳定。第二，浏览器能做的动作太多，读页面、搜索、点击、输入、下载、提交都混在一起，权限很难管。

更稳的做法，是把 OpenClaw 能力拆成几个小工具，再用 MCP 这类协议接给 Agent。这样 Agent 看到的不是一个大而全的浏览器，而是一组边界清楚的工具：读网页、找链接、展开内容、提取字段、生成待确认清单。

先不要把“控制浏览器”做成一个工具

很多人接 MCP 工具时，会想做一个万能工具：

1	browser_control(action, url, selector, text)

看起来灵活，实际很危险。因为这个工具几乎什么都能做：打开页面、点按钮、填输入框、提交表单、下载文件，甚至在登录状态里改配置。

对 Agent 来说，工具越万能，越容易乱用。它可能为了完成任务自己推断 action，也可能在 selector 不稳定时继续尝试别的按钮。最后你很难判断问题出在模型、工具参数、页面状态，还是任务本身写得太宽。

我更建议把浏览器能力拆小：

工具	允许做什么	不允许做什么
`fetch_page`	读取公开网页正文	不执行登录态动作
`search_web`	搜索候选页面	不把结果当事实
`inspect_page`	读取页面标题、链接、按钮、表单结构	不点击提交类按钮
`extract_fields`	按字段表提取可见内容	不补全没看到的信息
`expand_readonly`	点击 FAQ、折叠面板、目录跳转	不保存、不发布、不发送

这样做的好处是：每个工具都能单独测试，也能单独限权。Agent 想做高风险动作时，工具层本身就不会给它入口。

MCP 工具参数要窄，不要让模型自由发挥

MCP 工具最容易踩坑的地方，是参数写得太宽。

比如你给 Agent 一个参数：

1	{"instruction": "你想怎么操作都写在这里"}

这等于把安全边界交还给自然语言。模型当然能理解很多指令，但它也会误解、漏看、补全，尤其是在网页状态变化后。

我更喜欢把参数设计成这种结构：

{
  "url": "https://example.com/docs",
  "mode": "read_visible_text",
  "fields": ["title", "h1", "pricing", "faq", "last_updated"],
  "allow_same_origin_links": false,
  "include_uncertain_items": true
}

这里每个字段都在减少自由度。

url 明确页面范围。
mode 明确只读还是可展开。
fields 限定输出目标。
allow_same_origin_links 控制是否能继续跳转。
include_uncertain_items 要求把没确认的内容列出来。

这不是为了让工具“不智能”，而是为了让它更可控。Agent 负责思考任务，工具负责稳定执行一个小动作。

返回结果要给证据，不只给总结

浏览器工具返回结果时，不要只返回一段总结。

总结很舒服，但不好审计。你不知道它从哪里读到，也不知道哪些内容没读到。更稳的返回结构应该包含三类信息：

读到的字段。
字段来自页面哪个区域。
不确定或缺失的内容。

比如：

{
  "url": "https://example.com/pricing",
  "status": "partial",
  "fields": {
    "title": {"value": "Example Pricing", "source": "title"},
    "pricing": {"value": "未确认", "source": "not_visible"},
    "faq": {"value": ["Can I cancel?", "Is there a free plan?"], "source": "visible_faq"}
  },
  "uncertain_items": [
    "价格表可能需要点击 monthly/yearly tab 才完整显示",
    "页面没有显示更新时间"
  ]
}

这个结构比“这个页面主要介绍了定价方案”有用得多。因为后续 Agent、脚本或人工都能继续处理它。

如果你要把 OpenClaw 接到 Claude Desktop、Cursor 或其他 Agent 工作台里，这种结构化返回会比自然语言总结更稳。前置的 OpenClaw 能力分层，可以先看 OpenClaw 怎么用：让 Agent 读网页、查资料和控制浏览器；本篇只讨论怎么把这些能力拆成工具。

只读工具和可点击工具分开

浏览器任务里，最重要的分界线不是“能不能打开网页”，而是“会不会改变页面状态”。

只读工具可以放宽一点。它最多读错、漏读、总结差一点。可点击工具就要谨慎，因为点击可能触发弹窗、筛选、分页，也可能触发提交、保存、购买、删除。

我会把点击再拆成两类。

第一类是展开型点击：FAQ、折叠面板、标签页、页内目录、加载更多。这类点击通常只改变当前页面展示，不影响外部状态。

第二类是提交型点击：保存、发布、发送、购买、删除、授权、创建账号。这类默认不做工具，或者只做“识别风险并停下”。

工具名也应该体现这一点。比如 expand_readonly_section 比 click_button 好，因为它把工具意图写死了。

selector 不稳定时不要让 Agent 猜

浏览器自动化经常会遇到 selector 失效。

按钮文案变了，页面结构变了，弹窗挡住了，元素还没加载出来，旧 snapshot 过期了，这些都会让工具执行失败。

失败时，最差的设计是让 Agent 自己继续猜下一个 selector。它可能越猜越偏，最后点到完全不该点的地方。

更好的做法是让工具返回明确状态：

{
  "status": "blocked",
  "reason": "target_not_found",
  "visible_buttons": ["Subscribe", "Start trial", "Contact sales"],
  "next_action": "human_review_required"
}

这样 Agent 不需要装作自己知道。它可以把问题交回给人，或者换成只读分析。

给每个工具做权限分级

如果把 OpenClaw 能力接进 MCP，我会给工具分三级。

等级	能力	默认策略
L1	fetch、search、读取可见文本	可自动执行
L2	打开托管浏览器、展开只读内容、提取字段	任务内明确允许才执行
L3	输入文本、登录态页面、文件下载、提交前检查	必须人工确认

注意，L3 不是说永远不能做，而是不能让 Agent 默认做。尤其是登录态页面和真实账号页面，一定要先把工具限制清楚。

如果任务真的需要填表，我也建议工具停在提交前，只返回“字段检查”和“风险提示”，不要直接点击提交。