开元棋牌强化学习与Self-play棋牌AI

在开元棋牌强化学习的日常训练记录里，最容易让人放松警惕的，是一条持续上涨的Reward曲线。训练脚本跑了几十万局，日志里Reward平均值一路走高，看起来一切都在往好的方向发展。但这一研究模块反复确认的一件事是：Reward曲线上涨，只说明Agent从Environment里拿到的即时反馈变多了，并不直接说明它学会的Policy在更广泛意义上变强了。这两件事之间隔着好几层需要验证的假设，跳过验证直接下结论，是训练棋牌AI时最容易踩的坑之一。

Reward曲线好看，说明的是什么，又没说明什么

Reward是Agent每执行一个动作后，由Environment返回的单步反馈，衡量的是这一步在当前情境下的直接效果。训练过程中被优化的目标其实是Return，从某个时刻开始，未来一系列Reward累积得到的总量。曲线上涨说明的是，在当前的训练Environment、当前的Opponent Pool构成下，Agent积累Return的能力在提升。这句话里有两个限定条件——"当前的训练Environment"和"当前的Opponent Pool"，而这两个限定条件恰恰是最容易被忽略、也最容易出问题的地方。棋牌类游戏往往规则复杂、状态空间庞大，两个限定条件同时保持不变的情况并不常见，这也是为什么同一条Reward曲线，在不同训练阶段可能代表完全不同的真实情况。

Reward Hacking：Agent在钻训练环境的空子

Reward函数是人为设计的，用来近似"希望Agent学会什么"，但近似永远不等于完全吻合。只要Reward的设计存在漏洞，某个动作序列能持续拿到高Reward，但并不对应真正合理的棋牌策略，Agent大概率会找到它，因为这正是Policy Gradient、PPO这类方法在做的事：提高能带来更高Return的动作的概率。这种现象通常被称为Reward Hacking，训练日志上表现为Reward稳步上涨，但如果把训练过程录像回放，会发现Agent学到的是一套针对Reward计算方式的取巧打法，脱离对局的真实目标。棋牌类游戏的规则往往包含大量边界情形，例如特殊牌型、极端局面下的合法动作集合，Reward函数很难把每一种情形都精确覆盖，这就给Reward Hacking留出了空间。训练团队能做的，是把这类边界情形单独列出来作为专门的检查项，而不是寄希望于Reward函数天然覆盖所有情况。

训练环境和真实规则之间总会有偏差

即便Reward设计没有明显漏洞，训练用的Environment本身和真实规则之间也可能存在偏差。为了训练效率，Environment的实现通常会做一些简化或近似处理，比如某些低频规则分支的处理方式、超时或非法动作的判定逻辑。这些偏差在正常对局中很少被触发，所以不会明显拖慢Reward上涨的趋势，但一旦触发，Agent的表现可能会和训练时判若两人。这也是为什么这一研究模块始终强调，训练环境的规则准确性本身就是需要持续核查的对象，而不是默认正确的前提。把训练环境的规则实现和真实规则逐条比对，是一项枯燥但必要的工作，往往比调整算法本身更能解释表现落差的来源。

策略是否泛化，要在训练分布之外验证

Self-play生态本身也会塑造一种特定的对手分布。Agent在这个分布里学会的应对方式，是针对Self-play过程中反复出现的打法风格做出的适应，未必对所有风格都成立。Reward曲线只反映Agent在这个特定分布下的表现，无法反映它面对分布之外情形时会怎么样。要判断Policy是否真正具备泛化能力，需要主动跳出训练时的分布做验证：换用风格差异明显的对手、构造规则边界情形下的对局、甚至引入完全不参与训练的Rule-based Agent。这些验证手段的共同点是，它们都不依赖训练曲线本身，而是直接观察Policy在陌生情境下的实际行为。

把验证当作训练流程的一部分，而不是收尾动作

在开元棋牌强化学习的训练流程里，Reward曲线上涨应该被当作一个触发验证的信号，而不是可以直接采信的结论。第一步该做的，通常不是继续加大训练规模，而是回过头去看模型到底学会了什么：把若干局对局逐步回放，检查关键决策点上的动作选择是否符合棋牌策略的基本逻辑；把Agent放到没在Opponent Pool里出现过的对手面前，看Return是否仍然稳定；构造几种规则边界情形，看Agent的动作是否仍然合法、合理。这些检查成本不低，但比起把一个实际上学偏了的Policy当作训练成果，这笔成本是值得付的。Reward曲线可以作为训练是否在正常运转的一个参考指标，但它从来不是判断策略强弱的终点。

