一日一技：骚操作，利用 WSLg 实现“人机接力”，让OpenClaw绕过浏览器检测
内容提要
文章介绍利用WSLg和Chrome远程调试协议，实现OpenClaw在WSL2中绕过浏览器风控的“人机接力”方案。通过将Linux版Chrome投射到Windows桌面，人工完成登录和验证码，再让OpenClaw通过CDP接管浏览器继续自动化任务，解决环境隔离和风控问题。
延伸解读
人机协作的核心价值
文章提出的方案并非单纯的技术炫技，而是针对自动化任务中常见的验证码和登录风控问题，引入人工介入环节。通过WSLg将Linux浏览器界面投射到Windows桌面，人工完成最棘手的验证步骤，再交由OpenClaw继续自动化操作。这种“人机接力”模式平衡了自动化效率与安全性，尤其适用于需要登录态或面临严格风控的场景。
技术前提与限制
该方案依赖Windows 11的WSLg功能，以及Chrome的远程调试协议（CDP）。用户需在WSL中安装Chrome，并通过命令行启动以注入代理和调试端口参数。值得注意的是，文章示例中使用了本地代理（127.0.0.1:7890），这意味着用户需自行配置可用的代理服务，且代理的稳定性直接影响浏览器访问效果。
适用场景与注意事项
此方案主要面向Windows用户，旨在解决WSL2环境下浏览器自动化遇到的风控问题。它保留了Linux环境的统一性，同时利用Windows图形界面进行人工干预。但需注意，人工操作步骤（如登录、验证码）仍需手动完成，且浏览器窗口需保持开启状态，以便OpenClaw通过CDP连接。对于需要频繁切换账号或大规模自动化任务，此方法可能不够高效。
Q&A
OpenClaw在WSL2中遇到浏览器风控时，有什么痛点？
OpenClaw在WSL2中遇到浏览器风控时，主要有三个痛点：没有图形界面，验证码看不到；IP是机房或代理IP，账号容易被风控拦截；想用Windows本地浏览器但环境不统一。
WSLg是什么？它如何帮助实现人机接力？
WSLg是Windows 11的WSL GUI功能，可以让WSL里安装的GUI软件（如Chrome）直接在Windows桌面以窗口形式运行。这样人类可以用鼠标操作浏览器完成登录和验证码，而OpenClaw仍可通过localhost控制它，实现人机接力。
如何启动带远程调试端口的Chrome？
在Windows的PowerShell中执行命令：wsl -e google-chrome-stable --proxy-server="http://127.0.0.1:7890" --remote-debugging-port=9222 --user-data-dir=$HOME/.config/google-chrome。这样会启动Linux版Chrome，并开启CDP端口9222。
OpenClaw如何通过CDP接管已经登录的浏览器？
OpenClaw使用Playwright脚本，通过connect_over_cdp连接http://localhost:9222，然后获取已有的浏览器上下文和页面，即可接管浏览器继续自动化操作。
这套方案解决了哪些问题？
这套方案解决了三个问题：环境隔离（OpenClaw仍在Linux中运行，无需适配Windows）；过风控（人工完成登录，Cookies和Session保留在Linux容器中）；可视化调试（OpenClaw操作时可在桌面上观察，便于排查问题）。
为什么不用Mac mini而选择Windows WSL？
文章作者表示，如果有Mac mini就不会折腾Windows跑WSL，这个方案是给Windows用户提供的一条活路。
