AI代理在调用求解器之前如何检测CAPTCHA

简要说明

• AI代理的CAPTCHA检测应在调用求解工具之前识别支持的挑战证据。
• CapSolver的核心SDK将检测挑战、读取其参数和请求解决方案分离开来。
• 空的检测结果意味着SDK在检查的页面状态中未找到支持的挑战；这并不证明页面已准备好。
• 下面的示例在Google的公开reCAPTCHA演示页面上运行官方检测方法，而无需求解或提交任何内容。
• 保持相同的浏览器页面以进行下一步，区分普通页面错误和CAPTCHA，并在之后验证原始任务。

代理打开一个页面但无法继续。它可能已到达CAPTCHA、未完成的页面加载、速率限制或普通表单错误。立即调用求解器可能会将简单的浏览器问题转化为混乱的重复请求序列。

CapSolver 提供了记录的浏览器检测方法，可在求解前识别支持的CAPTCHA类型。有用的流程是检查当前页面，分类所发现的内容，选择相关工具，并检查最终结果。本指南将这些步骤分开，并使用一个小型可运行的示例。它专注于自有QA环境、批准的浏览器工作流程和公共演示页面，并明确区分检测挑战和完成应用任务。

使用记录的检测方法

在您的应用程序已控制兼容浏览器页面时，使用Core SDK的检测方法。

Core SDK参考 记录了四个相关操作：detect(page)返回检测到的CAPTCHA类型；get_captcha_info(page)读取结构化参数；solve(info)请求解决方案；以及solve_on_page(page)结合基于浏览器的检测、求解和填充。

进行检测检查时，调用检测方法。不要仅为了发现页面是否包含挑战而使用完整的求解方法。保持此选择明确，以便更容易理解哪些步骤需要求解服务凭证，哪些步骤仅检查浏览器状态。

SDK返回CAPTCHA类型枚举值，而不是应用程序可能在其自身状态消息中使用的任意标签。请阅读记录的值，而不是从字符串表示中发明映射。

CapSolver for AI Agents概述 解释了检测和参数准备发生在您的端，而实际识别使用服务。当查看日志时，此区别很重要：本地成功检测并不证明已发送求解请求。

首先运行一个小的检测示例

从官方演示页面开始，这样您可以在不涉及业务工作流的情况下检查浏览器访问和检测方法。

下面的示例改编了官方Core SDK的create_capsolver和detect用法。额外的代码打开并关闭一个Playwright浏览器，等待演示小部件的框架，并打印返回的枚举值。

测试环境使用Python 3.12、capsolver-core==0.1.1和playwright==1.63.0。在隔离环境中安装这些包并安装匹配的Chromium浏览器：

python -m pip install "capsolver-core[playwright]==0.1.1" "playwright==1.63.0"
python -m playwright install chromium --only-shell

Playwright的 Python安装指南 说明了单独的包和浏览器安装步骤。仅安装Python包并不能确保其匹配的浏览器可执行文件存在。

将以下内容保存为detect_demo.py：

import asyncio
from capsolver_core import create_capsolver
from playwright.async_api import async_playwright


async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        try:
            page = await browser.new_page()
            await page.goto(
                "https://www.google.com/recaptcha/api2/demo",
                wait_until="domcontentloaded",
            )
            await page.wait_for_selector('iframe[title="reCAPTCHA"]')
            async with create_capsolver(api_key="YOUR_API_KEY") as cap:
                types = await cap.detect(page)
                print([item.value for item in types])
        finally:
            await browser.close()


asyncio.run(main())

使用python detect_demo.py运行它。在验证运行中，实际打印结果为['reCaptchaV2']。

占位符密钥足够，因为此示例仅执行检测。它不会调用求解API，点击挑战，提交演示表单或验证令牌。实际求解操作需要适当的服务凭证和任务输入。

此运行确认了测试时该页面的演示检测路径。它不表示普遍的检测覆盖范围或求解成功率。

在决定下一步之前先查看当前页面

将检测视为对特定时刻页面的观察。

页面可能在小部件或应用程序控件出现之前完成初始导航。在示例中，domcontentloaded之后会等待已知的演示框架。对于其他页面，选择与实际界面对应的就绪条件。

Playwright Page API 描述了页面导航和元素等待行为。就绪检查应帮助确定正在检查的状态，而不是引入长时间的无条件睡眠。

当检测器返回类型时，记录足够的上下文以将该结果与中断的任务联系起来：批准的页面、时间以及待处理操作的简短描述。您不需要大型状态机框架即可开始。

当检测器返回空列表时，在继续之前检查页面。内容可能是普通的，仍在加载，未被该检测器支持，或受其他问题影响。“未检测到”和“任务成功”是两个独立的陈述。

一个带有验证码类的普通HTML元素也不一定等同于已初始化的小部件。测试实际页面行为，尤其是在网站更改其验证控件渲染方式后。

将验证码与相邻的失败区分开