"最新版打赢上一版"到底证明了什么

Self-play训练里最常见的一种进度感知方式，是让当前版本的Agent和它刚保存的上一个版本对弈，统计胜率。如果胜率持续超过五成，很自然会觉得策略在持续变强。这个判断在很多时候是成立的，但它依赖一个没有被明说的前提：策略之间的强弱关系具备传递性，即A赢B、B赢C就能推出A大概率赢C。棋牌类游戏的策略空间往往不满足这个前提，这也是开元棋牌强化学习在设计训练与评估流程时始终绕不开的一个问题。这类局部胜率数据很容易被误读为整体实力的单调提升，尤其是在训练日志被自动化脚本汇总、缺乏人工复核的情况下。

Strategy Cycle：策略之间可能互相克制成环

在很多对抗性游戏里，策略之间的胜负关系可以形成环，也就是通常说的Strategy Cycle：策略A的打法针对性地克制策略B，策略B又恰好克制策略C，而策略C反过来能克制策略A。如果训练只关注"最新版本打赢上一版本"，Agent很可能是在沿着这个环持续游走，每一步都战胜前一步的策略，但整体上并没有朝着某个稳定更优的方向前进。更麻烦的是，环上某个更早的节点，可能恰好是当前最新版本的克星，只是因为训练流程里已经不再和它对弈，这个弱点才没有被发现。这种环状关系不是训练出现错误的证据，而是棋牌类对抗游戏策略空间的一种常见结构特征，在很多涉及信息博弈的游戏里都可能出现。

遗忘旧策略是训练本身的自然倾向

Self-play的训练数据主要来自Agent与近期版本或当前版本的对局，这意味着训练信号会持续朝着"如何应对最近遇到的打法"倾斜。对更早期版本或者已经很久没出现过的打法风格，Agent的应对能力会随着训练推进逐渐生疏，这是一种训练层面的自然遗忘，不是bug，而是数据分布变化的直接结果。这种遗忘往往是渐进的，很难通过某一次训练报告直接观察到，只有拉长时间尺度、对比多个版本之间的表现，才能看出趋势。如果历史Checkpoint被丢弃，遗忘的过程就没有任何机制可以被发现或纠正，Agent可能在悄悄退化到某些早期打法面前，而训练日志上完全看不出异常，因为Reward和胜率都是相对于当前的训练对手计算的。

历史Checkpoint作为Opponent Pool的组成部分

保留历史Checkpoint，并把它们持续纳入Opponent Pool参与对局生成，是应对Strategy Cycle和策略遗忘的一种直接方法。让当前版本定期与若干个历史版本对弈，可以检验它是否仍然能应对更早期的打法风格，一旦发现某个历史版本能稳定战胜当前最新版本，就意味着训练过程中出现了退化或者环状克制关系，需要介入调整，可能是扩大Opponent Pool的多样性，也可能是调整Reward设计或训练超参数。这个检验没办法靠"最新版打赢上一版"这一种对局方式替代，因为它们回答的是完全不同的问题：前者回答的是有没有在退化或绕圈子，后者回答的是相邻两步之间有没有变化。

只用最新版本互测会掩盖什么

如果训练评估始终只在最新版本内部进行，最新版打次新版、次新版打次次新版，整条评估链条其实只覆盖了策略演化路径上很窄的一段。这种评估方式的问题在于，它没有能力发现训练路径整体是否在原地打转，也没有能力发现某个早期分支上的打法是否被完全遗忘。一个可能出现的情况是，Agent在连续几十个版本里都稳定战胜上一版，但如果拿最新版本去对战训练初期保留的某个Checkpoint，结果却是明显落后，这种落差只有在历史Checkpoint被保留并持续参与验证的情况下才能被发现。更极端的情况下，训练团队甚至可能完全说不清楚训练路径的真实形状，因为留存的记录都只是相邻版本之间的局部比较结果。

保留成本换来的是可验证性

保留历史Checkpoint会带来存储和计算上的额外开销，定期把它们纳入对局评估也会占用训练资源，这些是实打实的成本。但这笔成本换来的是训练过程的可验证性：能够随时回答"当前策略相比更早的版本，是不是在所有已知打法面前都没有退步"这个问题。在开元棋牌强化学习的训练框架里，历史Checkpoint因此被当作Opponent Pool里长期保留的一部分，而不是训练过程中的中间产物，用完即弃。

训练环境里的"稳定"是相对谁而言的稳定

