1. 为什么要在 WSL2 里跑可视化浏览器自动化如果你正在做网页自动化尤其是登录类、表单类、需要过验证码的场景纯无头浏览器经常会卡在一个尴尬的地方脚本跑得好好的突然弹出一个滑块或者扫码验证整个流程就断在那里日志里只有一句超时。这时候你需要的不是更复杂的反检测策略而是一个能让人直接看到、直接上手点的浏览器窗口。OpenClaw 配合 Google Chromedeb 版加 WSLg解决的正是这个问题。OpenClaw 负责编排自动化步骤Chrome 提供真实的 Linux 图形界面WSLg 把窗口直接投射到 Windows 桌面上。整个链路里浏览器是 headed 模式运行的也就是说验证码出现时你可以像平时用浏览器一样用鼠标去点、去拖、去扫码完成之后 Agent 继续往下跑。这套方案适合几类人一是做 RPA 但被验证码卡住的开发者二是需要复用登录态、又不想把账号密码交给纯脚本的团队三是想在 Windows 上体验 Linux GUI 自动化、又不想装虚拟机的个人。核心检索词就是 OpenClaw、Google Chrome、WSLg、WSL2、CDP 这几个下面会围绕它们把配置和排障讲透。我试过在 Ubuntu 24.04 上直接用 apt 装 chromium-browser结果装出来是个 snap 包装器CDP 端口时好时坏调试成本很高。后来换成 Google Chrome 官方 deb启动行为稳定多了。这篇文章就把这条路径完整走一遍包括 Chrome 启动参数、OpenClaw 连接配置、人工接管切换以及一次登录流程的验证。需要说明的是本文的 API 通道统一走 TaoToken 的 Key 接入官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 后面配置里会用到。整个流程不涉及任何网络加速工具纯粹是本地 WSL2 WSLg 的图形链路。2. TaoToken 统一 Key 的前置准备在开始配浏览器之前先把模型通道准备好。OpenClaw 在自动化过程中需要调用模型来做页面理解、步骤决策如果每个模型都单独配 Key管理起来很麻烦。TaoToken 的做法是给你一个统一 Key通过一个 Base URL 转发到不同模型这样 OpenClaw 的配置里只需要维护一份凭证。你需要先拿到 Key。打开 https://taotoken.net/api-keys 登录后创建一个 API Key复制出来备用。这个 Key 的格式通常是一串以 sk- 开头的字符串注意不要泄露到公开仓库里。拿到 Key 之后OpenClaw 的模型配置里要填三个东西Base URL、API Key、Model ID。Base URL 用 https://taotoken.net/api 注意这里不加任何 UTM 参数保持干净。Model ID 根据你实际要用的模型填比如 claude 系列或者 gpt 系列具体以 TaoToken 文档里的模型列表为准文档地址是 https://taotoken.net/doc 。如果你用的是 Claude Code 这类工具配置方式类似Base URL 和 Key 填同样的值即可。TaoToken 的 Coding Plan 页面 https://taotoken.net/coding-plan 里有针对长期编码场景的说明如果你打算把 OpenClaw 跑成常驻 Agent可以看一下那边的额度方案。这里要强调一点TaoToken 是统一的 API 接入通道不是浏览器插件也不参与浏览器自动化本身。它只负责模型调用这一层。浏览器控制是 OpenClaw 通过 CDP 直接和 Chrome 通信完成的两者是分开的。把这两层分清楚后面排障的时候就不会混淆。配置好 Key 之后建议先用模型对话页面 https://taotoken.net/chat 发一条消息确认 Key 本身是通的。如果那边都报 401就不用往下折腾浏览器了先解决鉴权问题。3. 可复制的 Chrome 启动与 OpenClaw 配置这一节是全文的核心所有配置都可以直接复制。先确认环境Windows 11 或支持 WSLg 的 Windows 版本WSL2 里跑 Ubuntu示例以 Ubuntu 24.04 为主。OpenClaw 已经安装openclaw --version能正常输出。第一步清理可能存在的 snap Chromium。Ubuntu 24.04 上apt install chromium-browser装的其实是 snap 包装器沙箱机制会干扰 CDP 的稳定性建议先卸掉snap list | grep -i chromium || true sudo snap remove chromium sudo apt remove -y chromium-browser sudo apt autoremove -y which chromium || true which chromium-browser || true第二步安装 Google Chrome 官方 debsudo apt update sudo apt install -y wget ca-certificates gnupg cd /tmp wget -O google-chrome-stable_current_amd64.deb https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb sudo apt install -y ./google-chrome-stable_current_amd64.deb sudo apt -f install -y which google-chrome-stable google-chrome-stable --version装完后直接运行google-chrome-stable如果 Windows 桌面上弹出了 Chrome 窗口说明 WSLg 图形链路是通的。这一步很关键如果窗口弹不出来后面 OpenClaw 也拉不起来 headed 浏览器。第三步配置 OpenClaw。配置文件通常在~/.openclaw/openclaw.json。这里要同时解决两件事一是让浏览器以 GUI 模式运行二是让 systemd 服务能拿到 DISPLAY 等图形环境变量。完整配置如下{ env: { shellEnv: { enabled: true, timeoutMs: 15000 } }, browser: { enabled: true, defaultProfile: openclaw, headless: false, noSandbox: true, executablePath: /usr/bin/google-chrome-stable, profiles: { openclaw: { cdpPort: 18800, color: #0000FF } } } }几个参数解释一下。headless: false是人工接管的前提必须为 false。executablePath指向 deb 安装后的真实路径用which google-chrome-stable确认。cdpPort是 CDP 调试端口OpenClaw 通过它控制浏览器默认 18800被占用时可以改。noSandbox在 WSL 环境下建议开启避免沙箱权限问题。env.shellEnv.enabled是解决 systemd 服务缺 DISPLAY 的关键它会让 gateway 从交互 shell 导入环境变量。第四步同步 token 并重启 gateway。如果你看到Config token differs from service token这类提示说明配置里的 token 和服务里跑的不一致需要强制重装再重启openclaw gateway install --force openclaw gateway restart第五步启动托管浏览器并验证openclaw browser --browser-profile openclaw start openclaw browser --browser-profile openclaw open https://example.com成功的话Windows 桌面会出现一个 Chrome 窗口页面被 OpenClaw 打开。这时候你可以手动在窗口里操作也可以让 Agent 继续控制两者共用同一个实例和登录态。如果中文显示成方块补一下字体sudo apt update sudo apt install -y fonts-noto-cjk fonts-noto-color-emoji fontconfig fc-cache -f -v4. 验证请求与人工接管流程实测配置完成后用一次真实的登录流程来验证整条链路。这里以一个需要扫码验证的站点为例步骤可以套用到你自己的场景。先让 OpenClaw 打开目标登录页openclaw browser --browser-profile openclaw open https://your-target-site.com/login然后在 OpenClaw 的 Agent 指令里描述任务比如“填写用户名密码并提交如果出现验证码就停下来等待人工”。Agent 会通过 CDP 操作页面你能在 WSLg 窗口里实时看到光标移动、输入框被填充。关键点在验证码出现的那一刻。Agent 检测到验证码元素后会进入等待态不再继续操作。这时候你直接在那个 Chrome 窗口里用鼠标完成扫码或滑块。因为浏览器是 headed 的窗口就是真实的 Chrome扫码用的是你本机摄像头或者手机没有任何额外障碍。验证通过后告诉 Agent 继续。它会重新读取页面状态接着走后续流程。整个过程中登录态保存在 OpenClaw 托管的 profile 里下次再跑同一个任务如果站点还认这个 session就不用重复登录。验证成功的标志有三个一是 WSLg 窗口里能看到完整页面渲染二是 Agent 的日志里能看到 CDP 连接正常、页面元素被定位三是人工接管后 Agent 能继续执行而不是报错退出。三个都满足说明 OpenClaw Chrome WSLg 这条链路是通的。这里补充一个实用技巧如果你要跑多个站点可以给每个站点配不同的 profile改cdpPort和color区分。这样登录态互不干扰窗口颜色也能帮你快速识别是哪个任务。模型调用这一层OpenClaw 会走你在 TaoToken 配好的 Base URL 和 Key。如果 Agent 在页面理解阶段报模型错误先去 https://taotoken.net/chat 确认 Key 有效再检查 OpenClaw 里的模型配置。浏览器层和模型层分开排查效率会高很多。5. 常见报错排查对照这一节列几个真实会遇到的报错以及对应的处理方式。Missing X server or $DISPLAY表现是启动浏览器时报Missing X server or $DISPLAY平台初始化失败。先在交互终端里确认环境变量echo DISPLAY$DISPLAY echo WAYLAND_DISPLAY$WAYLAND_DISPLAY echo XDG_RUNTIME_DIR$XDG_RUNTIME_DIR ls -la /tmp/.X11-unix如果这几个变量都不为空但服务里还是报这个错说明 systemd 服务没继承到。除了在openclaw.json里启用env.shellEnv还可以直接写一份环境文件cat ~/.openclaw/.env EOF DISPLAY:0 WAYLAND_DISPLAYwayland-0 XDG_RUNTIME_DIR/run/user/1000 EOF然后同步重启openclaw gateway install --force openclaw gateway restartFailed to start Chrome CDP on port 18800这个报错通常是两个原因端口被占用或者浏览器本身没起来。先查端口ss -lntp | grep 18800如果被占用改openclaw.json里的cdpPort比如换成 18801然后重启 gateway。如果是浏览器没起来多半还是 DISPLAY 问题回到上一条排查。另外确认executablePath指向的是 deb 安装的 Chrome不是 snap 残留。401 鉴权失败如果 Agent 在调用模型时报 401说明 TaoToken 的 Key 有问题。检查 Key 是否复制完整、是否过期Base URL 是否是https://taotoken.net/api。可以先用模型对话页面验证 Key再去 https://taotoken.net/api-keys 重新生成一个。reading choices 相关报错这类报错通常出现在模型返回格式不符合预期时。检查 Model ID 是否填对有些模型对输入格式有要求。如果换了模型就好说明是模型兼容性问题不是浏览器链路问题。OAuth 或登录态失效如果站点用的是 OAuth人工接管完成授权后Agent 需要重新读取页面。确保 Agent 的等待逻辑是轮询页面状态而不是固定 sleep。固定 sleep 容易在授权慢的时候提前继续导致后续步骤失败。中文显示方块前面提过装fonts-noto-cjk和fonts-noto-color-emoji然后fc-cache -f -v。装完重启浏览器实例。排查的时候记住一个原则先确认 WSLg 能弹窗再确认 OpenClaw 能连 CDP最后确认模型通道正常。三层分开验证比一上来就怀疑整个链路要快得多。6. 长期运行与接入建议如果你打算把这套方案跑成常驻的自动化服务有几个点值得注意。浏览器实例不要频繁重启。OpenClaw 托管的 profile 会保存登录态频繁重启会丢失 session导致每次都要重新人工接管。让 gateway 常驻浏览器按需 start任务结束后不要急着 kill。CDP 端口建议固定不要每次随机。固定端口方便你在外部工具里直接连上去调试比如用 Chrome DevTools 协议手动发指令。如果多任务并行用不同端口和 profile 隔离。模型通道方面长期跑的话建议用 TaoToken 的 Coding Plan额度更稳定。接入文档在 https://taotoken.net/doc 里面有 Base URL、Key、Model ID 的完整说明。需要管理多个 Key 的时候控制台 https://taotoken.net/console 可以统一查看。人工接管的触发条件要设计好。不要等 Agent 报错才停下来而是在指令里明确“遇到验证码元素就等待”。这样 Agent 会主动进入等待态而不是尝试绕过验证导致账号风险。最后Chrome 的启动参数可以通过 OpenClaw 的 profile 扩展。如果你需要额外的命令行参数比如指定 user-data-dir 或者禁用某些特性可以在 profile 配置里加 args 数组。具体字段以 OpenClaw 文档为准改完记得重启 gateway 让配置生效。整套流程跑顺之后你会发现可视化自动化的价值在于“可控”。Agent 做重复劳动人处理需要判断的环节两者在同一个浏览器窗口里无缝切换。这比纯无头方案更适合真实业务场景。