简介：基于深度强化学习的德州扑克AI算法优化项目，面向计算机、电子信息工程、数学等专业的高校学生，可作为课程设计、期末大作业或毕业设计的参考资料。项目以不完全信息博弈为场景，重点展示强化学习算法在策略决策中的建模与优化思路。压缩包为zip格式，共165个文件，约13.96MB，含58个py源码文件、48个pth模型权重文件、18个txt说明文件、18个csv训练记录、16个pkl数据文件及若干json配置等，目录结构清晰。目前已有325人学习浏览。除完整Python实现与项目说明文档外，还附带训练好的模型权重，可直接加载运行或继续优化；csv与pkl文件记录了训练中的性能变化与中间结果，有助于复盘调参思路、分析收敛情况，对复现或改进德州扑克AI算法具有较强参考价值。

1. 从随机决策到策略收敛：这份德州扑克 AI 源码到底改了什么

很多人下载德州扑克 AI 项目，第一件事就是拉去和电脑对打，赢了几把就以为算法跑通了。这个项目如果只拿来玩，就亏了。它不是一个能让你在牌桌上稳赢的“作弊器”，而是一套完整的深度强化学习训练系统：从牌局状态提取、动作离散化、奖励塑形，到 DQN 网络更新、经验回放、目标网络同步，再到自博弈式训练闭环，源码里全都有。适合三类人：做毕业设计需要完整工科闭环的学生、想入门深度强化学习但不想只跑 CartPole 的开发者、以及想在有限时间里把 DQN 调出真实博弈效果的算法爱好者。

这套代码的价值在于，它把德州扑克里最麻烦的部分——不完整信息博弈——变成了一个可训练、可复现、可观察收敛过程的工程任务。你从这份资源里能拿到的，不只是会打牌的模型，而是一套“怎么让智能体在决策边界模糊的场景里学会策略”的范本。

2. 先建模再训练：状态特征、动作空间与回报函数的设计

2.1 特征工程是这套 AI 的第一道分水岭

德州扑克不像围棋，棋盘信息完全可见。玩家只能看到自己的两张底牌和公共牌，对手的牌是隐藏的，还涉及加注、弃牌、诈唬等心理博弈。如果把原始牌面直接丢给网络，模型根本学不会。这个项目把每轮牌局的状态提取成一组固定维度的向量，我在阅读源码时梳理了核心特征组合：

• 手牌强度：基于两张底牌评估的初始牌力分数，归一化到 0~1
• 底池比例：当前底池与玩家筹码量的比值，反映风险敞口
• 街位信息：当前是翻牌前、翻牌、转牌还是河牌，用 one-hot 编码
• 对手动作历史：最近 N 轮对手的加注、跟注、弃牌行为的统计特征
• 玩家自身筹码量：绝对值和相对底池的比例，用于控制激进程度

特征维度在 20~40 之间，具体取决于历史窗口长度。这样设计的好处是，把一局牌的动态过程压缩成一个固定形状的张量，网络输入层就不需要处理变长序列，整体训练效率提升明显。特征归一化是这套代码比较细致的地方，所有特征在进网络前都经过 min-max 或者 z-score 处理，避免某一维数值过大导致梯度震荡。

2.2 动作空间裁剪：为什么不是所有合法动作都保留

德州扑克每轮合法动作数量很多，尤其是加注，可以加任意数量筹码。如果动作空间是连续的，DQN 根本没法直接输出 Q 值。这个项目对动作空间做了离散化裁剪，源码里常见的是把动作分成四类：

# 动作空间定义示例 ACTION_FOLD = 0 # 弃牌：放弃本轮，损失已投入的筹码 ACTION_CHECK = 1 # 过牌：不追加筹码，等待下一家动作 ACTION_CALL = 2 # 跟注：匹配当前最高下注额 ACTION_RAISE = 3 # 加注：按底池比例增加下注（如 0.5 倍底池）

