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

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

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

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

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

什么是 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 Sandbox
• 内置浏览器工具：通过 Playwright + Chrome DevTools Protocol 驱动真实 Chromium

浏览器工具

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

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

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

什么是 CapSolver？

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

为什么这个集成不同？

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

Hermes + CapSolver 从根本上不同：

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

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

“去那个页面，等待 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：持久后台进程（推荐用于生产环境）

对于任何比单次测试运行更长的设置，将启动包装在一个小的 shell 脚本中，以便你可以在后台运行 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/<您的版本>",
   "Protocol-Version": "1.3",
   "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/..."
}

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

如何使用

这是最重要的部分。完成设置后，使用Hermes与CapSolver进行交互非常简单。

黄金法则

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

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

示例1：一次性烟雾测试

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

hermes -z '打开 https://www.google.com/recaptcha/api2/demo。等待60秒以确保页面完全加载。然后点击标记为“Send!”或ID为"recaptcha-demo-submit"的按钮。点击后等待5秒，并告诉我页面上可见的文本。' --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系列）中可能被拒绝：

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

其工作原理

对于技术爱好者，这里是架构：

  您的消息                  Hermes 网关
  ──────────────────────────────────────────────────────────
  "前往页面，           ──►   Hermes 代理接收消息
   等待60秒，提交"           │
                                ▼
                           browser_cdp / browser 工具
                                │  （通过WebSocket
                                │   连接到 ws://127.0.0.1:9222）
                                ▼
                           ┌────────────────────────────────────┐
                           │  chrome-debug Chromium（后台）   │
                           │                                     │
                           │  ┌───────────────────────────────┐ │
                           │  │ CapSolver MV3 扩展           │ │
                           │  │ （通过 --load-extension 加载； │ │
                           │  │  需要 Chrome for Testing  │ │
                           │  │  或 Chromium — 品牌 Chrome  │ │
                           │  │  137+ 忽略此标志）         │ │
                           │  │                                │ │
                           │  │ 1. 内容脚本检测验证码         │ │
                           │  │ 2. 服务工作线程调用 CapSolver API │ │
                           │  │ 3. 收到令牌                   │ │
                           │  │ 4. 令牌注入到表单字段         │ │
                           │  └───────────────────────────────┘ │
                           └────────────────────────────────────┘
                                │
                                ▼
                           Hermes 代理等待60秒...
                                │
                                ▼
                           browser_cdp: 点击提交
                                │
                                ▼
                           表单提交并携带有效令牌
                                │
                                ▼
                           提交后的确认页面

为什么选择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. 内容脚本（注入到每个页面）监视已知的验证码小部件——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后，hermes doctor输出中缺少browser-cdp工具。

原因：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干净启动，但验证码从未被解决——每次提交都失败。

原因：您使用的是品牌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"  ← 无法工作

验证码未解决（表单失败）

可能原因：

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. 始终使用较长的等待时间

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

2. 保持消息自然

而不是：

"导航到URL，等待验证码解决，然后提交"

使用：

"前往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 开发者工具协议会将浏览器的完全控制权交给任何可以访问该端口的人。绝不要将 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

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

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

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

8. 与廉价模型搭配使用

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

结论

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 复制代码

   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，或者可以将 browser.cdp_url 保留在 config.yaml 中以实现永久连接——两者均针对同一 Chrome。

通过消息渠道使用 Hermes 呢？

该集成完全与渠道无关。一旦在 config.yaml 中设置了 browser.cdp_url，每项浏览器操作——无论来自 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 & 并确保 DISPLAY=:99 在 chrome-debug.sh 启动器中导出（Step 3 中的启动器已处理此问题）。此外，由于大多数服务器内核不授予 Chrome 沙盒所需的权限，需在 Chrome 参数中保留 --no-sandbox。

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

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

这与 Hermes Skills 兼容吗？

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