摘要
AI 想用 Simulator 的公开“攻击序列”查询（一次攻击连同反击、追加击的结果）来给攻击打分，前提是这个查询足够快。我们暂定单次查询 p95（95% 的调用不超过的耗时）预算为 2 毫秒，并做了可重复的本地测量。三个代表场景的 p95 都在 0.16 毫秒以内；从一个合法局面构造六个不同进攻面并一次查完，p95 为 1.316 毫秒，低于暂定的 10 毫秒扫描预算。这是本地抽样结果，不是对所有单位、状态、场地数量的保证。
要回答的问题
公开攻击序列查询本身有多快？在 AI 真正依赖它之前，单次和一轮扫描的耗时是否落在一个可接受的预算内？
方法与设置
- 离线构造固定局面，只计时公开查询那一次调用；规则事实和移动风险在计时前准备好。查询只接收公开观察、动作、事实和可选的公开路线，不接收可执行状态或引擎预览。
- 每个场景预热 50 次、测 300 次。Python 3.12.13，AMD64，本地 core 环境。超出所选预算时脚本以非零退出。
- 另做“菜单测量”：从合法局面构造六个进攻面，计时一次公开扫描（一批移动风险、一批规则事实、六次序列查询）；同时计时不变的 v55 策略在该局面实际 340 个动作的菜单上做一次完整选择。各预热 10 次、测 100 次。
结果
单次查询：
| 场景 | 支持程度 | 中位数（毫秒） | p95 | p99 |
|---|---|---|---|---|
| 普通第二击 | 部分 | 0.1264 | 0.1287 | 0.1391 |
| 疾速 + 幸运 × 隐藏圆盾，含协助反击 | 未知（列出条件情形） | 0.1508 | 0.1590 | 0.2124 |
| 已知路线中断 | 部分，无目标攻击 | 0.0242 | 0.0260 | 0.0293 |
菜单级：
| 操作 | 平均（毫秒） | p95 | p99 |
|---|---|---|---|
| 六进攻面公开扫描 | 1.2886 | 1.3162 | 1.3703 |
| v55 完整菜单选择（340 个动作，不含序列查询） | 10.1748 | 10.9844 | 21.2247 |
v55 的菜单里有 1 个默认攻击、268 个格子法术、67 个移动、2 个单位法术、等待和跳过。
后续私有候选的报告补测：在实际 343 个动作的菜单上串行 200 次，候选平均 9.633 毫秒、p95 9.685 毫秒；v55 平均 6.130 毫秒、p95 6.233 毫秒。该局面每次决策实际用 1 次序列查询，查询 p95 0.127 毫秒。两项暂定候选预算（完整决策 100 毫秒、序列小计 20 毫秒）均通过。
局限
- 这是可观测的本地预算，不是确定性的运行时上限。疾速场景返回的是“未知总量 + 条件情形”，计时它不会把它变成期望伤害。
- 两类计时分开测量，相加不等于候选策略的决策延迟；六进攻面局面是为覆盖路线构造的，不是真实的 340 动作菜单。
- 每次决策最多 64 次查询的饱和成本没有测。
结论与下一步
查询本身足够便宜。AI 真正依赖它之前，还要在状态丰富、协助候选多的完整对局里测量候选策略的完整决策时间、每次决策实际查询数、回退频率，并设决策级上限；查询返回未知时保留 v55 回退（完整对局评测见实验 0027）。
Comments