代码逻辑不难理解，但关键在参数敏感性。加注比例如果设成固定值，模型容易在激进和保守之间跳变；如果设成动态倍数区间（比如 0.5~2 倍底池之间随机选择），训练出的策略会更平滑。我自己的经验是，离散动作空间宁多勿少，但每多一个动作，网络输出维度就加一，训练所需样本量也成倍上涨。项目里默认的四动作方案是在收敛速度和策略表达力之间取平衡的做法。

2.3 回报函数：只赢底池不够，关键是抗风险

如果只是“赢了给正奖励，输了给负奖励”，模型会陷入一种局面：拿到好牌就疯狂加注，拿到烂牌就弃牌，完全不考虑诈唬和试探性跟注。这套代码的回报函数写得相对精细，它会综合底池变化、对手筹码消耗、牌局阶段三个因素来设定即时奖励，而不是单纯用胜负结算。

奖励塑形是这套项目的核心亮点之一。源码里会把“从对手弃牌中赢下的底池”和“从摊牌中赢下的底池”分开计算，后续你会看到这样分锅对策略风格的收敛很重要。另外还加了一个小惩罚项，用于抑制每局无意义的频繁加注，这在自博弈阶段非常关键——没有惩罚机制的话，两个 AI 会互相试探到天荒地老。

3. 让 DQN 真正跑起来：训练主循环、经验回放与目标网络细节

3.1 训练主循环拆解：每一步在做什么

项目核心训练脚本采用的是 DQN 的标准流程，但加了自博弈（Self-Play）的变体。训练主循环大致是：当前策略模型与历史策略池中的对手模型对局，对局过程中产生的状态转移数据存入经验池，再从中采样小批量更新当前网络。整个过程反复迭代。

# 训练主循环核心逻辑（简化版） for episode in range(total_episodes): state = env.reset() # 初始化一局牌，获取初始状态 while not episode_done: # epsilon-greedy 策略：前期多探索，后期多利用 action = select_action(state, epsilon) next_state, reward, done = env.step(action) store_transition(state, action, reward, next_state, done) if len(replay_buffer) > batch_size: batch = replay_buffer.sample(batch_size) loss = update_q_network(batch) # 计算 TD 误差并反向传播 if episode % target_update_freq == 0: sync_target_network() # 每 N 局同步一次目标网络 state = next_state epsilon = max(min_epsilon, epsilon * epsilon_decay)

这段代码是项目的骨架。select_action里用到的 epsilon-greedy 有两种常见实现：线性衰减和指数衰减，这个项目使用的是指数衰减，权重更新更平滑但前期探索充分度稍低。store_transition写入的是五元组，可以用deque维护固定容量，满了就覆盖最旧数据。update_q_network是核心计算部分，下面单独展开。

3.2 优先经验回放不是配角：它决定了收敛速度

项目采用的经验回放机制值得单独说。普通的 DQN 用均匀采样，但扑克局里大量数据是“平淡无奇”的——没什么大底池、没什么惊险抉择，这类数据对学习帮助有限。这套代码用了优先经验回放（Prioritized Experience Replay, PER），即每个转移样本带一个优先级权重，TD 误差越大，下次被采样到的概率越高。

# 优先经验回放采样逻辑 class PrioritizedReplayBuffer: def __init__(self, capacity, alpha=0.6): self.buffer = deque(maxlen=capacity) self.alpha = alpha # 优先级指数，0 为均匀采样，1 为完全按优先级 def push(self, transition, td_error): priority = (abs(td_error) + 1e-6) ** self.alpha self.buffer.append((transition, priority)) def sample(self, batch_size, beta=0.4): # 按优先级概率抽样，beta 用于重要性采样权重修正 probs = [p for _, p in self.buffer] total = sum(probs) probabilities = [p / total for p in probs] indices = random.choices(range(len(self.buffer)), probabilities, k=batch_size) return [self.buffer[i][0] for i in indices], indices

