aBaiAutoplus 深度拆解：当「注册机」进化成 AI 账号工厂

Mon, 01 Jun 2026 17:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

一分钟速读：aBaiAutoplus 不止是"注册机"，而是一套完整的 AI 账号自动化工厂——插件化架构支持 12 个平台，协议 + 浏览器双模式，甚至打通了 PayPal / GoPay 付款开通 ChatGPT Plus 的全链路。本文从 HTTP 指纹对抗、邮箱轮换、注册流程引擎到支付协议逆向，逐层拆解其技术内幕，并与同类工具横向对比。

引言

先问一个问题：一个账号注册工具，和"AI 账号工厂"之间差了多远？

答案是：差了付费通道和生命周期管理。

市面上注册 ChatGPT 账号的工具不少。用 Selenium 填个表单、接个验证码、输出 token —— 这是 2023 年的及格线。但到了 2026 年，当 ChatGPT Plus 的后付费链路涉及 Stripe → PayPal hCaptcha 风控 → Express Checkout → Hermes 兜底支付，或者 Stripe → Midtrans 收银台 → GoPay 14 步 API 付款，事情就完全是另一个量级的复杂度了。

aBaiAutoplus —— GitHub 上架两天 311 Star、208 Fork，基于 any-auto-register 二次开发，在插件化注册框架之上硬是接上了 GoPay 和 PayPal 两条付费管道，把注册工具做成了"账号 + Plus 订阅"的全自动生产线。

本文不是功能罗列。我们从架构、协议对抗、支付链路、生态对比四个维度切入，拆解它到底做了什么、怎么做到的、以及相比同类工具是「换皮」还是「进化」。

一、架构全景：插件化的"账号工厂"

先说结论：这是一个标准的 DDD（领域驱动设计）分层架构 + 插件注册表模式。

api/ ── FastAPI 路由层（REST + SSE 实时日志推送）
application/ ── 应用编排层（任务调度、付款流水线、多租户 API）
domain/ ── 领域模型（Account / Task / Proxy / Platform 抽象）
core/ ── 核心能力层（平台基类、注册引擎、代理池、生命周期）
platforms/ ── 平台插件层（每个平台一个独立包）
providers/ ── Provider 插件层（邮箱 / 验证码 / 接码 / 代理驱动）
frontend/ ── React + TypeScript + Vite + TailwindCSS
electron/ ── Electron 桌面端打包

1.1 插件的自发现机制

系统的灵魂在 core/registry.py。启动时用 pkgutil.iter_modules 扫描 platforms/ 下的所有 Python 包，任何带 @register 装饰器的 BasePlatform 子类都会被自动注册到全局注册表：

# 一个平台插件的典型结构
@register
class ChatGPTPlatform(BasePlatform):
 name = "chatgpt"
 display_name = "ChatGPT"
 supported_executors = ["protocol", "headless", "headed"]
 supported_identity_modes = ["mailbox"]
 supported_oauth_providers = ["google", "microsoft"]
 capabilities = ["plus_payment", "paypal_checkout"]

这意味着添加新平台不需要修改任何核心代码——你在 platforms/ 下新建一个包，实现 plugin.py，定义 build_protocol_mailbox_adapter() 和 build_browser_registration_adapter()，系统启动时它就会出现在 Web UI 里。

1.2 注册流程引擎：三种模式统一抽象

这是整个架构最精巧的部分。所有平台的注册逻辑被收敛到三个标准 Flow 类中：

Flow	适用场景	核心组件
ProtocolMailboxFlow	纯 HTTP API 注册 + 邮箱验证码	`worker_builder` → `register_runner` → `result_mapper`
BrowserRegistrationFlow	需要浏览器的注册（Turnstile / hCaptcha / OAuth）	`browser_worker_builder` → `browser_register_runner`
ProtocolOAuthFlow	OAuth 协议订阅（Google / Microsoft 登录）	`oauth_runner` → `result_mapper`

三者的共同点是都依赖 Adapter 模式：

@dataclass(slots=True)
class ProtocolMailboxAdapter:
 result_mapper: Callable # 结果映射器
 worker_builder: Callable # Worker 构造器
 register_runner: Callable # 注册执行器
 otp_spec: OtpSpec | None # 验证码抓取规格
 link_spec: LinkSpec | None # 验证链接抓取规格
 use_captcha: bool # 是否需要打码

