[AthenaHibou]

摘要

• 支持为账号自定义启动参数，开启前提示风险并带入当前参数，修改后原样传递给 ok-ww。
• 多账号批次按参数分组执行，保留账号顺序；补充参数预览、保存失败回退和回归测试。

Closes #1697

验证

• 后端相关测试 74 项通过，涵盖次数上限、剩余天数跳过，以及成功、维护、手停时的单条历史归档；历史回归在修复前 3 项失败、修复后全部通过。
• 前端测试 6 项通过，类型、lint、格式检查通过。
• 普通、原生逐账号、原生批次 E2E 共 3 项通过，覆盖确认与取消、参数保存与重载、错误提示、保存失败回退和离页关闭确认弹窗。
• 未运行真实脚本或游戏。

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1968

宝宝，自定义参数确实接到了启动入口，预览和执行也复用了同一份参数解析，没有偷偷补回默认参数，这点挺好喵。不过批次预检换了对象之后，把正常跳过的账号记成失败了；不开自定义参数也会受影响，这处要先修。

前端负责确认、保存和预览参数，manager 按相邻参数分组，BatchProxy 负责批次执行及账号结果。分组顺序和每组结束后的配置恢复都保留了，问题在预检修改的账号不是运行树里那一个。

[逻辑 · P2] 达到每日次数上限的账号被误记为异常

位置： manager.py:299–315。

当切号方式为 OKWW、由队列执行且某账号今日次数已达到 ProxyTimesLimit 时，新建的 BatchProxyTask 会在 构造函数 把 cur_user_item 换成临时账号节点。AutoProxy.check() 只将这个临时节点设为“跳过”，真实账号仍是“等待”。

接着 notify_user_check_failure() 会把真实账号改成“异常”，整体收尾 因而把正常限额跳过算作托管异常和未完成账号。原有“保留跳过状态”的保护没有失效，只是它读不到临时节点上的状态啦。变更前逐账号预检用 AutoProxyTask，持有真实节点，没有这个断点。

这里不必撤掉批次参数检查。让预检把跳过结果写回原账号，再交给现有通知和收尾即可；也可以让这一步直接使用真实账号节点，但别影响实际批次运行时的独立批次状态。

已有 test_batch_filters_each_accounts_real_daily_limit[0/1] 正好守着这个行为。dot酱读了 Windows 和 Ubuntu 的实际 CI 日志，两边都在第 272 行得到“等待”而不是“跳过”，不是无关的路径失败。测试 mock 了通知，所以停在“等待”；生产路径继续变成“异常”是上面调用链的静态推演。修复后请保留这两个断言，并让验收覆盖真实通知处理后的账号及整体结果，别只把测试里的状态补绿喵。

本次核对了配置与生成 API、前端保存/预览、参数透传、批次分组与取消收尾、备份及结果判定；复用了既有保存遥测，没有要求另加一套。dot酱没有执行项目代码、测试或真实游戏/UI 流程，CI 证据与静态检查分开列在上面。

—— dot酱拍拍爪敬上 🐾

[jinghero]

总体结论：修改后合并

AUTO-MAS-Project/AUTO-MAS #1968

宝宝，上轮“正常跳过被记成异常”已经修好了：预检现在写回真实账号，次数上限和剩余天数的断言也保留并扩展了，这处修得对喵。不过单账号运行也一起复用了真实节点，把批次内部的每轮日志带进账号历史了，还需要把这两个用途分开。

[逻辑 · P2] 单账号批次会重复归档，并把维护或手停多记成错误

位置： BatchProxy.py:42–48。

选择 OKWW_SINGLE，或 OKWW 按参数分组后某组只有一个账号时，这里不再创建独立批次节点。随后 BatchProxy.prepare() 先给真实账号建立一条汇总记录，继承的 AutoProxy.main_task():802–804 又在同一个账号节点添加本轮记录。

收尾时 BatchProxy.final_task() 把汇总记录设为 cur_user_log，再调用 AutoProxy.final_task():1103–1135，后者遍历账号全部记录。因此一次正常成功会写入两条成功历史；运行期间维护跳过或手动停止时，额外的轮次记录又不满足“当前记录”的判断，会额外归档成 error。这些是静态调用链推演，没有运行复现。

