在使用 OpenClaw 进行任务自动化时,我们经常会遇到一个棘手的问题:浏览器风控。
OpenClaw 运行在纯净的 WSL2 (Linux Server) 环境中,当它尝试用浏览器访问 Google 或 X (Twitter) 时,往往会被识别为“机器人”或者“可疑设备”。面对 Google 的九宫格红绿灯验证码,或者 X 的“已防止可疑登录”弹窗,运行在后台的 AI 往往束手无策——因为它“看不见”也“摸不着”,更没法像真人一样掏出手机收个验证码。
最完美的解决方案是什么?
不是在那死磕指纹浏览器技术,而是引入Human-in-the-loop(人机协作)。
让 OpenClaw 把浏览器“递”给你,你负责搞定最难的登录和验证码,然后你再把浏览器“还”给 OpenClaw,让它继续执行自动化任务。
今天我在折腾 OpenClaw 时,发现 Windows 11 的 WSLg (WSL GUI) 功能配合 Chrome 远程调试协议 (CDP),竟然能完美实现这种**“人机接力”**。
OpenClaw 在 WSL2 里跑得欢,但只要一上网:
Windows 11 的 WSLg 有个神奇的特性:你在 WSL 里安装的 GUI 软件(比如 Chrome),可以直接在 Windows 桌面以窗口形式运行,就像原生应用一样。
关键点来了:
既然它在 Windows 上有窗口,那我(人类)就可以用鼠标去操作它(过验证码、登录);
既然它本质上还是运行在 Linux 里的进程,那 OpenClaw 就可以通过 localhost 去控制它!
第一步:在 WSL 里安装 Chrome
常规操作,apt install google-chrome-stable 搞定。
第二步:带“私货”启动 Chrome
我们不能直接点图标启动,得用命令行,因为我们要注入两个灵魂参数:
--proxy-server:让它能翻墙(WSL 里这就很关键了)。--remote-debugging-port=9222:开启 CDP 端口,这是 OpenClaw 接管的后门。在 Windows 的 PowerShell 里执行这行命令(注意是用 wsl -e 调用):
wsl -e google-chrome-stable --proxy-server="http://127.0.0.1:7890" --remote-debugging-port=9222 --user-data-dir=$HOME/.config/google-chrome
注:这里使用了 http 代理以获得更好的兼容性。
执行完,你会发现 Windows 桌面上弹出了一个 Linux 版的 Chrome。
第三步:人类进场 (Human-in-the-loop)
这时候,这个浏览器完全归你控制。
x.com。第四步:OpenClaw 接管
保持浏览器不关。现在,可以让 OpenClaw 开始干活了。我让 OpenClaw 写了一段 Playwright 脚本,不需要 launch 新浏览器,而是直接 connect 刚才那个窗口:
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
# 直接连上那个已经被你打开、已经登录好的浏览器
browser = p.chromium.connect_over_cdp("http://localhost:9222")
# 找到刚才的页面上下文
context = browser.contexts[0]
page = context.pages[0]
# 开始自动化表演
# 比如:自动发一条推文
page.goto("https://x.com/compose/tweet")
page.keyboard.type("太神奇了,Windows11竟然可以用图形界面打开安装在wsl里面的Chrome!")
page.click("button[data-testid='tweetButton']")这就好比你开着一辆车(浏览器),过收费站(验证码/登录)的时候是你自己开的,过了收费站上了高速,你按了一下按钮,OpenClaw(AI) 接管了方向盘。
下图就是 OpenClaw 在我手动登录后,接管浏览器自动发出的推文:

这套方案完美解决了: