开元棋牌官网：棋牌AI策略研究实验室与多智能体大模型平台

在开元棋牌做过的几轮内部测试里，我们让一个LLM先复述某个抽象棋牌游戏的完整Rules，它能做到接近教科书水平的准确——先手规则、吃子条件、终局判定，问答形式下几乎不出错。但把同一个模型换成"直接看局面、直接输出下一步"的模式，也就是这里说的Direct LLM Action路径，问题很快出现：对局一旦超过十几步，规则解释能力和实际执行质量就开始明显脱节。这说明"理解规则"和"在具体State下正确应用规则"中间有一段距离，这段距离恰恰是棋牌AI工程里最容易被低估的部分——它不是靠让模型把规则背得更熟就能缩短的，因为背规则本身从来不是瓶颈。

Direct LLM Action会具体出什么问题

先说Illegal Action。规则本身可能不复杂，但某个Action是否合法往往依赖当前完整的Game State，包括之前若干步累积下来的局面信息，而不是孤立的一条规则文本。LLM在生成下一步时，如果没有一个显式的合法性校验环节，很容易给出"单看规则条文没错、放到当前局面里其实不允许"的Action。

第二是State Tracking Error。对局越长，LLM需要在上下文里维持的局面信息越多，包括谁还有哪些资源、哪些位置已经变化过、哪些之前发生过的事件仍然在影响当前的合法性判断。这类信息不是规则本身，而是规则反复作用之后的累积结果，一旦模型在中途漏记或记错一个细节，后面所有基于这个错误状态给出的判断都会跟着偏，而且这种偏差往往是悄悄发生的——模型不会主动提示"我可能记错了"，它会带着错误的State继续给出看起来很自信的下一步。

第三是Rule Application Error，和Illegal Action不完全相同：模型可能记得规则条文，但在正确的时机套用了错误的规则，比如把某个只在特定条件下生效的规则当成默认规则使用。这类错误在问答测试里很难被发现，因为单独问"这条规则是什么"时模型答得完全正确，问题出在应用的时机判断上。

第四是Shallow Planning。即便当前这一步没有违反任何规则，LLM给出的选择通常只隐含地考虑了很短的未来窗口——它更接近于"这一步看起来不错"，而不是"这一步之后对手大概率怎么应对、再往后几步局面会走向哪里"。这和后面要讲的Search机制形成的多步评估完全不是一回事：Search是显式地把多个未来分支展开、逐一评估之后再回传结果，而Direct LLM Action给出的判断更像是一次性的模式匹配，没有一个可以被检查的中间推理结构。

第五是Long-term Inconsistency：在长对局里，模型对同一类局面要素前后给出不一致的处理方式，这一步认为某个条件成立、几步之后又当作不成立，这种漂移在短对局测试里通常不明显，是长局面测试才会暴露出来的问题。

Rule-to-Strategy Pipeline想解决的是分工问题

我们提出的Rule-to-Strategy Pipeline不是要否定LLM在这里的作用，而是重新划分它的职责边界。完整链路是：Natural Language Rules作为输入，经过LLM Interpretation转成结构化、可被程序解析的Structured Rules；这套Structured Rules被编译成一个Executable World Model；任何候选Action在进入下一阶段之前，先经过一次独立的Legal Action Verification；通过验证的Action集合再交给Search（可以是简单的Minimax变体，也可以是MCTS）做多步评估；最后才输出Strategy。

这个结构里LLM只出现在最前面一次性的翻译环节，它做的是"把自然语言规则变成程序可以执行的规则"，而不是每一步都重新做"理解规则+应用规则+多步规划"这三件事。一旦Structured Rules编译完成，Legal Action Verification和Search都是确定性或可重复评估的过程，出了问题也容易定位到具体哪个环节，而不需要去猜测某一次生成里LLM到底是记错了State还是套错了规则。

需要说明的是，这条Pipeline并不否定LLM在更早期的价值，比如面对一个全新的、规则文档写得比较模糊的棋牌游戏时，用LLM把散乱的自然语言规则整理成结构化条目，仍然比人工从头编写规则解析器要快。区别在于，这次翻译工作完成之后，运行时的每一步决策不再依赖LLM的临场发挥，而是依赖一个已经可以被单独测试的World Model加上一个可以被单独调参的Search模块。

World Model不是一个流行词，是几个具体问题的答案

真正把这套Pipeline撑起来的是World Model，这个词经常被当成一个笼统的概念使用，但在这里它必须回答几个非常具体的问题。State怎么表示：需要能完整刻画局面又不遗漏对后续合法性判断有用的信息。执行某个Action之后State怎么变化：这是一个确定性或概率性的转移函数，不能靠"大致合理"来实现。当前State下哪些Action合法：这一步的答案要能被程序直接查询，而不是靠语言模型临场判断。Episode什么时候结束：终局条件必须显式、可判定。Reward或最终Outcome怎么计算：这决定了后续Search要优化的目标。

这几个问题任何一个被建错，后果不是"稍微不准"，而是系统性的。假如transition函数把某种局面变化建模错了，那么不管后续用多大的Search Budget、Search Depth有多深，Search都是在一个自洽但错误的世界模型里反复确认一个不成立的结论——搜索得越深，反而越像是在为一个错误答案积累证据，因为Search本身只负责在给定的World Model里找最优路径，它没有能力去质疑这个World Model是否符合真实规则。这也是为什么在讨论"要不要加大Search"之前，先要检查World Model本身有没有系统性偏差，这一步往往比调大计算量更值得优先处理，也是Rule-to-Strategy Pipeline把Legal Action Verification单独列为一个环节、而不是把它交给LLM临场判断的原因——一个可以被独立测试、独立回归验证的World Model，出了问题能定位，而混在Direct LLM Action里的隐式判断出了问题，往往连"错在哪一步"都很难复现。

在开元棋牌的技术讨论里，"决策树"是一个经常被误用的词，因为它同时指代两件完全不同的东西，如果不先把这两者分开，后面关于Search的讨论很容易变成鸡同鸭讲。

两种"决策树"不是一回事

机器学习里的Decision Tree，是一种监督学习模型：给定一批带标签的训练样本，算法按特征反复做二分或多分切分，生成一棵树，叶子节点对应一个预测结果。这棵树训练完成之后是静态的，用来对新样本做分类或回归，本质上是一个从历史数据里总结出来的判别函数。

Game AI里讨论的Decision Tree，准确说法应该是Search Tree：根节点是当前的Game State，每一条边代表一个可选的Action，边的另一端是执行这个Action之后可能出现的下一个State。这棵树描述的不是历史数据里的规律，而是从当前局面出发、面向未来的所有可能性——它是被"展开"出来的，而不是被"训练"出来的，展开的深度和广度取决于当前愿意投入多少Search Budget，而不是取决于有多少历史样本。两者共享"树"这个数据结构，但一个是对过去样本的总结，一个是对未来分支的枚举，功能和构造方式完全不同：分类树一旦训练完成就不再变化，Search Tree则是每一次决策都要重新展开（或者部分复用上一次的结果）。这个区分在讨论棋牌AI时经常被跳过，但跳过之后很多后续问题——比如"为什么不直接把树建完"——会变得没有意义，因为提问者脑子里想的其实是分类树那种一次性构造完的静态结构，而不是这里说的、理论上可以无限展开但实际必须节制的Search Tree。

Branching Factor为什么会让树"爆炸"

Search Tree的规模由两个变量共同决定：Search Depth，也就是往下展开多少层；Branching Factor，也就是平均每个节点有多少个合法的候选Action。State Space Explosion描述的正是这两者结合之后的增长速度：树的节点总数大致是Branching Factor的Search Depth次方，这是指数增长，不是线性增长。

用一个近似的数量级例子说明会更直观：假设某个局面平均有大约30种可选Action，也就是Branching Factor约等于30。只展开1层，需要考虑的下一步State大约是30个；展开2层，大约是30乘30，接近900个；展开4层，大约是30的4次方，接近81万；展开6层，是30的6次方，接近7亿；如果继续展开到10层，规模会来到30的10次方这个量级，远超任何常规系统能够逐一枚举的范围。这里的数字是用来说明增长速度的量级，不是某个具体游戏的真实统计结果，实际的Branching Factor会随局面阶段变化，开局阶段可能选择较多，某些残局阶段反而会收窄，但结论是稳定的：只要Branching Factor明显大于1，Search Depth每往下增加几层，需要考虑的State数量就会跨越好几个数量级，很快超出穷举展开的可行范围，这也是State Space Explosion这个词想表达的核心含义——爆炸的不是某一层，而是层数累积起来的乘积效应。

真正的问题不是"能不能展开"，是"该往哪展开"

既然完整展开在深度稍大之后就不现实，Game AI要处理的问题就变成：有限的Search Budget应该分配给哪些节点，而不是要不要展开更多节点。这里几个机制各自负责不同的部分。

Pruning的作用是提前排除掉那些几乎不可能被选中的分支，让计算不浪费在明显劣势的路径上，经典的Alpha-Beta剪枝就是在保证结果不受影响的前提下跳过部分子树——它的巧妙之处在于，跳过的子树即便真的展开了，也不会改变最终的决策，所以剪掉它不损失信息，只节省计算。

Heuristic解决的是另一个问题：如果不把每条路径都展开到Episode结束，怎么判断一个还没分出胜负的State大致处于什么水平。一个设计合理的Heuristic能给中间State一个近似评分，让Search不必依赖穷举到终局才能比较不同分支的好坏。

Policy Prior的作用是在还没有展开任何子节点之前，先给每个候选Action一个"值得关注"的先验排序，这个排序通常由训练好的模型给出，让计算资源优先流向更有可能重要的分支，而不是均匀地撒在所有Action上。

Value Function则是对某个State的长期价值给出一个直接估计，效果上类似Heuristic，但通常是通过学习获得，而不是人工设计的规则。它让Search可以在展开有限深度之后就"停下来"用一个估计值代替继续展开，把节省下来的计算预算转移到其他更值得深入的分支。这四个机制经常被组合使用而不是二选一：Policy Prior决定往哪个方向先看，Pruning决定哪些方向可以提前放弃，Heuristic或Value Function决定看到多深就可以停下来给个判断，三者配合才能在有限Search Budget下覆盖尽量多有意义的分支，单独用其中一个通常达不到同样的效果。

这四个机制合在一起要回答的都是同一个问题：在树的规模随深度指数增长、完整展开不可行的前提下，怎样让有限的计算尽量花在真正影响最终决策的节点上，而不是均匀或盲目地展开。Search Depth增加本身不是目标，如果Policy Prior给出的排序本身有系统偏差，或者Heuristic对局面价值的判断本身不准，那么把Search Depth从4层加到8层，多出来的计算大概率还是花在同一批被高估或低估的分支上，未必真正提高了决策质量。这也是为什么在评价一个Game AI系统时，只看它展开了多少层、算了多少个节点，意义有限，真正要看的是这些计算有没有被分配到值得研究的地方。

在讨论棋牌AI的Search Budget时，"模拟次数"很容易被当成唯一重要的指标，开元棋牌在做内部评估时刻意避免这种简化，因为MCTS的效果由很多环节共同决定，模拟次数只是其中一个，而且往往不是决定最终强度的那个最关键的环节。

