如何在浏览器自动化中使用Hermes Agent和CapSolver解决验证码

当你的 AI 代理为你浏览网页时，CAPTCHAs 是最大的障碍。受保护的页面会阻止代理，表单拒绝提交，任务会因等待人工干预而停滞。

Hermes Agent 由 Nous Research 开发，是一个自我改进的 AI 代理，可以运行在任何地方——从 $5 的 VPS 到 GPU 集群——并通过你已使用的每个渠道（Telegram、Discord、Slack、WhatsApp、Signal 和电子邮件）与你联系。它还可以驱动浏览器导航页面、点击按钮、填写表单并代表你提取数据。但像任何驱动浏览器的代理一样，它也会被验证码卡住。

CapSolver 完全改变了这一状况。通过将 CapSolver Chrome 扩展加载到 Hermes 附加的浏览器中，验证码会在后台自动且不可见地被解决。无需代码。无需从你这边调用 API。无需进行提示工程技巧。

最棒的是？你甚至不需要向代理提及验证码。 你只需告诉它在提交前等待片刻——当它点击提交时，验证码已经解决了。

什么是 Hermes Agent？

Hermes Agent 是由 Nous Research 开发的开源自主 AI 代理。它围绕三个原则设计：持久记忆（它在会话之间记住你和你的项目）、自主技能创建（它从经验中学习程序并在下次重复使用）和 基础设施灵活性（可以在微型 VPS、Docker 容器、无服务器沙盒或你自己的 GPU 机器上运行）。

核心功能

• 多渠道网关：通过 Telegram、Discord、Slack、WhatsApp、Signal、电子邮件或其自己的终端 UI 与你的代理交流
• 自定义模型：OpenRouter（200+ 模型）、Nous Portal、NVIDIA NIM、Z.AI、你自己的端点——通过 hermes model 切换
• 跨会话记忆：FTS5 会话搜索 + LLM 摘要意味着代理会记住你上周谈过的内容
• 技能系统：代理自己构建的程序性记忆，兼容 agentskills.io 标准
• 七种终端后端：本地、Docker、SSH、Singularity、Modal、Daytona、Vercel Sandboxes
• 内置浏览器工具：通过 Playwright + Chrome 开发者工具协议驱动真正的 Chromium

浏览器工具

Hermes 可以驱动 Chromium 浏览器执行实际工作——导航、读取 DOM、点击、输入、截图、抓取数据。其浏览器工具层有一个特别之处：Hermes 支持 五种可互换的浏览器提供商，而不是强迫你使用单一后端：

云提供商无法加载扩展——你无法控制远程浏览器。Camoufox 基于 Firefox，无法运行 Chrome MV3 扩展。干净的集成点是第五种：CDP attach，Hermes 连接到你单独启动的 Chromium。这就是 CapSolver 的位置。

这与像 OpenClaw（启动自己的 Chromium 并接受 browser.extensions 数组）或 Crawlee（你控制 Playwright 启动标志）这样的工具不同。在 Hermes 中，你带来自己的 Chrome 并预先加载扩展，Hermes 通过开发者工具协议连接到它。

什么是 CapSolver？

CapSolver 是一个领先的验证码解决服务，提供 AI 驱动的解决方案，用于绕过现代验证码挑战。它支持每种主要的验证码类型，并具有快速的响应时间，可无缝集成到自动化工作流中——无论你是通过 Playwright 驱动浏览器，直接调用其 API，还是像本指南中那样，在代理的浏览器会话中运行其 Chrome 扩展。

为什么这个集成不同

大多数验证码解决集成需要你编写代码——创建 API 调用、轮询结果、将令牌注入隐藏表单字段。这就是 Crawlee、Puppeteer 或 Playwright 等工具的工作方式。

Hermes + CapSolver 从根本上不同：

关键洞察：CapSolver Chrome 扩展在 附加 浏览器中运行。Hermes 通过 CDP 连接到该浏览器并正常驱动它。当代理导航到包含验证码的页面时，扩展——在同一个 Chrome 中完全对代理不可见——检测到小部件，调用 CapSolver API，并将解决方案令牌注入页面。当代理点击提交时，表单已经带有有效令牌。

你只需要给它时间。 不需要告诉代理“解决验证码”，你只需说：

“去那个页面，等待 60 秒，然后点击提交。”

就是这样。代理不需要知道 CapSolver 的存在。

前提条件

在设置集成之前，请确保你有：

