尧图网页设计 
简介这份资源是用 Caffe 与 C 复现 DeepMind AlphaZero 算法的工程实现面向具备一定深度学习与 C 基础、希望深入理解强化学习自对弈机制的开发者与研究者。作者尽量遵循原论文思路将核心算法模板化并与具体游戏规则分离理论上可迁移到围棋、国际象棋等任意棋类受限于算力仅实现了可变棋盘尺寸的井字棋与四连线两个示例。压缩包共 23 个文件约 1.04MB包含 C 头文件与源文件、Caffe 网络 prototxt 配置、预训练 caffemodel 权重、训练与测试批处理脚本以及说明文档和训练曲线图覆盖从网络定义到训练评估的完整流程。目前已有 201 人学习。读者可借此掌握 AlphaZero 的 MCTS 与神经网络结合方式、Caffe 模型配置方法并基于模板扩展自己的游戏环境。1. 从一份 Caffe_AlphaZero 源码包说起C 算法复现 AlphaZero 到底能跑出什么如果你手头只有一块普通显卡却想亲手把 AlphaZero 那套「自我对弈 蒙特卡洛树搜索 神经网络评估」的闭环跑通大概率会被官方实现的计算门槛劝退。这份 Caffe_AlphaZero-master 源码包解决的正是这个矛盾它用 Caffe 作为深度学习后端用 C 把 AlphaZero 的核心算法模板化把游戏规则和算法骨架彻底拆开只附带井字棋和四连线两个小游戏作为可运行示例。换句话说它不追求复现论文里的围棋强度而是让你在一台笔记本上就能看清 AlphaZero 每一步在干什么。适合谁适合已经会写 C、想搞懂 MCTS 与策略价值网络如何咬合、又不愿意一上来就啃分布式训练框架的工程师。整个包体量不大核心目录是 AlphaZero、ConnectNGame、TicTacGame 三块外加一组已经训练好的 caffemodel 和 prototxt拿来就能验证推理链路。2. 拆开目录看设计算法模板化与游戏规则分离是怎么落地的2.1 三个核心目录的职责边界拿到压缩包解压后顶层能看到 AlphaZero、ConnectNGame、TicTacGame 三个目录各自带独立的 include、src 和 CMakeLists.txt。这种结构不是随手分的它对应一个明确的设计意图AlphaZero 目录里放的是与具体游戏无关的算法骨架包括蒙特卡洛树搜索、自我对弈调度、训练样本回放这些逻辑ConnectNGame 和 TicTacGame 各自实现同一套游戏接口提供棋盘状态、合法走子、胜负判定和状态编码。算法层通过模板参数拿到游戏类型编译期就完成绑定运行期没有虚函数开销。我第一次看到这种拆法时觉得有点绕但真正想换游戏时才发现好处只要新游戏实现那几个约定接口AlphaZero 目录一行不用改。2.2 模板化接口需要游戏实现哪些方法游戏规则类需要暴露的能力常见做法是围绕这几类当前局面下所有合法动作、执行一个动作后返回新状态、判断当前状态是否终局以及胜负归属、把状态编码成 Caffe 网络输入所需的张量形状。井字棋和四连线都按可变棋盘尺寸实现所以编码函数里棋盘边长是运行时参数不是写死的常量。这一点在阅读源码时要特别留意因为网络输入的 blob 形状必须和编码结果严格对齐否则 Caffe 前向传播会直接报维度不匹配。下面这段是游戏接口的典型形态具体签名以你解压后的头文件为准这里给出的是结构示意// 游戏状态需要提供的最小接口示意实际以源码头文件为准 class GameState { public: // 返回当前局面下所有合法动作的索引 std::vectorint LegalActions() const; // 执行动作返回新的局面对象 GameState ApplyAction(int action) const; // 是否终局终局时通过返回值判断胜负 bool IsTerminal() const; float TerminalValue() const; // 当前玩家视角的胜负值 // 编码成网络输入张量通道数、边长由构造参数决定 void Encode(float* buffer, int board_size) const; };逻辑说明LegalActions 决定 MCTS 展开的分支宽度ApplyAction 必须返回新对象而不是原地修改否则自我对弈回放时会污染历史局面。TerminalValue 的符号约定要和训练时的价值目标一致井字棋里常见做法是赢为 1、输为 -1、平为 0从当前行棋方视角取值。Encode 负责把棋盘铺成 Caffe blob通道顺序一旦定下就不能中途改否则已训练好的 caffemodel 会失效。2.3 CMake 构建链路与依赖三个目录各有 CMakeLists.txt顶层还有一个总的 CMakeLists.txt 把它们串起来。构建前需要本机已经装好 Caffe 的 C 库和头文件以及 protobuf、boost 这类 Caffe 自身依赖。构建顺序上先编译游戏规则库再编译 AlphaZero 算法库最后链接出可执行文件。常见做法是在 build 目录里执行mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4参数说明CMAKE_BUILD_TYPE 设成 Release 很关键MCTS 里大量循环和容器操作Debug 模式下自我对弈一局能慢到让你怀疑人生。如果 cmake 报找不到 Caffe需要手动指定 CaffeConfig.cmake 所在路径通常用 -DCaffe_DIR... 传入。make -j4 的并行度按你机器核数调整Caffe 编译本身吃内存核数开太大容易 OOM。3. 跑通推理与训练从 caffemodel 到自我对弈的完整操作3.1 用现成模型验证推理链路包里已经带了 net_tic_tac_6_4_2_res_block.caffemodel 和对应的 prototxt还有 net_tic_tac_6_4_1_res_block 这一组。文件名里的 6_4_2 一般指棋盘边长 6、残差块数量 4、通道基数 2 这类配置具体含义以 prototxt 里的层定义为准。先用 test_tic_tac.bat 验证推理这个批处理会加载模型、构造一个局面、跑一次前向打印策略输出和价值输出。在 Linux 下把 bat 里的命令逐条翻译成 shell 即可核心就是调用编译出的可执行文件并传入模型路径和 prototxt 路径。验证时重点看两件事策略输出的维度是否等于棋盘格子数价值输出是否落在 -1 到 1 之间。如果维度对不上八成是 prototxt 里最后一层全连接输出数和游戏编码不匹配。3.2 训练脚本与 solver 参数train_tic_tac.bat 负责启动训练它背后读的是 solver.prototxt。solver 里几个参数直接决定训练能不能收敛base_lr 是初始学习率小游戏上常见做法是 0.001 到 0.01 之间max_iter 是总迭代次数snapshot 控制多久存一次模型lr_policy 决定学习率怎么衰减。下面是一份 solver 的关键字段示意# solver.prototxt 关键字段示意实际值以包内文件为准 net: net_tic_tac_6_4_2_res_block.prototxt base_lr: 0.001 lr_policy: step stepsize: 2000 gamma: 0.5 max_iter: 20000 snapshot: 2000 snapshot_prefix: snapshot/tic_tac逻辑说明step 策略表示每过 stepsize 次迭代把学习率乘以 gamma这种衰减方式在小规模自我对弈数据上比较稳。snapshot 间隔别设太大自我对弈数据分布会随训练推进而漂移存太稀容易丢掉中间可用的模型。训练日志里要盯 loss 曲线策略损失和价值损失应该同步下降如果价值损失震荡不降通常是胜负值符号约定和训练目标对不上。3.3 自我对弈数据是怎么喂进 Caffe 的AlphaZero 的训练数据不是预先准备好的数据集而是自我对弈实时产生的。每一局对弈MCTS 在每个局面给出访问次数分布作为策略目标对局结束后的胜负作为价值目标这些样本攒够一个 batch 就送进 Caffe 做一次反向传播。包里 training_curves.jpg 就是训练过程的曲线记录可以拿来对照你自己的训练结果。这里有个容易忽略的点MCTS 的模拟次数直接决定策略目标的质量模拟次数太少策略目标接近随机网络学不到东西模拟次数太多单局对弈时间线性增长。井字棋上常见做法是每步几百次模拟起步四连线因为分支更多需要适当加大。3.4 换一个游戏要改哪些地方想验证这套代码的通用性最直接的办法是照着 TicTacGame 再实现一个游戏。步骤是新建游戏目录实现第 2 章说的那组接口写自己的 CMakeLists.txt然后在顶层 CMakeLists.txt 里加进去。网络这边要新建一份 prototxt把输入 blob 形状改成新游戏的编码形状输出维度改成新游戏的合法动作数。改完重新编译先用随机对弈验证游戏规则本身没写错再接入 MCTS 跑自我对弈。这个流程走一遍你对「算法与游戏分离」的理解会比读十遍源码都深。4. 避坑与排查这份 Caffe_AlphaZero 最容易翻车的几个地方4.1 编译期找不到 Caffe 或 protobuf 版本冲突现象cmake 配置阶段报找不到 Caffe或者编译到一半报 protobuf 符号重复定义。原因本机装了多个版本的 protobufCaffe 编译时用的版本和你项目链接的版本不一致。解决先用protoc --version确认版本再检查 Caffe 安装时依赖的 protobuf 版本让两者对齐cmake 里显式指定 Caffe_DIR 和 Protobuf_DIR避免它自动搜到系统里另一个版本。4.2 模型加载成功但前向输出维度对不上现象test 脚本能加载 caffemodel但前向传播时报 blob 形状不匹配。原因prototxt 里输入层的形状和游戏 Encode 出来的张量形状不一致常见于改了棋盘尺寸却没同步改 prototxt。解决打开 prototxt 看 input_dim 或 Input 层的 shape和游戏编码函数里写入 buffer 的长度逐项核对通道数、高、宽三个维度都要对上。4.3 自我对弈跑得极慢甚至卡死现象一局井字棋自我对弈要跑好几分钟。原因编译成了 Debug 模式或者 MCTS 模拟次数设得过高也可能是游戏接口里 ApplyAction 做了深拷贝大对象。解决确认 CMAKE_BUILD_TYPE 是 Release把模拟次数先降到几十次验证流程通畅再逐步加检查 ApplyAction 是否返回了不必要的完整拷贝能移动语义就移动。4.4 训练 loss 不降或价值输出恒定现象训练若干轮后策略损失不降价值输出始终接近 0。原因自我对弈产生的胜负值符号约定和训练目标不一致或者 MCTS 策略目标退化成均匀分布。解决打印几个终局样本人工核对胜负值和当前行棋方视角是否一致检查 MCTS 返回的访问次数分布如果所有动作访问次数几乎相等说明模拟次数太少或先验网络输出异常。4.5 换游戏后编译通过但行为异常现象新游戏能编译自我对弈也能跑但棋力始终不涨。原因新游戏的合法动作索引和网络输出索引没有对齐或者终局判定漏了某些情况。解决写一个纯随机对弈的测试跑几千局确认不会出现非法走子或死循环再单独测终局判定把所有可能的终局形态枚举一遍核对返回值。5. 进阶玩法用训练曲线反推超参把这份代码当成实验台跑通之后这份代码真正的价值不在于井字棋下得多好而在于它是一个可以反复做实验的小型 AlphaZero 实验台。我一般会拿 training_curves.jpg 做基准然后系统性地改一个参数看曲线怎么变。比如固定其他条件只把 MCTS 模拟次数从 100 提到 400观察策略损失下降速度的变化再固定模拟次数只改 solver 里的 base_lr看价值损失会不会震荡。这种单变量对照做上五六组你对 AlphaZero 各组件敏感度的直觉会比看论文扎实得多。具体操作上建议把每次实验的配置和曲线单独存档命名带上关键参数比如sim400_lr0.001。训练脚本本身不用改改的是 solver.prototxt 和 MCTS 模拟次数的配置项。跑完一轮后用包里 test 脚本对固定局面做推理比较不同模型在同一局面上的策略分布差异这比只看 loss 数字更能说明问题。下面是一个批量跑对照实验的 shell 骨架# 批量对照实验不同模拟次数下各跑一轮训练 for sim in 100 200 400; do # 修改配置中的模拟次数具体配置项名以源码为准 sed -i s/num_simulations: .*/num_simulations: ${sim}/ config.txt # 启动训练日志和快照按模拟次数分目录存放 ./train_tic_tac --config config.txt --out_dir exp_sim${sim} done逻辑说明sed 那行按你源码里实际的配置项名替换不同实现里模拟次数的字段名可能不一样。out_dir 分目录是为了后面画曲线时能直接按目录读取日志不用手动整理。跑之前先确认磁盘空间够自我对弈快照虽然不大但几组实验叠加起来也会占地方。还有一个容易被忽略的验证技巧把训练好的模型拿去做「策略一致性」检查。对同一个局面让 MCTS 跑多次看它给出的动作分布是否稳定。如果同一个局面每次跑出来的首选动作都在变说明模拟次数不够或者网络输出噪声太大这时候加训练轮数意义不大应该先加模拟次数。这个检查我每次调完参数都会走一遍比盯着 loss 曲线更能提前发现问题。从那以后我每次改完超参都强制先跑一遍策略一致性检查再决定要不要继续训练。希望这份拆解能帮你把这份 Caffe_AlphaZero 真正跑起来、改起来。本文还有配套的精品资源点击获取 Caffe_AlphaZero 源码解析：C++ 实现 AlphaZero 算法与游戏分离
简介这份资源是用 Caffe 与 C 复现 DeepMind AlphaZero 算法的工程实现面向具备一定深度学习与 C 基础、希望深入理解强化学习自对弈机制的开发者与研究者。作者尽量遵循原论文思路将核心算法模板化并与具体游戏规则分离理论上可迁移到围棋、国际象棋等任意棋类受限于算力仅实现了可变棋盘尺寸的井字棋与四连线两个示例。压缩包共 23 个文件约 1.04MB包含 C 头文件与源文件、Caffe 网络 prototxt 配置、预训练 caffemodel 权重、训练与测试批处理脚本以及说明文档和训练曲线图覆盖从网络定义到训练评估的完整流程。目前已有 201 人学习。读者可借此掌握 AlphaZero 的 MCTS 与神经网络结合方式、Caffe 模型配置方法并基于模板扩展自己的游戏环境。1. 从一份 Caffe_AlphaZero 源码包说起C 算法复现 AlphaZero 到底能跑出什么如果你手头只有一块普通显卡却想亲手把 AlphaZero 那套「自我对弈 蒙特卡洛树搜索 神经网络评估」的闭环跑通大概率会被官方实现的计算门槛劝退。这份 Caffe_AlphaZero-master 源码包解决的正是这个矛盾它用 Caffe 作为深度学习后端用 C 把 AlphaZero 的核心算法模板化把游戏规则和算法骨架彻底拆开只附带井字棋和四连线两个小游戏作为可运行示例。换句话说它不追求复现论文里的围棋强度而是让你在一台笔记本上就能看清 AlphaZero 每一步在干什么。适合谁适合已经会写 C、想搞懂 MCTS 与策略价值网络如何咬合、又不愿意一上来就啃分布式训练框架的工程师。整个包体量不大核心目录是 AlphaZero、ConnectNGame、TicTacGame 三块外加一组已经训练好的 caffemodel 和 prototxt拿来就能验证推理链路。2. 拆开目录看设计算法模板化与游戏规则分离是怎么落地的2.1 三个核心目录的职责边界拿到压缩包解压后顶层能看到 AlphaZero、ConnectNGame、TicTacGame 三个目录各自带独立的 include、src 和 CMakeLists.txt。这种结构不是随手分的它对应一个明确的设计意图AlphaZero 目录里放的是与具体游戏无关的算法骨架包括蒙特卡洛树搜索、自我对弈调度、训练样本回放这些逻辑ConnectNGame 和 TicTacGame 各自实现同一套游戏接口提供棋盘状态、合法走子、胜负判定和状态编码。算法层通过模板参数拿到游戏类型编译期就完成绑定运行期没有虚函数开销。我第一次看到这种拆法时觉得有点绕但真正想换游戏时才发现好处只要新游戏实现那几个约定接口AlphaZero 目录一行不用改。2.2 模板化接口需要游戏实现哪些方法游戏规则类需要暴露的能力常见做法是围绕这几类当前局面下所有合法动作、执行一个动作后返回新状态、判断当前状态是否终局以及胜负归属、把状态编码成 Caffe 网络输入所需的张量形状。井字棋和四连线都按可变棋盘尺寸实现所以编码函数里棋盘边长是运行时参数不是写死的常量。这一点在阅读源码时要特别留意因为网络输入的 blob 形状必须和编码结果严格对齐否则 Caffe 前向传播会直接报维度不匹配。下面这段是游戏接口的典型形态具体签名以你解压后的头文件为准这里给出的是结构示意// 游戏状态需要提供的最小接口示意实际以源码头文件为准 class GameState { public: // 返回当前局面下所有合法动作的索引 std::vectorint LegalActions() const; // 执行动作返回新的局面对象 GameState ApplyAction(int action) const; // 是否终局终局时通过返回值判断胜负 bool IsTerminal() const; float TerminalValue() const; // 当前玩家视角的胜负值 // 编码成网络输入张量通道数、边长由构造参数决定 void Encode(float* buffer, int board_size) const; };逻辑说明LegalActions 决定 MCTS 展开的分支宽度ApplyAction 必须返回新对象而不是原地修改否则自我对弈回放时会污染历史局面。TerminalValue 的符号约定要和训练时的价值目标一致井字棋里常见做法是赢为 1、输为 -1、平为 0从当前行棋方视角取值。Encode 负责把棋盘铺成 Caffe blob通道顺序一旦定下就不能中途改否则已训练好的 caffemodel 会失效。2.3 CMake 构建链路与依赖三个目录各有 CMakeLists.txt顶层还有一个总的 CMakeLists.txt 把它们串起来。构建前需要本机已经装好 Caffe 的 C 库和头文件以及 protobuf、boost 这类 Caffe 自身依赖。构建顺序上先编译游戏规则库再编译 AlphaZero 算法库最后链接出可执行文件。常见做法是在 build 目录里执行mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j4参数说明CMAKE_BUILD_TYPE 设成 Release 很关键MCTS 里大量循环和容器操作Debug 模式下自我对弈一局能慢到让你怀疑人生。如果 cmake 报找不到 Caffe需要手动指定 CaffeConfig.cmake 所在路径通常用 -DCaffe_DIR... 传入。make -j4 的并行度按你机器核数调整Caffe 编译本身吃内存核数开太大容易 OOM。3. 跑通推理与训练从 caffemodel 到自我对弈的完整操作3.1 用现成模型验证推理链路包里已经带了 net_tic_tac_6_4_2_res_block.caffemodel 和对应的 prototxt还有 net_tic_tac_6_4_1_res_block 这一组。文件名里的 6_4_2 一般指棋盘边长 6、残差块数量 4、通道基数 2 这类配置具体含义以 prototxt 里的层定义为准。先用 test_tic_tac.bat 验证推理这个批处理会加载模型、构造一个局面、跑一次前向打印策略输出和价值输出。在 Linux 下把 bat 里的命令逐条翻译成 shell 即可核心就是调用编译出的可执行文件并传入模型路径和 prototxt 路径。验证时重点看两件事策略输出的维度是否等于棋盘格子数价值输出是否落在 -1 到 1 之间。如果维度对不上八成是 prototxt 里最后一层全连接输出数和游戏编码不匹配。3.2 训练脚本与 solver 参数train_tic_tac.bat 负责启动训练它背后读的是 solver.prototxt。solver 里几个参数直接决定训练能不能收敛base_lr 是初始学习率小游戏上常见做法是 0.001 到 0.01 之间max_iter 是总迭代次数snapshot 控制多久存一次模型lr_policy 决定学习率怎么衰减。下面是一份 solver 的关键字段示意# solver.prototxt 关键字段示意实际值以包内文件为准 net: net_tic_tac_6_4_2_res_block.prototxt base_lr: 0.001 lr_policy: step stepsize: 2000 gamma: 0.5 max_iter: 20000 snapshot: 2000 snapshot_prefix: snapshot/tic_tac逻辑说明step 策略表示每过 stepsize 次迭代把学习率乘以 gamma这种衰减方式在小规模自我对弈数据上比较稳。snapshot 间隔别设太大自我对弈数据分布会随训练推进而漂移存太稀容易丢掉中间可用的模型。训练日志里要盯 loss 曲线策略损失和价值损失应该同步下降如果价值损失震荡不降通常是胜负值符号约定和训练目标对不上。3.3 自我对弈数据是怎么喂进 Caffe 的AlphaZero 的训练数据不是预先准备好的数据集而是自我对弈实时产生的。每一局对弈MCTS 在每个局面给出访问次数分布作为策略目标对局结束后的胜负作为价值目标这些样本攒够一个 batch 就送进 Caffe 做一次反向传播。包里 training_curves.jpg 就是训练过程的曲线记录可以拿来对照你自己的训练结果。这里有个容易忽略的点MCTS 的模拟次数直接决定策略目标的质量模拟次数太少策略目标接近随机网络学不到东西模拟次数太多单局对弈时间线性增长。井字棋上常见做法是每步几百次模拟起步四连线因为分支更多需要适当加大。3.4 换一个游戏要改哪些地方想验证这套代码的通用性最直接的办法是照着 TicTacGame 再实现一个游戏。步骤是新建游戏目录实现第 2 章说的那组接口写自己的 CMakeLists.txt然后在顶层 CMakeLists.txt 里加进去。网络这边要新建一份 prototxt把输入 blob 形状改成新游戏的编码形状输出维度改成新游戏的合法动作数。改完重新编译先用随机对弈验证游戏规则本身没写错再接入 MCTS 跑自我对弈。这个流程走一遍你对「算法与游戏分离」的理解会比读十遍源码都深。4. 避坑与排查这份 Caffe_AlphaZero 最容易翻车的几个地方4.1 编译期找不到 Caffe 或 protobuf 版本冲突现象cmake 配置阶段报找不到 Caffe或者编译到一半报 protobuf 符号重复定义。原因本机装了多个版本的 protobufCaffe 编译时用的版本和你项目链接的版本不一致。解决先用protoc --version确认版本再检查 Caffe 安装时依赖的 protobuf 版本让两者对齐cmake 里显式指定 Caffe_DIR 和 Protobuf_DIR避免它自动搜到系统里另一个版本。4.2 模型加载成功但前向输出维度对不上现象test 脚本能加载 caffemodel但前向传播时报 blob 形状不匹配。原因prototxt 里输入层的形状和游戏 Encode 出来的张量形状不一致常见于改了棋盘尺寸却没同步改 prototxt。解决打开 prototxt 看 input_dim 或 Input 层的 shape和游戏编码函数里写入 buffer 的长度逐项核对通道数、高、宽三个维度都要对上。4.3 自我对弈跑得极慢甚至卡死现象一局井字棋自我对弈要跑好几分钟。原因编译成了 Debug 模式或者 MCTS 模拟次数设得过高也可能是游戏接口里 ApplyAction 做了深拷贝大对象。解决确认 CMAKE_BUILD_TYPE 是 Release把模拟次数先降到几十次验证流程通畅再逐步加检查 ApplyAction 是否返回了不必要的完整拷贝能移动语义就移动。4.4 训练 loss 不降或价值输出恒定现象训练若干轮后策略损失不降价值输出始终接近 0。原因自我对弈产生的胜负值符号约定和训练目标不一致或者 MCTS 策略目标退化成均匀分布。解决打印几个终局样本人工核对胜负值和当前行棋方视角是否一致检查 MCTS 返回的访问次数分布如果所有动作访问次数几乎相等说明模拟次数太少或先验网络输出异常。4.5 换游戏后编译通过但行为异常现象新游戏能编译自我对弈也能跑但棋力始终不涨。原因新游戏的合法动作索引和网络输出索引没有对齐或者终局判定漏了某些情况。解决写一个纯随机对弈的测试跑几千局确认不会出现非法走子或死循环再单独测终局判定把所有可能的终局形态枚举一遍核对返回值。5. 进阶玩法用训练曲线反推超参把这份代码当成实验台跑通之后这份代码真正的价值不在于井字棋下得多好而在于它是一个可以反复做实验的小型 AlphaZero 实验台。我一般会拿 training_curves.jpg 做基准然后系统性地改一个参数看曲线怎么变。比如固定其他条件只把 MCTS 模拟次数从 100 提到 400观察策略损失下降速度的变化再固定模拟次数只改 solver 里的 base_lr看价值损失会不会震荡。这种单变量对照做上五六组你对 AlphaZero 各组件敏感度的直觉会比看论文扎实得多。具体操作上建议把每次实验的配置和曲线单独存档命名带上关键参数比如sim400_lr0.001。训练脚本本身不用改改的是 solver.prototxt 和 MCTS 模拟次数的配置项。跑完一轮后用包里 test 脚本对固定局面做推理比较不同模型在同一局面上的策略分布差异这比只看 loss 数字更能说明问题。下面是一个批量跑对照实验的 shell 骨架# 批量对照实验不同模拟次数下各跑一轮训练 for sim in 100 200 400; do # 修改配置中的模拟次数具体配置项名以源码为准 sed -i s/num_simulations: .*/num_simulations: ${sim}/ config.txt # 启动训练日志和快照按模拟次数分目录存放 ./train_tic_tac --config config.txt --out_dir exp_sim${sim} done逻辑说明sed 那行按你源码里实际的配置项名替换不同实现里模拟次数的字段名可能不一样。out_dir 分目录是为了后面画曲线时能直接按目录读取日志不用手动整理。跑之前先确认磁盘空间够自我对弈快照虽然不大但几组实验叠加起来也会占地方。还有一个容易被忽略的验证技巧把训练好的模型拿去做「策略一致性」检查。对同一个局面让 MCTS 跑多次看它给出的动作分布是否稳定。如果同一个局面每次跑出来的首选动作都在变说明模拟次数不够或者网络输出噪声太大这时候加训练轮数意义不大应该先加模拟次数。这个检查我每次调完参数都会走一遍比盯着 loss 曲线更能提前发现问题。从那以后我每次改完超参都强制先跑一遍策略一致性检查再决定要不要继续训练。希望这份拆解能帮你把这份 Caffe_AlphaZero 真正跑起来、改起来。本文还有配套的精品资源点击获取