每个平台的 plugin.py 只需「组装」一个 Adapter 并返回，Flow 引擎负责执行环境的构建（代理注入、邮箱轮换、验证码回调、超时控制、取消检查）。这种设计让"注册"这件事变成了声明式配置——开发者不需要理解并发控制、异常重试、SSE 日志推送等技术细节。

1.3 技术栈选型中的安全考量

注意几个关键组件的选择：

HTTP 客户端：curl_cffi 而非 requests 或 httpx。原因很简单——curl_cffi 能伪造 TLS 指纹（impersonate="chrome136"），让请求在 TLS 握手层面就"看起来像浏览器"。Cloudflare / Akamai 等 WAF 对 requests 库的 JA3 指纹一抓一个准。
浏览器引擎：Playwright（Chromium）+ Camoufox（反指纹）+ BitBrowser（指纹浏览器）。三套浏览器后端覆盖不同场景——Playwright 用于普通表单、Camoufox 用于需要绕过 Turnstile 的场景、BitBrowser 用于 PayPal 这种对浏览器环境极度敏感的平台。
桌面端：Electron 内嵌完整 Python 后端，不依赖用户安装 Python 环境。这种"all-in-one"打包方式是降低使用门槛的关键——用户双击 .dmg 或 .exe 就能用。

二、核心突破口：从"注册"到"付款"的最后一公里

如果说插件化架构是骨架，那付款集成就是灵魂。这是 aBaiAutoplus 与上游 any-auto-register 最本质的分野。

2.1 GoPay 付款链路：14 步 API 协议

印尼 GoPay 是 ChatGPT Plus 订阅的一条「野路子」。因为 ChatGPT 在印尼的定价（IDR）相对低廉，且 GoPay 对虚拟卡/PIN 的验证不如欧美严格，整套链路可以被协议化。

其流水线分三步（实现见 application/gopay_pay_chatgpt.py）：

步骤一【协议】：调用 generate_plus_link(country=ID, currency=IDR)
 → 拿到 Stripe Hosted Checkout 的 cashier_url

步骤二【浏览器】：打开 cashier_url → 等待页面自动跳转到 Midtrans 域
 → 捕获 midtrans_url（Snap v3/v4 重定向 URL）

步骤三【协议】：GoPayPayment.pay(midtrans_url, account)
 → 14 步 Midtrans API：生成支付token → 启动交易 → GoPay 扫码/确认 → 回调

第三步最精彩——Midtrans 的 Snap 收银台本质是一套 RESTful API 编排，每步都需要精确的 header 构造、csrf token 传递、以及 JWT 签名验证。项目在 platforms/gopay-deploy/ 中做了一套完整的 GoPay 协议 Worker，从账号登录、PIN 验证、余额查询到付款确认，全链路协议化。

同时注意到一个巧妙的工程手段——PhoneTTLGuard：

class PhoneTTLGuard:
 """Hero-SMS 号码 20 分钟自动回收的护栏"""
 def __init__(self, ttl_seconds: int = 1200):
 self.ttl_seconds = ttl_seconds
 self._start = time.monotonic()

 def check(self) -> None:
 if self.elapsed() > self.ttl_seconds:
 raise RuntimeError("号码有效期已过，任务失败")

因为接码平台的印尼号码只有 20 分钟有效期，如果你在注册 GoPay 后超过 20 分钟才去调用付款接口，号码已被回收，短信验证码就收不到了。这个护栏用 time.monotonic()（不受系统时钟回拨影响）在每一步执行前检查，超时直接判失败——干净利落的工程防御。

2.2 PayPal 付款链路：HAR 协议逆向的艺术

比 GoPay 更复杂的是 PayPal。ChatGPT Plus 的后付费链路会经过 Stripe → PayPal 的审批协议跳转，PayPal 端有：

hCaptcha passive 检测（包含约 2200 字符的签名 JWT）
Generic Risk Center 企业风控（5 次交叉验证请求）
SignUp Guest 注册流（包括手机号验证、地址填充、卡片绑定）
Hermes 兜底支付（OPT_OUT 模式，$0 trial 不产生真实扣款）

项目仓库中一份 77MB 的 HAR 文件 checkout-20260523-160436-04xg0pylps_edu.hsxhome.com.har（含 846 个请求），被逐帧反推成了协议文档 PAYPAL_PROTOCOL_FLOW.md，拆解出 6 个 Stage、20+ 个端点的完整调用链。