1. Hermes Agent 已安装并运行网关（安装说明）
2. CapSolver 账户 和 API 密钥（在此注册）
3. Chromium 或 Chrome 用于测试（请参阅下面的重要说明）

重要提示：你需要 Chromium，而不是 Google Chrome

Google Chrome 137+（2025 年中发布）静默地移除了品牌版本中 --load-extension 的支持。 这意味着在使用标准 Google Chrome 的自动化会话中，Chrome 扩展无法加载。没有错误——该标志只是被忽略。

这影响了 Google Chrome 和 Microsoft Edge。你必须使用以下替代方案：

如何安装 Chrome for Testing：

# 选项 1：通过 Playwright（推荐——Hermes 内部已使用 Playwright）
npx playwright install chromium

# 二进制文件路径如下：
# ~/.cache/ms-playwright/chromium-XXXX/chrome-linux64/chrome           （Linux）
# ~/Library/Caches/ms-playwright/chromium-XXXX/chrome-mac/Chromium.app/Contents/MacOS/Chromium  （macOS）

# 选项 2：通过 Chrome for Testing 直接下载
# 访问：https://googlechromelabs.github.io/chrome-for-testing/
# 下载与你的操作系统匹配的版本

安装后，记下二进制文件的完整路径——你将在下一步中需要它。

分步设置

集成有两个部分协同工作：

1. 一个单独的 Chrome 进程，你用预加载的 CapSolver 扩展和 CDP 在已知端口（我们将使用 9222）上启动。
2. 对 Hermes 的 config.yaml 的小修改，告诉它连接到该 CDP 端口，而不是启动自己的浏览器。

就是这样——无需代码，无需修改 Hermes。

步骤 1：下载 CapSolver Chrome 扩展

下载 CapSolver Chrome 扩展并将其提取到稳定位置：

1. 前往 CapSolver 扩展的 GitHub 发布页面
2. 下载最新的 CapSolver.Browser.Extension-chrome-vX.X.X.zip
3. 解压 zip：

mkdir -p ~/.hermes/capsolver-extension
unzip CapSolver.Browser.Extension-chrome-v*.zip -d ~/.hermes/capsolver-extension/

4. 验证解压是否成功：

ls ~/.hermes/capsolver-extension/manifest.json

你应该看到 manifest.json——这确认了扩展位于正确的位置。

路径提示：当你以后将 --load-extension=... 传递给 Chrome 时，使用绝对、解析后的路径（而不是 ~）。一些 Chrome MV3 构建在通过自定义用户数据目录的符号链接加载扩展服务工作者时有边缘情况。如果你从其他位置符号链接扩展，请使用 readlink -f 解析实际路径并使用该路径。

步骤 2：设置 CapSolver API 密钥

打开扩展的配置文件 ~/.hermes/capsolver-extension/assets/config.js，并将 apiKey 值替换为你的：

export const defaultConfig = {
  apiKey: 'CAP-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',  // ← 你的密钥
  useCapsolver: true,
  enabledForRecaptcha: true,
  enabledForRecaptchaV3: true,
  // ...其余配置
};

你可以从你的 CapSolver 仪表板 获取你的 API 密钥。

步骤 3：启动带有扩展和 CDP 的 Chrome

这是关键步骤。我们单独启动 Chrome，带有三个关键标志：

• --remote-debugging-port=9222 —— 暴露 DevTools 协议，以便 Hermes 可以连接
• --load-extension=... —— 预加载 CapSolver 扩展
• --user-data-dir=... —— 使用专用配置文件，以免与你的个人 Chrome 冲突

Hermes 对用户数据目录有内置的约定：~/.hermes/chrome-debug。使用该路径意味着 Hermes 的内置 /browser connect 命令也“只需工作”，无需其他标志。

选项 A：一次性手动启动（适合快速测试）

/path/to/chrome-for-testing/chrome \
  --remote-debugging-port=9222 \
  --remote-debugging-address=127.0.0.1 \
  --user-data-dir="$HOME/.hermes/chrome-debug" \
  --load-extension="$HOME/.hermes/capsolver-extension" \
  --disable-extensions-except="$HOME/.hermes/capsolver-extension" \
  --no-first-run \
  --no-default-browser-check \
  --no-sandbox

将 /path/to/chrome-for-testing/chrome 替换为你的实际二进制文件，例如 ~/.cache/ms-playwright/chromium-1200/chrome-linux64/chrome。

