摘要

Public Quick 是只用玩家可见信息、在 Arena 实时 4 秒路径上运行的一步搜索 AI。实验 0076 阶段二中它有 4 次决策超过 4.4 秒（最长 4.533 秒）。本实验做一次有界的耗时修复，再复测。

结果：两种负载条件下每步最长分别为 3.888 秒和 3.903 秒，0 次超过 4.0 秒，超时的步骤都由规则 AI H3 合法接管，验收通过。不做棋力结论。

要回答的问题

一次有界修复能否让每步总耗时稳定在 4.4 秒以内，包括机器有其它负载时？

方法

  1. 快照状态修复：构造当前局面快照时，某些法术状态要通过搜索法强与持续时间来修复。改为只在引擎报出的问题可能由这两项修好时才搜索；明确修不好的（法术等级不符、召唤标记、免疫等）直接放弃；先逐个试法强，只剩“寿命不符”时才试持续时间。在 381 个开发点上：构造成功 347、菜单完全一致 311、攻击预览一致数都不变；构造中位 0.166→0.115 秒、最长 1.614→0.72 秒；被丢弃的法术状态 262→397（当前不影响菜单与攻击预览）。
  2. 实时执行器 v2：在截止前 0.25 秒停止等待，留出回收 worker 与映射动作的时间；记录收到第一个选择（H3）的耗时。

设置（冻结）

  • 开发来源 70800–70815（不使用 0076 阶段二的来源），Public Quick 执蓝、执红各一局对 H3，32 局，实时 4 秒，4 个进程。
  • 条件 a：不额外加负载；条件 b：同时运行受控 CPU 压力（4 个进程、70% 占空比，与本运行的 CPU 核段重叠）。
  • 验收：两种条件下每步都不超过 4.4 秒；超时都合法回退；无本运行遗留进程。

结果

指标 a 未额外加负载 b 受控 CPU 压力
局 / 决策 32 / 1,688 32 / 1,683
每步总耗时 p95 / 最大 2.083 / 3.888 秒 2.278 / 3.903 秒
> 4.0 秒 / > 4.4 秒 0 / 0 0 / 0
到截止（采用 H3） 21 25
采用 Public Quick / H3 / 菜单回退 1,521 / 167 / 0 1,512 / 171 / 0
收到 H3 首个选择 p50 / p95 / 最大 0.690 / 0.891 / 1.166 秒 0.734 / 0.924 / 1.064 秒
描述性胜负（开发来源） 29–3 29–3

本运行无遗留进程。到截止的比例约 1.3–1.5%，都由 H3 合法接管。

局限

条件 a 并不真正空闲：同一台机器上另一个会话的视频实时回放和测试在跑。开发来源，胜负不作棋力结论。

结论与下一步

有界耗时修复完成，进入作为 Arena 可选档位的生产集成验证（实验 0081）。