
Lucas Mitchell
Automation Engineer

AI浏览器代理应首先选择目标表单,识别其当前的CAPTCHA小部件,并在整个求解和应用验证过程中保持该关联。
考虑一个拥有支持门户的页面,同一页面上有两个表单:支持请求和可选的产品反馈。授权的QA代理正在测试支持请求。即使两个表单使用相同的提供者且外观相似,完成反馈CAPTCHA也不会满足任务要求。
CAPTCHA求解器如CapSolver应在代理确定目标表单所需的受支持挑战后使用。求解器为选定的CAPTCHA任务提供答案;应用集成仍需负责正确路由该答案。
这是一个针对您团队拥有或被授权测试的页面的工作流和QA设计指南。它描述了多小部件所需的记录、阶段边界和检查。它不声称提供适用于任意页面的经过测试的即用型SDK集成。
可靠的工作流需要明确的任务范围、拥有表单到小部件的映射,以及一种检查应用验证结果的方法。
从包含实际布局变体的测试页面开始,这些变体是您的应用所支持的。记录目标表单和允许的操作。代理不应推断每个可见的提交按钮都是其任务的一部分。
页面所有者应公开稳定的表单标识符,并保留提供者公共集成创建的小部件句柄。对于reCAPTCHA,这些句柄是客户端生命周期的一部分。它们与服务检查自动化交互的一般角色不同。
您还需要支持的求解任务、存储在页面内容之外的凭证、有限的等待策略,以及QA测试工具可以观察的后端结果。如果您的应用使用了所选求解路径不支持的CAPTCHA格式,请在该边界处停止,而不是猜测替代任务。
优先使用所有者控制的测试设施进行普通表单逻辑测试。如果允许的测试专门评估真实的求解路径,请单独标记该测试,以防止模拟的CAPTCHA结果被误认为是端到端服务验证。
第一阶段将代理的请求操作转换为一个明确的表单和小部件关联。
输入是允许的操作,例如在预发布门户上发送合成的支持请求。该操作通过应用的稳定标识符识别支持表单,并获取该组件维护的小部件引用。输出是表单引用加上当前小部件实例,而不是简单的“存在CAPTCHA”。
Google的reCAPTCHA v2显示文档展示了显式渲染和多个小部件。渲染返回小部件ID;getResponse和reset等方法接受小部件ID,省略时默认使用第一个小部件。对于目标操作属于其他表单的页面,此默认值可能不正确。
Cloudflare的Turnstile客户端渲染指南也描述了显式小部件渲染和生命周期管理。使用适当的提供者API和保留的句柄,而不是在提供者之间转移方法假设。
如果多个小部件映射到表单,或映射缺失,该阶段应以可操作的诊断信息失败。DOM顺序不足以证明所有权。保存表单引用、页面生成和映射结果以供检查;不要在诊断记录中保存令牌值。
第二阶段为每个标识符赋予单一含义,以防止异步工作混淆页面组件与远程求解器任务。
| 标识符 | 代表内容 | 不能替代的内容 |
|---|---|---|
| 表单引用 | 拥有的应用操作 | 提供者任务ID |
| DOM容器ID | 包含小部件的页面元素 | 提供者的运行时小部件句柄 |
| 提供者小部件ID | 渲染的小部件实例 | CAPTCHA站点密钥 |
| 站点密钥 | 提供者集成配置 | 表单尝试的唯一身份 |
| 求解任务ID | 返回的远程求解请求 | 浏览器元素或表单标识符 |
| 应用尝试引用 | 目标操作的一次执行 | 同一页面上的每次后续重试 |
这些标签形成一个建议的应用记录,而不是提供者响应模式。保留每个句柄的原始值和类型,而不是将每个标识符归一化为可互换的字符串。
两个小部件可以共享配置,但仍属于不同的表单。因此,当拥有页面故意重用该配置时,仅按站点密钥选择是不够的。应用需要在上一阶段建立的表单关联。
将页面或组件生成附加到记录中。对话框可以关闭并重新打开,同时保留其可见标题,但使用新的小部件实例。生成信息让后续阶段能够检测到一个看似熟悉的表单不再是开始求解尝试的实例。
第三阶段将选定的小部件关联转换为支持的求解信息,同时保留其与目标表单的连接。
CapSolver Core SDK参考区分了几个操作:detect(page)返回CAPTCHA类型,get_captcha_info(page)返回CAPTCHA信息记录,solve(info)返回解决方案。记录的令牌模式覆盖包括reCAPTCHA v2、reCAPTCHA v3和Turnstile;不包括点击图像网格或拖动滑块。
该参考还描述了浏览器填充回元数据,如container_id、callback和binded_button_id。将这些视为与拥有表单映射协调的证据。仅检测到的类型不足以计数小部件实例,列表中的第一个条目也不足以证明它属于代理的任务。
检查您自己页面上的可用信息,包括其框架和渲染行为。如果检测器未提供足够的证据来选择一个目标小部件,请停止进行集成修正。不要静默地将任务扩展到页面上的所有挑战。
该阶段的输出是选定的信息记录加上解释为何选择它的应用关联。其失败边界是模糊或不支持的覆盖。有用的证据包括选定的提供者类型和映射决策,但不包括秘密和解决方案令牌。
领取您的CapSolver优惠码
立即提升您的自动化预算!
在充值CapSolver账户时使用优惠码 CAP26,每次充值可获得 5% 的额外奖励——无限制。
现在在您的 CapSolver仪表板 中领取
第四阶段仅在选定的表单和小部件关联保持当前状态时接受求解结果。
在请求解决方案之前,将尝试标记为等待其选定的CAPTCHA信息。当异步操作返回时,重新检查页面生成和小部件关联。如果支持对话框已关闭或其CAPTCHA已刷新,原始结果不得重新分配给反馈表单。
CapSolver将solve_on_page文档化为页面级管道,返回包含信息、解决方案、填充状态和错误的结果。其列出的选项不包括小部件选择器。除非您的验证集成建立了所需的作用域,否则不要将该方法描述为表单作用域操作。手动solve(info)阶段返回解决方案;结果交付本身并不能证明正确表单已被填写。
在拥有应用中,通过已拥有小部件的组件集成路由答案。将该应用特定步骤与提供者检测分开。全局的“最新令牌”变量会使解释结果属于哪个表单变得困难,并可能掩盖跨表单错误。
此阶段的输出是处置结果:传递给目标当前组件、不再需要,或因关联更改而被拒绝。在提交前记录发生了哪种处置。求解错误应保持无关的反馈小部件不变。
最终阶段验证支持请求本身,并记录足够的上下文以区分求解、路由和应用失败。
Google的服务器端响应验证指南要求验证响应令牌,并指出令牌是一次性使用且两分钟后过期。这些规则不应与求解器的单独结果检索窗口混淆。拥有应用必须执行其提供者特定的后端验证。
然后,QA测试工具应检查应用的实际完成信号。对于支持门户,这可能是由拥有后端返回的测试请求引用。绿色小部件或填写的响应字段本身不能证明正确支持请求已被接受。
存储一个紧凑的结果,包含测试用例引用、表单引用、小部件生成、求解处置、后端验证处置和目标操作结果。这些是建议的应用字段。避免在常规日志中存储原始解决方案令牌、真实支持消息内容或凭证。
当测试失败时,保留最后一次成功的阶段。“小部件映射缺失”、“求解器返回错误”和“应用拒绝提交”需要不同的修复。此阶段历史比单一的CAPTCHA错误更有助于调查。
一个有用测试矩阵在保持目标表单操作不变的同时,改变小部件顺序和生命周期。
| 拥有页面的测试用例 | 预期的工作流行为 |
|---|---|
| 反馈小部件出现在支持小部件之前 | 代理仍选择支持表单的小部件 |
| 两个表单共享一个站点密钥 | 表单关联决定选择 |
| 在求解过程中支持对话框关闭 | 结果记录为不再需要 |
| 在求解过程中支持小部件刷新 | 旧结果不会分配给替换的小部件 |
| 无关小部件报告错误 | 代理不会切换其目标操作 |
| 目标表单没有唯一的的小部件映射 | 工作流在求解请求前停止 |
| 后端拒绝提交的响应 | 测试报告验证失败,而非成功 |
首先用受控的固定装置运行矩阵,然后在允许的情况下单独测试支持的真实集成。固定装置测试建立本地路由行为;它们不证明外部求解器或提供者验证服务有效。
这个问题不同于同时启动多个独立求解任务。处理多个reCAPTCHA挑战的现有指南涵盖了并发任务处理。在有多个小部件的页面上,更困难的要求是保留一个目标操作与其特定小部件之间的关系。
按此顺序组装工作流:选择表单,保留其小部件关联,选择支持的求解信息,路由结果,并验证应用结果。在这些所有权检查清晰且可测试后,在求解阶段添加CapSolver。
Q: 检测到reCAPTCHA是否告诉代理应提交哪个表单?
检测不会确定目标表单。代理在请求解决方案或提交任何内容之前,需要应用的任务范围和明确的表单到小部件关联。
Q: 同一页面上的两个小部件可以共享站点密钥吗?
页面可以在小部件之间重用集成配置,因此站点密钥不应被视为唯一表单尝试标识符。应同时使用小部件实例和拥有表单映射。
Q: 可以选择第一个CAPTCHA信息记录吗?
仅在拥有页面映射验证它是目标小部件时才选择第一个记录。列表中的位置不能确定所有权,页面更改可能改变哪个组件显示在首位。
Q: AI代理是否应解决它发现的每个CAPTCHA?
代理应仅解决其允许操作所需的受支持挑战。即使它们在同一页上可见,无关的小部件仍不在该任务范围内。
Q: 在求解过程中页面发生变化时应如何处理?
工作流应在使用结果前重新检查页面和小部件关联。如果原始组件被替换或尝试结束,请将结果记录为未使用,并停止该尝试,而不是将其路由到其他地方。