简介
除了简单的 API 集成,OpenClaw 在与图形用户界面交互时还具有深刻的能力。使用 Computer Use 模型标准(由 Claude 3.5 Sonnet 普及),您的本地代理可以控制 Chromium 实例执行复杂的视觉导航。
本教程涵盖从设置本地 Chrome 测试环境到编写健壮的网络爬取提示流程的所有内容。
1. 前置条件
- •OpenClaw v1.3.0 或更新版本。
- •支持 Vision + Computer Use 工具的 LLM(如 Anthropic 模型或专业本地模型如 Qwen2-VL)。
- •主机上已安装 Google Chrome 或 Chromium。
2. 启用浏览器工具
在 OpenClaw 配置文件(~/.openclaw/config.json)中,确保浏览器能力已启用。
3. "坐标与点击"工作流
与传统的基于 DOM 的爬虫(如 Puppeteer 或 Playwright)不同,OpenClaw "看"屏幕。它获取截图,计算您想要的按钮的 X/Y 坐标,并移动虚拟鼠标点击它。
示例:表单填写
您可以自然地提示代理:
4. 处理验证码
因为 OpenClaw 通过真实的浏览器配置文件操作,它自然避免了许多基本的机器人检测脚本。但对于可见的验证码,您有两个选项:
- 1.人机协作:添加提示指令:"如果遇到验证码,暂停执行并请求我来解决。":
- 2.API 解决方案:将第三方解码器技能与浏览器技能集成。:
5. 提取数据(视觉爬取)
无需解析复杂的 HTML 嵌套表格,您可以要求 OpenClaw 以可视化方式构建数据。
故障排除
- •点击未命中目标:确保显示缩放设置为 100%。分数缩放(150%)可能会混淆坐标映射。:
- •"找不到可执行文件":验证配置中的 browser_path 与系统 Chrome 安装路径完全匹配。:
选哪个 profile,各自的代价是什么
这是浏览器自动化里决定其他一切的选择,而且它首先是个安全决策,其次才是能力决策。托管 profile 是隔离的、功能完整的;挂载你自己的 Chrome 会把你已登录的会话交给 Agent,同时反而砍掉一部分能力。
| 托管 "openclaw" profile | 挂载已有 Chrome 会话 | |
|---|---|---|
| 登录状态 | 没有。你在隔离 profile 里重新登录。 | 你的,在每个站点上都已生效。 |
| CSS 选择器操作 | 可用 | 不可用 |
| PDF 导出、下载捕获 | 可用 | 不可用 |
| 需要有人在电脑前 | 不需要 | 需要——Chrome 会弹出阻塞式的「允许远程调试?」 |
| 一条错误指令的影响范围 | 限于一个用完即弃的 profile | 你真实会话能触达的任何站点 |
除非有具体理由,否则用托管 profile。挂载已有会话这个模式,是为「重新登录确实不现实」的场景准备的;应该把它理解为「把你已登录的浏览器交给 Agent」,而不是一个图方便的选项。
先跑起来,并确认它真的跑起来了
浏览器以控制服务的形式跑在网关内部的回环地址上,驱动的是 Chromium 系浏览器——Chrome、Brave、Edge 或 Chromium 本身。一开始让窗口可见;headless 是个不错的生产设置、却是个糟糕的首次运行设置,因为成功和失败在无头模式下长得一模一样。
{
browser: {
enabled: true,
headless: false,
defaultProfile: "openclaw",
},
}看着浏览器动,是分辨「Agent 选择不动手」和「浏览器服务根本没起来」最快的方式。等你信任它之后再把 `headless` 打开。
openclaw config patch --file ./browser.json5 openclaw gateway restart
控制服务是跟着网关一起启动的。改了 browser 这块配置,不重启不生效——「我改了但没反应」里有相当一部分是这个原因。
# Then ask for something that requires a real page load, e.g. # "open example.com and tell me the heading" # # Watch the window. If nothing opens, the service did not start — # check the gateway log before changing any other setting.
问一个模型靠自己的知识答不上来的问题。一个它不上网也能答的问题,它就不会上网,你也就什么都验证不到。
收窄它被允许做的事
有两个设置承担了大部分有意义的加固工作。两个默认都不开,因为它们都是拿能力换安全,而合适的平衡点取决于你让 Agent 去访问什么。
{
browser: {
evaluateEnabled: false,
ssrfPolicy: "strict",
},
}`evaluateEnabled` 允许 Agent 在页面里执行任意 JS。这对抓取结构别扭的站点确实有用,同时它也是浏览器工具里权限最宽的一项。关掉它,看看你实际会做的事有没有哪件真的坏掉。`ssrfPolicy` 则把导航限制在受信主机上——当页面内容能影响 Agent 下一步去哪时,这一条最要紧。
{
browser: {
profiles: {
work: { cdpPort: 9222 },
},
},
}一个带独立 `cdpPort` 的命名 profile,至少能把挂载范围限定在你有意启动的那个浏览器实例上,而不是碰巧开着的任意一个 Chrome 窗口。
浏览器自动化里最容易咬人的地方
- ✗页面内容是不可信输入。页面里可以写着对 Agent 说的话,而一个「先浏览、再行动」的 Agent,是可以被网站指挥的。
- ✗挂载已有会话意味着 Agent 就是已登录的你。凡是你的浏览器不用重新认证就能做的事,它都能做。
- ✗headless 不是更安全,只是更看不见。等行为验证过之后再用它,而不是在你还没搞清 Agent 会做什么的时候。
- ✗在自动化下会坏掉的站点通常坏得很安静——页面加载了、选择器什么都没匹配到,然后 Agent 汇报它看到的内容,而不是汇报它失败了。