最值得关注的技术点：

① hCaptcha passive 的"不战而胜"

PayPal 的 /auth/validatecaptcha 端点接受 hcaptchaToken=NOT_REACHABLE 作为参数——也就是说，在某些条件下，PayPal 自己的前端 JavaScript 在检测不到 hCaptcha 时也不会拒绝请求，而是走到一个 authchallengenodeweb 模板（返回 200 + 7387 字节 HTML）。真正的 hCaptcha 校验在另一个端点 /auth/verifyhcaptchapassive 中触发，需要 hCaptcha SDK 生成的 P1_<签名JWT> token。

这个发现意味着：如果能绕过 PayPal 的 Generic Risk Center 风控评分，hCaptcha 可能根本不会被触发。这是典型的"从协议层面理解风控触发条件"的逆向思路，而不是硬着头皮去对着 hCaptcha 死磕。

② Hermes 兜底支付的 $0 trial 秘密

在前几次 addCard 时，GraphQL mutate 返回 ISSUER_DECLINE / CARD_GENERIC_ERROR 并不代表失败。PayPal 会自动在 redirect URL 追加 addFIContingency=noretry&fallback=1&reason=CARD_GENERIC_ERROR（base64 编码），把流量导进 /webapps/hermes 兜底支付。Hermes 里只需发一个 authorize mutation，带 fundingPreference={"balancePreference":"OPT_OUT"}，PayPal 就会直接返回 status=success——因为它识别到这是一笔 $0 试用的审批授权，不需要真实扣款。

OPT_OUT 是整条链路中最关键的一个参数。它告诉 PayPal：“别从任何资金渠道扣款，这是一笔授权审批。” 不掌握这个细节，你会以为 visa 虚拟卡被拒就是失败。掌握了，你就知道这条 HAR 里的所有"失败"步骤都是预期的路由分支。

2.3 代理池：成功率驱动的智能轮换

代理在 AI 账号注册中是核心竞争力。Cloudflare 对数据中心 IP 的态度越来越严苛，Turnstile 验证码的通过率与 IP 质量直接挂钩。

aBaiAutoplus 的代理池设计有三种层级：

层级	来源	特点
静态代理池	手动添加的固定代理	按成功率加权轮询，连续失败 5 次自动禁用
动态 API 提取	代理商的 HTTP API 动态提取	每次提取新 IP，适合大批量任务
旋转网关代理	BrightData / Oxylabs / IPRoyal 等	固定入口地址，每次请求自动分配不同出口 IP

三个关键设计：

自动回退：动态代理失败 → 回退到静态代理池 → 再失败才报错
成功率统计：GET /api/stats/by-proxy 可按代理查询成功率排行
平台敏感度区分：不同平台对 IP 的容忍度不同，可分别配置代理策略

三、生态完整性：从注册到交付的全链路

一个只注册不管后续的工具是半成品。aBaiAutoplus 做了完整的生命周期闭环：

3.1 账号生命周期管理器

# core/lifecycle.py
- 每 6 小时：有效性检测（check token 是否还能用）
- 每 12 小时：Token 自动续期（当前支持 ChatGPT session_token 刷新）
- Trial 过期扫描：快过期 → 预警标记，已过期 → 状态更新为 EXPIRED

这不是装饰性功能——如果你有 200 个 ChatGPT 账号，手动检查每个 token 是否过期是不现实的。生命周期管理器让账号池成为一种「可运营的资源」，而非一次性消耗品。

3.2 多维度成功率仪表盘

/api/stats/overview → 全局概览（总数、成功率、状态分布）
/api/stats/by-platform → 按平台统计成功率（看哪个平台风控严）
/api/stats/by-day → 按天注册趋势（看成功率是否在下降）
/api/stats/by-proxy → 代理成功率排行（淘汰低质代理）
/api/stats/errors → 失败错误聚合（分析常见失败原因）

把成功率数据分析做成独立 API，意味着可以接入 Grafana / Prometheus 等外部监控，而不只是看 Web UI 上的图表。这是「工具」到「运维平台」之间的一条分界线。

3.3 账号导出生态

注册完的账号需要被消费。支持 6 种导出格式：

