🎉全新面向 AI Agent 的 CapSolver-MCP、agent 工具和 SDK 集成
Emma Foster
Machine Learning Engineer
已发表 Oct 29, 2026
已更新 Oct 29, 2026 · 最小阅读量
在一个被允许的浏览器任务中，AI 代理遇到一个 CAPTCHA。你的应用已经知道页面 URL 和公用 site key。下一步应该是发起一个 HTTP 请求，还是调用 MCP 工具？
关键区别在于：谁来控制这个操作。你维护的服务可能需要直接的任务 ID 和自定义的轮询逻辑；而已有 MCP 客户端则更适合通过可发现、具备明确定义输入的工具来完成工作。两种方式都仍然需要一个能正确使用结果的浏览器工作流。
CapSolver 提供任务 API 和 MCP 服务。下面的对比帮助你为同一个 CAPTCHA 检查点确定它们各自的角色。先从你需要的 CAPTCHA 任务类型入手，再确定应用中哪个部分来“拥有”该任务。
直接 API 将求解请求暴露给你的应用，而 MCP 则向 MCP 客户端暴露工具。
在 API 路径中，你的服务将一个有文档的任务发送给 createTask。异步任务返回一个标识符，应用使用它来请求任务结果。应用自行决定将该标识符存在哪，以及由哪个 worker、在什么时候再次检查。
在 MCP 路径中，客户端连接到服务器，发现其中可用的工具，并使用结构化参数调用某个工具。MCP 工具规范定义了工具的发现和调用方式。之后，服务器会在该工具边界之内执行自己的实现逻辑。
CapSolver 的 MCP 服务封装了其 Core SDK。官方服务器仓库是实现参考，而不是另一个单独的 CAPTCHA 求解模型。因此，仅仅改变接口并不能作为识别准确率更高或求解速度更快的证据。
选择与你现有执行组件职责相匹配的接口。
| 决策点 | 直接任务 API | MCP 服务 |
|---|---|---|
| 既有应用 | 当你的后端本就负责 HTTP 调用和作业状态时非常有用 | 当宿主环境已经具备发现和调用 MCP 工具的能力时非常有用 |
| 任务生命周期 | 你的应用保留任务 ID 并主动获取结果 | 工具实现负责其内部求解流程 |
| 输入 | 针对任务的 API schema | 已安装服务器所声明的工具 schema |
| 结果处理 | 解析 API 的错误/状态封装以及任务特定的 solution | 检查 MCP 的返回值以及工具自身的成功/错误数据 |
| 能力检查 | 阅读目标任务类型的文档 | 检查已安装的工具列表和 supported-types 注册表 |
| 浏览器续接 | 你的应用通过其支持的浏览器流程来应用结果 | 浏览器的拥有者仍需要受支持的方式来继续后续操作 |
这是一个实现选择，而不是对提供方的排名。无论选择哪一列，你都仍然需要正确识别挑战类型，并检查最终页面状态。异步 API 将请求工作与接收结果分离。你的代理必须维护这些步骤之间的关联。
当 worker 属于后端时，直接掌控任务生命周期会更有利。例如，一个已授权的目录代理可能会暂停浏览器作业，记录返回的求解任务 ID，并在规定的截止时间内等待。之后，另一个 worker 就可以检查该作业记录，而无需让模型来“回忆”发生过什么。
getTaskResult 参考描述了异步状态以及任务特定的 solution 数据。要将结果与自己创建的任务一一对应。不要把每个任务都当作异步任务来处理，因为 createTask 文档中也描述了某些任务类型可以立即返回结果。
具备 MCP 能力的客户端可以受益于统一的发现接口。你可以在发起允许的调用之前检查当前有哪些工具可用，以及它们需要哪些参数。当客户端已经在运行其他工具时，将 CAPTCHA 处理也通过相同的交互模式暴露出来就会很方便。
MCP 架构概览区分了 host、client 和 server。这些角色帮助说明：一个已连接的服务器可以向代理提供服务，同时却不一定拥有当前打开的浏览器。
兑换你的 CapSolver 优惠码
立刻提升你的自动化预算！
在为 CapSolver 账户充值时使用优惠码 CAP26，每次充值可额外获得 5% 奖金——无次数上限。
现在就到你的 CapSolver 控制面板 兑换。
使用一个受支持的任务来比较输入，而不是假定可以直接把 API 请求体复制到 MCP 调用中。
对于 token 模式求解，目前的 MCP 服务参考对外暴露 solve_captcha。我们安装的 capsolver-mcp 0.1.3 声明了三个必填输入：captcha_type、website_url 和 website_key。其运行时注册表列出了 reCaptchaV2、reCaptchaV3 和 cloudflare。这些名称描述的是已安装工具的接口面，而不是承诺 MCP 封装会暴露完整的 HTTP API 目录。
而原始任务 API 则使用 clientKey 和 task 对象，task 包含所选 API 任务类型及其文档中定义的字段。工具参数和 API 字段名属于不同的 schema。应将账号密钥保存在服务器或后端环境中，而不是作为对话参数传递给代理。
在选择任一路径之前，先写清楚：挑战类型、被允许访问的页面、实际可用的输入、期望的结果，以及由哪个组件向浏览器交付该结果。如果缺少某个必需输入，应优先解决这个缺口，而不是让模型自行猜测。
在继续浏览器任务之前，要同时检查传输层结果和求解器结果。
对于原始 API，要先检查文档中定义的错误和状态字段，再去消费 solution。将任务 ID 与应用作业一同保存。如果响应表明仍在处理中，就应按文档的检索流程继续，而不是自动创建第二个任务。
对于 MCP，一个已完成的请求仍然可能包含工具层面的错误。工具也可能在 MCP 结果内部返回应用级别的成功或错误数据。应根据服务器的文档或观察到的输出，对这两层分别进行处理。避免使用诸如“工具返回了文本＝CAPTCHA 已被解决”这样的泛化规则。
之后浏览器需要自己做接受检查：原先任务所允许的表单或数据请求是否完成？预期的记录是否存在？如果工具在另一个页面上执行，其结果并不能证明代理暂停的页面已经发生了变化。已有的 MCP 安装指南覆盖了安装步骤；要将这部分工作与“应用如何消费结果”的决策区分开来。
在依赖 MCP 集成之前，先检查当前安装的工具 schema 和注册表。软件包版本可能会暴露与旧版示例不同的工具集合或受支持任务类型。
在 capsolver-mcp 0.1.3 中，通过真实的本地连接可以获取工具 schema 和 supported-types 注册表。一个缺少必填页面 URL 和 site key 的 solve_captcha 请求会被拒绝。这些检查只是在建立输入契约，而不是在衡量付费求解或网站接受情况。
在你自己的上线流程中，用有效凭据测试确切被允许的挑战，然后检查应用期望的结果。能够列出工具的客户端，只是通过了连接这一步而已。
对比你团队真正要维护的工作量：对于直接 API 调用，是一个作业存储与轮询 worker；对于 MCP，则是一个客户端/服务器运行环境与工具结果解析器。有些应用会同时需要两者。例如，代理可以请求一个高层操作，而后端 worker 则拥有求解任务的生命周期。
不要想当然地认为 MCP 会让求解变成免费的，或认为多加一层软件就一定会让速度变慢。真正有用的成本对比，必须基于你的实际使用场景和部署情况。在真实环境评估时，要分别看待付费任务消耗、客户端使用以及运行环境托管成本。
围绕代理的“执行所有者”来选择接口。当需要后端作业工作流时，选择直接 API 控制；当已有兼容工具客户端需要发现能力时，选择 MCP。在两种情况下，CapSolver 都提供受支持的 CAPTCHA 操作，而你的应用负责验证用户期望的最终结果。
问：MCP 会取代 CAPTCHA API 吗？
不会。MCP 提供的是一个工具接口，服务器可以在其实现内部调用底层求解器。它改变的是集成边界，而不是移除求解服务本身。
问：AI 代理要使用 CAPTCHA 求解器，是否必须用 MCP？
不必须。代理应用可以通过后端代码调用有文档的 API。当 MCP 的发现与工具接口契合你已经在使用的客户端时，它就很有用。
问：我能把 API 任务请求体直接发给 solve_captcha 吗？
应使用已安装工具自身的 schema。MCP 工具的参数与 HTTP API 中 clientKey 加 task 对象的封装不同。
问：连接上 MCP 服务器是否就能证明求解有效？
不能。连接和工具发现只证明协议可访问。付费求解以及被你允许的应用所接受，仍需要单独验证。
问：代理是否应该对同一个 CAPTCHA 同时尝试两种路径？
应为这次尝试指定一个唯一的执行所有者。让两条路径同时、各自独立地调用，会产生重复工作，也会让“将结果与正确浏览器任务对应起来”变得更加困难。
Emma Foster
Machine Learning Engineer
Where machine learning meets practical AI tooling.
关于作者
