简介：一套基于深度学习和蒙特卡洛树搜索的围棋机器人Python源码，面向计算机相关专业毕业设计、课程设计和期末大作业场景，也适合需要项目实战练习的学习者。项目融合深度神经网络与蒙特卡洛树搜索，代码完整、经过导师指导并获评99分，结构清晰，可直接运行或作为二次开发基础。压缩包共96个文件，以56个Python脚本为核心，覆盖agent、go、game、train等模块；辅以JSON配置、C/C++扩展、Markdown说明等，分别承担参数管理、性能加速、使用说明等用途。整体约183KB，小巧易部署。已有74人学习或下载。内容包含各功能模块完整源码、神经网络训练与数据加载脚本、命令行与UI交互界面，并提供README说明文档，方便理解项目架构与运行流程。无论是用于毕设展示还是算法学习，都能获得一套可直接演示、继续扩展的完整工程。
1. 为什么围棋机器人把深度学习和蒙特卡洛树搜索绑在一起
19 路围棋的合法局面数远超过可观测宇宙的原子数，任何程序想靠“把所有变化算完”来下棋，局面复杂度会先一步把内存和 CPU 全部拖垮。真正让围棋 AI 从“能下”到“下得像人”的转折点，是 2016 年 AlphaGo 把深度神经网络塞进蒙特卡洛树搜索（MCTS）的搜索回路：神经网络负责压缩局面判断和走子倾向，MCTS 负责在这些概率估计之上做有方向的长线模拟。这种组合直接绕开了显式暴力搜索，也绕开了手写棋形的规则库。
这份标题里的 Python 源码，层面大致是复刻 AlphaGo Zero 的简化工程版本：既包含 CNN 策略网络和价值网络，也包含 UCB 公式驱动的蒙特卡洛树搜索，以及把两者串起来的人机对弈入口。适合的人群很明确：懂一点 Python、想弄清“深度学习和搜索算法如何协作”的开发者，或者做过目标检测但没碰过博弈树的读者。不必期待它具备职业棋力，核心价值在于代码能把“策略先验 + 搜索权衡”这条主线完整演示出来。
2. 从围棋机器人 Python 源码看懂棋盘、策略网络与 MCTS 的边界
2.1 先找到源码里三块互不打扰的代码：棋盘表示、网络推理、树搜索
到手一个名为“基于深度学习和蒙特卡洛树搜索的围棋机器人”的 Python 源码压缩包，解压后第一件事不是急着装依赖，而是扫一眼文件划分。这类工程无论原作者怎么起文件名，核心模块几乎都逃不开三类职责：第一类是围棋规则本身，包括棋盘、提子、劫争、胜负判定；第二类是神经网络定义与推理接口，负责把“当前局面”变成“策略概率 + 胜率估计”；第三类是蒙特卡洛树搜索的主体，负责选择、扩展、模拟、回溯四个步骤。
如果源码把它全塞进一个 play.py，读起来会非常吃力；我一般会把代码整理成下面这样再继续看：
# 常见目录划分 go/ go.py # 棋盘与落子规则，含提子和禁着点判断 features.py # 将棋盘局面编码为神经网络的输入张量 network.py # 策略网络 + 价值网络定义，PyTorch 实现 mcts.py # 蒙特卡洛树搜索节点与完整搜索流程 selfplay.py # 自我对弈数据生成，用于后续训练 play.py # 命令行人机对弈入口逻辑说明：棋盘规则文件不应该 import 模型文件，否则一旦你想换一种网络结构，会连规则代码一起改动。MCTS 只依赖两个外部接口，一是“给定局面返回策略概率”，二是“给定局面返回价值估计”，而不是直接操作 pytorch 权重。这样分层的好处是能分别测试规则、网络和搜索：先用纯规则做落子合法性校验，再随机权重跑一次树搜索，最后才接上训练好的权重。
参数说明：上面的“go/”只是一个示意目录名，实际源码里可能是“board.py”“policy.py”这样的名字，但你不必被文件名捆住，按功能的单向依赖关系去找即可。判断标准只有一个：如果从 mcts.py 里能看到 CNN 的卷积核尺寸，说明模块边界已经污染了。
2.2 棋盘状态用 1/0/2 表示，合法落子位置必须生成掩码
围棋盘面最小的表示方法是一个二维数组，0 表示空，1 表示黑子，2 表示白子。很多初学者会在这一步把棋盘直接塞给神经网络，但神经网络不关心“提子”“眼”“劫”这些语义；它只关心固定形状的输入张量。因此源码里通常会有一个独立函数，把棋盘翻译成多个特征平面。
下面这段代码是棋盘类的简化骨架，重点看“合法动作掩码”的生成方式：
class GoBoard: def __init__(self, size=19): self.size = size self.board = [[0] * size for _ in range(size)] self.current_player = 1 # 1 黑，2 白 def legal_mask(self): mask = [] for r in range(self.size): row = [] for c in range(self.size): # 这里应检查自填、打劫、重复局面等规则 row.append(1 if self.board[r][c] == 0 else 0) mask.append(row) return mask逻辑说明：legal_mask输出的二维 mask 会让 MCTS 把所有合法落点统一处理。树搜索选择节点时，会对 mask 为 0 的位置做概率重归一化，保证强先验不会推荐一个已经不能落子的坐标。
参数说明：current_player必须显式记录，因为神经网络的输入特征里要有“当前执黑还是执白”的通道；如果只靠棋盘里的棋子颜色判断，类似“黑白两边同样形状但轮到谁走”的镜像局面会让网络输出完全不同的策略，不加这一维特征网络根本分不清先后手。
2.3 深度网络吃进 17 张特征图，吐出让树搜索参考的概率
AlphaGo Zero 使用的围棋输入是 8 个过去局面叠加成 17 层特征图，每层都是 19×19：当前局面之前 8 步中，每步用两层分别表示我方棋子和对方棋子，第 17 层是一个全 1 的当前执子方通道。PyTorch 版本里网络定义大致长这样：
import torch import torch.nn as nn class PolicyValueNet(nn.Module): def __init__(self, board_size=19, num_planes=17): super().__init__() self.conv = nn.Sequential( nn.Conv2d(num_planes, 32, kernel_size=3, padding=1), nn.BatchNorm2d(32), nn.ReLU(), nn.Conv2d(32, 64, kernel_size=3, padding=1), nn.BatchNorm2d(64), nn.ReLU() ) self.policy_head = nn.Conv2d(64, 1, kernel_size=1) self.value_head = nn.Conv2d(64, 1, kernel_size=1) def forward(self, x): x = self.conv(x) policy = torch.tanh(self.policy_head(x)).view(x.size(0), -1) value = torch.tanh(self.value_head(x)).view(x.size(0), -1) return policy, value逻辑说明：policy输出维度是网络输出层的节点数，等于 19×19 再额外加一个 Pass。MCTS 选择子节点时读的是 softmax 之后的先验概率，而value是标量胜率，范围被tanh限制在 -1 到 1 之间。要注意的是，BatchNorm2d在推理模式下会使用训练阶段累积的均值方差，所以加载权重后必须调用model.eval()，否则树搜索每次前向推理的数值都不稳定。
参数说明：上面简化网络把value展平成N×1，实际工程里更常见的是先做全局平均池化再接全连接层。你不需要改num_planes，除非源码用的是 AlphaGo 原版而非 Zero 版本；原版里还要加入手工灵魂特征和当前局面特征，特征平面数量会超过 40。
2.4 UCB 公式怎么写才是“蒙特卡洛树搜索”不是随机下棋
蒙特卡洛树搜索的核心是选择性忘掉“均匀随机模拟”的旧套路，改成按 UCB 类公式选择节点。围棋机器人的实现一般遵循下面的公式：
import math def ucb_score(parent_visits, node_visits, win_rate, prior, c_puct=1.4): return win_rate + c_puct * prior * math.sqrt(parent_visits) / (1 + node_visits)逻辑说明：win_rate是当前子节点累计价值估计，数值越接近 1 代表这个分支越被看好；prior是深度学习策略网络给出的先验概率，负责把搜索引向“人类看起来合理”的位置。c_puct控制探索强度：值越大，越倾向于尝试先验概率高但访问次数还很少的点；值越小，越倾向于追着当前胜率最高的点猛挖。
参数说明：这里的node_visits在分母位置加了 1，是为了避免新节点访问次数为 0 时出现除零错误。实际搜索中每个节点的胜率往往被存储为“当前执子方视角”而不是“根节点执子方视角”，否则回溯时会漏掉“换手”的一层正负号。
从工程角度，你读源码时应先确认 MCTS 节点类里有没有累计visit_count和total_value两个字段。如果只有 visit_count 而没有 total_value，那它在回溯时一定用了某种增加式更新方式，两种写法都成立，但排查价值时前者更直观。
class MCTSNode: def __init__(self, parent=None, prior=0.5): self.parent = parent self.prior = prior self.children = {} self.visit_count = 0 self.total_value = 0.0这段节点结构说明：访问次数增长由回溯阶段驱动，每次走到叶子节点并完成一次模拟后，从根节点到该叶子路径上的每个节点都会把visit_count加 1，同时把叶子节点的价值加到total_value。下一步选择子节点时，win_rate = total_value / visit_count。
3. 把源码跑在本地：从 Python 环境配置到最小对弈命令
3.1 深度学习环境配置：先装 torch 还是先装 numpy？
拿到此类源码后最常见的失败点是环境冲突，而不是算法代码错误。源码里凡是写“基于深度学习”的围棋项目，基本都要用 PyTorch 或 TensorFlow；如果电脑里已经有 TensorFlow，再装一个 PyTorch 往往能共存，但 CUDA 版本不同会导致某一套无法调用 GPU。更稳妥的做法是新建独立虚拟环境，把深度学习依赖全部隔离在里面。
python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install numpy torch pip install gym # 仅当源码需要环境接口时才需要，可先跳过命令逻辑说明：python -m venv用当前解释器创建虚拟环境，激活后所有包都装到项目.venv目录里，不影响系统 Python。torch会自动带 numpy 依赖，但显式安装 numpy 可以避免源码里用np.random时因为 torch 依赖版本不一致出现小版本错误。
参数说明：如果你没有 NVIDIA GPU 或不想折腾 CUDA，千万别直接跑默认的 pip install torch 再抱怨它把 2GB 下下来。常见做法是先确认 PyTorch 官方安装命令，CPU 版一般用pip install torch --index-url https://download.pytorch.org/whl/cpu这样的显式 CPU 渠道，避免安装带 CUDA 的预编译包后加载失败。装完后用python -c "import torch; print(torch.__version__)"验证，这一步能过滤掉超过一半的环境配置问题。
3.2 加载训练好的权重，把局面变成概率
源码里通常会给一个model.py或者network.py来定义网络结构，权重文件常见的扩展名是.pth、.pt或.pth.tar。权重加载的坑在于 PyTorch 的torch.load默认会把张量绑定到原来的设备，比如在训练机上保存的对象类型可能是 GPU tensor，换到无 GPU 的机器上就报 “Attempting to deserialize object on a CUDA device”。我要在推理入口加一句map_location="cpu"：
import torch import torch.nn.functional as F def load_network(path, board_size=19): model = PolicyValueNet(board_size=board_size) state = torch.load(path, map_location="cpu") if "state_dict" in state: state = state["state_dict"] model.load_state_dict(state) model.eval() return model def policy_inference(model, board_tensor): with torch.no_grad(): logits, value = model(board_tensor.unsqueeze(0)) probs = F.softmax(logits, dim=1).squeeze(0) return probs, value.item()逻辑说明：board_tensor.unsqueeze(0)把一个 17×19×19 的特征张量变成 1×17×19×19，这个批维是 CPU/GPU 一次性算多个局面时预留的。torch.no_grad()关闭自动微分图，树搜索在一次对局里往往要跑几百上千次前向推理，开着 grad 会让显存持续堆积，速度也会掉一个量级。
参数说明：load_state_dict要求模型结构严格匹配权重里的层名。如果加载时报 unexpected key 或 missing key，优先怀疑的是源码网络定义文件与权重不匹配，而不是权重损坏。常见做法是打印 state dict 的 key 列表和模型 named_parameters 的 key 列表做 diff，两个列表完全一致再继续排查。
3.3 从终端开始一局人机对弈：最小启动命令
确认权重能加载后，不要急着点训练，先跑一局人机对弈看整条链路是否通。源码里的入口文件名不确定，但命令行参数基本围绕“棋盘大小、搜索次数、是否用 GPU、PASS 规则”这几个方向设计。一个比较通用的启动命令如下：
python play.py --board-size 9 --ai mcts --playouts 1000 --temperature 0.1命令逻辑说明：--board-size 9先在小棋盘上验证，因为 19 路的搜索宽度会让单次playout时间不可接受。--playouts 1000指每回合蒙特卡洛树搜索从根节点向下模拟 1000 次，它几乎成正比地关系着单步思考时间。--temperature 0.1是根节点采样温度，温度越低越倾向选访问次数最高的点，适合验证“AI 是否真的在按策略走”。
如果源码没有命令行参数，也不要慌，直接改play.py里的全局常量即可。我一般会先搜索文件顶层有没有BOARD_SIZE、N_PLAYOUTS、TEMPERATURE之类的赋值，把它们改成上面同样的值。接下来你只需要按提示输入坐标，比如a1或H8，就能看到策略网络和 MCTS 一起工作的效果。
3.4 用自对弈生成数据检查代码路径是否完整
人机对弈只能验证界面层，真正考验“深度学习 + 蒙特卡洛树搜索”耦合是否正确的是自对弈脚本。自对弈会反复执行“MCTS 选点 -> 落子 -> 收集训练样本 -> 终局判分”这一循环；如果这个循环跑不出合法 SGF 文件，那么后续无论你调什么参数都白搭。
python selfplay.py --games 5 --simulation 200 --record sgf_output命令逻辑说明：--games 5先生成 5 盘棋，每盘棋会分别执行数次甚至数十次棋盘前向推理。--simulation 200可以设置得比人机对弈低很多，因为自对弈只是验证模块回路，不需要下得很强。--record sgf_output把对局记录输出到目录，之后你可以用第 5 章里的回放脚本逐手检查落子是否合法。
如果自对弈在第二步就报IndexError，十有八九是策略网络输出的概率向量长度和棋盘坐标映射不一致：网络输出 361 个概率，但代码里用np.argmax之后除以 19 得到坐标时忘了 P451 维。正确的做法是把概率 reshape 成 19×19，再与合法动作 mask 相乘。这也是整个源码里最容易出 bug 的地方之一。
4. 调参优化：让源码里的 MCTS 和深度学习互相配合
4.1 MCTS 的三个必调参数：c_puct、playouts、temperature
运行起来之后，源码里的棋力瓶颈往往不在网络本身，而在 MCTS 的采样策略。下面三个参数是必须看懂的，也是你拿去跑不同规模棋盘时最常改的：
| 参数 | 常见默认值 | 作用 | 调低/调高后的表现 |
|---|---|---|---|
| c_puct | 1.4 | 控制先验概率与访问频率的平衡 | 调低后搜索趋向“只走胜率高的点”，调高后会尝试更多新变化 |
| playouts | 800 到 1200 | 决定每次落子的搜索深度 | 调低后每步很快但棋感粗糙，调高后更准但耗时线性增长 |
| temperature | 开局 1.0，终局 0.1 | 控制根节点采样随机性 | 调高会让开局更分散，调低会让终局更确定 |
在黑白双方都不敢贸然动手的布局阶段，传统命令行程序会用温度采样来增加多样性。代码一般会写在 MCTS 返回落子结果的时候：
def choose_action_by_temperature(root, temperature): visits = [] children = list(root.children.values()) for child in children: visits.append(child.visit_count) visits = np.array(visits, dtype=np.float64) if temperature < 1e-8: action = int(np.argmax(visits)) else: wins = visits ** (1.0 / temperature) probs = wins / wins.sum() action = np.random.choice(len(children), p=probs) return action逻辑说明：temperature降到接近 0 时，直接用argmax选访问次数最多的点，此时不需要考虑随机采样，也能避免1/temperature溢出。temperature比较高时，访问次数先做指数缩放再归一化成概率，这样做既能保留“访问次数多的点更可能被选”的倾向，又不会让所有对局都走同一条路线。
参数说明：有些源码里的temperature是 float，传成整数0会直接触发1/0的除零错误。我在写这种函数时一般会加if temperature < 1e-8的防御判断，而不是直接判等于 0。
4.2 给根节点加 Dirichlet 噪声，不然强先验会让树搜索变成策略网络复读机
深度网络策略一旦训练成熟，它的概率分布会非常尖锐：某些局面下 90% 的概率都集中在同一个落点。如果 MCTS 初始根节点的 prior 直接用这个概率，搜索会很快收敛到单一方向，完全失去“探索其他可能变化”的能力。AlphaGo Zero 论文里用的办法是给根节点先验加 Dirichlet 噪声：
def add_dirichlet_noise(root, child_priors, alpha=0.03, epsilon=0.25): noise = np.random.dirichlet([alpha] * len(child_priors)) for i, child in enumerate(root.children.values()): child.prior = (1 - epsilon) * child_priors[i] + epsilon * noise[i]逻辑说明：alpha控制噪声分布的集中程度，19 路围棋常用0.03，当棋盘缩小到 9 路时，常数需要按棋盘点数缩放，否则噪声会在过小的棋盘中产生过大扰动。epsilon表示原始先验被替换的比例，0.25 的含义是“整体分布的 25% 来自随机噪声，75% 来自策略网络”。
参数说明：Dirichlet 噪声只在根节点加，不要加到中间层节点。因为中间层节点代表“假设已经走到的局面”，它的先验需要用来刻画“黑方在已知局面下的正确策略”，不需要再用随机扰动来制造多样性。这个区分也是检查自己实现是不是“AlphaGo Zero 式”的关键点。
4.3 推理放 GPU 还是 CPU？先解决四个常见的“慢”来源
很多人在源码里把 playouts 调到 2000 以后，发现每步棋要思考 30 秒以上。先用推理代码里是不是做了没有必要的开销，再决定上不上 GPU。我遇到的四个主要慢来源如下：
第一，没有关掉自动求导。只要 inference 阶段没有torch.no_grad()，每一次前向都会构建计算图，CPU 推理时间直接翻倍。第二，模型没有固定到同一个设备。模型在cuda，输入张量却在cpu上，PyTorch 不会立刻报错，但每次都会做一次设备拷贝。第三，MCTS 每走一个子节点都重新拼一次全部历史局面特征。特征计算应该缓存复用一个只增不减的列表，而不是在每次递归选点时从头算 17 层平面。第四，单次推理 batch_size 为 1。自对弈时如果想提速，可以把当前层的所有叶子节点打包成一个 batch 同时推理。
下面这段代码演示了在已有模型上同时打开推理模式和半精度：
model.eval() model.inference_mode() # PyTorch 2.x 也可用 torch.inference_mode() 包裹整段 if torch.cuda.is_available(): model = model.half()逻辑说明：model.half()把权重转为 FP16，在支持半精度运算的 GPU 上能明显加速大规模 MCTS；但在 CPU 上反而可能更慢，所以这个分支一定要检查是否有 CUDA 设备。torch.inference_mode()比no_grad更加彻底，它完全禁用自动求导，推理代码不允许再调用会把张量重新变成需要梯度的操作。
如果你实在不知道慢在哪，就用 Python 自带性能分析器跑一次：
python -m cProfile -s cumtime play.py --ai mcts --playouts 400命令逻辑说明：cProfile会把每个函数的累计执行时间排序输出，结果里排名靠前的函数如果是policy_inference，说明瓶颈在神经网络推理；如果是ucb_score或select_child，说明树节点访问次数太多且数据结构里采用了线性查找。后者可以考虑把子节点存放从 list 改成 dict 或直接用坐标哈希表。
5. 从源码出发，用回放和 GTP 扩展你的围棋机器人
5.1 用 SGF 回放定位“败招”：价值曲线和策略自信度
程序下完一盘之后，不应该只留一个胜负结果。常见做法是写一个回放脚本读取 SGF，然后对每一手棋重新调用策略网络，记录下“网络认为这一步胜率是多少”。这个过程中你能直观看到哪一手棋让价值曲线突然跳水。回放代码可以这样写：
def replay_with_value(path, model): board = GoBoard() for node in sgf_iterate(path): # 解析 SGF 主变，返回每一步落子 state_tensor = encode_board(board) _, value = policy_inference(model, state_tensor) print(node.move, round(value, 3)) board.apply_move(node.move)逻辑说明：value.item()返回的值是从当前执子方视角看出的胜率，假设黑方胜率为 0.7，轮到白方时的同局面图标会变成 -0.7，所以回放时不要只看单点数值，要看“相对于前一手的变化幅度”。如果某手落子后价值从 0.55 瞬间跌到 0.1，通常就是源码里 MCTS 因为 playouts 不够没有发现对手的反击。
参数说明：encode_board必须和训练时保持一致，特别是历史局面层数的取值来源，有些源码保存 SGF 时会额外记录前三手，但特征编码里第八手之前需要填零，这一细节错了会导致回放价值曲线完全没有参考意义。
5.2 把机器人接成 GTP 引擎，图形客户端就能指挥它下棋
当你不满足于在终端里键入坐标，可以把对弈入口改造成 GTP 协议。GTP 是图形界面和围棋程序之间的文本协议，核心只有几个命令：play表示对方落子，genmove表示让程序生成一手棋，quit表示退出。源码里通常会有 MCTS 对外接口，你只需要在 while 循环里逐行读标准输入并打印结果：
import sys def gtp_loop(search_fn): board = GoBoard() for line in sys.stdin: cmd = line.strip().split() if cmd[0] == "play": board.apply_move(parse_vertex(cmd[1])) print("= \n\n") elif cmd[0] == "genmove": move = search_fn(board) board.apply_move(move) print(f"= {format_vertex(move)}\n\n") elif cmd[0] == "quit": print("= \n\n") return逻辑说明：GTP 的响应必须以=开头，行尾要留一个空行，这是协议给图形客户端判断“响应已完整”的停靠标记。把print的输出重定向到标准输出即可，但注意不要在多进程或并行搜索时让调试日志混进标准输出，否则客户端会把日志当成响应解析失败。
参数说明：parse_vertex负责把图形界面传来的d4这类坐标转换成棋盘数组下标，最容易出错的是字母i在围棋中一般不用作坐标列号，这是为了避免与数字1混淆的习惯。编程时也应当让 GTP 命令boardsize 9能重新初始化棋盘，因为图形客户端通常先发boardsize再开始对弈。按这套接口写完，任何支持 GTP 的开放图形前端都会把你这份 Python 围棋机器人当成熟人引擎来驱动。
本文还有配套的精品资源，点击获取