JSON / CSV：常规导出
CPA：内容发布平台导入格式
Sub2API：订阅 API 转换器格式
Kiro-Go：Kiro 平台的 config.json 格式
Any2API：开源 API 网关格式（注册完自动推送到网关，即注册即用）

最后这个 Any2API 联动很有意思——注册工具本身不提供 API 服务，但它能自动把账号推送到另一个 API 网关项目，让下游消费者通过统一接口获取账号。这是一种「微服务化」的思路：注册工具专注生产，API 网关专注分发。

3.4 Any2API 自动推送映射

平台	推送目标	数据类型
Kiro	kiroAccounts	账号池
Grok	grokTokens	Token 池
Cursor	cursorConfig	Cookie + 配置
ChatGPT	chatgptConfig	Token + 配置
Blink	blinkConfig	凭证
Windsurf	windsurfAccounts	账号池

四、横向对比：与同类工具的异同

4.1 any-auto-register（上游项目）

维度	any-auto-register	aBaiAutoplus
⭐ Star	2529	311
🍴 Fork	885	208
平台数	13+	12（继承上游 + 新增 GoPay）
协议模式	✅	✅
浏览器模式	✅	✅
PayPal 付款	❌	✅（浏览器 PayPal 结账）
GoPay 付款	❌	✅（协议 14 步 API 付款）
Any2API 联动	✅	✅
接码渠道	SMS-Activate / HeroSMS	+ SMSPool / SMSBower
C 端管理门户	❌	✅（customer_portal_api）
桌面客户端	Mac / Win（社区版）	Mac / Win（完整版）

本质差异：any-auto-register 做了「注册」，aBaiAutoplus 做了「注册 + 付费」。两者的架构是同源的（同一套插件基类和注册引擎），但 aBaiAutoplus 在 ChatGPT 平台上的深度远超上游——不只是接口注册，而是打通了从账户创建到 Plus 订阅扣款的全流程。

可以这么说：

any-auto-register = 注册框架 + 多平台适配器
aBaiAutoplus = 注册框架 + ChatGPT Plus 付费工程 + GoPay 全套协议

4.2 gpt-auto-register（⭐397）

最直接的单平台竞品。基于 Python + Selenium，专注 ChatGPT 账号注册。

维度	gpt-auto-register	aBaiAutoplus
浏览器引擎	Selenium（单引擎）	Playwright / Camoufox / BitBrowser（三引擎）
架构	单体脚本	插件化 DDD 分层
平台支持	ChatGPT 单一平台	12 平台
付款集成	❌	✅（PayPal + GoPay）
Web UI	无	React + SSE 实时日志
账号管理	基础导出	生命周期管理 + 仪表盘 + 多格式导出
TLS 指纹	无	curl_cffi impersonate
桌面客户端	无	Electron

差距不在功能数量，在架构理念。gpt-auto-register 是一个能用的注册脚本；aBaiAutoplus 是一个可扩展的注册平台。

4.3 chatgpt-auto-register（⭐13）

基于 undetected-chromedriver 的入门级实现。功能最基础，适合学习原理，不具备生产级可用性。与 aBaiAutoplus 不在同一量级，不做详细对比。

4.4 差异化总结

如果把「AI 账号注册工具」的进化分为三个阶段：

第一代（2023） Selenium + 手动配置 → 注册成功
第二代（2024-25） Playwright + 多平台 + 插件化 → 注册 + 管理
第三代（2026） 协议逆向 + 付费打通 + 微服务生态 → 全链路自动化

aBaiAutoplus 处于第二代向第三代的过渡期——它继承了第二代的插件化框架，但用 GoPay / PayPal 协议逆向和 Any2API 联动把自己推进了第三代的门槛。三者的核心差异体现在付费集成、TLS 对抗深度、以及生态完整度上。

五、工程细节中值得关注的亮点

5.1 TLS 指纹伪装的双层策略

项目在 HTTP 层面有两套请求方案：

curl_cffi（core/http_client.py）：默认 impersonate="chrome136"，伪造完整的 TLS 握手指纹
tls_client（core/tls.py）：更轻量的选择，用于 GoPay 等对 TLS 检测不那么严格的场景

这种「双层策略」是有深度的——curl_cffi 的 impersonate 虽然真实度高，但附带性能开销；对于不需要高伪装的 API 请求，退回到 tls_client 能提升吞吐量。

5.2 邮箱层的「深度防御」

9 种邮箱 Provider 不是简单的多选，而是一种分层防护策略：

