摘要

Public Quick 是只用玩家可见信息的一步搜索 AI。它在实验 0076 中以原型形式通过了 4 秒实时评测，0080 压缩了耗时尾部。本实验把它作为 Arena 档位 public_quick 接入真实实时路径后，用 32 个新来源再打一遍，主要防止代码迁移、worker 接线和资源管理引入问题，不重新证明算法。

结果：49 胜 14 负 1 双输，来源差 +0.5312 [0.3125, 0.7188]，每步最长 3.776 秒，四项检查全部通过，与 0076 阶段二一致。

要回答的问题

生产路径是否把系统搞坏了？

方法与设置

  • 候选：Arena 档位 public_quick，经 Arena 的实时 AI 入口；worker 内先算 H3（英雄无敌三式规则 AI）再算 Public Quick，4 秒预算，截止前 0.25 秒停止等待。
  • 对手：H3（进程内）。
  • 32 个新来源（种子 71100–71131）。来源是一个随机种子生成的镜像开局，候选执蓝、执红各一局，共 64 局；来源差 = 候选两局得分和 − 1；来源自助重抽 10,000 次（种子 0）的 95% 区间。规则版本 Core453。
  • 检查项（事先写定）：0 非法动作、64 局严格重放、无遗留 worker；每步 ≤ 4.4 秒；采用比例与阶段二（88.5%）同量级；区间下界 > 0 视为与阶段二一致，否则排查，不调参重打同批来源。

结果

检查项 结果
合法 / 重放 / 遗留 0 非法；64/64 一致；本运行无遗留进程
每步耗时 3,205 次决策：p95 2.922 秒，最长 3.776 秒；> 4.0 秒 0 次
采用比例 Public Quick 2,566（80.1%）；H3 639（核心未给动作 550、到截止 89）；公开菜单回退 0
来源差 49 胜 14 负 1 双输；+0.5312 [0.3125, 0.7188]（19 好 2 差）

局限

到截止 89 次（2.8%，阶段二 0.55%），p95 2.92 秒（阶段二 2.31 秒）。可能原因（未逐项验证）：生产 worker 每步先完整算一次 H3、并在新进程里重新加载选秀目录；运行后半段另一会话的离线视频复核同时占用 CPU。到截止的步骤都采用了 H3 的选择，没有退到公开菜单。悬停预览仍来自本地 Simulator，未与商业客户端对照。

结论与下一步

生产路径与阶段二一致，Public Quick 作为 Arena 可选 AI 交付（默认仍是 v59）。可在 worker 中让 H3 与 Public Quick 共用一次目录加载，以降低截止比例。