Hermes Agent 浏览器自动化：本地 Chrome 走 CDP 连接实操

Thu, 10 Sep 2026 10:00:00 +0000

上一篇写了 Hermes Agent 桌面端 runtime 的配置记录（Hermes Agent 桌面端 Runtime 配置实战），这篇接着聊它的浏览器自动化。这篇以"浏览器怎么用"为主线，以后要是再配置别的浏览器后端、或者学到新的浏览器工具用法，我继续往这篇里补。

浏览器自动化是 agent 比较核心的一块能力——网页导航、点按钮、填表单、抓动态内容都靠它。Hermes 这块后端选项很多，有云端的（Browserbase、Browser Use、Firecrawl），有本地的（Camofox、CDP 连自家 Chrome、本地 Chromium）。我这边主要踩的是通过 CDP 连本地 Chrome这条线，中间有个坑挺典型，先记下来。

一、后端选项总览

官方文档把浏览器后端分成了几类，先摆个全局视图：

后端	模式	说明
Browserbase	云	托管云浏览器 + 反机器人，有住宅代理、验证码破解
Browser Use	云	替代云浏览器服务商，走 REST API
Firecrawl	云	带内置爬取能力的云浏览器
Camofox	本地	基于 Firefox 的本地反检测指纹伪装
本地 Chrome（CDP）	本地	连你自己正在跑的 Chrome，`/browser connect`
agent-browser	本地	靠本地 Chromium 驱动

所有模式里，agent 都能做到网页导航、页面元素交互、表单填写、信息提取。页面以可访问性树（基于文本的快照）表示，交互元素分配引用 ID（如 @e1、@e2），agent 靠这些 ID 去点击、输入——这也是它跟传统像素级 RPA 最大的区别。

二、我这边的配置：CDP 连本地 Chrome

2.1 正确配置方式

在 ~/.hermes/config.yaml（Windows 上是 %LOCALAPPDATA%\hermes\config.yaml）里加：

1
2
3


browser:
 cdp_url: "http://localhost:9222"
 backend: off

关键点：cdp_url 和 backend: off 必须一起设，只设 cdp_url 不设 backend 就会踩坑。

2.2 为什么必须 `backend: off`

browser.backend 的默认值是空字符串 ""，含义是：

空值 ""：自动检测。如果系统上能找到 browser-use CLI（通过 uvx 或 PATH），会自动切到 browser_exec 工具（Browser Use CLI 模式）；
"browser-use"：强制用 browser_exec + Browser Use CLI；
"off"：强制用内置浏览器工具（browser_navigate、browser_click、browser_vision 等）。

我只配了 browser.cdp_url、没设 backend: off，而系统上恰好有 uvx，于是 Hermes 自动进了 Browser Use CLI 模式：通过 uvx browser-use 拉独立的 Python 环境，在 workspace 里下载了一堆依赖（openai、pillow、reportlab、cryptography……），最后报了个 agent_helpers 模块不存在的错。绕了一圈才明白——browser.cdp_url 本身是有效的 CDP 配置，但它预期的使用场景是配合内置浏览器工具，而不是 Browser Use CLI 模式。

2.3 工作原理

设了 backend: off 之后，内置浏览器工具会自动读 browser.cdp_url：

browser_navigate 这类工具通过 _get_cdp_override() 读取配置；
把 HTTP CDP URL（http://localhost:9222）解析成 WebSocket URL（通过 /json/version 拿 webSocketDebuggerUrl）；
通过 WebSocket 连到已运行的 Chrome 实例；
用 CDP Supervisor 做对话和帧检测。

整个过程不需要装 browser-use CLI，也不用下载任何额外依赖包——这就是 backend: off + cdp_url 的优势所在，轻量、直接、还看得见浏览器在干嘛。

三、启动 Chrome 与验证

3.1 手动启动

Chrome 得用调试模式启动：

1
2


# Windows
start chrome --remote-debugging-port=9222 --auto-open-devtools-for-tabs

验证 CDP 端点是否可达：

1
2


Invoke-RestMethod -Uri "http://localhost:9222/json/version"
# 应返回包含 webSocketDebuggerUrl 的 JSON

如果 Chrome 没在调试模式跑，Hermes 的 /browser connect 也会尝试自动启动它并带 --remote-debugging-port=9222。Linux 和 macOS 上手动启动命令分别是 google-chrome --remote-debugging-port=9222 和 Chrome.app 路径加同参数。

3.2 一键启动脚本（批处理）

手动敲命令行有点麻烦，我另外写了个批处理脚本，双击就能自动定位 Chrome、起调试端口、等待就绪，还能自动打开验证页面。好处是它用独立的 profile 目录（%LOCALAPPDATA%\HermesChromeProfile），跟日常浏览的 Chrome 会话分开，不会跟你自己在用的标签页打架。

