1. 项目概述当代码智能体遇上“电话验证墙”最近在折腾Claude这类AI代码智能体时我发现一个挺有意思的现象很多开发者包括我自己在内都遇到过智能体在执行自动化任务时卡在“电话验证”这一步。你给它一个任务比如“帮我注册一个GitHub账号”或者“自动登录这个电商平台抓取价格”它前面的步骤都执行得行云流水生成代码、模拟点击、填写表单一气呵成。但一到需要接收短信验证码或者点击“获取验证码”按钮的环节整个流程就瞬间“僵住”了智能体要么陷入循环等待要么直接报错退出留下一句“无法完成需要人工交互的步骤”。这其实不是Claude或者某个特定智能体的“Bug”而是一个在自动化与安全机制交叉地带的经典困境。我把它称为“代码智能体的电话验证墙”。本质上这是无头浏览器自动化与基于人机验证和真实身份绑定的安全流程之间的一场博弈。对于开发者而言理解这堵“墙”为什么存在以及如何巧妙地“绕过去”或“翻过去”是让AI智能体真正发挥全流程自动化威力的关键。今天我就结合自己踩过的坑和摸索出的解决方案来详细拆解这个问题。简单来说一个典型的代码智能体比如使用Playwright或Selenium的脚本在遇到电话验证时其困境是结构性的环境隔离智能体通常在干净的、虚拟化的或容器化的环境中运行缺乏一个持久化的、可接收短信的真实手机号。动态性对抗现代验证码如reCAPTCHA, hCaptcha和短信验证码下发逻辑本身就包含了对抗自动化的机制如行为分析、IP信誉检测、请求频率限制。流程中断自动化脚本是线性的它期待一个确定的输入如表单字段并产生一个确定的输出。而短信验证码是一个需要从外部世界你的手机异步获取的信息这打断了脚本的线性执行流。所以这个项目要解决的就是如何赋予我们的代码智能体一个“虚拟手机”和“绕过验证”的能力让它能像真人一样完成需要电话验证的流程。下面我们就从设计思路开始一步步拆解。2. 核心思路与架构设计构建智能体的“外部感官”要让Claude这类代码智能体突破电话验证核心思路不是让它在“墙内”硬闯而是为它构建一套“外部感官”和“协作系统”。我们不能指望AI凭空变出一个手机号并收到短信但我们可以搭建一个中间层由这个中间层来负责处理所有需要“真实世界交互”的部分。2.1 总体架构解耦与中继我设计的解决方案架构主要分为三个部分如下图所示概念图1. 智能体执行核心这是Claude生成的代码或你编写的自动化脚本本身负责主要的业务流程如导航、填表、点击。当遇到需要输入验证码的输入框时它应暂停等待而不是尝试去“获取”验证码。2. 验证码服务中继层这是最关键的一层。它包含两个核心服务虚拟号码服务接口集成如Twilio、TextVerified、SMSPool等提供临时/虚拟手机号码的API服务。智能体在执行注册前先通过此接口获取一个可用的手机号。短信接收与解析服务这是一个常驻的后台服务可以是一个微服务或一个脚本它持续监听轮询或通过Webhook上一步获取的虚拟号码的收件箱。一旦收到短信就从中提取出验证码通常是通过正则表达式匹配6位数字。3. 通信桥梁连接智能体核心和中继层。当智能体需要验证码时它通过这个桥梁去查询。实现方式有多种共享存储如Redis。中继层将收到的验证码以手机号为Key存入Redis智能体在需要时用同样的Key去读取。这是最简单高效的方式。HTTP API中继层暴露一个简单的REST API智能体发送请求携带任务ID或手机号来获取验证码。消息队列如RabbitMQ或Kafka。中继层将验证码作为消息发布到指定队列智能体订阅该队列消费消息。这个架构的核心思想是解耦将“自动化业务流程”与“对抗性安全交互”分离。智能体只做它擅长的事基于规则的浏览器操作而将不擅长的事与动态安全机制交互交给专门的服务去处理。2.2 技术栈选型考量为什么选择这样的技术栈这里有一些背后的考量Playwright vs Selenium对于现代Web应用的自动化我更倾向于Playwright。它由微软开发对动态网页尤其是大量使用JavaScript框架如React, Vue.js的页面的支持更好自动等待机制更智能能有效减少因元素未加载完成导致的失败。而电话验证页面往往就是这种动态页面的典型。Redis作为共享存储因为它速度快、支持键值过期非常适合存储短期有效的验证码。我们可以给存储的验证码设置一个TTL例如300秒超时自动清除避免数据堆积。虚拟号码服务的选择Twilio提供高质量的虚拟号码但号码是固定的长期使用可能被目标网站标记且成本较高。适合对稳定性要求高、预算充足的商业项目。TextVerified/SMSPool等提供一次性的临时号码价格低廉号码池大可以有效规避风控。但号码质量参差不齐有些可能已被滥用。适合需要大量注册、对成本敏感的场景。自建网关极端情况下可以考虑使用旧手机和Android自动化工具如Tasker搭建但复杂度高不推荐初学者。注意使用虚拟号码服务必须严格遵守其服务条款和目标网站的用户协议。用于测试、学习或个人合法用途的自动化是合理的但用于恶意注册、爬取或骚扰则是违规且非法的。3. 核心模块实现详解理论讲完了我们来看具体怎么实现。我会以“使用Playwright Python Redis TextVerified API”这个组合为例因为它在功能、成本和实现难度上取得了不错的平衡。3.1 虚拟号码获取模块首先我们需要一个模块来管理虚拟手机号。这里以TextVerified的API为例其他服务商接口类似。# sms_service.py import requests import time import logging class VirtualSMSProvider: def __init__(self, api_key, servicetextverified): self.api_key api_key self.base_url https://www.textverified.com/api/ if service textverified else self.session requests.Session() self.session.headers.update({Authorization: fBearer {api_key}}) logging.basicConfig(levellogging.INFO) self.logger logging.getLogger(__name__) def get_phone_number(self, service_name): 向服务商请求一个可用于特定服务如GitHub的虚拟号码。 :param service_name: 目标网站名称服务商据此分配号码 :return: 手机号字符串或None如果失败 # TextVerified API示例获取一个号码 # 实际端点请查阅最新API文档 try: payload {service: service_name} response self.session.post(f{self.base_url}number/request, jsonpayload, timeout30) response.raise_for_status() data response.json() phone_number data.get(phoneNumber) self.logger.info(f成功获取虚拟号码: {phone_number} for {service_name}) return phone_number except requests.exceptions.RequestException as e: self.logger.error(f获取虚拟号码失败: {e}) return None def get_verification_code(self, phone_number, max_wait120, interval5): 轮询获取指定虚拟号码的短信验证码。 :param phone_number: 虚拟手机号 :param max_wait: 最大等待时间秒 :param interval: 轮询间隔秒 :return: 验证码字符串或None如果超时 start_time time.time() while time.time() - start_time max_wait: try: # 假设API有一个端点通过号码查询短信 params {phoneNumber: phone_number} response self.session.get(f{self.base_url}sms, paramsparams, timeout10) if response.status_code 200: messages response.json() for msg in messages: # 使用正则表达式提取6位数字验证码 import re code_match re.search(r\b\d{6}\b, msg.get(text, )) if code_match: code code_match.group() self.logger.info(f成功获取验证码: {code} from {phone_number}) return code time.sleep(interval) except requests.exceptions.RequestException as e: self.logger.warning(f轮询短信时出错: {e}) time.sleep(interval) self.logger.warning(f在{max_wait}秒内未收到{phone_number}的验证码) return None关键点解析错误处理网络请求必须包含完善的异常捕获try...except和状态码检查response.raise_for_status()。虚拟号码服务API可能不稳定。轮询策略get_verification_code函数采用了简单的轮询。在实际生产中如果服务商支持Webhook短信到达后主动推送应优先使用Webhook效率更高资源消耗更少。正则提取短信内容格式千变万化re.search(r\b\d{6}\b, text)是一个提取6位数字码的稳健模式。对于4位或字母数字混合的验证码需要调整正则表达式。3.2 验证码中继与存储服务接下来我们实现一个简单的FastAPI服务作为中继层它调用上面的虚拟号码服务并将收到的验证码存入Redis。# relay_server.py from fastapi import FastAPI, BackgroundTasks import redis import asyncio from sms_service import VirtualSMSProvider import uuid import logging app FastAPI() redis_client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) sms_provider VirtualSMSProvider(api_keyYOUR_API_KEY) logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) app.post(/task/start) async def start_verification_task(service_name: str, background_tasks: BackgroundTasks): 启动一个验证任务。返回一个任务ID和获取到的虚拟手机号。 task_id str(uuid.uuid4()) phone_number sms_provider.get_phone_number(service_name) if not phone_number: return {error: Failed to acquire phone number} # 将任务ID和手机号关联存储并设置较长的过期时间如10分钟 redis_client.setex(ftask:{task_id}:phone, 600, phone_number) # 在后台启动一个异步任务来监听这个号码的短信 background_tasks.add_task(poll_sms_for_task, task_id, phone_number) return {task_id: task_id, phone_number: phone_number} app.get(/task/{task_id}/code) async def get_verification_code(task_id: str): 智能体通过此接口查询验证码。 code redis_client.get(ftask:{task_id}:code) if code: # 获取成功后立即删除防止重复使用 redis_client.delete(ftask:{task_id}:code) return {code: code} return {code: None} async def poll_sms_for_task(task_id: str, phone_number: str): 后台任务为指定任务轮询短信验证码。 max_wait 120 interval 3 code sms_provider.get_verification_code(phone_number, max_wait, interval) if code: # 将验证码存入Redis并设置较短过期时间如60秒因为验证码通常很快失效 redis_client.setex(ftask:{task_id}:code, 60, code) logger.info(fTask {task_id}: Code {code} stored in Redis.) else: logger.warning(fTask {task_id}: Failed to receive code.)设计要点异步后台任务使用FastAPI的BackgroundTasks来执行耗时的短信轮询避免阻塞主API响应。这样/task/start接口可以快速返回任务ID和手机号。任务状态管理通过Redis存储任务状态手机号、验证码并使用setex设置自动过期实现了简单的状态管理和资源清理。接口设计提供了两个清晰的接口。智能体先调用/task/start获取手机号然后在需要填验证码时循环调用/task/{task_id}/code直到拿到验证码或超时。3.3 智能体端集成Playwright脚本改造最后也是最重要的一步改造你的Claude生成的或手写的Playwright脚本使其能够与我们的中继服务协同工作。# automated_registration.py import asyncio from playwright.async_api import async_playwright import requests import logging RELAY_SERVER_URL http://localhost:8000 # 你的中继服务地址 SERVICE_NAME TargetWebsite # 你要注册的网站 async def register_with_phone_verification(): # 1. 启动验证任务获取虚拟手机号 task_resp requests.post(f{RELAY_SERVER_URL}/task/start, json{service_name: SERVICE_NAME}) if task_resp.status_code ! 200: logging.error(无法启动验证任务) return task_data task_resp.json() task_id task_data[task_id] virtual_phone task_data[phone_number] logging.info(f任务ID: {task_id}, 虚拟手机号: {virtual_phone}) # 2. 启动Playwright浏览器 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 调试时可设为False context await browser.new_context() page await context.new_page() try: # 3. 导航到目标网站注册页 await page.goto(https://target-website.com/signup) # 4. 填写常规表单邮箱、密码等 await page.fill(input[nameemail], your_emailexample.com) await page.fill(input[namepassword], YourSecurePassword123!) # 5. 在电话输入框填入获取的虚拟手机号 phone_input page.locator(input[typetel]).or_(page.locator(input[namephone])).first await phone_input.fill(virtual_phone) # 6. 点击“发送验证码”按钮 send_button page.locator(button:has-text(发送验证码)).or_(page.locator(button:has-text(Get Code))).first await send_button.click() # 7. 等待并轮询中继服务获取验证码 verification_code None max_attempts 30 # 尝试30次每次间隔2秒总等待1分钟 for attempt in range(max_attempts): await asyncio.sleep(2) code_resp requests.get(f{RELAY_SERVER_URL}/task/{task_id}/code) if code_resp.status_code 200: code_data code_resp.json() if code_data[code]: verification_code code_data[code] logging.info(f第{attempt1}次尝试获取到验证码: {verification_code}) break else: logging.info(f第{attempt1}次尝试验证码尚未到达...) if not verification_code: logging.error(等待验证码超时注册失败。) await browser.close() return # 8. 在网页验证码输入框中填入获取的验证码 code_input page.locator(input[placeholder*验证码]).or_(page.locator(input[namesmsCode])).first await code_input.fill(verification_code) # 9. 提交表单或点击验证按钮 submit_button page.locator(button[typesubmit]).or_(page.locator(button:has-text(验证))).first await submit_button.click() # 10. 等待注册成功提示 await page.wait_for_selector(text注册成功, timeout10000) logging.info(注册流程成功完成) except Exception as e: logging.error(f自动化流程执行出错: {e}) # 可以在这里截图保存错误现场 await page.screenshot(pathferror_{task_id}.png) finally: await browser.close() if __name__ __main__: asyncio.run(register_with_phone_verification())脚本改造的核心逻辑流程中断与恢复脚本在点击“发送验证码”后流程被“中断”。此时脚本不再继续执行网页操作而是进入一个轮询等待状态不断向中继服务询问验证码是否到达。健壮的选择器使用page.locator(‘...’).or_(page.locator(‘...’)).first这种模式来定位元素提高了脚本对不同网站结构的适应性。因为不同网站的输入框名称、占位符差异很大。超时与重试机制获取验证码的轮询有明确的次数和间隔限制避免脚本无限期挂起。错误处理与日志完整的try...except块和详细的日志记录对于调试复杂的自动化流程至关重要。4. 高级策略与疑难杂症排查即使搭建了上述架构在实际运行中你仍会遇到各种问题。下面是我总结的一些高级策略和常见问题的排查清单。4.1 对抗高级反自动化机制很多网站的电话验证不仅仅是发个短信那么简单背后有复杂的风控。IP信誉与频率限制问题从数据中心IP云服务器发起的大量注册请求或短时间内用多个虚拟号请求验证码极易触发风控导致号码被屏蔽或要求进行更复杂验证如滑块验证码。对策使用住宅代理让请求的IP地址看起来像普通家庭宽带。有专门的代理服务商提供高质量的住宅代理IP。控制节奏在脚本中随机插入等待时间await page.wait_for_timeout(random.randint(1000, 5000))模拟真人操作的不确定性。分散请求如果有多台机器或任务使用不同的代理IP池。浏览器指纹检测问题网站通过检测浏览器指纹如WebGL, Canvas, 字体列表, User-Agent等来判断是否为自动化工具。对策Playwright和Puppeteer提供了较原生CDPChrome DevTools Protocol的浏览器上下文指纹相对容易被检测。可以考虑使用playwright-stealth等插件这类插件尝试修改浏览器上下文的属性使其指纹更接近真实浏览器。更换自动化工具对于指纹检测极其严格的网站可能需要使用基于真实浏览器内核的自动化方案但复杂度更高。验证码前置问题在点击“发送验证码”按钮前就弹出图形验证码如点选、滑块。对策这是最棘手的情况。解决方案分层次尝试绕过有些验证码在headlessFalse非无头模式下不会弹出或者使用特定的User-Agent可以绕过。人工打码对于低频任务可以设置当检测到验证码元素出现时暂停脚本并提示人工处理。Playwright可以监听对话框或特定元素出现。接入打码平台对于高频需求必须集成第三方打码平台如2Captcha, Anti-Captcha的API。这需要在脚本中捕获验证码图片发送给平台等待返回结果并填入。这是一整套新的集成工作。4.2 常见问题排查速查表问题现象可能原因排查步骤与解决方案获取不到虚拟号码1. API密钥错误或余额不足。2. 请求的服务如‘GitHub’没有可用号码。3. 网络问题或服务商API故障。1. 检查API密钥登录服务商后台查看余额和可用服务。2. 尝试更换其他服务名称或等待号码池补充。3. 使用curl或Postman直接测试API端点。收不到短信验证码1. 虚拟号码已被目标网站拉黑。2. 短信有延迟常见。3. 服务商的短信接收功能故障。4. 目标网站发送短信失败。1. 更换另一个虚拟号码服务商或号码。2. 增加轮询等待时间max_wait和间隔。3. 在服务商后台查看该号码的收件箱是否正常。4. 手动用该号码在网站尝试看是否能收到。验证码错误/过期1. 从短信中提取验证码的正则表达式不匹配。2. 验证码已过期通常只有60-300秒有效期。3. 脚本填入验证码太慢。1. 打印出收到的原始短信内容调整正则表达式。2. 确保中继服务一收到码就立刻存储脚本尽快获取并填入。3. 优化脚本减少填入验证码前的操作延迟。点击发送按钮无效1. 元素选择器不正确没点到真正的按钮。2. 按钮被动态加载需要等待。3. 触发了前端验证如手机号格式错误。1. 使用Playwright的page.pause()或录制工具重新定位元素。2. 在点击前增加等待await button.wait_for(state‘visible’)。3. 确保填入的手机号格式符合要求如国家代码。流程被要求进行图形验证1. IP信誉太低。2. 行为模式被判定为机器人。1. 首要方案切换为高质量的住宅代理IP。2. 增加操作间的随机延迟模拟人类操作。3. 考虑集成打码平台作为最后手段。4.3 稳定性与可维护性优化要让这套系统长期稳定运行还需要一些工程化考量配置外部化将API密钥、代理服务器地址、目标网站URL、选择器等所有可变参数放入配置文件如config.yaml或环境变量中不要硬编码在脚本里。状态持久化与监控将任务状态手机号、验证码、成功/失败不仅存入Redis还可以写入数据库如SQLite或PostgreSQL便于后期分析成功率、号码质量、失败原因。实现任务队列对于大规模自动化使用Celery Redis/RabbitMQ来管理任务队列实现任务的分布式调度、重试和优先级管理。容器化部署将中继服务FastAPI Redis和智能体脚本分别打包成Docker镜像使用Docker Compose编排可以轻松地在任何服务器上部署和扩展。5. 伦理、合规与最佳实践在结束之前我必须强调最重要的一点能力越大责任越大。遵守规则绝对不要将这套技术用于恶意爬虫、垃圾注册、刷单、欺诈或任何违反目标网站服务条款和法律法规的活动。这不仅是道德问题也可能让你面临法律风险。尊重资源虚拟号码和代理IP都是稀缺资源。合理控制请求频率避免对服务商和目标网站造成不必要的负担。用于正当场景这套技术的正当用途包括但不限于自动化测试为你的Web应用编写包含完整注册流程的端到端E2E测试。数据迁移在合规前提下为批量创建测试账号提供便利。个人学习与研究理解现代Web安全机制与自动化技术的对抗。有限的、合规的自动化任务如为自己管理的多个社交媒体账号进行自动化维护需确保不违反平台规则。我个人的体会是解决“电话验证墙”的过程远比写一个简单的爬虫脚本要复杂。它迫使你去思考整个系统的架构理解网络安全的攻防逻辑并精心设计各个模块之间的协作。当你看到智能体终于能独立完成一个需要短信验证的完整流程时那种成就感是巨大的。这不仅仅是让一段代码跑通了更是你构建了一个小型但功能完备的自动化生态系统。最后一个小技巧在开发调试阶段可以先用一个你自己能控制的、真实的手机号来测试整个流程包括短信接收确保核心逻辑无误后再切换到虚拟号码服务。这样可以排除很多干扰因素快速定位问题是在你的代码逻辑还是在外部服务集成上。
突破AI代码智能体自动化瓶颈：构建虚拟手机号与验证码中继系统
发布时间：2026/5/27 9:04:35
1. 项目概述当代码智能体遇上“电话验证墙”最近在折腾Claude这类AI代码智能体时我发现一个挺有意思的现象很多开发者包括我自己在内都遇到过智能体在执行自动化任务时卡在“电话验证”这一步。你给它一个任务比如“帮我注册一个GitHub账号”或者“自动登录这个电商平台抓取价格”它前面的步骤都执行得行云流水生成代码、模拟点击、填写表单一气呵成。但一到需要接收短信验证码或者点击“获取验证码”按钮的环节整个流程就瞬间“僵住”了智能体要么陷入循环等待要么直接报错退出留下一句“无法完成需要人工交互的步骤”。这其实不是Claude或者某个特定智能体的“Bug”而是一个在自动化与安全机制交叉地带的经典困境。我把它称为“代码智能体的电话验证墙”。本质上这是无头浏览器自动化与基于人机验证和真实身份绑定的安全流程之间的一场博弈。对于开发者而言理解这堵“墙”为什么存在以及如何巧妙地“绕过去”或“翻过去”是让AI智能体真正发挥全流程自动化威力的关键。今天我就结合自己踩过的坑和摸索出的解决方案来详细拆解这个问题。简单来说一个典型的代码智能体比如使用Playwright或Selenium的脚本在遇到电话验证时其困境是结构性的环境隔离智能体通常在干净的、虚拟化的或容器化的环境中运行缺乏一个持久化的、可接收短信的真实手机号。动态性对抗现代验证码如reCAPTCHA, hCaptcha和短信验证码下发逻辑本身就包含了对抗自动化的机制如行为分析、IP信誉检测、请求频率限制。流程中断自动化脚本是线性的它期待一个确定的输入如表单字段并产生一个确定的输出。而短信验证码是一个需要从外部世界你的手机异步获取的信息这打断了脚本的线性执行流。所以这个项目要解决的就是如何赋予我们的代码智能体一个“虚拟手机”和“绕过验证”的能力让它能像真人一样完成需要电话验证的流程。下面我们就从设计思路开始一步步拆解。2. 核心思路与架构设计构建智能体的“外部感官”要让Claude这类代码智能体突破电话验证核心思路不是让它在“墙内”硬闯而是为它构建一套“外部感官”和“协作系统”。我们不能指望AI凭空变出一个手机号并收到短信但我们可以搭建一个中间层由这个中间层来负责处理所有需要“真实世界交互”的部分。2.1 总体架构解耦与中继我设计的解决方案架构主要分为三个部分如下图所示概念图1. 智能体执行核心这是Claude生成的代码或你编写的自动化脚本本身负责主要的业务流程如导航、填表、点击。当遇到需要输入验证码的输入框时它应暂停等待而不是尝试去“获取”验证码。2. 验证码服务中继层这是最关键的一层。它包含两个核心服务虚拟号码服务接口集成如Twilio、TextVerified、SMSPool等提供临时/虚拟手机号码的API服务。智能体在执行注册前先通过此接口获取一个可用的手机号。短信接收与解析服务这是一个常驻的后台服务可以是一个微服务或一个脚本它持续监听轮询或通过Webhook上一步获取的虚拟号码的收件箱。一旦收到短信就从中提取出验证码通常是通过正则表达式匹配6位数字。3. 通信桥梁连接智能体核心和中继层。当智能体需要验证码时它通过这个桥梁去查询。实现方式有多种共享存储如Redis。中继层将收到的验证码以手机号为Key存入Redis智能体在需要时用同样的Key去读取。这是最简单高效的方式。HTTP API中继层暴露一个简单的REST API智能体发送请求携带任务ID或手机号来获取验证码。消息队列如RabbitMQ或Kafka。中继层将验证码作为消息发布到指定队列智能体订阅该队列消费消息。这个架构的核心思想是解耦将“自动化业务流程”与“对抗性安全交互”分离。智能体只做它擅长的事基于规则的浏览器操作而将不擅长的事与动态安全机制交互交给专门的服务去处理。2.2 技术栈选型考量为什么选择这样的技术栈这里有一些背后的考量Playwright vs Selenium对于现代Web应用的自动化我更倾向于Playwright。它由微软开发对动态网页尤其是大量使用JavaScript框架如React, Vue.js的页面的支持更好自动等待机制更智能能有效减少因元素未加载完成导致的失败。而电话验证页面往往就是这种动态页面的典型。Redis作为共享存储因为它速度快、支持键值过期非常适合存储短期有效的验证码。我们可以给存储的验证码设置一个TTL例如300秒超时自动清除避免数据堆积。虚拟号码服务的选择Twilio提供高质量的虚拟号码但号码是固定的长期使用可能被目标网站标记且成本较高。适合对稳定性要求高、预算充足的商业项目。TextVerified/SMSPool等提供一次性的临时号码价格低廉号码池大可以有效规避风控。但号码质量参差不齐有些可能已被滥用。适合需要大量注册、对成本敏感的场景。自建网关极端情况下可以考虑使用旧手机和Android自动化工具如Tasker搭建但复杂度高不推荐初学者。注意使用虚拟号码服务必须严格遵守其服务条款和目标网站的用户协议。用于测试、学习或个人合法用途的自动化是合理的但用于恶意注册、爬取或骚扰则是违规且非法的。3. 核心模块实现详解理论讲完了我们来看具体怎么实现。我会以“使用Playwright Python Redis TextVerified API”这个组合为例因为它在功能、成本和实现难度上取得了不错的平衡。3.1 虚拟号码获取模块首先我们需要一个模块来管理虚拟手机号。这里以TextVerified的API为例其他服务商接口类似。# sms_service.py import requests import time import logging class VirtualSMSProvider: def __init__(self, api_key, servicetextverified): self.api_key api_key self.base_url https://www.textverified.com/api/ if service textverified else self.session requests.Session() self.session.headers.update({Authorization: fBearer {api_key}}) logging.basicConfig(levellogging.INFO) self.logger logging.getLogger(__name__) def get_phone_number(self, service_name): 向服务商请求一个可用于特定服务如GitHub的虚拟号码。 :param service_name: 目标网站名称服务商据此分配号码 :return: 手机号字符串或None如果失败 # TextVerified API示例获取一个号码 # 实际端点请查阅最新API文档 try: payload {service: service_name} response self.session.post(f{self.base_url}number/request, jsonpayload, timeout30) response.raise_for_status() data response.json() phone_number data.get(phoneNumber) self.logger.info(f成功获取虚拟号码: {phone_number} for {service_name}) return phone_number except requests.exceptions.RequestException as e: self.logger.error(f获取虚拟号码失败: {e}) return None def get_verification_code(self, phone_number, max_wait120, interval5): 轮询获取指定虚拟号码的短信验证码。 :param phone_number: 虚拟手机号 :param max_wait: 最大等待时间秒 :param interval: 轮询间隔秒 :return: 验证码字符串或None如果超时 start_time time.time() while time.time() - start_time max_wait: try: # 假设API有一个端点通过号码查询短信 params {phoneNumber: phone_number} response self.session.get(f{self.base_url}sms, paramsparams, timeout10) if response.status_code 200: messages response.json() for msg in messages: # 使用正则表达式提取6位数字验证码 import re code_match re.search(r\b\d{6}\b, msg.get(text, )) if code_match: code code_match.group() self.logger.info(f成功获取验证码: {code} from {phone_number}) return code time.sleep(interval) except requests.exceptions.RequestException as e: self.logger.warning(f轮询短信时出错: {e}) time.sleep(interval) self.logger.warning(f在{max_wait}秒内未收到{phone_number}的验证码) return None关键点解析错误处理网络请求必须包含完善的异常捕获try...except和状态码检查response.raise_for_status()。虚拟号码服务API可能不稳定。轮询策略get_verification_code函数采用了简单的轮询。在实际生产中如果服务商支持Webhook短信到达后主动推送应优先使用Webhook效率更高资源消耗更少。正则提取短信内容格式千变万化re.search(r\b\d{6}\b, text)是一个提取6位数字码的稳健模式。对于4位或字母数字混合的验证码需要调整正则表达式。3.2 验证码中继与存储服务接下来我们实现一个简单的FastAPI服务作为中继层它调用上面的虚拟号码服务并将收到的验证码存入Redis。# relay_server.py from fastapi import FastAPI, BackgroundTasks import redis import asyncio from sms_service import VirtualSMSProvider import uuid import logging app FastAPI() redis_client redis.Redis(hostlocalhost, port6379, db0, decode_responsesTrue) sms_provider VirtualSMSProvider(api_keyYOUR_API_KEY) logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) app.post(/task/start) async def start_verification_task(service_name: str, background_tasks: BackgroundTasks): 启动一个验证任务。返回一个任务ID和获取到的虚拟手机号。 task_id str(uuid.uuid4()) phone_number sms_provider.get_phone_number(service_name) if not phone_number: return {error: Failed to acquire phone number} # 将任务ID和手机号关联存储并设置较长的过期时间如10分钟 redis_client.setex(ftask:{task_id}:phone, 600, phone_number) # 在后台启动一个异步任务来监听这个号码的短信 background_tasks.add_task(poll_sms_for_task, task_id, phone_number) return {task_id: task_id, phone_number: phone_number} app.get(/task/{task_id}/code) async def get_verification_code(task_id: str): 智能体通过此接口查询验证码。 code redis_client.get(ftask:{task_id}:code) if code: # 获取成功后立即删除防止重复使用 redis_client.delete(ftask:{task_id}:code) return {code: code} return {code: None} async def poll_sms_for_task(task_id: str, phone_number: str): 后台任务为指定任务轮询短信验证码。 max_wait 120 interval 3 code sms_provider.get_verification_code(phone_number, max_wait, interval) if code: # 将验证码存入Redis并设置较短过期时间如60秒因为验证码通常很快失效 redis_client.setex(ftask:{task_id}:code, 60, code) logger.info(fTask {task_id}: Code {code} stored in Redis.) else: logger.warning(fTask {task_id}: Failed to receive code.)设计要点异步后台任务使用FastAPI的BackgroundTasks来执行耗时的短信轮询避免阻塞主API响应。这样/task/start接口可以快速返回任务ID和手机号。任务状态管理通过Redis存储任务状态手机号、验证码并使用setex设置自动过期实现了简单的状态管理和资源清理。接口设计提供了两个清晰的接口。智能体先调用/task/start获取手机号然后在需要填验证码时循环调用/task/{task_id}/code直到拿到验证码或超时。3.3 智能体端集成Playwright脚本改造最后也是最重要的一步改造你的Claude生成的或手写的Playwright脚本使其能够与我们的中继服务协同工作。# automated_registration.py import asyncio from playwright.async_api import async_playwright import requests import logging RELAY_SERVER_URL http://localhost:8000 # 你的中继服务地址 SERVICE_NAME TargetWebsite # 你要注册的网站 async def register_with_phone_verification(): # 1. 启动验证任务获取虚拟手机号 task_resp requests.post(f{RELAY_SERVER_URL}/task/start, json{service_name: SERVICE_NAME}) if task_resp.status_code ! 200: logging.error(无法启动验证任务) return task_data task_resp.json() task_id task_data[task_id] virtual_phone task_data[phone_number] logging.info(f任务ID: {task_id}, 虚拟手机号: {virtual_phone}) # 2. 启动Playwright浏览器 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 调试时可设为False context await browser.new_context() page await context.new_page() try: # 3. 导航到目标网站注册页 await page.goto(https://target-website.com/signup) # 4. 填写常规表单邮箱、密码等 await page.fill(input[nameemail], your_emailexample.com) await page.fill(input[namepassword], YourSecurePassword123!) # 5. 在电话输入框填入获取的虚拟手机号 phone_input page.locator(input[typetel]).or_(page.locator(input[namephone])).first await phone_input.fill(virtual_phone) # 6. 点击“发送验证码”按钮 send_button page.locator(button:has-text(发送验证码)).or_(page.locator(button:has-text(Get Code))).first await send_button.click() # 7. 等待并轮询中继服务获取验证码 verification_code None max_attempts 30 # 尝试30次每次间隔2秒总等待1分钟 for attempt in range(max_attempts): await asyncio.sleep(2) code_resp requests.get(f{RELAY_SERVER_URL}/task/{task_id}/code) if code_resp.status_code 200: code_data code_resp.json() if code_data[code]: verification_code code_data[code] logging.info(f第{attempt1}次尝试获取到验证码: {verification_code}) break else: logging.info(f第{attempt1}次尝试验证码尚未到达...) if not verification_code: logging.error(等待验证码超时注册失败。) await browser.close() return # 8. 在网页验证码输入框中填入获取的验证码 code_input page.locator(input[placeholder*验证码]).or_(page.locator(input[namesmsCode])).first await code_input.fill(verification_code) # 9. 提交表单或点击验证按钮 submit_button page.locator(button[typesubmit]).or_(page.locator(button:has-text(验证))).first await submit_button.click() # 10. 等待注册成功提示 await page.wait_for_selector(text注册成功, timeout10000) logging.info(注册流程成功完成) except Exception as e: logging.error(f自动化流程执行出错: {e}) # 可以在这里截图保存错误现场 await page.screenshot(pathferror_{task_id}.png) finally: await browser.close() if __name__ __main__: asyncio.run(register_with_phone_verification())脚本改造的核心逻辑流程中断与恢复脚本在点击“发送验证码”后流程被“中断”。此时脚本不再继续执行网页操作而是进入一个轮询等待状态不断向中继服务询问验证码是否到达。健壮的选择器使用page.locator(‘...’).or_(page.locator(‘...’)).first这种模式来定位元素提高了脚本对不同网站结构的适应性。因为不同网站的输入框名称、占位符差异很大。超时与重试机制获取验证码的轮询有明确的次数和间隔限制避免脚本无限期挂起。错误处理与日志完整的try...except块和详细的日志记录对于调试复杂的自动化流程至关重要。4. 高级策略与疑难杂症排查即使搭建了上述架构在实际运行中你仍会遇到各种问题。下面是我总结的一些高级策略和常见问题的排查清单。4.1 对抗高级反自动化机制很多网站的电话验证不仅仅是发个短信那么简单背后有复杂的风控。IP信誉与频率限制问题从数据中心IP云服务器发起的大量注册请求或短时间内用多个虚拟号请求验证码极易触发风控导致号码被屏蔽或要求进行更复杂验证如滑块验证码。对策使用住宅代理让请求的IP地址看起来像普通家庭宽带。有专门的代理服务商提供高质量的住宅代理IP。控制节奏在脚本中随机插入等待时间await page.wait_for_timeout(random.randint(1000, 5000))模拟真人操作的不确定性。分散请求如果有多台机器或任务使用不同的代理IP池。浏览器指纹检测问题网站通过检测浏览器指纹如WebGL, Canvas, 字体列表, User-Agent等来判断是否为自动化工具。对策Playwright和Puppeteer提供了较原生CDPChrome DevTools Protocol的浏览器上下文指纹相对容易被检测。可以考虑使用playwright-stealth等插件这类插件尝试修改浏览器上下文的属性使其指纹更接近真实浏览器。更换自动化工具对于指纹检测极其严格的网站可能需要使用基于真实浏览器内核的自动化方案但复杂度更高。验证码前置问题在点击“发送验证码”按钮前就弹出图形验证码如点选、滑块。对策这是最棘手的情况。解决方案分层次尝试绕过有些验证码在headlessFalse非无头模式下不会弹出或者使用特定的User-Agent可以绕过。人工打码对于低频任务可以设置当检测到验证码元素出现时暂停脚本并提示人工处理。Playwright可以监听对话框或特定元素出现。接入打码平台对于高频需求必须集成第三方打码平台如2Captcha, Anti-Captcha的API。这需要在脚本中捕获验证码图片发送给平台等待返回结果并填入。这是一整套新的集成工作。4.2 常见问题排查速查表问题现象可能原因排查步骤与解决方案获取不到虚拟号码1. API密钥错误或余额不足。2. 请求的服务如‘GitHub’没有可用号码。3. 网络问题或服务商API故障。1. 检查API密钥登录服务商后台查看余额和可用服务。2. 尝试更换其他服务名称或等待号码池补充。3. 使用curl或Postman直接测试API端点。收不到短信验证码1. 虚拟号码已被目标网站拉黑。2. 短信有延迟常见。3. 服务商的短信接收功能故障。4. 目标网站发送短信失败。1. 更换另一个虚拟号码服务商或号码。2. 增加轮询等待时间max_wait和间隔。3. 在服务商后台查看该号码的收件箱是否正常。4. 手动用该号码在网站尝试看是否能收到。验证码错误/过期1. 从短信中提取验证码的正则表达式不匹配。2. 验证码已过期通常只有60-300秒有效期。3. 脚本填入验证码太慢。1. 打印出收到的原始短信内容调整正则表达式。2. 确保中继服务一收到码就立刻存储脚本尽快获取并填入。3. 优化脚本减少填入验证码前的操作延迟。点击发送按钮无效1. 元素选择器不正确没点到真正的按钮。2. 按钮被动态加载需要等待。3. 触发了前端验证如手机号格式错误。1. 使用Playwright的page.pause()或录制工具重新定位元素。2. 在点击前增加等待await button.wait_for(state‘visible’)。3. 确保填入的手机号格式符合要求如国家代码。流程被要求进行图形验证1. IP信誉太低。2. 行为模式被判定为机器人。1. 首要方案切换为高质量的住宅代理IP。2. 增加操作间的随机延迟模拟人类操作。3. 考虑集成打码平台作为最后手段。4.3 稳定性与可维护性优化要让这套系统长期稳定运行还需要一些工程化考量配置外部化将API密钥、代理服务器地址、目标网站URL、选择器等所有可变参数放入配置文件如config.yaml或环境变量中不要硬编码在脚本里。状态持久化与监控将任务状态手机号、验证码、成功/失败不仅存入Redis还可以写入数据库如SQLite或PostgreSQL便于后期分析成功率、号码质量、失败原因。实现任务队列对于大规模自动化使用Celery Redis/RabbitMQ来管理任务队列实现任务的分布式调度、重试和优先级管理。容器化部署将中继服务FastAPI Redis和智能体脚本分别打包成Docker镜像使用Docker Compose编排可以轻松地在任何服务器上部署和扩展。5. 伦理、合规与最佳实践在结束之前我必须强调最重要的一点能力越大责任越大。遵守规则绝对不要将这套技术用于恶意爬虫、垃圾注册、刷单、欺诈或任何违反目标网站服务条款和法律法规的活动。这不仅是道德问题也可能让你面临法律风险。尊重资源虚拟号码和代理IP都是稀缺资源。合理控制请求频率避免对服务商和目标网站造成不必要的负担。用于正当场景这套技术的正当用途包括但不限于自动化测试为你的Web应用编写包含完整注册流程的端到端E2E测试。数据迁移在合规前提下为批量创建测试账号提供便利。个人学习与研究理解现代Web安全机制与自动化技术的对抗。有限的、合规的自动化任务如为自己管理的多个社交媒体账号进行自动化维护需确保不违反平台规则。我个人的体会是解决“电话验证墙”的过程远比写一个简单的爬虫脚本要复杂。它迫使你去思考整个系统的架构理解网络安全的攻防逻辑并精心设计各个模块之间的协作。当你看到智能体终于能独立完成一个需要短信验证的完整流程时那种成就感是巨大的。这不仅仅是让一段代码跑通了更是你构建了一个小型但功能完备的自动化生态系统。最后一个小技巧在开发调试阶段可以先用一个你自己能控制的、真实的手机号来测试整个流程包括短信接收确保核心逻辑无误后再切换到虚拟号码服务。这样可以排除很多干扰因素快速定位问题是在你的代码逻辑还是在外部服务集成上。
