• 作者: 作者
  • 时间:
  • 分类: 文章

在这个 AI 迭代快得让人眼花缭乱的时代，我们总在尝试让模型做更多“体力活”。最近在折腾 Hermes 这个大模型 Agent 时，遇到个挺典型的痛点：Agent 运行在 WSL（Windows 子系统 Linux）里，但我想让它直接操作 Windows 桌面上的 Chrome 浏览器。

Hermes Agent 文档截图

Hermes Agent FAQ 文档部分，展示了关于连接浏览器的相关说明。

毕竟，很多需要登录验证、或者图形化操作的网页任务，直接在 Linux 环境里跑无头浏览器（Headless Chrome）有时候不如直接用主机上的浏览器来得直观和方便，而且还能省去迁移 Cookie 和登录状态的麻烦。

如果你也有类似的烦恼，或者单纯想做一点新技术的“极客尝试”，今天这篇保姆级教程可能刚好对你胃口。我们不搞复杂的网络隧道，就用最直接的方法——**远程调试端口（CDP）**来打通这层“次元壁”。

为什么不直接在 WSL 里跑浏览器？

当然，在 WSL2 里安装一个 Linux 版本的 Chrome 或者 Chromium 也是完全可行的。但是，Windows 下的浏览器环境往往包含了我们日常使用的插件、书签、保存的密码以及各种会话状态。

让 Hermes 直接接管 Windows 上的 Chrome，等于让 AI 继承了你的“数字身份”环境。这对于需要登录特定账号抓取数据、或者进行自动化测试的场景来说，简直是降维打击。而且，你可以在旁边实时看着 AI 的一举一动，安全感满满。

核心原理：Chrome 远程调试协议 (CDP)

Chrome 调试模式启动界面

通过指定参数启动 Chrome 后弹出的全新窗口界面截图。

Chrome 浏览器自带一套非常强大的开发者工具协议（Chrome DevTools Protocol）。只要我们在启动 Chrome 时加上特定的参数，就能开启一个调试端口（默认是 9222）。任何能访问该端口的程序，都可以像控制提线木偶一样控制浏览器。

我们的思路就很清晰了：

  1. 在 Windows 上启动 Chrome 并开启远程调试端口。
  2. 确保 WSL 能访问到 Windows 的这个端口。
  3. 告诉 Hermes（或者底层的 Puppeteer/Playwright 等 MCP 工具），去连接这个端口就行了。

WSL 网络连接测试结果

在 WSL 终端中执行 curl 命令验证与 Windows 主机端口连通性的返回结果。

第一步：准备 Windows 端的 Chrome

为了避免跟平时使用的个人浏览器混淆，强烈建议单独开一个 Chrome 进程用于 AI 调试。

Windows 下开启调试模式的方法：

你需要先关闭所有正在运行的 Chrome 窗口（这步很重要，否则端口可能被占用的进程无法开启调试模式）。然后，打开终端（CMD 或 PowerShell），输入以下命令启动 Chrome：

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="C:\temp\chrome_debug_profile"

参数解析：

  • --remote-debugging-port=9222：指定 9222 端口为调试通信端口。
  • --user-data-dir=...：指定一个独立的用户数据目录。这是为了防止 AI 的操作搞乱你原本浏览器里的历史记录和插件，用一个临时文件夹是最稳妥的。

执行完这条命令，.chrome 会弹出一个全新的窗口。此时，你的 Windows 主机已经做好了被“接管”的准备。

第二步：搞定 WSL 与 Windows 的网络互通

WSL2 的网络机制是一个轻量级的虚拟机，它的 IP 地址是动态变化的。不过，好消息是微软替我们想好了一切。

在 WSL（比如 Ubuntu 终端）里，你可以通过访问 $(cat /etc/resolv.conf | grep nameserver | awk '{print $2}') 这个地址来访问 Windows 主机。

但在大多数实际测试中，直接访问 127.0.0.1:9222 通常也是可以工作的，因为 Windows 端的端口监听默认是允许所有网络接口访问的。为了验证，你可以在 WSL 终端里试一下：

curl 127.0.0.1:9222/json/version

如果返回了一段包含 Browser、WebKit-Version 等信息的 JSON 字符串，恭喜你，网络层是通的。如果不行，尝试换成 Windows 的局域网 IP 或者上述提到的 cat /etc/resolv.conf 获取的 IP。

第三步：配置 Hermes 与 MCP

这就到了最关键的一步，我们需要把前面的工作成果“告诉” Hermes。

根据 Hermes 的文档（FAQ 部分），它支持通过 MCP (Model Context Protocol) 来调用浏览器相关的工具。我们需要在配置文件中指定浏览器的连接地址。

找到你的 Agent 配置文件（通常在 .config 目录下或者项目的 Settings 界面中），定位到 MCP (Browser) 相关的配置项。你需要修改的通常是连接 WebSocket 或 HTTP 端口的部分。

将目标地址设置为： http://127.0.0.1:9222

或者，如果你是在 WSL 内部配置，且前面步骤中使用了特定的 Windows IP，这里就填那个 IP 加上端口。

第四步：重启与实战测试

改完配置可不算完，大部分 Agent 都不会动态热加载配置，所以你需要去设置里或者通过命令行重新加载一下 MCP 服务器。

测试对话示例： 在聊天框里输入：“帮我打开百度，然后搜索一下今天的天气。”

如果一切顺利，你会惊讶地发现，Windows 桌面上的那个 Chrome 窗口突然自己动了起来：打开标签页、输入网址、点击搜索框……宛如有一个幽灵在帮你操作。

避坑指南与常见问题

折腾技术嘛，难免遇到一两个坑，这里先帮你把雷排掉：

  1. 端口被占用：如果 Chrome 启动不起来，报错端口被占用，用 netstat -ano | findstr :9222 查一下是哪个进程在搞鬼，关掉它。
  2. WSL 网络不通：Windows 上的防火墙可能会拦截来自 WSL 的请求。如果 curl 不通，试着暂时关闭一下防火墙，或者在防火墙里放行 9222 端口的入站规则。
  3. 多用户冲突：记得一定要用 --user-data-dir 开一个新数据目录，不然 AI 可能会莫名其妙地把你浏览器里的东西关掉或改掉。

写在最后

把 Hermes 接到 Windows 的 Chrome 上，其实只是 AI 自动化的一个小小切片。这种“跨系统协同”的能力，能让我们在 Linux 环境下享受强大的开发工具，同时保留 Windows 环境下的图形交互便利。

试着让你的 AI 帮你订票、填表或者自动刷一下课程进度，你会发现，解放双手的感觉真好。

标签: none

评论已关闭