脚本我打包成了一个 zip 放在项目里，直接下载解压就能用：

下载：start_chrome_agent.zip
使用：解压后双击 start_chrome_agent.bat，等它提示 [OK] Chrome CDP is ready，再回 Hermes 里跑 /browser connect ws://localhost:9222 连上即可。如果你已经通过 config.yml 配置了 browser.cdp_url，那么就不需要做连接了。

脚本逻辑其实就三步：先探测端口是不是已经在监听——在就直接报连接方式并打开 /json/version 验证页退出；不在就创建 profile 目录，用独立 profile 启动 Chrome，然后轮询最多 10 秒等 CDP 就绪。几处容易踩的点：

如果跑在 WSL2 / Docker 里，把脚本里的 EXTRA_ARGS=--remote-debugging-address=0.0.0.0 那行取消注释，否则容器外部连不上调试端口；
端口已被占用但不通，大概率是别的 Chrome 实例占着同一个 profile 目录，关掉那个实例再跑；
脚本用的是独立 profile，所以即使你平时 Chrome 开着，也能再起一个调试实例，互不影响。

连上之后，所有浏览器工具（browser_navigate、browser_click 等）操作的都是你实际在跑的 Chrome 实例，而不是起云会话——想实时看 agent 操作、要用自己的 Cookie/登录态、或者想省掉云浏览器成本的时候，这条线很合适。

四、模式手动切换

不想写配置文件的话，CLI 也能临时切：

1
2
3
4
5
6
7
8


# 切到内置工具模式（用 CDP）
hermes browser off

# 切到 Browser Use CLI 模式
hermes browser use

# 设置 CDP URL 并连接
hermes browser connect http://localhost:9222

/browser connect 还支持连特定端点（ws://host:port），以及 /browser status 看当前连接、/browser disconnect 断开回到 cloud/local 模式。当然，hermes tools 菜单的 Browser Automation 部分也能图形化配置。

五、常用浏览器工具

连着 CDP 之后，内置工具集大概是这些，都是基于可访问性树引用的：

工具	作用
`browser_navigate`	导航到指定 URL，其他浏览器工具之前必须先调它
`browser_snapshot`	拿当前页面的文本可访问性树快照，返回可交互元素及引用 ID
`browser_click`	按引用 ID 点击元素
`browser_type`	输入框输入文本，先清空再输入
`browser_scroll`	上下滚动页面
`browser_press`	按键（Enter、Tab、Escape 等），适合提交表单
`browser_back`	返回历史上一页
`browser_get_images`	列出页面上所有图片 URL 和 alt 文本
`browser_vision`	截图 + AI 视觉分析，适合验证码、复杂布局
`browser_console`	读控制台输出和未捕获的 JS 异常

其中 browser_vision 对验证码、图表这类"文本快照抓不住"的场景特别好用；截图存在 ~/.hermes/cache/screenshots/，24 小时后自动清理。browser_console 则适合排查页面里静默的 JS 错误——可访问性树看不出来，控制台能暴露。

填表单的典型流程：

browser_navigate("https://example.com/signup")
browser_snapshot() → 看到带 ref 的表单字段
browser_type(ref="@e3", text="john@example.com")
browser_click(ref="@e8") → 点"Create Account"
browser_snapshot() → 确认成功

六、几个值得留意的点

简单信息检索优先用 web_search / web_extract，更快更省成本；只有要跟页面交互（点按钮、填表单、动态内容）才用浏览器工具。
Browserbase 云模式有自动隐蔽能力：随机指纹、视口随机化、验证码自动求解是基础项；住宅 Agent、高级隐蔽（要 Scale 计划）、保持连接这些是付费项。免费计划下 Hermes 会自动降级，先禁 keepAlive 再禁 Agent。
会话录制：browser.record_sessions: true 可把会话自动录成 WebM，存在 ~/.hermes/browser_recordings/，超过 72 小时自动清理。
限制要心里有数：交互基于可访问性树而非像素坐标；大页面快照在 8000 字符处会被截断或摘要；云会话会消耗积分；浏览器里没法下载文件。想免费本地浏览，就走 /browser connect。

七、坑点小结

这次最典型的坑就一个：browser.cdp_url 配上后没设 backend: off，被自动切进了 Browser Use CLI 模式，拉了一堆依赖还报错。记牢 cdp_url + backend: off 这个组合，就能走轻量的内置工具 + CDP 路线。后面要是再研究其他浏览器后端（比如 Camofox、Firecrawl）或学到新工具用法，我继续补进这篇。

参考

官方文档：浏览器自动化
上一篇：Hermes Agent 桌面端 Runtime 配置实战

Browser-Use on 大卷学长的博客