MCTS到底在做什么

MCTS由四个阶段组成，每一轮迭代都会依次经过这四步。

Selection：从Root节点，也就是当前的Game State出发，按照一个选择规则逐层往下走，每一层都要在"已经评估过、看起来比较好的分支"和"还没有被充分探索、可能被低估的分支"之间做取舍。最常见的规则是UCT，它给每个候选节点一个分数，这个分数同时考虑该节点目前的平均评估值和它被访问过的次数，访问次数少的节点会得到一定的探索加成，避免Search过早锁死在某几条路径上。

Expansion：当Selection走到一个还没有被完全展开的节点时，加入一个或多个新的Child State，把树的边界向外推进一步。

Simulation/Evaluation：对刚加入的节点做一次价值估计。早期版本的MCTS常用随机走子一直到Episode结束、再看结果的方式来完成这一步，这也是"蒙特卡洛"这个名字的来源。但现代系统通常不这样做，而是用一个训练好的Value Network直接对当前State给出一个价值估计，同时用Policy Network对候选Action给出先验概率，这个先验会在Selection阶段影响UCT的计算。换句话说，现代MCTS不是"靠大量随机模拟硬算出答案"，而是用学习到的先验和价值估计去引导一个相对精简的搜索过程。

Backpropagation：把这一次Evaluation得到的结果，沿着从Root到当前节点的路径，逐层更新回每一个经过的祖先节点，更新它们的访问次数和平均价值。这一步的意义是让后续的Selection在下一轮迭代时能用上这一轮学到的信息——没有Backpropagation，每一次Simulation/Evaluation得到的信息就只停留在最深的那个节点，无法反过来影响Root附近的分支该往哪里继续展开。

这四步循环往复，每循环一次消耗一次评估，这些评估次数的总量就是通常说的Search Budget。

真正的价值在于"分配"，不在于"次数"

把这四个阶段放在一起看会发现，MCTS的核心机制其实是Selection：它决定了每一份新增的计算预算被投向树上的哪个位置。如果Selection的引导是准的——也就是UCT的分数排序和实际的局面价值排序基本一致——那么增加Search Budget确实能让树在真正重要的分支上展开得更深、评估得更准。但如果引导本身有偏差，增加的计算很可能被反复投向同一批已经评估过、边际信息量很小的节点，或者投向一开始就被先验低估、实际上更重要的分支根本没有得到足够关注。

这也是为什么不能把"模拟了100万次"直接理解成"比10万次强10倍"。这个说法背后隐含了一个假设：计算量和策略强度是线性对应的，但MCTS的运作机制并不支持这个假设。这里先不要看最终的Win Rate，而要看这100万次里有多少是花在了真正值得研究的节点上。

六个具体原因

Diminishing Returns：任何搜索方法在计算量增加到一定程度后，新增的每一份计算带来的信息增量都会递减，因为最值得研究的分支已经被评估得比较充分，剩下的计算只能在细节上做微调，这条曲线通常是先陡后平，而不是一路保持同样的斜率。

Poor Policy Prior：如果Policy Network给出的先验概率本身有系统偏差，Selection阶段从一开始就会把大量计算导向错误的分支，增加总的模拟次数并不能修正这个方向性错误，只是在错误的方向上算得更细。

Incorrect Value Estimate：Backpropagation传回的是Evaluation阶段给出的价值估计，如果Value Network本身对某类局面的判断存在系统偏差，这个错误信号会随着模拟次数增加被更牢固地写入整棵树，模拟越多，错误的评估反而被更多次确认。

Large State Space：对于分支因子大、State Space本身巨大的游戏，100万次模拟相对于可能局面的总数仍然只是极小的一个子集，绝对数量的增加未必带来覆盖面上的实质提升——这和前面讨论Branching Factor时提到的指数增长是同一个问题的两面，State Space越大，同样的模拟次数能覆盖到的比例就越小。

Repeated Exploration：在某些参数设置或局面结构下，Selection机制会倾向于反复访问同一小批节点，而不是把计算分散到更多值得关注的候选分支上，这种情况下增加总次数主要是在加深已有的重复访问，而不是拓宽评估范围。

Weak Environment Model：这是更底层的问题——如果Simulation阶段依赖的对局面转移和终局判定的建模本身不准确，那么不管模拟多少次，MCTS都是在一个和真实规则有偏差的世界里反复确认结论，次数增加只会让这个错误结论看起来更"稳定"。

把这六个原因放在一起看，结论是一致的：Search Budget的绝对数值只是影响最终策略强度的一个变量，真正决定效率的是Policy Prior准不准、Value Estimate准不准、Selection有没有陷入重复探索、以及最底层的Environment Model是否可靠。在这些前提没有检查清楚之前，单纯把模拟次数从10万调到100万，得到的提升可能远小于表面数字暗示的那样，有时候把同样的算力预算改成先修正Policy Network的系统偏差，或者重新检查Value Network在某类局面上的估计是否可靠，带来的提升会比单纯堆高Search Budget更明显——这也是"先诊断再加算力"这个顺序在实际工程里常常被验证有效的原因。

在开元棋牌内部复盘Self-play训练结果时，一个反复出现的提醒是：训练局数、Win Rate曲线这些数字很容易营造出"策略在稳步变强"的印象，但要判断这个印象是否可靠，得先把强化学习的几个基础概念厘清，再具体看Self-play这套机制到底产生了什么、又在什么地方留下了结构性的盲区。

先把基本框架说清楚