自己的域名邮箱（Laoudo）：稳定性最高，适合重要账号，不会被封
自建 Cloudflare Worker 邮箱：完全可控，邮箱域名随机，难以被平台封禁
公共临时邮箱（DuckMail / TempMail.lol）：零配置，适合快速测试
MoeMail 自动注册：连邮箱也是自动创建的，适合大规模并发

不同场景用不同邮箱，这是一种对抗意识——当平台开始针对特定邮箱域名做风控时，你有备选方案。

5.3 验证码求解的递进策略

策略	优先级	使用场景
本地 Solver（Camoufox 自动点击 checkbox）	1	Turnstile checkbox，最快最省
远程 Solver（YesCaptcha / 2Captcha）	2	需要图片识别或本地失败时
手动介入	3	极端风控场景

「先本地、再远程、最后手动」的递进逻辑，比直接调打码平台更经济。

5.4 开源安全审计的"工程良心"

项目开源前做了一份详细的安全审计（OPEN_SOURCE_RELEASE.md），发现的 P0 级问题包括：

81 个真实 ChatGPT 账号明文凭证已被 git 跟踪
8 个 GoPay 账号的手机号 + PIN 明文泄露
13 个调试 dump 文件含 PayPal / Stripe 实时 cookie

这份审计本身就是一个有价值的技术文档——它展示了「开源前要做哪些安全检查」的完整 checklist：

扫描 git 历史中的凭证文件
检查源码中的硬编码 API Key
审查第三方 APK 逆向常量是否可公开
验证 .gitignore 规则是否生效
git filter-repo 重写历史的完整命令

每个打算开源的开发者都应该读一遍这份文档。

六、局限与风险

6.1 技术局限

GoPay 地域锁定：依赖印尼手机号 + 印尼 IP，对中国用户不友好
PayPal 浏览器自动化不稳定：BitBrowser profile 持久化是双刃剑——历史 cookie 积累后可能触发异常检测
Camoufox 依赖：本地 Solver 依赖于 Camoufox 的反指纹浏览器，ARM 架构支持有限
MoeMail 公共实例不可控：依赖第三方部署的实例稳定性

6.2 运维负担

3.7M 行 Python（含依赖）不是小工程，依赖更新和兼容性维护是个长期问题
跨平台浏览器自动化（Playwright + Camoufox + BitBrowser）的环境配置复杂度高
多接码渠道、多验证码渠道的 API 轮换和余额管理需要持续关注

6.3 法律与道德边界

项目在 README 中明确了「仅供学习研究」的定位，并且基于 AGPL-3.0 许可证。但必须指出：

自动化注册违反几乎所有目标平台的 ToS
协议化支付链路可能涉及支付欺诈的法律风险
印尼 GoPay 的 APK 逆向常量（CLIENT_SECRET 等）存在 ToS 和版权问题

技术是好技术，但使用场景需要谨慎判断。

七、总结

aBaiAutoplus 之所以值得深入分析，不是因为它「又多了一个注册工具」，而是因为它展示了注册工具从脚本到平台的完整进化路径。

它的核心价值不在于星星数（311 相比上游的 2529 还差得远），而在于：

架构上：插件化 + DDD 分层，让注册能力可扩展、可维护
技术上：支付协议逆向（PayPal 6 Stage + GoPay 14 步），把"注册"延伸到"付费"
工程上：代理池智能轮换、邮箱分层防护、TLS 指纹对抗，形成了一个完整的反风控体系
生态上：Any2API 联动、多格式导出、customer_portal_api，让注册工具成为可运营的基础设施

与同类工具相比，它最大的差异化优势是付费链路的打通——这是三个对比项目都不具备的能力。GoPay 协议付款和 PayPal 浏览器结账这两条「野路子」，背后是扎实的 HAR 分析和协议逆向工作，不是简单的 API 拼接。

当然，它的"进化"仍在进行中——AGPL-3.0 许可证意味着衍生项目可以在此基础上继续扩展，而 3.7M 行的 Python 代码量也意味着维护成本不低。

对于想学习注册工具架构设计、支付协议逆向、或者浏览器自动化实战的开发者，这个项目是一个非常有价值的参考案例。

本文基于 2026 年 6 月 1 日的仓库状态分析。项目仍在快速迭代中，部分细节可能已有更新。

GoPay on 逍遥笔记