无头服务器：如果你在没有物理显示器的 Linux 服务器上运行（VPS、EC2 等），请参阅下面的最佳实践部分了解 Xvfb 设置。Chrome 扩展子系统需要显示上下文。

选项 B：持久后台进程（推荐用于生产）

对于任何比单个测试运行更长的设置，将启动包装在一个小脚本中，以便你可以在后台运行 Chrome，干净地重启它，并用你已有的进程管理器（systemd、supervisor、runit、OpenRC、Docker 等）监督它。

将此保存为 ~/.hermes/chrome-debug.sh 并 chmod +x 它：

#!/usr/bin/env bash
# ~/.hermes/chrome-debug.sh
# 启动 Chrome-for-Testing 并预加载 CapSolver 扩展
# 并在 127.0.0.1:9222 上暴露 CDP。

CHROME_BIN="$HOME/.cache/ms-playwright/chromium-1200/chrome-linux64/chrome"
EXT_DIR="$HOME/.hermes/capsolver-extension"
USER_DATA_DIR="$HOME/.hermes/chrome-debug"

export DISPLAY=:99   # 用于无头 Linux —— 请参阅最佳实践

exec "$CHROME_BIN" \
  --remote-debugging-port=9222 \
  --remote-debugging-address=127.0.0.1 \
  --user-data-dir="$USER_DATA_DIR" \
  --load-extension="$EXT_DIR" \
  --disable-extensions-except="$EXT_DIR" \
  --no-first-run \
  --no-default-browser-check \
  --no-sandbox \
  --disable-dev-shm-usage \
  --disable-features=Translate

最简单的持久启动是：

nohup ~/.hermes/chrome-debug.sh > /tmp/chrome-debug.log 2>&1 &

对于生产环境，用你偏好的进程管理器监督该脚本。一个最小的 systemd 单位在 ~/.config/systemd/user/chrome-debug.service：

[Unit]
Description=CapSolver 配备的 Chrome 用于 Hermes Agent
After=network.target

[Service]
ExecStart=%h/.hermes/chrome-debug.sh
Restart=always
RestartSec=5

[Install]
WantedBy=default.target

然后：

systemctl --user daemon-reload
systemctl --user enable --now chrome-debug

任何等效的设置（supervisord 程序、runit 服务、Docker 容器等）同样适用——集成只关心某物保持 chrome-debug.sh 运行。

步骤 4：告诉 Hermes 通过 CDP 连接

编辑你的 Hermes 配置文件 ~/.hermes/config.yaml。找到 browser: 部分（它通常只有 inactivity_timeout），并添加 cdp_url：

browser:
  inactivity_timeout: 120
  cdp_url: http://127.0.0.1:9222

这一行告诉 Hermes 的 browser_cdp 工具将所有浏览器操作通过我们在第 3 步中启动的 Chrome 实例路由，而不是启动自己的。

可逆性：这是对 Hermes 本身的唯一更改。要回滚，删除 cdp_url 行。Hermes 返回到它之前使用的默认浏览器提供者（Browserbase、Browser Use 等），没有其他副作用。

步骤 5：重启 Hermes

如果 Hermes 正在运行，请重启它以获取新的 cdp_url：

# 直接运行（前台或在你的监督下）：
hermes gateway run

# 或通过你监督 Hermes 的任何进程管理器重启——
# 唯一的要求是新的环境/配置生效。

步骤 6：验证设置

Hermes 随附一个内置的诊断命令，可以一次性检查集成的每个部分：

hermes doctor

你应寻找以下信号：

◆ 工具可用性
  ✓ browser-cdp        ← CDP 附加已启动
  ✓ browser
  ...

◆ API 连接性
  检查 OpenRouter API...  ✓ OpenRouter API

如果 browser-cdp 出现在 工具可用性 下，Hermes 已检测到你的 CDP 端点，集成已正确连接。如果缺失，Hermes 静默禁用该工具（无错误）——这就是要关注的诊断。

你也可以直接确认 Chrome 是否可访问：

curl -s http://127.0.0.1:9222/json/version

以下响应确认CDP已启动：

{
   "Browser": "Chrome/<your version>",
   "Protocol-Version": "1.3",
   "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/..."
}

关于CapSolver服务工作者的可见性：Chrome MV3服务工作者会积极进入空闲状态，而在较新的Chrome版本中，/json/list可能完全不显示它们，即使它们正在运行。从 /json/list 中缺失并不代表诊断结果——通过让代理加载实际的reCAPTCHA页面并观察页面内的小部件结果来确认CapSolver是否正常工作，而不是轮询目标列表。