这里alpha参数决定优先级的影响力，beta是重要性采样权重，用来修正因为非均匀采样带来的估计偏差。新手最容易踩的坑是把alpha拉到 1.0 之上，导致某些 TD 误差大的样本被反复采样，网络陷入局部震荡。我一般习惯设在 0.6 左右，跑 2 万局之后逐步调高。

需要说明的是，td_error本身就是计算 Q 值更新时附带得出的中间量，并不需要额外算一遍，所以 PER 带来的计算开销很小。这个项目在这一点上做得比较干净，值得学习。

3.3 目标网络同步频率与学习率：两个超参数决定成败

DQN 里最经典的 hack 是目标网络（Target Network）。如果更新 Q 值用的还是当前网络的预测值，就会出现“自己追自己尾巴”的问题，训练震荡极其剧烈。项目的做法是维护一个结构完全相同但参数延迟同步的网络，每target_update_freq步把当前网络权重复制过去。

# 目标网络同步逻辑 if episode % target_update_freq == 0: target_net.load_state_dict(policy_net.state_dict())

target_update_freq设太小，目标网络更新的太快，会退化成没有目标网络，训练不稳定；设太大，目标 Q 值过于陈旧，收敛变慢。参数设置的常见区间是每 500~2000 局同步一次，对应到每步更新频率在 mm 数量级。我在跑这个项目时习惯的做法是：先固定学习率为 0.0001（Adam 优化器），跑 5000 局观察 loss 曲线，如果 loss 波动范围超过 0.05，再调小学习率或调大同步频率。

4. 避坑与优化：自博弈滞后、奖励爆炸与评估陷阱

4.1 自博弈训练范式：为什么 AI 和 AI 打容易跑偏

这个项目采用了自博弈训练，即当前策略会和它自己的历史版本对局。自博弈让模型越来越适应对手的行为模式，训练出的策略往往非常锋利，但也容易“钻空子”——比如发现某种固定套路能稳定战胜历史弱对手后，策略会朝那个方向过度收敛，而不是学习通用打法。源码里对此的常见处理是维护一个历史对手池，每次随机抽取一个对手来对局，而不是只和当前最新策略打。

这套代码里，历史策略池的容量和替换策略是控制收敛质量的旋钮。策略池太大，训练速度变慢；太小，又容易退化到“只针对当前自己”的扎堆博弈。我跑出来的经验是，池子容量设为 8~16 个历史版本、每 500 局替换一次为当前策略，效果比较稳健。如果你的目标是毕业设计展示，不需要“打出最强风格”，就采用更保守的设置，展示稳定收敛的曲线。

4.2 奖励数值漂移与梯度爆炸的观察方法

训练深度强化学习模型，最怕的就是 loss 曲线炸掉或奖励数值越跑越大、没有上限。德州扑克的奖励范围本来就是可正可负的，如果奖励塑形系数没控制好，模型会疯狂挖掘奖励漏洞，出现“每次翻牌前都全下”的极端策略。这个项目的一个隐蔽坑点就在这里：由于自博弈，对手的筹码结构也在变化，同一手牌的绝对奖励数值在不同训练阶段含义完全不同。

解决思路在源码的 reward normalization 部分有体现：把每个 episode 的总奖励除以一个滑动平均的参考值，让模型学习的是“相对好坏”而不是“绝对数值”。如果你跑出来的 reward 曲线在 2 万局后还在持续爬升、没有任何收敛迹象，大概率是奖励塑形里没有做归一化，或者学习率偏大。先停掉训练，把 reward 归一化打开再跑。

4.3 常见踩坑记录：现象、原因、解决

• 现象：训练 loss 持续下降，但同一玩家跟 AI 对打时 AI 表现毫无进步，甚至变蠢。原因：奖励被归一化后，模型学会了最大化相对优势，而非赢得真实牌局。自博弈对手池中整体水平也在提升，但绝对胜率并没有提高。解决：定期在训练过程中冻结当前策略，和一组固定难度的基线对手（比如随机策略、保守策略）做离线评估，用外部胜率作为真实指标，而不是只看内部 loss。