一个棋牌AI在训练环境里跑出稳定的Reward曲线和稳定的胜率，通常意味着它已经能够很好地应对训练过程中反复遇到的那一类对手。这句话里"训练过程中反复遇到的那一类对手"是关键限定：稳定性是相对于训练时接触过的对手分布而言的，不是相对于所有可能的对手而言的。这个区分听起来是常识，但在实际训练记录里，很容易被简化成一句"模型已经很稳定了"，而丢掉了后半句限定条件。这种简化看似无伤大雅，但在训练报告习惯用单一数字概括模型表现的情况下，很容易被无意间当成结论传递下去。

训练分布和测试分布本来就可能不一致

Self-play生态里的对手主要是Agent自己的历史版本或当前版本，这些版本之间打法上存在共性，它们都是同一套训练流程、同一套Reward设计下产生的，风格上必然有相近之处。这意味着训练分布本身就是偏的，覆盖的是"Self-play能演化出来的打法"这一个子集，而不是这个棋牌游戏里所有可能存在的打法。一个从未参与过训练、按照固定规则或启发式逻辑行动的Rule-based Agent，打法来源和Self-play生态完全不同，很可能落在训练分布覆盖不到的区域。Policy在这样的对手面前表现下滑，本质上是一次分布外（out-of-distribution）测试暴露了训练分布的局限，而不是训练过程本身出了错。换句话说，训练分布内部看起来很"多样"的对手，放到整个棋牌游戏可能存在的打法空间里看，覆盖面可能相当有限。

过拟合的不是数值，而是打法生态

通常说起过拟合，容易联想到训练数据量不够、模型记住了具体棋局这类问题。但棋牌AI在Self-play里出现的过拟合更多是对"打法生态"的过拟合：Policy学会的是一套针对Self-play种群里常见打法的应对方式，这套应对方式建立在对手会怎么下棋的隐含假设之上。Rule-based Agent的决策逻辑往往和Self-play种群里演化出来的打法差异很大，它可能会做出Self-play对手很少做的选择，走一些在Self-play生态里因为不划算而很少被探索、但规则上完全合法的路线。Policy如果只在Self-play生态内部打磨过，遇到这类选择时缺乏对应的应对经验，表现下滑几乎是预期之内的结果。这种过拟合不会在训练损失或Reward曲线上留下明显痕迹，因为衡量标准本身就是在同一个打法生态内部定义的。

Rule-based Agent的价值在于它不参与训练

Rule-based Agent之所以是有效的验证手段，核心原因是它的行为逻辑独立于训练过程，不会被Self-play的演化方向影响，也不会被Agent的Policy变化牵着走。它提供的是一个相对固定的参照系：只要Rule-based Agent的规则本身没有变化，Policy面对它的表现变化就能比较干净地归因于Policy自身的变化，而不用担心"对手也在变强"这个混杂因素。这一点是历史Checkpoint也部分具备、但Rule-based Agent更彻底的优势，历史Checkpoint终究还是Self-play生态的产物，而Rule-based Agent从设计上就完全在这个生态之外。

把Rule-based Agent纳入常规验证，而不是偶尔抽查

在开元棋牌强化学习的验证流程里，Rule-based Agent通常不止扮演一次性的"期末考试"角色，而是作为常规验证环节之一，和历史Checkpoint、多样化的Opponent Pool一起，持续观察Policy在训练分布之外的表现。如果某次训练迭代后，Policy在训练环境内的Reward和胜率都在上涨，但面对Rule-based Agent的表现却在下降，这通常是一个明确信号：Policy正在往更贴合Self-play生态、但泛化性更差的方向发展。这种信号只有在测试分布和训练分布刻意保持不同的情况下才能被观察到，如果验证也完全用Self-play内部的对局来做，这类退化会被训练曲线的上涨趋势完全遮盖，直到面对真实、多样的对手时才会暴露出来。

分布外测试不是要证明模型很差，而是要看清边界

面对Rule-based Agent表现下滑，并不意味着训练环境里的一切努力都白费了，也不意味着这个Policy没有价值。它说明的是这个Policy目前的能力边界在哪里，在Self-play塑造的打法生态内，它是稳定和有效的；离开这个生态，稳定性需要重新验证。清楚这条边界，训练团队才能决定下一步该往哪个方向投入：是扩充Opponent Pool的多样性，让训练分布更接近真实的打法分布，还是针对Rule-based Agent暴露出的具体弱点做定向调整。分布外测试的意义正在于此，它把"训练环境里表现很好"和"能力真正到位"这两件容易被混为一谈的事情，重新分开检验。