场景
一个团队需要在50个反检测浏览器配置文件中注册平台账户。每个账户需要唯一的电子邮件、姓名、电话号码和密码。注册流程包括电子邮件验证、reCAPTCHA v2挑战和注册后的入职步骤。
手动完成需要3-4小时。使用Ornold MCP和AI代理，整个批次在25分钟内完成——包括CAPTCHA求解和错误恢复。
准备：每个配置文件的数据
第一步是为50个配置文件中的每一个准备唯一的数据。注册表单所需的每个字段都需要为每个会话提供不同的值。在配置文件之间重复使用数据是最快被标记的方式。
团队准备了包含以下内容的数据集：
- 唯一的电子邮件地址（每个配置文件一个，来自不同提供商）
- 与配置文件的区域设置/语言设置相匹配的真实姓名
- 强密码（每个配置文件唯一，不是顺序的）
- 用于短信验证的电话号码（来自虚拟号码服务）
数据质量比自动化速度更重要。一个重复的电子邮件或明显虚假的姓名可能会触发欺诈检测并标记整个批次。投入时间生成真实、多样化的数据集。
// 示例配置文件数据集结构
const profiles = [
{ email: "sarah.mitchell@proton.me", name: "Sarah Mitchell", phone: "+1-555-0142", password: "kR9#mPx2vL" },
{ email: "james.wong@tutanota.com", name: "James Wong", phone: "+1-555-0198", password: "nT4$hQw8bJ" },
// ... 还有48个唯一的配置文件
];
阶段1：启动和导航
准备好50个Linken Sphere会话（每个都有自己的代理、指纹和时区），第一步是同时将所有会话导航到注册页面。
// 启动所有会话并导航到注册页面
await browser_list(); // 验证50个会话可用
await browser_parallel_navigate({ url: "https://target.example/signup" });
// 等待表单在所有会话中加载
await browser_parallel_wait_for({
text: "Create your account",
timeoutMs: 20000
});
50个会话中的48个在8秒内加载了注册页面。两个会话由于代理延迟而较慢——`wait_for`命令在14秒标记处等待它们赶上。
阶段2：表单填充
每个会话需要自己的唯一数据。Ornold的并行填充命令接受一个值数组，该数组与活动会话1:1映射：
// 填充电子邮件——每个会话获得唯一值
await browser_parallel_fill({
ref: "email",
values: profiles.map(p => p.email)
});
// 填充姓名
await browser_parallel_fill({
ref: "fullname",
values: profiles.map(p => p.name)
});
// 填充密码
await browser_parallel_fill({
ref: "password",
values: profiles.map(p => p.password)
});
在所有50个会话中填充表单大约需要3秒。基于DOM的交互模式（免费，无vision信用）轻松处理了结构化表单字段。
阶段3：CAPTCHA求解
注册页面有reCAPTCHA v2挑战。Ornold在所有50个会话中检测到它，并并行发送求解请求：
// 在所有50个会话中求解CAPTCHA
const captchaResult = await browser_solve_captcha();
// { total: 50, detected: 50, solved: 47, failed: 3 }
50个CAPTCHA中的47个在第一次尝试中求解（15-35秒）。三个会话失败——求解服务超时。团队没有重试整个批次，而是只重试了失败的会话：
// 重试失败的会话
const retryResult = await browser_solve_captcha();
// 仅针对仍有未求解CAPTCHA的会话
// { total: 3, detected: 3, solved: 3, failed: 0 }
CAPTCHA求解是大多数注册流程中最慢的步骤。在填充表单后求解（不是之前）以最小化令牌过期的可能性。
阶段4：提交和验证
表单填充完毕且CAPTCHA已求解，下一步是点击提交按钮并验证注册成功：
// 提交表单
await browser_parallel_click({ ref: "submit" });
// 等待成功页面
await browser_parallel_wait_for({
text: "Check your email",
timeoutMs: 15000
});
// 检查状态
const status = await browser_status();
提交后的结果：
- 46个会话到达"Check your email"确认页面
- 2个会话获得了额外的安全挑战（电话验证提示）
- 1个会话收到"too many requests"错误
- 1个会话在提交期间超时
阶段5：错误恢复
团队没有重启整个批次，而是分别处理每种失败类型：
电话验证（2个会话）
这些会话需要额外的步骤。AI代理检测到电话输入字段，填入数据集中的虚拟号码，然后提交。两个会话在短信验证后完成。
速率限制错误（1个会话）
"too many requests"错误与代理有关——IP最近被使用过。团队切换了会话的代理并重试。注册在第二次尝试时成功。
超时（1个会话）
简单的页面重新加载和重新提交解决了这个问题。表单数据仍然被填充（浏览器保留了它），所以只需要重复提交操作。
最终结果：50个账户全部成功注册。从第一次导航到最后确认的总时间：23分钟。
使这成为可能的因素
几个因素将这从脆弱的脚本转变为可靠的批处理操作：
- 每个配置文件的数据——每个会话都有唯一、真实的数据。没有重复，没有模式。
- 并行执行——所有50个会话一起通过每个阶段，而不是一次一个。
- 选择性恢复——每个会话处理失败，而不是通过重启批次。AI代理识别出问题所在并应用正确的修复。
- 阶段之间的状态检查——每个步骤后的`browser_status()`和`wait_for`调用早期捕获分歧。
- CAPTCHA重试逻辑——失败的求解被单独重试，而不是重新求解整个批次。
时间分解
- 会话启动+导航：~15秒
- 表单填充（50个会话）：~3秒
- CAPTCHA求解（第一遍）：~35秒
- CAPTCHA重试（3个会话）：~25秒
- 表单提交+验证：~10秒
- 错误恢复（4个会话）：~8分钟
- 总计：~23分钟50个账户
没有错误恢复阶段，46个会话的快乐路径在大约2分钟内完成。大部分总时间花在CAPTCHA求解和处理边界情况上——这在这个规模上是预期的。
进一步扩展的经验教训
- 数据质量是瓶颈，而不是自动化速度。花更多时间在真实数据集上，而不是优化点击时间。
- 代理质量直接影响成功率。便宜的共享代理导致速率限制和阻止。住宅或移动代理性能明显更好。
- 不要运行超过你的机器能处理的会话。50个Chromium实例需要16-24 GB的RAM。监控资源使用情况，在扩展会话数量之前扩展硬件。
- 从一开始就将恢复构建到工作流中。在50+个配置文件中，某些失败是有保证的。问题是你是自动处理还是手动处理。
- 先用5个配置文件测试。在扩展到50之前验证整个流程端到端。大规模调试呈指数级困难。
- 分散大批次。从同一IP范围同时运行100个配置文件是一个危险信号。分成20-30个一组，中间有延迟。