• 现象：程序报错IndexError: index out of range，集中在特征提取模块。原因：某局牌对手数量不足或底牌序列异常，导致历史动作窗口的长度无法填满特征向量。解决：在特征提取函数入口处加断言，检查动作历史长度是否达到history_length参数的最小值；不足时用 0 向量补齐，而不是截断或跳过。

• 现象：GPU 利用率极低，训练大部分时间都在等待。原因：训练主循环里env.step是同步串行执行的，一局牌模拟完成才产生一批数据，GPU 只能间歇性工作。解决：改造为多环境并行采样，或者减少单局模拟的等待时间。改动量不大，核心是把env.step封装进multiprocessing池子，用apply_async收集结果。

• 现象：模型下载后加载权重直接报错，state_dict键名不匹配。原因：PyTorch 版本差异导致网络层命名不同，或者模型文件是用 GPU 训练、在 CPU 上加载时缺少map_location参数。解决：加载时统一加model.load_state_dict(torch.load(path, map_location='cpu'))，并对比网络构造函数与保存文件的键名。这个坑基本是版本问题引起的，建议跑之前先打印权重文件里前三个键名核对。

5. 把模型部署到对局测试：离线评估与策略导出路径

训练完的模型不能只在训练脚本里自嗨，要验证它到底有没有学到东西，最快的方法是写一个独立的评估脚本，让训练好的策略与固定策略打几百局，统计胜率和平均底池收益。这个项目的模型保存通常包含两个文件：策略网络权重和优化器状态，权重文件可以直接加载到评估脚本里推理。

# 离线评估核心代码 model = DQN(state_dim, action_dim).to(device) model.load_state_dict(torch.load('best_model.pth', map_location='cpu')) model.eval() # 关闭 dropout 和 batch norm 的统计更新 win_count = 0 chip_diff_total = 0 for i in range(500): final_chips = evaluate_one_round(model, opponent='random') chip_diff = final_chips - initial_chips chip_diff_total += chip_diff if chip_diff > 0: win_count += 1 print(f"胜率: {win_count / 500:.2%}, 平均筹码差: {chip_diff_total / 500:.1f}")

评估脚本写好后，可以多跑几个固定策略做对比，比如随机策略、保守策略（只跟注不加注）、激进策略（拿到好牌全下）。我实践下来发现一个很反直觉的现象：训练好的模型对随机策略的胜率往往不是最高的，反而是对激进策略的胜率最高——因为激进策略会频繁送筹码。如果你用随机策略做基线，胜率数字可能不好看，但模型本身是没问题的，所以评估基线的选择要谨慎。

如果要进一步把这个模型用到其他对局环境中，需要把模型推理逻辑从训练脚本中剥离。目前这份资源的模型输出是四种动作的 Q 值，只要在外部环境里把环境的状态转化为同样的特征向量格式，就能解释模型的输出；hard coding 的加注幅度参数也需要检查，因为外部规则可能不允许 0.5 倍底池的加注。我一般会写一个interact.py脚本，把模型封装成一个纯函数：输入特征向量，输出动作索引，这样就彻底解耦了训练和部署。

我吃过亏的地方在于：模型在训练环境里跑得风生水起，换到规则稍有不同的环境里就完全失效——后来才发现是特征编码里的“底池比例”计算方式变了，底池包含的筹码口径不同，模型看到的输入和训练时完全不是一回事。从那以后，我每次评估都会强制先在环境接口层面过一遍特征向量对比代码，确保训练和推理走的是同一套编码逻辑，再谈胜率和收益。这份资源的好处就在于特征提取代码是完整封装好的，直接调用、别自己重写，就不会踩这个坑。希望帮到你。

本文还有配套的精品资源，点击获取