1. 为什么我劝你把浏览器自动化交给 OpenClawOpenClaw 的浏览器自动化能力说白了就是让 AI 像人一样打开网页、点按钮、填表单、抓数据。它底层跑的是 Playwright但对外暴露的是一套更贴近自然语言的工具接口navigate 打开页面、snapshot 拿页面快照、click 点元素、type 输入文字、evaluate 执行 JS、screenshot 截图留证。适合谁适合那些天天跟后台系统、数据看板、需要登录才能看的页面打交道的开发者尤其是你已经用 OpenClaw 跑通了一些 Skill现在想让 AI 真正“动手”而不是只“动嘴”。我试过用纯 API 的方式抓数据遇到需要登录、页面动态渲染、接口有签名校验的场景就特别难受。浏览器自动化的价值在于它不关心你后端怎么实现只要人能点到的AI 基本都能点到。这篇就聚焦落地配置给你一份可复制的 Playwright 接入骨架把 settings.json 里几个关键字段讲透再带你跑一次完整的网页操作验证从配置到执行全流程走通。2. 前置准备TaoToken 接入与 OpenClaw 环境OpenClaw 本身不绑定模型供应商但浏览器自动化里的 snapshot 理解、evaluate 结果分析、多步骤决策都依赖一个稳定的模型后端。我这边用的是 TaoToken 的 API 接入原因是它的接口格式跟主流兼容配置成本低而且模型对话、Coding Plan、API Keys 都有独立入口排障时定位清晰。你需要先拿到 API Key。打开 https://taotoken.net/api-keys 生成一个注意这个 Key 只在创建时完整显示一次复制好放安全的地方。如果你还没决定用哪个模型可以先到 https://taotoken.net/model-chat 试一下对话效果确认模型对页面结构描述的理解能力够用再回来配 OpenClaw。环境侧你需要确认三件事Node.js 版本不低于 18因为 Playwright 对运行时版本有要求OpenClaw 已经装好并能正常启动系统里没有残留的旧版浏览器驱动冲突。如果你之前装过 Playwright 的全局版本建议先清一下缓存避免 OpenClaw 内置浏览器启动时找不到正确的 Chromium 路径。3. 可复制配置settings.json 关键字段与 Playwright 骨架OpenClaw 的浏览器配置集中在 settings.json 的 browser 节点下。下面这份是我实测能跑通的骨架你可以直接抄把注释部分按自己环境改掉。{ browser: { mode: builtin, headless: false, timeout: 30000, viewport: { width: 1440, height: 900 }, userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36, remoteUrl: , cdpUrl: , storageState: /tmp/openclaw-browser-state.json, downloadsPath: /tmp/openclaw-downloads }, model: { provider: taotoken, apiKey: 你的_TAOTOKEN_API_KEY, baseUrl: https://taotoken.net/api, model: claude-sonnet-4-20250514 } }几个字段单独说一下。mode 有三个可选值builtin 用 OpenClaw 自带的 Playwright 浏览器开箱即用cdp 走 Chrome DevTools Protocol连你本机已经登录的 Chrome适合需要保持 Cookie 和 Session 的场景remote 连远程浏览器节点适合服务器批量任务。headless 建议调试阶段设成 false你能肉眼看到 AI 在点什么出问题好定位跑稳定了再改 true 省资源。storageState 这个字段很关键它把登录态持久化到本地文件。你第一次手动登录某个站点后OpenClaw 会把 Cookie 和 localStorage 写进这个 JSON下次启动直接复用不用反复登录。timeout 默认 30 秒遇到重页面可以调到 60000。如果你要用 CDP 模式连本机 Chrome启动 Chrome 时加调试端口macOS 下是这样/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port9222Windows 下换成对应路径Linux 直接google-chrome --remote-debugging-port9222。然后在 settings.json 里把 mode 改成 cdpremoteUrl 填http://localhost:9222。这样 OpenClaw 就能接管你当前打开的标签页登录态天然复用。4. 验证请求跑一次完整的网页操作配置改完重启 OpenClaw我们来跑一个最小验证打开一个页面抓取标题截图再点一个链接。整个过程用 OpenClaw 的 browser 工具链完成。第一步navigate 打开目标页。我选一个结构简单的公开页面做演示避免反爬干扰await browser.navigate(https://example.com, { waitUntil: networkidle, timeout: 30000 })waitUntil 设成 networkidle 表示等网络请求基本静默后再继续比默认的 load 更稳适合动态渲染页面。第二步snapshot 拿页面快照。这一步会返回当前 URL、页面标题、所有可交互元素的结构化描述。AI 靠这个快照决定下一步点哪里const page await browser.snapshot() console.log(JSON.stringify(page, null, 2))你会看到类似这样的输出包含 title、url、以及一个 elements 数组每个元素带 selector、text、type。这就是 AI 的“眼睛”。第三步evaluate 执行 JS 提取数据。比如抓页面所有链接const links await browser.evaluate(() { return [...document.querySelectorAll(a)].map(a ({ text: a.innerText.trim(), href: a.href })).filter(l l.text.length 0) }) console.log(links)第四步screenshot 截图留证方便你回看 AI 当时看到的画面await browser.screenshot({ path: /tmp/openclaw-verify.png })第五步click 点一个元素验证交互链路await browser.click(textMore information) await browser.waitForLoadState(networkidle) const afterPage await browser.snapshot() console.log(afterPage.url)如果 URL 变了说明点击生效整条链路跑通。实测下来从 navigate 到 click 完成整个流程在 5 秒内结束比手动开浏览器点一遍快得多。5. 本篇常见错排查配置和验证过程中最容易卡在几个地方。我按出现频率排一下。第一个浏览器启动失败报 Chromium 找不到。这通常是 Playwright 的浏览器没装全。OpenClaw 内置浏览器依赖 Playwright 的 Chromium 包你可以在 OpenClaw 目录下跑一次安装命令补上。如果之前装过全局 Playwright版本冲突也会导致这个问题清掉全局缓存再让 OpenClaw 自己管理。第二个snapshot 返回空元素列表。页面还没渲染完就抓了。解决办法是在 navigate 之后加 waitForSelector等关键元素出现再 snapshotawait browser.waitForSelector(.main-content, { timeout: 10000 }) const page await browser.snapshot()第三个click 报元素不可见或不可交互。很多网站用动态 class或者元素被遮挡。先用 snapshot 看真实结构优先用文本选择器text登录或 aria 属性[aria-label搜索]比 class 选择器稳。如果元素在 iframe 里需要先切 frame。第四个登录态丢失。检查 storageState 路径是否可写以及你是否在同一个 browser context 里操作。跨 context 不会共享状态。CDP 模式下登录态跟着你本机 Chrome 走一般不会丢。第五个被目标站限流。设置合理的 User-Agent控制访问频率别在循环里高频 navigate。遇到验证码就停下来让用户手动介入这是安全机制不要试图绕过。如果你在接入环节卡住比如 API Key 报错或 baseUrl 配错直接看 https://taotoken.net/doc 的接入文档里面把常见返回码和排查步骤列得很清楚。模型侧的问题比如 snapshot 理解不准可以到 https://taotoken.net/model-chat 换个模型对比一下。6. 长期跑自动化建议上 Coding Plan浏览器自动化一旦跑顺你大概率会想把它做成定时任务或者常驻 Agent比如每天早上抓一次竞品价格、每小时巡检一次后台状态。这种长期编码和 Agent 场景按量计费的 API 调用成本会慢慢上来而且你还需要更稳定的并发和更长的上下文支持。我现在的做法是把长期跑的自动化任务切到 Coding Planhttps://taotoken.net/coding-plan 里有针对持续编码和 Agent 的套餐额度更可控适合这种 7x24 跑的场景。短期验证和调试还是用 API Keys 按量走灵活。两者配合既不浪费额度也不担心任务断掉。配置骨架你已经有了验证流程也跑通了接下来就是把你自己的目标站点填进去调选择器加等待慢慢把 Skill 写厚。浏览器自动化的坑大多在页面结构变化和反爬策略上遇到问题先 snapshot 看现场再截图对照基本都能定位。