强化学习的基本设定是：一个Agent处在一个Environment里，在每个时间步观察当前的State，如果Agent只能获取部分信息，这时更准确的说法是它观察到的是一个Observation而不是完整的State。基于这个观察，Agent按照它的Policy选择一个Action，Environment根据这个Action返回一个Reward，并把State转移到下一个State，这个过程反复进行，直到满足终止条件，一整段从开始到终止的过程叫作一个Episode。

这里有两组概念必须分清楚。第一组是Reward和Return：Reward是Environment在某一步给出的即时反馈，是一个局部信号；Return是从当前时刻开始，把之后所有时间步的Reward按某种方式累积起来的总量，强化学习训练要最大化的通常是Return的期望，而不是某一步Reward本身，这也是为什么一个短期看起来吃亏的Action，只要能换来更好的长期Return，仍然可能是Policy应该选择的Action。第二组是Policy和Value：Policy是一个从State（或Observation）到Action的映射，直接决定"这一步做什么"；Value是对某个State（或State-Action对）未来能获得多少Return的估计，回答的是"这个位置大概值多少"，两者可以在同一个网络里联合训练，但一个负责决策、一个负责评估，混用会让讨论失去精度。

Self-play解决了什么，又留下了什么问题

Self-play的做法是让Agent与自己的当前版本或者若干历史版本对战，产生的对局数据被继续用来更新Policy和Value。这个机制的直接好处是训练不再依赖人工准备对手，Agent会随着自己变强而自动获得更强的训练对手，形成一个理论上可以持续演进的闭环，这也是它在强化学习里被广泛采用的原因。

但这个闭环也带来几个结构性的问题。第一个是Strategy Cycle：如果训练对手集中在近期的少数几个版本，很容易出现策略之间互相克制成环的情况——策略A能稳定打赢策略B，策略B能稳定打赢策略C，但策略C反过来又能打赢策略A，训练曲线在这种情况下依然可能表现为持续上涨，因为每一代确实打赢了上一代，但这个"变强"是相对于这个小圈子而言的，圈子之外并不必然成立。第二个是Overfitting：Agent的Policy和Value可能在不知不觉中被训练成专门针对"训练过程里反复出现的这几种对手风格"做优化，一旦遇到风格完全不同的对手，之前学到的判断可能大幅失效。第三个是Opponent Diversity不足带来的局部策略生态问题：整个训练过程如果都发生在同一条自我博弈的演化路径上，Agent实际上只探索了策略空间里很小的一部分区域，这个区域之外可能存在完全不同的、从未被这个训练过程接触过的打法。

这里需要明确写清楚的一点是：Self-play不能被认为一定会自动收敛到全局最强的策略，它能够保证的只是在当前这个训练所构造出来的小型策略生态内部，新版本相对于旧版本在持续变强，这和"在所有可能的策略里都表现稳定"是两件不同的事情，中间的落差正是Strategy Diversity不足时最容易被忽略的部分。

Opponent Pool才是真正值得关注的设计点

如果Self-play本身不能保证Generalization，那么判断一个训练结果是否可靠，重点就要放在评估阶段用的Opponent Pool设计上，而不是训练局数或者Latest Model互相对战的Win Rate。一个只用最新模型互相对战做评估的流程，本质上是在同一个小圈子内部循环验证，很难暴露前面提到的Strategy Cycle和Overfitting问题。

更有信息量的Opponent Pool应该包含几类结构不同的对手：Historical Checkpoint，也就是训练过程中较早期的版本，用来检查新版本是不是只是在克制"最近的自己"；Fixed Baseline，一个从头到尾不参与训练、保持不变的参照策略，用它的表现可以跨时间横向比较不同版本的真实水平；Rule-based Agent，用明确规则构造、不依赖学习的对手，用来检查模型是否掌握了一些基本的、规则层面就能预判到的应对；基于Search的Agent，用来检查模型的判断在面对显式多步规划的对手时是否依然站得住；采用不同Policy结构或训练路径的Agent，因为即便目标相同，不同的训练路径也可能收敛到风格迥异的策略；以及模型在训练过程里完全没有见过的Agent，这一类是最关键的，因为它直接检验的是Generalization本身——模型遇到训练时从未接触过的打法，表现是稳定下降一些，还是断崖式失效。

把这些对手放进评估流程后，真正要看的不是模型在Opponent Pool整体上的平均Win Rate有多高，而是这个Win Rate在不同类型对手之间的分布是否均匀。如果模型对Historical Checkpoint和Fixed Baseline表现稳定，但一遇到Previously Unseen Agent就大幅下滑，这基本就能说明当前的Self-play训练出的是一套针对训练环境本身优化过的局部策略，而不是一套具备较好Generalization能力的通用策略。

这个分布本身也可以随训练进程持续跟踪，而不只是训练结束后做一次性检查：如果模型对Latest Model的Win Rate一直在涨，但对Fixed Baseline或Previously Unseen Agent的Win Rate长期停滞甚至下降，这通常是Strategy Diversity在训练中段就已经开始收窄的信号，比等到训练跑完几百万局之后再排查要早得多，也更容易在还来得及调整Opponent Pool构成的时候介入。换句话说，Opponent Pool不只是评估阶段的工具，把它的一部分提前接入训练过程本身，往往才是缓解Strategy Cycle和Overfitting的更直接办法。

Equilibrium不是"打出了最优解"，而是"没有人想单方面换策略"

先把Nash Equilibrium的定义讲清楚，因为这是整篇文章后面所有论证的基础，也是最容易被简化成营销话术的一个概念。一个策略组合构成Nash Equilibrium，指的是：给定其余所有参与者的策略保持不变，任何一个参与者单方面改变自己的策略，都不能让自己得到比现在更好的期望结果。注意这个定义完全没有说"这是最优的打法"，也没有说"双方都发挥出了最强水平"，它只是说这个组合是稳定的——没有人有理由主动偏离。这个"稳定"和日常语言里的"最好"不是同一件事，很多关于棋牌AI的讨论把两者混用，是概念上的一个常见误区。

