摘要

玩家反馈 Arena 里最强的 deep 档 AI 一步要等一分钟以上。deep 是研究用搜索：向前看两层、每层保留 6 个候选、对随机结果抽 4 个样本，没有墙钟上限。本次只消除重复计算，不降低深度、宽度或样本数，也不引入“超时就随机选”。同一保存开局的完整 deep 决策从原代码 180.301 秒降到第一批优化后的 88.256 秒；后续批次一度降到 59.279 秒，但补强一项正确性检查后，当前版本为 62.909 秒。每次比较的动作和完整评分都相同。这仍然远超交互需求，问题没有解决。

要回答的问题

deep 一步慢在哪里？能否在结果逐项不变的条件下减少重复工作？

方法

输入是一份候选存档（不能确认就是玩家那局），在独立进程里从保存的初始状态调用正常 deep 入口；没有连接服务或推进玩家对局，存档前后内容相同。改动全部是“同一请求内、同一对象”的缓存：

  • Simulator 动作结算、回执和回合调度复用已有的状态计算缓存；合法动作菜单按精确的引擎/状态对象复用，最多 512 个。
  • AI 估值复用同一不可变单位的基础价值（最多 8192 项），法术各伤害分支、反击风险、等待/移动评分也用上；单位一变就重算。
  • 状态验证用轻量身份键查找；状态摘要（用于识别相同局面的“指纹”）加入最多 128 个状态的私有缓存。

结果

运行（同一开局，完整返回） 耗时 节点
原代码 180.301 秒 8179
加单位估值与搜索缓存 106.669 秒 8179
加菜单缓存 99.835 秒 8179
加验证查找优化 88.256 秒 8179
修正剪枝界限缓存后（见下） 90.481 秒 —
加静态评分提前剪枝 75.603 秒 7472
加状态摘要缓存 59.279 秒 7472
补强不可变性检查后（当前） 62.909 秒 7472

同一局镜像施法后的第二个状态：原代码 81.982 秒 → 44.180 秒 → 当前 36.612 秒。前四行之间动作与完整决策逐项相等。同一局的两个状态不是两场独立战斗，也不是 p95。

失败与负结果

  • 途中发现一个正确性问题：被剪枝的界限分数被当成精确值缓存，已另行修复（策略身份加了 exact-window-cache-v1），之前“结果相等”的记录只对当时版本成立。
  • “Python 可哈希”不等于“不可变”：一个自定义哈希的列表在创建后被修改，旧缓存返回了旧摘要。反例实际失败后，改为只接受已知冻结结构和内置不可变容器，耗时因此从 57.628 秒回到 62.909 秒。
  • 诊断器最初直接比较事件字典，因上层附加的策略元数据不同而失败；改用引擎的确定性事件字节比较。

局限

  • 单个存档、少数几次测量，不是多场景延迟验收；用户会话关联和实际试玩未验证。
  • 剩余热点（合法法术枚举、规则验证、免疫/修正查询）尚未优化；缓存它们必须考虑定义、目标身份和可变输入。

结论与下一步

重复计算减少约三分之二，但 deep 仍需一分钟左右。后续：实验 0501 做序列化复用，实验 0502 改走四秒限时的可玩路径，实验 0504 诊断四秒内到底能完成多少搜索。