智叟云集系统：任务调度、性能分析与异常恢复

一、先区分响应速度与处理能力

自动化采集有两类经常混淆的指标：单个任务多久返回，以及系统每小时可以处理多少任务。前者是时延，后者是吞吐量。增加云手机通常可以减少排队、提高同时处理能力，但不会直接缩短平台生成同一条回答所需的时间，也不会自动解决界面等待、分享延迟或错误重跑。

一次完整采集的耗时可拆成：排队等待、设备准备、问题提交、回答生成、正文与截图处理、对话与信源获取、校验落盘和清理。对于快速入口，还需要计入临时环境准备与恢复。只有对这些阶段分别计时，才能判断优化是否有效。

二、如何建立可信的耗时统计

计时口径必须保持一致。如果一轮只统计回答出现，另一轮包含截图、分享、信源和重试，两者不能直接比较。单平台成功耗时、失败退出耗时、批次总耗时与排查等待应分别记录。批次中一个平台快速失败会拉低总时间，但这种减少没有业务价值。

以上为同一台手机顺序执行、固定测试问题、包含正文与证据返回的三轮记录。三轮总耗时约 645.3 秒，12 次任务有 9 次成功；DeepSeek 当时停留在登录页面，因此其失败耗时不能加入成功均值。完成登录后的另一项本地调试测试约 107.1 秒成功返回，但问题不同，不属于这组三轮对照。

三、从一台手机到设备池

一台手机的前台界面是共享资源。两个任务同时点击、输入或滚动，会造成问题发错对话、截图串到其他任务、分享链接不匹配等错误。因此，即使服务器有很多线程，同一手机仍应保证一次只执行一个采集任务。

多台设备则可以分组并行。固定一台手机使用一个平台有助于减少切换和状态变化，但也可能让负载不均衡：某个平台问题多，其队列会更长。合理的调度器应依据任务积压、设备健康、平台能力和完成速度调整分配，而不是把设备数量永久平均分配。

以 100 个问题、四个平台为例，业务层可拆成 400 个子任务。如果按平台各配置 25 台设备，理论上可同时处理 100 个子任务；实际并发仍受连接、主机资源、代理隔离和账号可用性影响。设备数只是容量上限的一部分，不能直接推导“速度提高 100 倍”。

当前程序提供采集执行器和本机设备互斥，不提供完整的百台设备管理系统。便携版共享本机约定的锁位置，用于协调遵守同一约定的实例；它无法约束另一台主机上的任务。跨主机需要统一设备租约、任务所有者、心跳与租约失效后的隔离机制，避免旧任务仍在运行时新任务接管手机。

四、超时、重试与幂等

重试不是无条件重新提问。登录过期、连接未授权和页面结构变化，通常需要先修复条件；不断重试只会增加等待和重复操作。短时网络故障、分享快照稍晚可用等情况，才适合在预算内有限重试。任务队列与采集器都设置重试时，需要统一总次数，防止两层相乘。

每次重试应有独立的尝试编号和结果目录。模型回答具有变化性，不能把第一次回答的正文与第二次回答的截图合并。业务侧还应区分“重复收到同一个提交请求”与“用户明确要求再次提问”：前者可以用幂等键复用任务，后者应创建新任务。

结果上传或回调失败也不等于采集失败。已经取得完整证据后，应重试传输或通知，避免重新调用手机。生产后端需要把采集状态与交付状态分开保存，使“已采集、待上传”成为可恢复的中间状态。

五、异常处理必须面向具体阶段

错误展示本身也是可靠性的一部分。此前出现过连接被拒绝后界面仍显示“本批次结束”，用户因此以为程序没有响应。修正后的便携版把连接未授权解释为明确失败，并保留错误详情，避免终态提示覆盖真正原因。日志应帮助用户采取下一步，而不只记录异常堆栈。

六、接入业务后台的建议路径

建议后端先接收任务并立即返回编号，实际采集由后台工作进程执行。完成后把正文、链接、平台、状态与耗时写入数据库；截图等文件放到受控文件服务或对象存储，数据库只保存位置和校验信息。前端查询任务状态，不需要一直占用同一个 HTTP 请求等待采集完成。

在工程落地上，可以先验证单台设备的完整闭环，再加入队列、任务表与结果上传，最后实现多主机设备租约、监控告警和人工恢复入口。当前模拟 API 不能作为真实云手机服务已经接通的证明。生产环境应设置访问鉴权、任务归属检查、文件访问控制，并让后台而非客户端决定实际设备地址。

扩容验收除了吞吐量，还需要测试同设备争用、进程异常退出、设备离线、代理清理失败与任务重复提交。当前实验性代理使用固定本地端口，不能直接在同一主机启动多份并发采集；必须先做端口与代理环境隔离。设备池是否可用，应以这些故障场景下仍能正确结束和恢复为标准。