如何使用它

这是最重要的部分。一旦设置完成，使用CapSolver与Hermes非常简单。

黄金法则

不要向代理提及CAPTCHAs或CapSolver。 在提交表单前给它一些时间。

代理不需要知道CAPTCHAs的存在。扩展程序会在后台处理一切。你只需要在指令中包含一个等待时间，让扩展程序有时间在表单提交前解决挑战。

示例1：一次性烟雾测试

Hermes的一次性模式（hermes -z "..."）非常适合测试集成。在任何安装了hermes CLI的终端中运行：

hermes -z 'Open https://www.google.com/recaptcha/api2/demo. Wait 60 seconds for the page to fully render. Then click the button labeled "Send!" or with id "recaptcha-demo-submit". After clicking, wait 5 seconds and tell me the visible text on the page.' --yolo

幕后发生的事情：

1. Hermes通过CDP附加到你的Chrome
2. 代理导航到Google的reCAPTCHA演示页面
3. CapSolver的内容脚本（在Chrome内部运行）检测到reCAPTCHA小部件
4. 扩展程序的服务工作者调用CapSolver API并解决挑战（通常在5–15秒内）
5. 令牌被注入到隐藏的g-recaptcha-response表单字段中
6. 60秒后，代理点击提交
7. Google的服务器验证令牌并返回结果页面
8. 代理读取提交后的文本："Verification Success... Hooray!"

这个"Verification Success... Hooray!"字符串是Google自己的确认消息——只有在表单中提交有效的reCAPTCHA令牌时才会出现。

示例2：通过消息通道

从任何连接到Hermes网关的通道（Telegram、Discord、Slack等）发送：

前往 https://example.com/login，将电子邮件字段填写为
"me@example.com"，将密码字段填写为 "mypassword123"，
然后等待30秒并点击“登录”按钮。
告诉我登录后加载的页面是什么。

Hermes会将请求路由到其代理，附加到同一Chrome，填写表单，给扩展程序时间解决登录页面上的任何CAPTCHA，点击“登录”，并回复登录后的页面内容——而你从未提及过CAPTCHAs。

示例3：提交带有reCAPTCHA的联系表单

打开 https://example.com/contact 并填写联系表单：
- 姓名: "John Doe"
- 电子邮件: "john@example.com"
- 消息: "你好，我有关于你们服务的问题。"
等待45秒，然后点击“发送消息”。
页面上会出现什么确认信息？

推荐的等待时间

提示：如果不确定，使用60秒。等待更长时间总比过早提交更好。额外的等待时间几乎是免费的——你的CapSolver费用是按解决次数计算，而不是按秒计算。

有效自然语言模式

以下是在Hermes任何通道中可以使用的经过验证的表达方式：

• "前往[URL]，等待60秒，然后提交表单"
• "导航到[URL]，填写[字段]，等待30秒，然后点击[按钮]"
• "打开[URL]，大约一分钟后再点击提交并告诉我结果"
• "访问[URL]，等待片刻以使页面完全加载，然后提交"

不要这样说

避免这些表达方式——它们可能让代理困惑，并且在一些安全调优的模型（尤其是GLM系列）中已被观察到会触发拒绝：

• "等待CAPTCHA被解决"（代理不知道CAPTCHAs）
• "使用CapSolver解决验证"（代理不控制扩展程序）
• "点击reCAPTCHA复选框"（扩展程序处理此操作——点击可能干扰）
• "绕过安全检查"（听起来具有对抗性——一些模型会拒绝）

其工作原理