现有底层不会合并它们：add_log_record() 每次添加独立记录，历史保存 也逐条落库。旧实现把运行轮次放在独立批次节点，真实账号只保留账号汇总，没有这次混入。影响是历史重复及错误归类，不是每日 ProxyTimes 翻倍，那个计数仍只在账号收尾时增加一次。

请让批次任务继续区分“预检写真实账号状态”和“运行轮次用独立节点”：例如只在准入阶段同步跳过结果，实际执行仍保留独立批次节点。别为了修历史再把旧跳过问题带回来啦。验收用一个参与人走准备、执行、收尾与历史保存，分别确认成功、维护、手停的历史条数和状态；这次新增测试 mock 了 spawn，还没有走到这条归档链。

dot酱已读取新提交的实际 CI 日志：Windows 为 2045 passed、1 skipped，Ubuntu 为 2002 passed、43 skipped，均另有 17 subtests。绿色 CI 能说明现有用例通过，不能覆盖上面的遗漏；本轮只做静态复审，未执行项目代码、测试或真实游戏流程。此前参数透传、分组与配置恢复的已核验部分没有新增改动，不重复铺开喵。

—— dot酱拍拍爪敬上 🐾

[AthenaHibou]

dot酱，对不起喵，这轮复审指出的问题确实存在。上次修复了准入时的跳过状态，却漏查了单账号运行后的历史归档链，辛苦你再帮忙抓出来了喵。

已在 62fa11e 修复：

• 构造和准入阶段保留真实账号节点；进入 prepare() 后，无论单账号还是多人批次，都另建独立运行节点，隔离内部轮次日志与账号汇总。
• 回归实际执行 prepare → main_task → final_task → save_user_history，仅隔离外部进程、通知和历史存储边界。成功、维护、手动停止三个场景在旧代码上均复现两条历史；修复后均只有一条，状态分别为 success、skipped、cancelled，成功计数也只增加一次。原有次数上限、剩余天数跳过回归继续通过。
• 扩散检查另补了离开账号页时关闭自定义参数确认弹窗，避免旧弹窗继续操作已离开的账号，并加入浏览器流程验证。

本地后端相关测试 74 项、前端测试 6 项、三种模式 E2E 3 项通过，类型、lint 和格式检查通过。新提交的 CI 正在运行，未执行真实游戏流程。

谢谢 dot酱耐心复查，这次把准入、执行和归档连起来验证了喵 🐾

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1968

宝宝不用道歉啦，咱们是在一起把代码修稳，不是在抓谁犯错喵。dot酱核对了这版：准入时保留真实账号，进入执行后再建独立运行节点，之前的跳过误判和重复历史两处都修好了。审查范围内没有剩余的必须修改项，可以合。

这次补的测试确实连起了执行和归档，不再只停在派发前：成功、维护、手停分别断言只有一条历史，状态为 success、skipped、cancelled，成功次数也只加一次。dot酱还回看了准备失败、重试、日志归属和收尾，单账号与多人批次没有因为这次拆分出现新的确认问题。

离页销毁自定义参数确认弹窗那处，dot酱前面没提醒到，谢谢宝宝主动补上啦。当前由组件自己销毁弹窗，浏览器用例也增加了离页后弹窗消失、开关未被保存为开启的断言；没有另加状态管理或保存入口，处理很直接。

已读取当前提交的完整 pytest CI 日志：Windows 为 2048 passed、1 skipped，Ubuntu 为 2005 passed、43 skipped，均另有 17 subtests。作者提供的本地修复前后对照和浏览器验证属于作者验证；dot酱本轮做的是静态复审，没有独立执行项目代码、测试、浏览器或真实游戏流程。

辛苦宝宝把准入、执行和归档认真串起来检查了，猫爪这次可以松开啦 🐾

—— dot酱拍拍爪敬上 🐾

[AthenaHibou]

✋️😭🤚