仅在证据支持该分类时，将页面发送到验证码处理路径。

验证码 是一种可能的中断。过期的会话、无效的表单字段、缺失的权限或网络错误需要不同的响应。如果页面显示多个消息，请检查哪个消息阻止了预期操作。

例如，HTTP 429 表示请求速率限制，并可能包含重试延迟。它本身并不证明存在验证码。检测器和应用程序响应应分别告知决策的不同部分。

保持下一步操作简单：

• 如果预期的普通页面已准备好，继续批准的任务。
• 如果检测到支持的挑战，请检查其参数和配置的处理程序。
• 如果页面显示无关错误，请遵循该错误的故障排除路径。
• 如果状态不明确，请停止并检查，而不是反复调用求解器。

这是在相关文章AI代理任务为何卡在验证码上中描述的实际边界。检测应使下一步决策更清晰，而不是围绕每个失败页面创建另一个循环。

领取您的CapSolver优惠码

立即提升您的自动化预算！
在充值CapSolver账户时使用优惠码 CAP26，每次充值可额外获得 5% 的奖励——无限制。
现在在您的 CapSolver仪表板 中领取

为下一步选择合适的CapSolver层

选择与已控制任务的应用程序相匹配的集成层。

Python浏览器脚本可以直接使用核心SDK。一个由LLM驱动的应用程序可以通过代理工具适配器暴露支持的操作。MCP客户端需要配置的MCP服务和对服务实际提供功能的访问。

代理工具文档 描述了适配器与核心引擎的关系。在提示中添加工具描述并不会自动将其连接到浏览器。执行器仍需要所需的运行时上下文。

对于初学者实现，保持检测和批准的下一步操作紧密相连。如果浏览器在检测后已导航，请检查新页面状态，而不是在未检查的情况下重用旧参数。

不要仅仅因为存在某些方法就将其添加到代理中。暴露任务所需的操作，并定义应用程序应在何时停止。保持工具选择的小规模有助于故障排除。

验证检测和求解后发生的情况

针对每个阶段进行验证。

检测应报告SDK发现的内容。参数读取应生成所选任务所需的字段。求解调用应返回其记录的结果或错误。浏览器工作流应达到其自己的预期页面、数据或确认。

对于批准的目录读取，成功意味着获得请求的项目数据。对于测试表单，成功意味着观察应用程序的确认。检测器返回类型并不满足任一条件。

在验证集成时使用少量检查：

1. 普通页面不会触发不必要的求解。
2. 支持的已初始化小部件可以被识别。
3. 无关的页面错误遵循其自己的分支。
4. 更改的页面会推翻之前观察的假设。
5. 未成功的尝试会报告有用的原因并在选定限制内停止。

这些检查测试应用程序决策，而不是承诺支持每个现实世界的挑战。保持实际检测输出可供调试，而不是用通用的“验证码已修复”消息替换它。

在不构建复杂系统的情况下控制重复检查

为每个任务设置明确的停止点，并在尝试更多工作之前检查重复的中断。

如果同一挑战再次出现，请检查页面是否更改、处理程序是否完成以及应用程序是否接受结果。重复检测与创建另一个付费求解任务不同。分别跟踪这些操作，以免无害的观察静默地变成重复提交。

通常，简短的诊断记录就足够了：页面标识、检测类型、处理程序结果和应用程序结果。 OWASP日志指南 建议在操作日志中保护敏感信息。排除API密钥、会话cookie、原始解决方案令牌和不必要的页面内容。

从单个测试转向计划工作时，保持相同的清晰检查。逐步扩大范围，按原因审查失败，并在批准的任务或访问条件发生变化时停止。复杂性应遵循已证明的需求。

保持检测与任务完成分离

可靠的检测为代理提供更好的下一步行动证据。它不会取代求解、浏览器状态检查或应用程序的确认。

从示例开始，将就绪检查适应您的批准页面，并在需要时使用 CapSolver 进行支持的挑战步骤。保持简单的顺序：观察、分类、处理、验证。

常见问题

Q: AI代理如何检测验证码？

应用程序可以使用支持的检测方法检查实时浏览器页面，并将该证据返回给代理。CapSolver的Core SDK记录了一个检测方法，该方法返回识别的验证码类型。

Q: 检测是否需要付费求解请求？

演示的仅检测调用检查了浏览器页面而未调用求解服务。求解是需要适当凭证和任务输入的独立操作。

Q: 空的检测结果意味着什么？

这意味着在检查的页面状态中未找到支持的类型。在将该结果视为继续的许可之前，请检查就绪情况、页面错误和检测器覆盖范围。

Q: 该示例能否检测每个网站上的每个验证码？

不能。该示例已在一台官方reCAPTCHA演示页面上验证。其他挑战类型、渲染模式和浏览器上下文需要自己的检查。

Q: 代理何时应停止？

当页面状态不明确、工作流超出其批准范围或重复处理未产生确认进展时停止。报告观察到的原因，而不是继续无限制的循环。