对于技术爱好者，以下是架构：

  Your message                  Hermes Gateway
  ──────────────────────────────────────────────────────────
  "go to page,           ──►   Hermes Agent receives message
   wait 60s, submit"           │
                                ▼
                           browser_cdp / browser tools
                                │  (attach via WebSocket
                                │   to ws://127.0.0.1:9222)
                                ▼
                           ┌────────────────────────────────────┐
                           │  chrome-debug Chromium (background)│
                           │                                     │
                           │  ┌───────────────────────────────┐ │
                           │  │ CapSolver MV3 extension       │ │
                           │  │ (loaded via --load-extension; │ │
                           │  │  requires Chrome for Testing  │ │
                           │  │  or Chromium — branded Chrome │ │
                           │  │  137+ ignores this flag)      │ │
                           │  │                                │ │
                           │  │ 1. content script detects CAPTCHA │
                           │  │ 2. service worker calls CapSolver API │
                           │  │ 3. token received                │ │
                           │  │ 4. token injected into form field │ │
                           │  └───────────────────────────────┘ │
                           └────────────────────────────────────┘
                                │
                                ▼
                           Hermes Agent waits 60 seconds...
                                │
                                ▼
                           browser_cdp: click Submit
                                │
                                ▼
                           Form submits WITH valid token
                                │
                                ▼
                           Post-submit confirmation page

为什么使用CDP附加而不是“直接传递扩展程序数组”？

Hermes的浏览器工具层基于五个可互换的提供者（Browserbase、Browser Use、Firecrawl、Camoufox、无头Chromium）。其中三个是云服务——你无法控制浏览器二进制文件，因此无法放置--load-extension标志。一个（Camoufox）是基于Firefox的。第五个——CDP附加——是唯一可以插入用户控制的Chromium的接口。

权衡是值得的：Hermes默认保持云可移植性，但一旦你想要浏览器端的超级功能（CapSolver、你自己的广告拦截器、自定义MV3工具、持久cookie等），你只需自己启动Chrome并指向Hermes。一行配置。完全控制。

--load-extension 实际做了什么

当Chrome以--load-extension=/path/to/extension启动时，它将该目录视为未打包的扩展程序——与Chrome开发者模式使用的机制相同。扩展程序的清单、内容脚本和服务工作者都会像你从Chrome网络商店安装一样注册。没有沙箱区别，没有降级的API访问权限——它是一个完全特权的扩展程序。

然后CapSolver扩展程序接管其余部分：

1. 内容脚本（注入到每个页面）监视已知的CAPTCHA小部件——reCAPTCHA、Cloudflare、AWS WAF等。
2. 当检测到小部件时，内容脚本向服务工作者发送消息
3. 服务工作者使用assets/config.js中的密钥通过CapSolver API进行身份验证，提交挑战详情，并轮询令牌
4. 一旦收到令牌，它通过内容脚本注入到页面的隐藏响应字段中
5. 当代理点击提交时，表单已经包含一个有效的已解决令牌

Hermes代理完全不参与——它看到的是一个正常页面，等待你告诉它等待的时间，然后提交。只是页面恰好有一个有效的令牌。

环境注意事项：避免在Chrome标志中使用--disable-background-networking。它会阻止CapSolver服务工作者的出站XHR/fetch——因此扩展程序永远无法访问CapSolver API。第3步的配方故意省略了它。

完整配置参考

Hermes端：~/.hermes/config.yaml

唯一需要更改的是在browser:块下添加cdp_url：

browser:
  inactivity_timeout: 120
  cdp_url: http://127.0.0.1:9222

Chrome端：--load-extension 参数

你应该传递给Chrome的完整标志列表：

CapSolver端：assets/config.js

~/.hermes/capsolver-extension/assets/config.js中的最小配置：

export const defaultConfig = {
  apiKey: 'CAP-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
  useCapsolver: true,
  enabledForRecaptcha: true,
  enabledForRecaptchaV3: true,
  // ... 请参阅CapSolver文档以获取完整的切换列表
};

故障排除

hermes doctor 不在工具可用性下列出 browser-cdp

症状：重启Hermes后，browser-cdp工具在hermes doctor输出中缺失。

原因：Hermes仅在配置CDP端点时注册browser-cdp——无论是config.yaml中的browser.cdp_url、BROWSER_CDP_URL环境变量，还是活动的/browser connect会话。检查是配置存在性，而不是可达性（参见tools/browser_cdp_tool.py:_browser_cdp_check）。最常见的原因是在config.yaml中键名拼写错误或嵌套错误，而不是Chrome不可达。

解决方法：

# 1. 确认键正确嵌套在"browser:"下（不是顶级）
grep -A2 '^browser:' ~/.hermes/config.yaml
# 预期输出：
#   browser:
#     ...
#     cdp_url: http://127.0.0.1:9222

# 2. 然后确认Chrome确实在此端点运行
curl -s http://127.0.0.1:9222/json/version

# 3. 如果Chrome未运行，检查chrome-debug日志：
tail -n 30 /tmp/chrome-debug.log     # 或：journalctl --user -u chrome-debug -n 30

扩展程序未加载（品牌Chrome问题）

症状：Chrome干净启动，但CAPTCHAs从未被解决——每次提交都失败。

原因：你使用的是品牌Google Chrome 137+，它会静默忽略--load-extension。

解决方法：切换到Chrome for Testing或Chromium。验证你的二进制文件：

/path/to/your/chrome --version
# Chrome for Testing: "Chromium 143.0.7499.4"
# 品牌Chrome:    "Google Chrome 143.0.7499.109"  ← 不起作用

CAPTCHA未解决（表单失败）

可能原因：

1. 等待时间不足——增加到60秒
2. 无效的CapSolver API密钥——检查你的CapSolver仪表板
3. 余额不足——为你的CapSolver账户充值
4. 后台网络禁用——确保你的Chrome参数中没有--disable-background-networking标志（它会阻止扩展程序的出站API调用）
5. 品牌Chrome——参见上文

重启后首次操作浏览器超时

症状：Hermes重启后首次浏览器操作超时，但后续操作正常。

原因：冷启动CDP握手偶尔会超过Hermes的默认工具超时。后续操作复用热的WebSocket并快速完成。

解决方法：重试一次命令。如果问题仍然存在，增加config.yaml中的browser.inactivity_timeout。

切换二进制文件后Chrome崩溃

症状：切换到另一个Chrome版本后，Chrome崩溃并出现磁盘缓存错误。

原因：用户数据目录是由不同Chrome版本创建的，现在不兼容。

解决方法：

# 1. 停止当前的chrome-debug进程（无论你如何管理它）
pkill -f "remote-debugging-port=9222"

# 2. 清除旧的配置文件
rm -rf ~/.hermes/chrome-debug

# 3. 重启chrome-debug（通过你的进程管理器，或重新运行脚本）
nohup ~/.hermes/chrome-debug.sh > /tmp/chrome-debug.log 2>&1 &

CapSolver服务工作者未显示在/json/list中

症状：curl http://127.0.0.1:9222/json/list仅返回page条目，没有service_worker。

原因：Chrome MV3服务工作者会积极进入空闲状态，而在较新的Chrome版本中，/json/list端点可能完全不显示它们——即使它们正在处理事件。

解决方法：这不是诊断信息。不要依赖/json/list来确认CapSolver是否加载。相反，将代理导航到实际的reCAPTCHA保护页面（例如https://www.google.com/recaptcha/api2/demo），并观察表单提交是否成功。成功的提交是扩展程序已加载并解决挑战的证明；目标列表缺失并不是失败信号。

最佳实践

1. 始终使用较长的等待时间

更长的等待时间总是更安全。CAPTCHA通常在5–20秒内解决，但网络延迟、复杂挑战或重试可能会增加时间。30–60秒是最佳选择。

2. 保持消息自然

而不是：

"导航到URL，等待CAPTCHA解决，然后提交"

使用：

"前往URL，等待大约一分钟，然后提交表单"
自然的表达方式在与代理交互时效果更好，并且更易于与安全调优的模型配合使用——在一些GLM类模型上，围绕CAPTCHA的对抗性表述已被观察到会触发拒绝响应。

3. 监控您的CapSolver积分

每次解决CAPTCHA会消耗积分。定期查看您的积分，网址为capsolver.com/dashboard，以避免中断。

4. 使用专用用户数据目录

不要将 --user-data-dir 指向您的真实Chrome配置文件。使用 ~/.hermes/chrome-debug（Hermes内置的 /browser connect 也默认指向此目录）。这样代理的浏览器将与您的个人浏览完全隔离。

5. 仅将CDP绑定到环回地址

--remote-debugging-address=127.0.0.1 在生产环境中是必需的。Chrome DevTools Protocol 会将浏览器的完全控制权交给任何能够访问该端口的人。切勿将9222端口暴露在公共网络中。

6. 在无头服务器上使用 Xvfb

Chrome扩展程序即使在您不需要看到浏览器时也需要显示上下文。在没有物理显示器的Linux服务器上，运行一个虚拟显示器：

# 安装 Xvfb（Ubuntu/Debian）
sudo apt-get install xvfb

# 启动虚拟显示器
Xvfb :99 -screen 0 1920x1080x24 &

# 告诉Chrome使用它（上面的 chrome-debug.sh 启动器已默认设置 DISPLAY=:99）
export DISPLAY=:99

如果您使用的是第3步中的 chrome-debug.sh 启动器，顶部的 export DISPLAY=:99 行已处理此问题——只需确保主机上运行了 Xvfb :99。

7. 在生产环境中使用进程管理器监督Chrome

松散的 chrome & 命令在父shell退出、Chrome崩溃或系统重启时会终止。将启动过程封装在 chrome-debug.sh（第3步）中，并使用您已用于其他堆栈组件的任何工具进行监督——systemd、supervisord、runit、Docker等。该集成与进程管理器无关；选择已在主机上运行的工具即可。

8. 搭配廉价模型使用

由于模型永远不会看到CAPTCHA——扩展程序会隐形解决——您不需要为高CAPTCHA负载的工作使用前沿模型。一个廉价且功能完备的模型就足够了（例如，在 config.yaml 中设置 provider: openrouter 和 default: z-ai/glm-4.6）。所有智能都存在于扩展程序中；模型只需导航、输入和点击。

9. 信任其过往表现

用于此Hermes集成的CapSolver基础设施已处理了生产自动化流水线中的reCAPTCHA v2/v3、Cloudflare Turnstile和AWS WAF挑战——这并非仅为本教程拼凑的临时解决方案，而是团队已用于大规模爬虫和QA自动化的相同解决层。

结论

Hermes + CapSolver集成代表了代理工作流中CAPTCHA解决的根本性新方法。您无需编写代码来检测CAPTCHA、调用API或注入令牌，只需：

1. 使用 --load-extension=/abs/path/to/capsolver-extension 和 --remote-debugging-port=9222 启动一次Chrome
2. 在 ~/.hermes/config.yaml 的 browser: 块中添加 cdp_url：
   yaml Copy

   browser:
     cdp_url: http://127.0.0.1:9222

   （注意嵌套键——顶级 cdp_url 会被静默忽略）
3. 自然地与您的代理交流——在表单提交前包含等待时间
4. 在表单提交后读取正常页面结果

CapSolver Chrome扩展程序将处理其余工作——检测CAPTCHA、通过CapSolver API解决，并将令牌注入页面。您的代理根本无需了解任何关于CAPTCHA的信息。

这就是拥有自主AI代理时CAPTCHA解决的样子：隐形、自动且无需编码。

准备好了吗？ 注册CapSolver 并使用优惠码 herme 在首次充值时获得额外奖励！

常见问题

我需要告诉代理关于CapSolver吗？

不需要。 实际上，您应避免在消息中提及CAPTCHA或CapSolver。扩展程序在后台隐形工作。只需在您的指令中包含等待时间（例如，“等待60秒，然后提交”）以给扩展程序解决页面上任何CAPTCHA的时间。

为什么不能使用常规的Google Chrome？

Google Chrome 137+（2025年中发布）在品牌版本中移除了 --load-extension 命令行标志。这意味着无法在自动化会话中加载Chrome扩展程序。您需要Chrome for Testing或独立Chromium，它们仍支持此标志。

我可以使用Hermes的云浏览器提供商（Browserbase、Browser Use）吗？

不可以——云提供商在别人的基础设施上运行浏览器，因此您无法在会话中加载任意扩展程序。本指南中的CDP附加模式是将Hermes与Chrome扩展程序结合的唯一方式。（一旦在 config.yaml 中设置 browser.cdp_url，Hermes会将浏览器流量路由到本地Chrome，云提供商在您删除该行前将保持静默。）

我可以使用除Chrome for Testing以外的其他浏览器吗？

可以——任何仍支持 --load-extension 的Chromium浏览器都适用。您可以使用：

• Chrome for Testing（推荐——本指南使用）
• Chromium（独立构建）
• Playwright的内置Chromium（如果您运行过 npx playwright install，则已安装）
• Brave、Vivaldi、Opera——均为Chromium内核，仍接受该标志
• 较旧的 Google Chrome ≤ 136——但137+版本已移除该标志，因此不要锁定到过时版本

集成方法相同：将 --remote-debugging-port=9222 --load-extension=/path/to/capsolver-extension 指向您偏好的二进制文件。

以下内容无效：

• 品牌版Google Chrome 137+——静默忽略 --load-extension
• Microsoft Edge——同样已移除该标志
• 基于Firefox的浏览器（Firefox、LibreWolf、Camoufox）——CapSolver扩展为Chrome MV3格式，而非Firefox WebExtensions
• Hermes的云浏览器提供商（Browserbase、Browser Use、Firecrawl）——您无法控制远程二进制文件，因此无法加载自定义扩展

Camoufox呢？Hermes支持它。

是的——Camoufox是Hermes的五个内置浏览器提供商之一，是执行不涉及Chrome扩展程序任务的优秀隐身Firefox选项。但问题是Camoufox基于Firefox，而CapSolver浏览器扩展是Chrome MV3格式——因此两者无法在同一个会话中运行。

好消息：使用Hermes您无需永久选择。~/.hermes/config.yaml 中的 browser.cdp_url 配置是一个单开关——在需要CAPTCHA解决时指向配备CapSolver的Chrome，在需要Firefox隐身时指向Camoufox。典型设置同时运行两者：

# 活动行：通过注释/取消注释切换配置文件
browser:
  cdp_url: http://127.0.0.1:9222          # CapSolver Chrome（本指南）
  # cdp_url: http://127.0.0.1:9333        # Camoufox端点

然后重启Hermes（hermes gateway run，或通过监督该网关的工具触发重启），切换将在几秒内生效。相同的Hermes、相同的频道、相同的能力——根据工作负载使用不同的浏览器。

Hermes的 /browser connect 命令与此设置兼容吗？

是的。Hermes内置的 /browser connect 斜杠命令（在交互式 hermes TUI中）指向我们使用的默认用户数据目录（~/.hermes/chrome-debug）和相同端口（9222）。一旦设置好chrome-debug旁车，您可以在Hermes中交互式使用 /browser connect，或在 config.yaml 中保留 browser.cdp_url 以实现永久连接——两者均针对同一Chrome。

通过消息渠道使用Hermes呢？

该集成完全与渠道无关。一旦在 config.yaml 中设置 browser.cdp_url，每项浏览器操作——无论来自CLI的 hermes -z、交互式 hermes TUI，还是来自Telegram、Discord、Slack、WhatsApp、Signal或电子邮件的消息——都会通过您的CapSolver配备的Chrome路由。扩展程序在所有情况下以相同方式解决CAPTCHA。

在自动化测试中应使用Google演示页面吗？

仅将演示页面作为快速烟雾测试使用。在Google官方reCAPTCHA常见问题解答中，他们建议为自动化测试创建专用的测试站点密钥，而不是在生产流水线中依赖公共演示页面。

CapSolver扩展支持哪些CAPTCHA类型？

CapSolver Chrome扩展程序自动解决reCAPTCHA v2（复选框和隐形）、reCAPTCHA v3、Cloudflare、AWS WAF CAPTCHA以及其他广泛部署的组件。内容脚本会检测页面上的CAPTCHA类型并相应解决——您无需进行每种类型的配置。（注意：Cloudflare Turnstile和Cloudflare 5秒挑战无法通过浏览器扩展解决；它们仅可通过CapSolver的API解决，且超出本指南范围。）

CapSolver的费用是多少？

CapSolver提供基于CAPTCHA类型和数量的具有竞争力的定价。访问 capsolver.com 查看当前定价。

Hermes Agent是免费的吗？

Hermes Agent是开源的（github.com/NousResearch/hermes-agent），可在您自己的硬件上免费运行。您需要所选AI模型提供商的API密钥（推荐OpenRouter——Hermes通过它支持200多个模型），以及一个带有积分的CapSolver账户用于CAPTCHA解决。

您应该告诉代理等待多长时间？

对于大多数CAPTCHA，30-60秒足够。实际解决时间通常为5-20秒，但增加额外缓冲可确保可靠性。不确定时，使用60秒。

我可以在无头服务器上使用此功能吗？

是的。您需要Xvfb（X虚拟帧缓冲区）来提供显示，因为Chrome扩展程序需要显示上下文。在主机上运行 Xvfb :99 -screen 0 1920x1080x24 & 并确保在 chrome-debug.sh 启动器中导出 DISPLAY=:99（第3步中的启动器已处理此问题）。同时，在Chrome参数中保留 --no-sandbox，因为大多数服务器内核不会授予Chrome沙箱所需的权限。

我可以运行多个Hermes实例指向同一个chrome-debug吗？

技术上可以，但您需要自行管理标签/会话冲突。对于大多数工作负载，一个Hermes ↔ 一个chrome-debug是最简洁的设置。如果需要真正的并行性，请在不同端口（9222、9223等）上运行多个chrome-debug旁车，并将每个Hermes指向其自己的实例。

这与Hermes技能兼容吗？

是的。Hermes技能是程序化记忆——代理已学习的步骤序列。涉及浏览CAPTCHA保护网站的技能将自动受益于CapSolver集成，与临时消息相同，因为被增强的是浏览器工具本身。无需对技能进行任何更改。