举一个简化例子。设想一个三选一的扑克式对局，双方每一手可以选择进攻、防守、诈唬三种基本Action，收益关系类似石头剪刀布：进攻克制诈唬，诈唬克制防守，防守克制进攻。如果双方都以三分之一的概率随机混合这三种Action，任何一方单独把某一种Action的比例调高，长期期望收益都不会变好，因为对手是随机应对的，任何偏好都会被平均抵消。这个均匀混合策略就是一个Equilibrium点。但如果对手实际上并不是随机应对，而是明显偏爱防守，那么针对这个具体对手，进攻方显然应该提高进攻比例，而不是继续均匀混合——继续均匀混合虽然仍然是"稳定"的，却放弃了本可以拿到的额外收益。这正是Equilibrium策略和对某个具体对手最优之间的落差，也是整篇文章要展开的起点。

Best Response回答"针对这个对手该怎么打"，Exploitability回答"我最多能被打掉多少"

Best Response是一个相对于具体Opponent Policy定义的概念：给定对手的策略，无论是已知的还是估计出来的，能让自己获得最高期望收益的回应策略，就是这个对手策略的Best Response。它天然是对症下药的，一旦对手策略变化，Best Response也要跟着变化。这里有一个容易被忽略的前提：计算Best Response需要一个对手策略作为输入，而在真实对局里，这个输入通常不是精确已知的，而是靠观察和推断得到的估计，估计本身的误差会直接传导进Best Response的质量。

Exploitability则是另一个方向的度量：给一个策略本身打分，看它在面对世界上最擅长针对它的对手，也就是这个策略的Best Response对手时，最多会被打掉多少期望收益。Exploitability越低，说明这个策略越难被系统性针对，因为即便对手掌握了完整信息并且专门为它设计打法，能拿到的额外收益也有限。很多自我对弈式的训练方法，实际优化目标正是持续降低Exploitability，而不是针对某一类具体对手做优化，这也是为什么这类训练出来的策略往往显得"稳健但不够狠"。

低Exploitability和最大化利用某个具体对手，不是一回事

这是本文要强调的核心矛盾。低Exploitability是一个面向最坏情况的保守指标，它回答的是"如果对手拼命针对我，我最多损失多少"；而最大化利用一个具体对手，回答的是"面对这一个特定、通常带有偏好和弱点的对手，我能不能拿到超出Equilibrium水平的额外收益"。一个逼近Equilibrium、Exploitability很低的策略，在面对一个策略明显失衡的具体对手时，往往表现得够用但不够狠——它不会输给这个对手，但也没有充分利用对手的弱点。反过来，一个针对某个具体对手调优到极致的策略，往往会主动放弃一部分Equilibrium式的稳健性，把自己的Exploitability推高，一旦对手换了打法或者被识破，这个策略反而容易被反打。这里存在一个边界条件：只有当对手偏离Equilibrium的幅度足够大、而且这个偏离在可观测的时间窗口内相对稳定，主动提高自己的Exploitability去换取额外收益才是划算的；如果对手本身也接近Equilibrium或者打法变化很快，激进利用带来的额外收益可能覆盖不了自己被反打的风险。

Opponent Modeling在做什么，以及为什么它会过时

要在保持一定稳健性的前提下去逼近对具体对手的Best Response，需要Opponent Modeling。它通常分析Action History，也就是对手过去做过哪些选择；Strategy Preference，也就是对手在类似局面下偏好哪一类打法；Response Pattern，也就是对手对特定压力或信号的反应模式；State-dependent Behavior，也就是对手的行为是否随特定State特征系统性变化，比如同一个对手在局势领先和落后时可能表现出完全不同的风格，如果建模时把所有局面混在一起统计，会把两种截然不同的行为模式平均成一个失真的画像。这些分析共同构成一个关于对手的概率模型，而不是一个确定性预测——它给出的是这个对手在这类局面下大概率会怎么做的分布估计，而不是对手接下来一定会这样做的断言，样本量不够的时候，这个估计本身还带有统计噪声，不能当成精确值使用。

更重要的是，这个模型是有时效性的。它依赖的样本来自对手当前呈现出的策略分布，一旦对手本身也在学习、调整，或者只是临场换了打法，旧的Opponent Model就会开始失真。因此实际系统里，Strategic Adaptation往往要处理一个权衡：利用幅度调得越大，面对模型突然过时的风险也越大；调得太保守，又会把Opponent Modeling带来的额外收益让出去。一种常见的工程做法，是把最终策略设计成Best Response倾向和Equilibrium倾向之间的一个可调混合，混合权重随对手模型的置信度动态调整——持续监控预测偏差，一旦观测到对手行为和模型预期系统性偏离，就主动收缩利用力度，往Equilibrium式的稳健策略回撤，而不是假设一次建立的对手模型会一直有效。

完整信息和不完整信息，边界在"谁能看到当前State"

一个博弈是Perfect Information，指的是在决策的每一个时间点，参与者能观察到的都是完整的当前State——棋盘上所有棋子的位置、之前所有落子历史，任何一方都不缺信息。围棋、国际象棋、中国象棋这类棋类游戏，在标准规则下都属于这一类：AI要解决的问题很单纯，就是给定一个双方共同已知的State，搜索接下来哪一步的期望结果最好，搜索树的每一个节点都对应一个双方都认可的确定局面。

