摘要

状态估计（SE）在解释生物面板的攻防时，会调用规则模拟器做“来源筛选”和“等待效果参考”等查询。这些查询受时间预算限制：预算用完时，应当把结果标记为“未完成”，这样战斗记录 App 的常驻计算服务会在空闲时继续算完。

本实验发现：这两类查询在超时后只返回一句说明文字，没有设置公开结果和 App 唯一识别的“未完成”标记，于是 App 以为已经算完，不会续算。修复后，在两份真实保存请求上用“预算为 0”强制复现，标记正确出现，恢复计算后结果与正常结果完全相同。外部审阅又指出 App 的 20 次跟进上限只约束界面请求、管不住核心服务内部的空闲循环，于是另加了每个请求最多 4 次空闲尝试的上限。

要回答的问题

当属性参考计算因预算耗尽而中断时，系统是否会如实标记“未完成”，并在之后续算出与完整计算相同的结果？续算是否有上限？

数据与来源

只复用两段已选训练来源的保存请求（58 帧和 49 帧），都通过公开的 SE 入口计算。不新增 OCR、视频或规则；“预算为 0”和人为注入超时属于软件边界验证，不代表正常运行中的延迟或识别准确率。

方法

  1. 来源筛选和等待参考两个函数在捕获超时时，通过一个可选的私有进度字典标记“未完成”；规则不支持、缺少观察、状态未计入这些情况不触发续算。
  2. 准备页参考和同帧参考两条路径按面板分别收集进度，只给确实超时的那一行加“未完成”标记。SE 已有的汇总逻辑（任何一行未完成则整体未完成）和 App 已有的空闲续算（间隔 1 秒、界面最多跟进 20 次）直接复用。
  3. 新增后台上限：每次成功接收请求后，常驻服务最多做 4 次空闲尝试，用完就阻塞等待新请求；新请求重新获得 4 次额度。成功或异常会提前停止；排队中的请求和输入结束优先于下一次空闲尝试。由于界面最多跟进 20 次，同一份证据最多是 21×4=84 次空闲调用，不能误报为“整轮只做 4 次”。单个规则调用仍可能超出协作预算，不承诺硬性截止或抢占。
  4. 正常完成的结果不增加字段、不改变文字或候选。

设置

每份请求依次运行三次：先完整计算一次以预热其它查询，再以预算 0 固定耗尽，最后无期限恢复一次；原始输入不变。另用 App 原来的常驻服务脚本（原 0.2 秒预算、1 秒续算间隔、20 次上限）做故障注入验证。

结果

真实保存请求前后对照：

保存请求 修复前（预算耗尽） 修复后（预算耗尽） 恢复后
58 帧 4 条参考有预算提示，但顶层和行都没有“未完成” 4 条参考和顶层都标记未完成 与修复前的无期限结果完全相同
49 帧 8 条参考有预算提示，但没有标记 8 条参考和顶层都标记 完全相同

在预算耗尽的情况下，只有推断行和顶层的“未完成”标记发生变化；去掉这些标记后全部结果相同。观察、攻击证据、排除结果和原请求都不变。

常驻服务验证：

  • 单次注入超时：首个请求 84.174 毫秒、未完成，对应的准备页参考行被标记；空闲循环继续，第二次 83.099 毫秒完成，结果与正常结果相同。
  • 持续注入超时（加上限后）：两次请求（67.905、72.405 毫秒）都保留 4 条未完成，每次恰好 4 次空闲调用后停止，之后 300 毫秒内没有再调用；移除故障后第三次 83.206 毫秒完成，结果与正常结果相同。11 次调用（3 次前台 + 8 次空闲）逐次记录。
  • 单次故障复验：78.197 毫秒未完成，一次空闲调用后完成，下一次 89.752 毫秒结果与正常相同。

以上包含预热和等待的总时长（10–24 秒）不作为性能基准。

软件检查： 新入口 9 项（修改前 3 失败、6 通过，失败恰好是“未完成”标记丢失）；最终合计 381 个不同的软件检查通过、12 个因主机没有符号链接权限而跳过。这不是 381 场实战。

失败与负结果

  • 首次持续故障验证时，实验包装器的全局函数名被服务导入覆盖，导致递归失败；失败输出保留，修正包装器（改用独立名字）后在新目录运行，没有为迎合测试修改生产代码。
  • 首次 App 测试误指定了一个不存在的测试文件，未收集到用例；找到真实位置后重跑，原记录保留。
  • 同一个“持续未完成”测试在修改前的原服务脚本上失败，新脚本通过。

局限

  • 没有证明正常用户运行中一定会触发这个问题。
  • 这不是完整的检查点恢复；资源持续不足时不保证最终完成。
  • 4 次是保守的有限尝试配置，不是性能调优结论。
  • 真实识别准确率、全公式组合覆盖和安装版都未达标；本修复不代表候选准确率提高。

结论与下一步

超时现在会被如实标记，常驻服务会在有限次数内续算出与完整计算相同的结果。外部审阅认可这一有界设计，并建议明确“后台只预热、不推送结果”“每请求上限不等于整轮上限”；两点都已写明。此专项就此收尾，不再扩建续算机制；下一步回到保存输入中，检查属性历史变化是否被后续条件推断正确消费。