OpenClaw 接入 Chrome 这件事最近在 AI 自动化圈子里讨论度明显上来了。简单说OpenClaw 是一个开源的、可以部署在自己机器上的个人 AI 助手框架它能记住上下文、调用工具、执行任务而把 Chrome 浏览器接进去之后这个助手就不再是“只会聊天的机器人”而是能真正打开网页、翻页面、填表单、抓信息、点按钮的“数字员工”。我在这条路上折腾了大概两周把 Windows 下的 WSL2 环境、Node.js、Chrome 调试通道全部跑通也踩了至少五六个文档里不会写的坑。这篇东西就是给同样想试水 OpenClaw 接 Chrome 的读者一套可复现的路径顺便把那些“卡住十分钟其实只是一个小参数没对”的问题一次性讲清楚。无论你是想让它定时抓数据、自动操作后台系统还是单纯好奇 AI 控制浏览器怎么落地这篇文章都应该对你有用。1. 为什么是 OpenClaw Chrome先想清楚再动手1.1 OpenClaw 的核心定位OpenClaw 是一个开源的个人 AI 代理框架它把大模型和外部工具之间的调用关系做成了统一接口。很多人第一次听说它是因为它跟“电脑使用”这个概念有关——AI 不只是回答你而是能替你在本机执行操作。它跟那些只能在网页里跑的聊天机器人最大的区别就是它真的有一双“手”。OpenClaw 背后的运行方式并不神秘一个部署在本机或者云服务器上的服务端负责调度模型、管理记忆、注册工具然后通过 MCPModel Context Protocol模型上下文协议把工具暴露给模型去调用。为什么这两年大家开始关注这类项目因为大模型本身的“文字推理”能力已经足够强了但在真实世界里做事还需要“感知环境—做出决策—执行动作—观察结果”的闭环。OpenClaw 做的就是把闭环里的“感知”和“执行”两端接上。浏览器、终端、文件系统、甚至笔记软件都可以作为它的外挂工具。所以你会发现OpenClaw 并不是一个“浏览器专用”的软件它只是把浏览器变成了它最重要的一类工具。对我这种每天要处理大量网页操作的人来说这就意味着以前要写脚本、做定时任务、搞爬虫的活现在可以用自然语言去指挥 AI 完成。1.2 为什么偏偏选 Chrome 而不是其他浏览器选择 Chrome 来做 AI 的浏览器不是因为它“最好用”而是因为它最容易控制。Chrome 对外提供了两种关键的自动化接口一套是 Chrome DevTools Protocol也就是 CDP通过一个调试端口就能对浏览器做几乎一切操作——打开页面、点击元素、读取 DOM、截图、执行 JS另一套是扩展机制配合本地桥接工具还能做更多宿主层面的交互。更关键的是基于 Chromium 内核的自动化生态非常成熟Playwright、Puppeteer 这些工具天生就是为它准备的。相比之下其他主流浏览器的自动化支持虽然也在进步但要么是调试协议的完整度不够比如无法覆盖所有 DOM 操作要么是官方没有提供稳定的远程调试模式。做 AI 自动化控制这种需要高频、准确、可回溯的操作时选 Chrome 是最稳的一条路。你不用为了适配浏览器的“个性”多写代码CDP 接口就是通用标准。我见过有人尝试用其他浏览器接入最后大多还是回到 Chrome因为在真实的项目中稳定压倒一切。1.3 三层链路组成的整体架构我实际跑通后把 OpenClaw 接 Chrome 的整体架构归纳为三条链路。第一条是模型链路OpenClaw 服务端负责调起大模型把用户指令翻译成工具调用序列第二条是工具链路服务端通过 MCP 协议连接浏览器控制服务这个控制服务直接面对 Chrome第三条是浏览器链路Chrome 以调试模式启动对外暴露 WebSocket 接口接收控制指令并把页面状态返回给上层。这三条链路任何一条断了整体就不可用。我在这两周踩过的坑里有三分之一是模型配置问题三分之一是工具服务没起来剩下三分之一是 Chrome 本身的调试环境没对。所以这篇博文的实操部分我会沿着这三条链路依次配置而不是把步骤打乱着来。你把架构记住之后后面的每一条命令、每一个配置项你都能清楚地知道它到底服务于哪条链路排查问题的时候就能快速定位到底是模型的问题、MCP 服务的问题还是 Chrome 的问题。1.4 它到底能干什么三类典型的浏览器任务为了让你对这个组合的实际价值有更具体的感知我把它能做的事情大致分成三类。第一类是信息抓取类让 AI 打开多个网页按你的要求提取特定字段最终汇总成表格或报告。比如每天早晨让 AI 登录行业资讯站抓取前十条热点标题整理发到你的笔记里。第二类是流程操作类让 AI 登录后台系统、录入数据、点击菜单、提交表单。很多公司的内部系统没有开放 API以前只能靠人工录入现在可以让 AI 按固定流程操作比如每天把邮件里的订单信息录入到 ERP。第三类是测试验证类让 AI 对页面做冒烟测试、点击关键按钮、截图对比这个对前端开发者尤其有用。场景类型典型输入输出难度信息抓取“打开 A、B、C 三个页面提取价格字段并对比”结构化表格或报告低流程操作“把这个 CSV 里的数据逐条录入系统”操作用时与成功记录中测试验证“访问主页点击登录按钮截图”截图与操作日志中当然你也可以把这三类组合起来做更复杂的工作流。比如“每天定时打开后台导出昨天的销售数据整理成邮件草稿”。OpenClaw 接 Chrome 之后这些任务就不再依赖你从早到晚盯着页面手动操作了。2. 部署前的硬性条件WSL2、Node.js、Chrome 怎么准备2.1 在 PowerShell 里先把 WSL2 状态查明白如果你是在 Windows 上部署 OpenClaw第一个拦路虎一定是 WSL2。OpenClaw 的服务端通常跑在 Docker 容器里而 Windows 上的 Docker Desktop 依赖 WSL2 作为后端。很多新手一上来就报错大概率是因为 WSL2 没装好或者默认版本不对。我建议在动手前先打开 PowerShell直接执行wsl --status这个命令会告诉你当前 WSL 内核版本、默认分发版等关键信息。如果系统提示“WSL 正在通过 Microsoft Store 更新”或者找不到内核那就需要先执行更新命令wsl --update wsl --set-default-version 2然后安装一个 Linux 发行版比如 Ubuntu。这里要特别提醒一点WSL2 和 WSL1 的差别不只是版本号前者是真正的轻量虚拟机网络和文件性能更接近原生 LinuxDocker Desktop 在 WSL2 上跑才稳定。如果你查到默认版本是 1建议先改过来否则后面安装 OpenClaw 依赖包时会遇到一堆权限和路径问题。我就见过有人在 WSL1 环境下硬装 Docker结果每次重启都要重新初始化极其痛苦。WSL2 装好之后还有一个小技巧建议你单独建一个用于 OpenClaw 的发行版实例不要和你日常开发环境混在一起。用以下命令可以查看当前已有实例wsl --list --verbose如果只有默认的 Ubuntu那就够了。后续 Docker Desktop 会和这个实例绑定不建议频繁切换或删除。2.2 Node.js 装哪个版本、为什么必须装很多教程里会把 Node.js 一笔带过但它其实是接 Chrome 能不能跑通的关键依赖。为什么 OpenClaw 会和 Node.js 扯上关系因为很多 MCP 服务器包括控制 Chrome 的那几个官方实现都是用 Node.js 写的运行时、工具注册、WebSocket 通信都依赖它。所以你的机器上必须有一个能用的 Node.js 环境。我这里直接说结论装 LTS 版本就好比如 Node.js 20 或 22。不要装太新的尝鲜版也不要装太老的版本。MCP 相关包对 Node 版本有最低要求但更高的版本偶尔会踩到原生模块编译的坑。安装方式很简单去 Node.js 官网下载对应安装包一路下一步就行如果你已经在用 WSL2也可以在 Ubuntu 里通过 nvm 来管理版本两边保持同大版本即可。建议装好后在命令行里验证node -v npm -v能正常输出版本号就说明环境基础这关过了。另外要注意 PATH 环境变量尤其在 Windows 上有些人装完 Node.js 之后发现 npx 命令找不到就是因为 PATH 没有包含 Node.js 的安装目录。这个细节会在你第一次启动 MCP 服务时直接暴露出来。2.3 Chrome 版本与调试端口先统一认知Chrome 本身大家都有但 OpenClaw 接入 Chrome 需要的是那个“开启调试模式的 Chrome 实例”。这里有两个容易混淆的点一个是调试端口一个是独立的用户数据目录。调试端口默认用 9222Chrome 启动后会在 http://localhost:9222/json 上暴露一个页面列表这就是 CDP 的入口。用户数据目录则建议单独设置一个比如 automation-profile避免和日常浏览器的登录状态、缓存互相干扰。启动命令大概长这样chrome.exe --remote-debugging-port9222 --user-data-dirC:\openclaw\automation-profile --no-first-run这里有一个常见的认知误区你不能靠“普通地打开 Chrome”来让 OpenClaw 连上必须带着调试参数启动的 Chrome 才会监听调试端口。我最早就是忘了这一步OpenClaw 那边怎么配置都连不上后来才发现 Chrome 根本没开调试监听打开任务管理器一看进程发现所有 Chrome 实例都是普通模式。这个问题我会在后面的常见问题章节再详细讲。2.4 端口与网络规划谁在监听谁部署时你需要对端口做一个小规划。OpenClaw 服务端本身占一个端口MCP 服务可能占一个Chrome 的调试端口又是另外一个。我用一个简单的表格把端口视图列出来组件默认端口说明OpenClaw 服务端根据版本配置通常是 3000 或 8080提供对话界面和 APIchrome-devtools-mcp无固定监听端口作为客户端连接 Chrome通过本地 WebSocket 与 Chrome 通信Chrome 调试端口9222对外提供 CDP 接口这里最值得注意的问题是如果 OpenClaw 服务端是跑在 Docker 容器里的那么容器里的 MCP 服务要访问宿主机的 Chrome需要小心网络模型。在 WSL2 下Docker 容器通常可以通过host.docker.internal这个主机名访问宿主机所以你在给 OpenClaw 配置 MCP 服务时可以把 Chrome 的地址写成http://host.docker.internal:9222而不是http://localhost:9222。localhost在容器内部指向的是容器自己不是你的 Windows 宿主机。这个坑不提前说清楚后面连不上你大概率会一头雾水。3. 三条接入 Chrome 的通道DevTools MCP、Playwright、Companion3.1 Chrome DevTools MCP控制 Chrome 的经典方案Chrome DevTools MCP 是目前连接 OpenClaw 和 Chrome 最推荐的通道。它本质上是把 CDP 的能力封装成 MCP 标准工具这样 OpenClaw 通过 MCP 协议调用时不需要知道 CDP 具体怎么发消息。比如它提供browser_navigate、browser_click、browser_type、browser_snapshot这样的工具名OpenClaw 的大模型只要知道“导航到 url、点击选择器、输入文本”这些语义即可。用起来非常直接先启动带调试端口的 Chrome再通过 npx 启动 MCP 服务npx chrome-devtools-mcplatest这个服务默认会去连 9222 端口的 Chrome。配置在 OpenClaw 里注册为 MCP server 之后模型就能调用浏览器工具。我实测下来的感觉是这套方案响应速度快、操作稳定特别适合“打开某网页、提取特定信息、点某个按钮”这类任务。而且因为它直接控制的是你本地真实 Chrome所以已有的登录态、代理设置、书签都能复用这一点在实际工作中非常宝贵。你不需要为 AI 单独维护一套登录体系。3.2 Playwright MCP要速度与批量时的选择另一条通道是 Playwright MCP。Playwright 是行业里非常成熟的浏览器自动化框架它不只是控制 Chrome还能控制 Chromium、Firefox、WebKit 等浏览器。Playwright MCP 的服务端也是用 npx 启动npx playwright/mcplatest这方案的好处是Playwright 本身有非常强的选择器引擎和等待机制AI 在复杂页面上不容易“点空”。比如页面上有动态加载的内容Playwright 会自动等待元素出现又比如某些按钮是通过 JS 事件绑定的Playwright 也能正确处理。缺点也很明显它启动的是自己的浏览器实例而不是你日常打开的 Chrome等于 AI 在一个“全新”环境里工作cookies、登录状态那些都要重新来。所以如果你想让 AI 操作一个你已经登录的系统用 Playwright 方案就得先想办法把登录态导入进去反而多了一步。我的看法是如果你要做一个独立的自动化小工具不依赖任何历史登录状态Playwright MCP 很合适如果你是让 AI 帮你处理日常工作流比如操作你已经打开的后台页面那还是用 Chrome DevTools MCP 更自然。两条通道并不冲突你完全可以在 OpenClaw 里同时注册两个 MCP server按任务需要去调用。3.3 Companion 与浏览器扩展面向桌面窗口的场景还有一种场景是要控制宿主机上已经打开的浏览器窗口本身比如你已经登录了某个后台系统希望 AI 在上面操作。这时候纯粹靠 CDP 就不太够因为很多交互是窗口级的。OpenClaw 在这种场景下会提供一个 Companion 类型的配套组件本质上是一个浏览器扩展加一个本地桥接服务。配置方法大致是在 Chrome 扩展管理页chrome://extensions/打开开发者模式加载已经下载好的扩展目录扩展会与本地桥接服务建立连接OpenClaw 服务端再通过这个桥接服务发送控制指令。这个方案对 Windows 用户尤其有意义因为 Docker 容器里的 OpenClaw 默认接触不到宿主机的桌面窗口。Companion 就是一座桥把容器内的 AI 指令和宿主机的浏览器界面打通。配置的时候要注意三点第一扩展版本要和 OpenClaw 服务端版本匹配不然协议对不上第二本地桥接服务要常驻运行如果用完就退出AI 下一次调用浏览器时又得重新握手第三扩展权限尽量给最小化只让它访问必要的页面数据不要把所有站点都交给 AI 去读。3.4 选型决策清单直接告诉你选哪个为了让你不纠结我直接给一个选型清单方案适用场景优点缺点Chrome DevTools MCP通用网页任务要登录态、要稳定直接复用日常 Chrome操作真实页面需要手动启动调试模式端口冲突时要排查Playwright MCP独立自动化、批量数据抓取、跨浏览器自带等待机制元素定位强独立浏览器环境无日常登录态Companion/扩展桌面窗口级操作、需要控制真实界面能处理窗口级交互配置相对多需要装扩展我的经验是第一次玩从 Chrome DevTools MCP 入手做完第一个任务之后再按需求去试另外两种。别一上来就三个全配配置多了反而不好排查问题。4. 完整实操从零跑通 OpenClaw 控制 Chrome4.1 第一步启动一个带远程调试端口的 Chrome这一步是整个流程的地基。在 Windows 上我建议直接写一个 bat 文件放在 OpenClaw 的工作目录里每次启动双击一下就行里面填上完整的启动命令echo off C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9222 --user-data-dirC:\openclaw\automation-profile --no-first-run --no-default-browser-check启动之后先在浏览器里访问http://localhost:9222/json/version如果看到一段 JSON里面有Browser版本和 WebSocket 地址说明调试端口已经正常打开。这个验证动作一定要做因为它能确认 Chrome 是真的挂着调试模式而不是你想象中它已经挂上了。这里有个细节很多人会纠结要不要在这个自动化 Profile 里登录账号。我建议把常用登录态准备好因为 OpenClaw 控制的其实就是这个指定目录的 Chrome登录一次之后AI 后续操作都能自动复用。但要注意不要用主浏览器的 Profile 去开调试端口否则日常浏览和 AI 操作会互相干扰你敢让 AI 在你登录着支付账户的浏览器里随便点击吗独立 Profile 是底线。4.2 第二步在 OpenClaw 里注册 MCP 服务OpenClaw 服务端运行起来之后需要把浏览器控制服务注册进去。不同版本的 OpenClaw 配置入口略有差异有的在图形界面里有的在配置文件里。以配置文件方式为例你需要在 OpenClaw 的配置中心找到 MCP Servers 区域新增一个条目{ mcpServers: { chrome-devtools: { command: npx, args: [chrome-devtools-mcplatest], env: {} } } }保存并重启 OpenClaw 服务。判断是否注册成功可以看 OpenClaw 的日志通常会出现类似MCP server connected: chrome-devtools的提示。如果连接失败先确认 npx 是能全局调用的也就是说 PATH 环境变量里要有 Node.js 的目录。你可以直接在终端里再敲一次npx chrome-devtools-mcplatest看它能不能正常启动如果这里有报错那就跟 OpenClaw 没关系纯粹是 Node.js 环境的问题。4.3 第三步配置可用的模型OpenClaw 默认配置里可能绑定的是某个云端模型但实际使用中你也可以把它指向本地模型。以 qwen2.5 为例如果你是用 Ollama 在本地起模型那么 OpenClaw 的模型配置可以写成类似这样以下只是结构参考字段名以你版本为准model: provider: openai-compatible base_url: http://localhost:11434/v1 model_id: qwen2.5:7b api_key: ollama这里要提醒一句小参数模型做简单问答没问题但要让它稳定完成“打开网页、分析内容、点击元素”这种多步骤任务能力会吃紧。我实测下来小模型容易在中途“忘记”自己正在执行浏览器任务会转而去编答案。所以配置模型时优先选工具调用能力强的模型。如果你手头有更强的模型接入渠道那就优先用强的工具调用。浏览器自动化任务对模型“在正确时机调用正确工具并传对参数”的要求很高这比写一篇作文难多了。4.4 第四步用一句话指挥浏览器干活一切就绪后在 OpenClaw 的对话界面里直接输入一句自然语言任务。比如请打开 example.com在搜索框里输入“OpenClaw”然后截图给我看结果。这句话会经过模型链路、工具链路、浏览器链路最终变成 Chrome 里一连串真实操作。如果配置正确你能在 Chrome 窗口里亲眼看到页面自动跳转、输入文字、点击按钮整个过程就像有人在远程操作你的浏览器。我甚至可以告诉你在日志里你会看到模型依次调用了browser_navigate、browser_snapshot、browser_type这些工具每调用一次就是 AI 在真实世界里“动”了一下。我第一次跑通的时候还是挺有成就感的。但我复盘了一下其实“能跑通”和“能稳定用”之间还有距离。如果要让 AI 完成一个十几步的长任务建议把大任务拆成多个小指令每步确认结果这样会可靠很多。比如先让它打开页面并返回标题确认无误后再让它找输入框、填数据然后再让它提交。分段确认既能降低出错概率也能在出错时快速定位到底是哪一步出了问题。4.5 关键日志与状态验证怎么判断它真的连上了实操中判断是否真的连通有几个检查点。第一个是 Chrome 的/json/version接口能返回 JSON第二个是 chrome-devtools-mcp 启动后没有报错第三个是 OpenClaw 日志里出现 tool call 记录第四个是对话里 AI 能回答出浏览器当前页面的标题或 URL。具体而言当 AI 回答的内容里带有“我已经打开了 example.com页面的标题是……”时说明它已经通过工具拿到了真实页面状态。如果它回答得含糊其辞比如“我觉得应该打开了”那就要怀疑是不是工具调用根本没生效。我建议你把这四个检查点写进自己的操作笔记里以后排查问题会快很多。不要只看对话界面那个最终回答前端展示会“美化”很多东西要看日志里的原始 tool call 记录那个才是真正的执行真相。5. 常见问题排查与避坑实录5.1 WSL2 状态报错请在 PowerShell 里跑 wsl --status很多第一次在 Windows 上跑 OpenClaw 的朋友会遇到这样一段提示大意是“WSL 环境无法安全验证请在 PowerShell 中运行 wsl --status”。这个问题的本质是 WSL2 子系统没有正确初始化Docker Desktop 检测不到可用的 WSL 后端。这里的“无法安全验证”和网页证书、网络完全没关系它是在说 WSL 虚拟化环境本身没有被系统正确识别。解决步骤我整理成一条线打开 PowerShell执行wsl --status看当前状态如果显示异常执行wsl --shutdown把 WSL 彻底重启然后执行wsl --update更新内核重新打开 Docker Desktop在设置里把“Use the WSL 2 based engine”勾上。这四步能解决九成以上的 WSL 初始化问题。还有一小部分情况是电脑上确实没安装任何 Linux 发行版Docker 没有可用的子系统那就要先装一个 Ubuntu。装完之后再次运行wsl --status确认状态是“Default Version: 2”这一关才算真正过去。5.2 CDP 连接失败端口、版本和进程三重排查如果你配置没问题但 OpenClaw 一直说连不上浏览器按这个顺序排查第一步用netstat -ano | findstr :9222确认 9222 端口有监听第二步访问http://localhost:9222/json/version看是否有 JSON 返回第三步检查 Chrome 版本和 chrome-devtools-mcp 的兼容性老版本 Chrome 对某些新协议字段支持不好第四步检查是不是有残留的 Chrome 进程占用了 user-data-dir建议用任务管理器把相关进程全部关掉再重试。这个过程中最常被忽略的是“残留进程”。你以为你关了 Chrome但很多后台扩展进程还在跑它们占着 Profile 目录导致新启动的调试实例起不来。解决方式就是任务管理器里把所有 chrome.exe 进程全部结束再重新用 bat 命令启动。5.3 提示“无法安全验证”的页面怎么办在自动化过程中如果 AI 访问的站点证书过期或者不是受信任的机构签发Chrome 会拦截并显示安全警告页此时页面上的元素是无法正常交互的。处理思路有两个一是在独立调试目录里通过 Chrome 的设置把这类站点加入例外二是仅在测试环境里提醒 AI 使用该站点的 HTTP 版本。这里我特别强调千万不要为了省事全局关闭证书校验那会把自动化环境暴露在极大风险里。你让 AI 操作的可是你真实机器上的真实浏览器一旦关闭安全校验意味着任何中间人和恶意页面都有可能截获或篡改数据。正确做法是针对特定站点做例外而且要缩小到最小范围。做自动化的前提永远是安全边界第一。5.4 模型开始“胡编乱造”给 AI 设定操作边界使用小模型或未微调的模型时经常出现任务执行到一半AI 突然开始总结“我已经完成了”但实际上什么都没干的情况。原因大多是模型没有获得准确的工具返回值或者上下文太长把初始目标冲淡了。我的做法是在 OpenClaw 的配置里给浏览器工具增加使用约束每执行一步必须读取当前页面的关键状态不允许在没有打开页面的情况下直接回答“页面内容”遇到加载超时先截图再判断。这些约束看起来像“规则”其实就是提示词工程的一部分。你可以把这类约束挂在系统提示词里也可以在每次任务描述里加一句“先做完再回答”。我更推荐前者因为改一次所有任务都能生效。另外如果你发现模型频繁调用错误的工具名大概率是因为 MCP 服务注册的工具描述信息不完整可以尝试更新 MCP 包版本新版本工具描述通常更详尽。5.5 自动化过程中的页面稳定性问题最后聊一个细节点很多网站会检测自动化特征或者频繁弹窗、跳转验证码这会让整个流程断掉。我的经验是尽量让 AI 完成核心操作后人再接手处理验证码等环节而不是指望 AI 能搞定所有反自动化机制。另外给点击操作加延迟模拟更自然的人类节奏能减少一部分风控误判。具体怎么做呢你可以在 OpenClaw 的工具调用配置里设置操作间隔或者在给 AI 的指令里明确写“每次点击后等待 0.5 秒再执行下一步”。这个小技巧在登录场景里特别管用连续快速操作非常容易触发风控。还有如果页面中有 iframe 或者 shadow DOM很多自动化工具会拿不到元素这时候你要对页面结构做一个分析而不是反复重试浪费时间。5.6 常见问题速查表我把这一节的所有问题整理成速查表方便你直接对照现象可能原因解决动作WSL 环境无法安全验证WSL2 未初始化执行 wsl --status、wsl --update、wsl --shutdown无法连接 9222 端口Chrome 未带调试参数启动用 bat 文件重新启动独立 Profilelocalhost 连不上Docker 容器内网络隔离改用 host.docker.internal 或宿主机实际 IPnpx 命令找不到PATH 未配置 Node.js重装 Node.js 或手动添加 PATHAI 回答但没执行模型工具调用能力弱换更强模型或增加约束提示词页面元素点击无效动态加载、iframe用 Playwright MCP 或手动拆分步骤端口被占用残留 Chrome 进程任务管理器结束所有 chrome.exe这个表你最好截个图存着实际排障的时候比翻教程快多了。6. 最后分享一点我的实际体会我个人在这两周的实操里最大的体会是OpenClaw 接 Chrome最花时间的不是“接上”而是“稳定地接上”。第一遍配置其实一晚上就能跑通但后面你会不断发现各种小问题——端口占用、WSL 没初始化、模型选择不对、页面加载慢导致 AI 判断失误。这些坑单个都不大排起来却特别浪费时间。我后来养成了一个习惯每次改一个配置都先做一次最小验证——只开一个页面、只做一步操作——确认链路没断再往上加复杂度。这个习惯帮我省了大量时间。另外想给还没有动手的朋友一个建议不要一上来就追求“让 AI 帮我完成一整套工作流”先从“让它打开一个网页并把标题返回给我”这种最简单的任务开始。把基础链路跑通、日志看明白后面怎么玩都好说。OpenClaw 接 Chrome 这件事说到底就是给 AI 安装了一双眼睛和一只手但真正教会它怎么用这双手还需要你在反复试错中把各种边界摸清楚。如果你也正在折腾这个过程希望这篇记录能帮你少走几步弯路。