Imperfect Information指的是至少存在一部分信息，某些参与者无法直接观察到——对手手里还有哪些牌、暗置的棋子具体是什么、还没翻开的牌堆顺序。这类游戏里，Agent在任意时刻拿到的不是完整State，而是一个受限的Observation：自己能看到的部分，加上公开发生过的历史，这种"只能看到局面一部分"的处理方式通常被称为Partial Observation，它是Imperfect Information在Agent实际输入层面的具体表现形式。这个差别不是游戏难度的差别，而是问题结构本身发生了变化——Agent首先要处理的问题，从给定State搜索下一步，变成给定Observation，判断自己现在可能处在哪些State，搜索反而要退到第二步。

随机性和隐藏信息是两件不同的事

这里有一个很容易混淆的地方：一个过程有随机性，不等于这个过程构成Imperfect Information。掷骰子、公开抽牌这类过程，即便结果本身不可预测，但只要结果对所有参与者同时可见——骰子点数摆在桌面上，抽到的牌翻开给所有人看——那么从这一刻起，这仍然是Perfect Information：大家看到的是同一个已经确定、且共同已知的State，只是这个State在此之前是随机生成的，搜索时把这一步当成一个概率分支处理即可，不需要维护任何关于"谁不知道什么"的额外结构。真正构成Imperfect Information的，是信息已经确定下来，但只有部分参与者能看到，比如牌已经发到手上，但对手看不到你摸到的具体牌面；或者一步操作已经执行，但只有操作者自己知道具体内容。随机性关心的是结果在生成之前是否可预测，隐藏信息关心的是结果生成之后谁能看到它，这是两条独立的轴，不能互相替代着讨论，一个游戏完全可以同时具备随机性和隐藏信息，也可以只有其中一个。

Belief State：面对多个可能State，保持一个概率判断

当Hidden State存在时，Agent手里只有一个Observation，而这个Observation背后，可能对应不止一个真实State——对手的牌有若干种排列方式都能推出同一段可观察的历史。这时候一个明显不成立的做法，是从这些可能State里随便挑一个，假装它就是真实情况，然后按这个假设去搜索和决策：一旦选错，后续所有推理都建立在错误前提上，而且这个错误在搜索过程中不会自动暴露出来。更合理的做法是不去猜哪一个必然成立，而是对所有可能State维持一个概率判断，这就是Belief State的核心思想。整个流程大致可以描述成：从一组可能的Hidden States出发，结合已经发生的Observation和游戏规则，推算出一个Probability Distribution，这个分布就是当前的Belief；决策不是基于某一个假设State做出的，而是基于整个Belief做出的，Action的选择要在这个概率分布下衡量期望结果，而不是在某一个被主观选中的State下衡量。随着对局推进，新的Observation会不断到来，Belief也要相应更新，早期形成的Belief如果不随新证据修正，同样会变得不准确。

Information Set：无法被区分的一组可能状态

Information Set指的是，从Agent当前掌握的信息来看，完全无法互相区分的一组可能真实State的集合。同一个Observation之所以可能对应多个真实State，是因为Observation本身只携带了部分信息——凡是在这部分信息之外有差异、但在Agent能看到的范围内表现完全一样的State，都会落进同一个Information Set，Agent没有任何手段能在它们之间做出区分，只能依赖Belief去描述它们各自的可能性。Information Set的大小本身也是一个值得关注的量：对局刚开始时可能的真实State非常多，Information Set很大，Belief接近均匀分布；随着更多Observation到来，Information Set逐渐收缩，Belief也会向少数几个State集中，但很少能收缩到只剩一个。

正是因为搜索的对象不再是单一确定的State，而是一个Information Set加上一个Belief，面向Perfect Information设计的经典搜索方法不能直接套用。Information Set MCTS，也就是ISMCTS，是这个方向上的一类尝试，思路是把搜索树的节点建立在Information Set而不是单一State之上，在每次模拟时从当前Belief里采样出一个具体State世界，再在这个采样世界上做常规的搜索和展开，多次采样、多次模拟之后再把结果汇总回Information Set层面的统计量。但这不是一个可以套用到所有Imperfect Information问题上的万能算法：它的效果依赖Belief本身的准确程度，如果Belief因为对手行为模式变化或者建模不足而出现偏差，采样出来的世界就会系统性地偏离真实分布；同时Information Set本身可能很大，导致采样和搜索的效率下降，遇到需要精细策略混合才能不被针对的场景，单纯的采样搜索也未必能收敛到足够稳健的策略。ISMCTS解决的是如何在Information Set上做搜索这一步，它不能替代把Belief维护准确这个前提条件。

一个常见的实现失误：把Observation当成State来处理

在实际工程实现里，一个容易犯的错误，是直接把Perfect Information场景下的搜索代码套用到Imperfect Information场景，只是把输入换成Agent自己能看到的Observation，然后当成完整State来搜索。这样做的问题在于，搜索出来的策略会隐含一个不成立的假设——世界只有Observation所显示的这一种可能，任何依赖对手手中具体牌面的判断都会被这个假设污染。比如搜索过程如果需要判断对手是否可能持有某种关键牌，一个把Observation当State的实现会直接读取一个固定值，而不是在Belief给出的概率分布上做加权评估，结果往往是对某些原本应该谨慎处理的局面表现得过度自信，一旦真实State和被想当然代入的那个State不一致，决策就会出现系统性偏差。这类失误不容易在小规模测试里被发现，因为如果测试对局恰好覆盖到的真实State和默认假设State相符，问题不会暴露，只有在对手风格或者牌面分布发生变化以后才会集中显现。

先分清博弈类型，再谈"多个AI互相比赛"

Two-player Zero-sum：双方收益严格相反，一方多拿的收益，正好是对方少拿的收益，围棋、国际象棋这类经典对局都属于这一类，也是博弈论里理论工具最成熟的场景，很多经典结论最初都是在这个场景下证明的，比如通过Minimax求解可以得到一个稳定的Equilibrium Value。

