摘要

实验 0502 让网页 AI 在四秒内返回最近完成的选择，高档位大多退回 quick。本次要弄清楚四秒里时间花在哪：准备候选动作要多久、每个“根动作”（当前这一步可选的动作）在每个随机样本上的比较何时返回。结论：开局时 deep 光准备共同候选就用了 2.507 秒，四秒窗口内 0 个根动作结果；第 3 步后菜单小得多，deep 仍然 0 个。只把随机样本从 4 降到 1 也解决不了。工具已实现，在线增量搜索尚未实现，默认策略和预算都没变。

要回答的问题

四秒预算下，quick/strong/deep 分别完成了哪些工作？是候选准备慢、单个分支慢，还是工作顺序不合理？

方法

新诊断工具从 Arena 保存的某个状态检查点观察一次研究搜索，不执行选出的动作、不连接服务、不改输入，每一步都写进逐行日志：搜索开始、每个随机样本的根候选、共同候选、每个根搜索返回、结束或失败。

  • 四秒是“协作式观察窗口”，只在被观察的方法边界停下，单次引擎调用可能越过窗口（实测退出在 4.002–4.010 秒）；它不是网页进程的硬截止，计时也不含进程启动、结算、保存和浏览器，不能当五秒验收。
  • 未完成时只保留部分记录，不返回上一次遗留的选择。插桩只装在工具自己的实例上，退出即恢复。
  • 可选研究消融：随机样本改为 1；关闭根部等待/跳过/移动的延伸（这也会改变移动候选的准入，不是纯性能对照）。

设置

同一候选存档的开局和第 3 步后两个状态，各 6 种配置，共 12 次。两个状态都先从原保存完整回放核对。这是一局里的两个状态，不是 12 场对局。在视频分析进程结束后串行运行，限 8 核、低优先级。

结果

状态 档位 候选准备完成 四秒内返回的“根动作×样本” 覆盖全部样本的动作 完成选择
开局 quick 0.654 秒 6 6（1 个样本） 0.811 秒
开局 strong 2.618 秒 2，仅样本 0 0 否
开局 deep 2.507 秒 0 0 否
第 3 步后 quick 0.081 秒 6 6（1 个样本） 0.086 秒
第 3 步后 strong 0.463 秒 8（样本 0 五个、样本 1 三个） 0 否
第 3 步后 deep 0.339 秒 0 0 否

开局菜单有 475 个动作（44 个单位目标法术、369 个六角格法术、60 个移动、等待和跳过）。第 3 步后只有 63 个，准备已经很快，但 deep 的第一个分支仍占满剩余时间。

状态 消融 结果
开局 strong，1 样本 未完成；返回 5 个根结果
开局 deep，1 样本 未完成；只返回 1 个根结果
开局 strong，关延伸，4 样本 未完成；16 个根结果只覆盖前 2 个样本
第 3 步后 strong，1 样本 3.389 秒完成，选攻击精灵追踪者
第 3 步后 deep，1 样本 未完成，0 个根结果
第 3 步后 strong，关延伸，4 样本 0.443 秒完成，8 个动作都完成 4 样本，选同一攻击

完成的消融与 quick 选择相同，只说明工作分配变了，不是战术质量提升。两个状态的候选里都保留了移动动作，没有复现“移动候选被挤掉”的担忧。

失败与负结果

首轮工具测试 10 通过、1 失败：测试把 JSON 列表直接和 Python 元组比较。改为类型化比较后 12 项通过；与现有搜索相关测试合计 128 项通过（9.19 秒），加消融后工具 16 项通过（1.34 秒）。

局限

只有一局的两个状态；插桩和日志有开销；quick/strong/deep 都读取对手隐藏构筑，不是公平 AI。

结论与下一步

不能只靠“完整迭代后再发布”或“减少随机样本”来解决：deep 连第一个分支都可能越过四秒。strong 按“先样本、后全部根动作”的顺序工作，导致有很多结果却没有一个动作完成全部样本。增量原型应先让少数根候选在同一样本集合上比完，再扩宽；先建立便宜的共同基线，再给有战术理由的动作追加延伸。是否接入网页由之后的战术质量检查决定。