如何通过Hermes Agent和CapSolver解决浏览器自动化中的CAPTCHA

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

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

浏览器工具

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

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

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

什么是CapSolver？

CapSolver 是领先的验证码解决服务，提供人工智能驱动的解决方案，用于绕过现代验证码挑战。支持每种主要验证码类型和快速响应时间，CapSolver可无缝集成到自动化工作流中——无论你是通过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：持久后台进程（推荐用于生产）

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

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

#!/usr/bin/env bash
# ~/.hermes/chrome-debug.sh
# 启动预加载 CapSolver 扩展的 Chrome-for-Testing
# 并在 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是否正常工作，而不是通过轮询目标列表。

如何使用

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

黄金法则

不要向代理提及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系列）中已被观察到会触发拒绝：

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

其工作原理

对技术感兴趣的读者，以下是架构：

  您的消息                  Hermes网关
  ──────────────────────────────────────────────────────────
  "去页面，           ──►   Hermes代理接收消息
   等待60秒，提交"           │
                                ▼
                           browser_cdp / browser工具
                                │  （通过WebSocket
                                │   连接到 ws://127.0.0.1:9222）
                                ▼
                           ┌────────────────────────────────────┐
                           │  chrome-debug Chromium（后台）│
                           │                                     │
                           │  ┌───────────────────────────────┐ │
                           │  │ CapSolver MV3扩展       │ │
                           │  │ （通过--load-extension加载； │ │
                           │  │ 需要Chrome进行测试  │ │
                           │  │ 或Chromium —— 品牌Chrome │ │
                           │  │ 137+忽略此标志）      │ │
                           │  │                                │ │
                           │  │ 1. 内容脚本检测CAPTCHA │
                           │  │ 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. 内容脚本（注入到每个页面）监视已知的CAPTCHA小部件——reCAPTCHA、hCaptcha、FunCaptcha、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，等待约一分钟，然后提交表单"
自然的表达方式与代理更兼容，并且与安全调优的模型更友好——在 CAPTCHA 周围使用对抗性措辞已被观察到会导致某些 GLM 类模型拒绝响应。

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

如果您使用的是第 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）。所有智能功能都在扩展程序中；模型只需导航、输入和点击即可。

结论

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 在首次充值时获得额外奖励！

FAQ

我需要告诉代理关于 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、相同的频道、相同的能力——根据工作负载使用不同的浏览器。

Hermes 的 /browser connect 命令是否适用于此设置？

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

通过消息渠道使用 Hermes 是否可行？

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

在自动化测试中是否应使用 Google 示例页面？

仅在快速测试中使用示例页面。在 Google 的官方 reCAPTCHA 常见问题中，他们建议为自动化测试创建专用的测试站点密钥，而不是在生产管道中依赖公共示例页面。

CapSolver 扩展程序支持哪些 CAPTCHA 类型？

CapSolver Chrome 扩展程序可自动解决 reCAPTCHA v2（复选框和隐形）、reCAPTCHA v3、hCaptcha、FunCaptcha、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 Skills 兼容吗？

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