General-sum放松了收益完全相反这个假设，参与者的收益可以部分一致、部分冲突，也可以完全独立。Cooperative指的是参与者共享同一个目标函数，团队赢即所有人赢，这类场景下策略研究的重点是协作效率而不是互相针对；Competitive指目标互相冲突，一方的收益提升往往对应另一方收益的下降；而现实中很多多人棋牌场景更接近Mixed Interaction：几个参与者之间可能存在临时结盟、局部合作，但整体上没有一个统一的团队目标，联盟本身也可能因为局势变化而破裂重组，一个参与者在某一阶段的最优选择，可能是配合暂时领先的另一方去限制第三方，等局势变化后立场又会反过来。这几种类型不是同一个问题的不同规模版本，而是收益结构本质不同的问题，所以不能笼统地说成多个AI互相比赛，因为比赛这个词遮盖了收益结构到底是对立、一致还是混合，而这个结构差异会直接决定该用什么样的分析工具。更准确的说法是，Multi-Agent场景里同时存在Coordination和Competition两种基本关系：Coordination指参与者之间需要对齐行动才能拿到更好结果，Competition指参与者之间的收益此消彼长，而Mixed Interaction往往是这两种关系在不同参与者对之间同时成立、甚至随时间切换的结果。

为什么多加几个Agent不是简单的规模扩大

Two-player Zero-sum博弈的很多理论结论——比如存在唯一的Equilibrium Value、Minimax结果具有良好的稳定性——大多依赖零和和双人这两个条件同时成立。一旦参与者变成三个及以上，即便还保留竞争关系，博弈也不再是简单的零和结构，Equilibrium可能不再唯一，不同Equilibrium之间给不同参与者带来的结果也可能不同，这本身就让该往哪个Equilibrium收敛变成一个新问题，而不只是更难算的问题：三人博弈里，两个较弱的参与者临时结盟对抗较强的一方，本身就可能构成一种稳定但对第三方极度不利的局面，这在两人零和博弈里根本不存在对应结构。

MARL里的Non-stationarity：环境本身在变

多智能体强化学习，也就是MARL，面对的核心结构性问题之一是Non-stationarity。单Agent强化学习通常假设，从Agent的视角看，它所处的Environment在训练过程中是基本固定的，这样它才能通过反复试错，逐步收敛到一个稳定策略。但在多个Agent同时学习的场景下，这个假设不成立：Agent A所处的Environment，除了游戏本身的规则，还包括其他Agent当前的策略；而其他Agent，比如Agent B，同样也在训练、也在调整自己的策略。这意味着，从A的视角看，即便游戏规则完全没变，它所面对的Environment也在随B的训练进度不断漂移——A上一轮学到的、看起来有效的应对方式，可能因为B在这一轮调整了打法而突然失效，A的训练曲线因此可能出现来回震荡，而不是像单Agent场景那样平稳收敛。这种对手也在学习导致的环境漂移，就是MARL里的Non-stationarity问题，它直接削弱了很多单Agent方法依赖的收敛性保证，也是为什么多智能体训练往往需要额外的机制去稳定这个过程，比如让部分Agent的策略在训练某一方时暂时保持固定。

Credit Assignment：团队拿到一个结果，但功劳该怎么分

当多个Agent共同产生一个最终结果——无论是Cooperative场景下的团队Reward，还是Mixed Interaction场景下某个联盟的最终收益——一个绕不开的问题是Credit Assignment：这个最终结果里，到底是哪个Agent、在哪一个时间步骤上、执行的哪一个具体Action，对结果贡献了多少。这个问题在时间维度和Agent维度上是叠加的：某个Agent可能在中局做了一个短期看起来吃亏的Action，实际上是为了给后续另一个Agent的关键操作创造条件，如果只按最终结果笼统地把功劳或者责任平摊给所有参与者、所有时间步骤，训练信号会变得很嘈杂，很难让每个Agent学到具体是我的哪一步做对了或者做错了，训练效率也会因此明显下降。

Joint Action Space随Agent数量膨胀

除了Non-stationarity和Credit Assignment，Agent数量本身也在直接推高问题规模：每一个决策时刻，真正影响局面走向的是所有Agent同时选择的组合，也就是Joint Action。如果每个Agent单独的Action选项有若干种，Joint Action Space的大小会随参与者数量快速增长，两人场景下还能承受的搜索或者枚举方式，扩展到四人、五人场景时会迅速变得不可行。这也是为什么把两人方法直接套用到多人博弈这个思路很快会遇到瓶颈——问题的难度不是随参与者数量线性增加，而是博弈结构从零和变为非零和、Non-stationarity、Credit Assignment和Joint Action Space膨胀这几个因素叠加在一起共同起作用的结果，每一个因素单独看都会推高难度，合在一起会互相放大。

一个具体的失败场景：把两人自我对弈的训练流程直接搬到多人

两人零和博弈的自我对弈训练，通常让一个策略持续和自己的历史版本对抗，因为在这种设定下，只要策略在稳步进步，对手的水平也在同步提升，训练目标相对稳定。但如果把同样的训练流程直接搬到三人及以上的场景，很容易出现策略震荡：三个同时训练的Agent可能会陷入互相压制、循环切换主导策略的状态，A的策略变强会促使B调整，B的调整又让C占优，C占优后A之前的策略又重新变得有效，训练曲线不再单调收敛，而是在几种打法之间循环。这本质上是Non-stationarity在多人、非零和结构下被放大的结果，处理这类问题通常需要额外机制，比如维护一个历史策略池，让训练对手不只是最新版本，而是从历史版本里采样，用来打破这种循环、稳定训练过程。

Win Rate能证明"赢了"，不能证明"为什么赢"

如果只用Win Rate去评价一个棋牌大模型的战略推理能力，会遇到一个基本问题：胜率是一个高度聚合的结果，它把很多互相独立的因素揉在了同一个数字里——对手池本身的强弱和风格分布、样本量是否足够、对局是不是恰好没有触发模型的规则理解漏洞、对手有没有能力抓住模型的战略失误。两个模型可以拿到接近的Win Rate，但产生这个结果的原因可能完全不同：一个是真的在规划、在预判对手、在执行连贯的多轮计划；另一个可能只是在每一步做局部还不错的选择，遇到的对手也没有能力惩罚它的战略漏洞，所以侥幸没有暴露问题。仅从最终胜负出发，没办法区分这两种情况，如果换一批风格不同、水平更高的对手，两个模型的表现很可能出现明显分化。

一个真正的战略推理评测，至少要拆开检查这几件事

要判断一个模型是不是真的具备Strategic Reasoning，需要把评测拆解成一系列更具体的问题，而不是只看结果。首先是Rule Adherence，也就是模型是不是真正理解规则——它给出的Action是不是始终合法，会不会出现因为误解规则而做出的无效或者次优选择。其次是State Tracking，模型在多轮交互之后，是不是仍然准确掌握当前局面的完整信息，还是已经出现了信息丢失或者记错，比如误记了之前已经发生过的关键事件。第三是Planning Depth和Foresight，模型的决策是基于对后续若干步走势的推演，还是只是在对当前这一步做局部判断，一个只做单步判断的模型即便每一步看起来都合理，串起来也未必构成一个连贯的计划。第四是Opponent Awareness，模型有没有对Opponent接下来可能的反应做出预判，并把这个预判纳入自己的决策，而不是把对手当成一个固定不变的背景。第五是Long-term Memory，在一局比较长、经历了多轮交互之后，模型是不是还记得自己最初设定的战略目标，还是决策已经逐渐偏离最初的方向而不自知。第六是Decision Consistency，模型前后几轮的决策逻辑是不是连贯一致，还是出现了自相矛盾的选择。最后还要检查Generalization，也就是这些能力是不是只在训练或者测试时见过的局面下才成立，换一个新的局面结构或者新的对手风格，这些能力还能不能保持，这一条常常是区分表面上会下棋和真正具备策略推理能力的分水岭。

用Multi-axis Strategy Evaluation取代单一分数

把上面这些维度拼在一起，可以设计成一个Multi-axis Strategy Evaluation，至少包含Rule Compliance、State Tracking、Planning、Opponent Awareness、Long-term Memory、Decision Consistency、Generalization、Final Performance这几个轴，每个轴分别打分，而不是把所有维度压缩成一个总分。这类多维度结果适合用Radar图、Matrix或者Scorecard的形式呈现：Radar图可以直观看出一个模型的能力轮廓是均衡型还是偏科型；Matrix适合同时对比多个模型在同一组维度上的表现；Scorecard则更适合逐项列出具体的评测细节和失败案例，方便定位问题出在哪一步。举例来说，如果两个模型的Final Performance接近，用这种方式拆开以后，可能会发现一个模型在State Tracking和Rule Compliance上表现稳定，但Long-term Memory偏弱，容易在长局里逐渐偏离最初目标；另一个模型规划能力更强，但Opponent Awareness不足，容易被对手的非常规打法针对。需要说明的是，这里如果给出任何具体分数，都只是用来说明呈现方式的示例数据，不代表某个真实模型的实际评测结果，实际评测结果必须建立在具体的评测集和对局样本之上，不能拿示例数字当成真实结论引用。

Reasoning-Action Gap：说得对，不代表做得对

除了以上这些维度，大语言模型作为Strategic Agent还会暴露一个更特殊的问题，就是Reasoning-Action Gap。这类模型通常会先输出一段文字形式的推理过程，再给出具体的Action，而这两者之间并不天然保证一致。一个常见的失败场景是：模型在推理文本里清楚地写出当前应该优先保护某个关键区域，这段分析单独看逻辑完全合理，甚至能说明它对局面的判断是准确的，但紧接着输出的实际Action，却是离开这个区域，或者做了一个和刚才这段推理明显矛盾的操作。这说明一个模型能够生成合理的Reasoning，不代表它最终执行的Action真的遵循了这段Reasoning——Knowing，也就是知道应该怎么做，和Doing，也就是实际上真的这样做，之间是可以脱节的。

这个问题之所以值得单独强调，是因为它很容易被忽略：如果评测只看模型的文字解释，会得到这个模型战略理解很到位的印象；如果只看最终的Action序列，又可能没有意识到问题出在Reasoning和Action没有对齐，而不是Reasoning本身有问题。因此，评估一个模型的Reasoning-Action Consistency，应该把推理文本和实际输出的Action逐步对照检查，看模型有没有真正执行自己刚才提出的计划，而不是分别孤立地评价它说得对不对和它最后赢没赢。一个模型解释得非常合理以后，下一步该做的，正是去检查它的实际Action有没有执行它刚才的计划，这也是把Reasoning-Action Consistency和Generalization放进同一个评测框架里的原因——一个只在训练分布内对齐良好、换个场景就脱节的模型，同样不能算真正具备战略推理能力。具体到工程实现上，一个可行的检查方式，是在每一步决策时把模型输出的Reasoning文本和它选择的Action分别记录下来，用规则或者另一个模型去检查两者是否指向同一个方向，一旦发现大量不一致案例，往往说明问题出在Action生成环节没有真正依赖前面的Reasoning，而不是Reasoning本身写得不好。