简介这份资源是2012年RoboCup 3D仿真足球世界杯冠军南京邮电大学团队的可执行代码面向机器人仿真、多智能体协同与强化学习方向的研究者与竞赛选手可用于复现冠军方案、研究决策算法与团队协作策略。压缩包共175个文件约29.13MB以rsg脚本、svn-base版本文件、rb与sh脚本为主另含apollo3d仿真环境相关文件及少量format、entries等版本控制元数据整体保留了完整的工程目录结构。资源基于Apollo Soccer Simulator平台开发涵盖球员移动、传球、射门、防守等行为的策略实现并涉及对手行为预测、多智能体协同与实时通信等关键技术。目前已有899人学习下载适合希望深入理解RoboCup 3D竞赛代码组织方式、借鉴冠军团队算法设计思路的读者参考研究。1. 2012robocup3d 冠军南邮可执行代码一份能跑起来的比赛级 Agent 底稿如果你手头正好有一份 2012robocup3d 冠军南邮可执行代码却卡在“怎么让它跑起来、跑起来之后怎么改、改了之后怎么验证”这三步上那这篇笔记就是写给你的。RoboCup 3D 仿真联赛3D Simulation League在 2012 年前后已经进入多智能体协同相当成熟的阶段南邮南京邮电大学当年拿下的这套可执行代码本质上是一份完整的 Nao 机器人 Agent 行为决策底稿——它包含感知解析、世界模型维护、跑位策略、踢球动作选择以及底层通信协议对接。很多人拿到这类比赛代码的第一反应是“先编译再说”结果往往在依赖、参数、启动顺序上连续翻车。我自己的习惯是先把它当成一个黑匣子跑通最小闭环再逐层拆开看决策逻辑。这套代码适合两类人一是想复现当年比赛级 Agent 架构的在校队员二是想把多智能体决策思路迁移到其他仿真环境的工程师。下面按“先跑通、再理解、后调优”的顺序展开。2. 先搞清楚这套可执行代码到底由什么组成2.1 从可执行文件反推 Agent 的模块划分拿到一份 2012robocup3d 冠军南邮可执行代码不要急着找源码。先看目录结构通常会有这么几类东西可执行二进制或脚本入口、配置文件.conf / .ini / .xml、动作定义文件、以及日志输出目录。当年 3D 仿真联赛的 Agent 一般通过 UDP 和仿真服务器rcssserver3d通信所以可执行代码里一定有一个主循环收感知 → 更新世界模型 → 决策 → 发指令。你可以用file和ldd先确认二进制架构和动态库依赖# 查看可执行文件类型和架构 file ./agent_binary # 查看动态库依赖缺什么补什么 ldd ./agent_binary # 如果是脚本入口看 shebang 指向哪个解释器 head -n 5 ./start_agent.sh逻辑说明file告诉你这是 x86 还是 x86_64、是 ELF 还是脚本ldd列出运行时需要的 .so缺库是新手最常见的翻车点。参数说明如果ldd输出里有 “not found”先别改代码去装对应版本的运行库注意 2012 年的代码大概率依赖较老的 libc 和 boost 版本。2.2 仿真服务器与 Agent 的通信参数怎么对齐RoboCup 3D 仿真里Agent 和服务器之间靠端口和团队名配对。可执行代码里通常有一个配置文件写着服务器 IP、端口、团队名、机器人编号。常见做法是服务器监听 3100Agent 端口和 3200监视器端口每个 Agent 用不同编号连上去。你需要确认配置文件里的字段和服务器启动参数一致# agent.conf 典型字段 server_host 127.0.0.1 server_port 3100 team_name NUPT robot_id 1逻辑说明team_name必须和服务器端允许的团队名匹配否则连上去会被踢robot_id在同一队内不能重复。参数说明如果服务器跑在本机server_host用 127.0.0.1如果跑在局域网另一台机器改成那台机器的 IP并确认防火墙放行 UDP 3100。很多人在这里踩坑服务器起来了Agent 也启动了但双方就是不在一个频道上最后发现是团队名大小写不一致。2.3 最小启动顺序先服务器再监视器最后 Agent启动顺序错了Agent 会反复重连甚至直接退出。我一般按这个顺序来# 1. 启动仿真服务器 rcssserver3d --port 3100 # 2. 启动监视器可选但强烈建议否则你只能看日志猜 rcssmonitor3d # 3. 启动 Agent传入配置文件 ./start_agent.sh --config ./agent.conf逻辑说明服务器必须先监听端口Agent 才能连上监视器用来可视化场上状态没有它排查行为异常会非常痛苦。参数说明--port要和 Agent 配置里的server_port一致如果监视器连不上检查它默认连的端口是不是 3200。这一步跑通的标准是监视器里能看到机器人出现在场上Agent 日志里出现 “connected” 或类似字样。3. 让 Agent 真正动起来从感知到动作的链路拆解3.1 感知数据解析别让坐标单位把你坑了Agent 从服务器收到的感知数据通常包含关节角度、陀螺仪、加速度计、视觉标记flag的距离和角度。2012 年前后的代码里视觉标记的距离常用球坐标表示角度单位可能是弧度也可能是度。你需要找到解析感知的那段逻辑确认单位换算。常见做法是先把原始感知打印出来和监视器里看到的实际位置对照反推单位。# 伪代码解析视觉标记并转成场地坐标 def parse_visual(percept): for marker in percept.visual_markers: dist marker.distance # 单位可能是米 theta marker.theta # 水平角弧度 phi marker.phi # 垂直角弧度 # 转成相对机器人的笛卡尔坐标 x dist * math.cos(phi) * math.cos(theta) y dist * math.cos(phi) * math.sin(theta) z dist * math.sin(phi) update_world_model(marker.name, x, y, z)逻辑说明这段代码把球坐标转成笛卡尔坐标再更新世界模型。参数说明theta和phi的符号约定不同代码可能不一样必须用监视器实测校准dist如果单位是厘米记得除以 100。血泪经验当年我调这套代码时场上机器人一直往反方向跑最后发现是theta的正方向定义和我的假设相反。3.2 世界模型维护位置估计的滤波不能省比赛级 Agent 不会直接用单帧感知做决策而是维护一个世界模型对球、队友、对手的位置做估计。2012 年南邮这套代码里常见做法是用简单的卡尔曼滤波或滑动平均。你需要找到world_model相关的更新函数看它怎么融合多帧数据。# 简化版用滑动平均平滑球的位置 class BallTracker: def __init__(self, window5): self.history [] self.window window def update(self, x, y): self.history.append((x, y)) if len(self.history) self.window: self.history.pop(0) avg_x sum(p[0] for p in self.history) / len(self.history) avg_y sum(p[1] for p in self.history) / len(self.history) return avg_x, avg_y逻辑说明滑动平均能抑制感知噪声但会引入延迟。参数说明window越大越平滑但响应越慢比赛里通常取 3 到 5。如果你发现机器人追球时总是慢半拍先检查这个窗口是不是设太大了。3.3 动作选择踢球决策的状态机怎么读可执行代码里最核心的部分是行为决策。2012 年那批 Agent 大多用有限状态机FSM或行为树。你需要找到状态定义和转移条件。常见状态包括找球、追球、调整站位、踢球、回防。每个状态对应一组底层动作指令。# 伪代码简化版踢球状态机 class KickFSM: def step(self, world): if self.state FIND_BALL: if world.ball_visible: self.state APPROACH_BALL else: self.turn_head_to_scan() elif self.state APPROACH_BALL: if world.ball_distance 0.5: self.state ALIGN_FOR_KICK else: self.walk_to(world.ball_position) elif self.state ALIGN_FOR_KICK: if self.aligned_with_goal(): self.state KICK else: self.adjust_orientation() elif self.state KICK: self.execute_kick() self.state FIND_BALL逻辑说明这段状态机展示了从找球到踢球的完整链路。参数说明world.ball_distance 0.5这个阈值需要根据机器人步长和踢球动作范围调整aligned_with_goal()的对齐精度直接影响射门成功率。我一般会先把状态转移日志打出来看机器人在哪个状态卡住再针对性调阈值。4. 参数调优与行为验证怎么判断改对了4.1 关键参数表哪些值必须按场地和机器人改这套代码里有一批参数是强依赖运行环境的不能照搬。下面是我整理的核心参数表参数名含义典型值调整依据ball_distance_threshold触发踢球的球距0.5 m机器人腿长和踢球动作范围walk_speed行走速度0.3 m/s仿真步长和关节限制head_scan_angle头部扫描角度±90°视觉传感器视野kick_power踢球力度0.7球速和精度权衡filter_window世界模型滤波窗口5 帧感知噪声水平逻辑说明这张表不是让你照抄而是告诉你每个参数背后的物理意义。参数说明walk_speed设太大机器人会摔倒设太小追不上球kick_power设太大球会飞出场外设太小传不到队友脚下。我一般会先用默认值跑一遍记录每个参数对应的行为表现再逐个微调。4.2 用日志和监视器交叉验证行为改完参数后怎么知道改对了我的做法是同时开监视器和日志让 Agent 跑 5 分钟然后对照时间戳看关键事件。比如球距小于阈值时日志里应该出现 “KICK” 状态监视器里应该看到踢球动作。如果日志有但监视器没有说明底层动作指令没发出去如果监视器有但日志没有说明状态机没进到那个分支。# 过滤关键状态转移日志 grep -E STATE|KICK|BALL agent.log | tail -n 50 # 统计各状态停留时间 awk /STATE/ {print $NF} agent.log | sort | uniq -c | sort -rn逻辑说明第一条命令看最近的状态变化第二条统计哪个状态占时间最多。参数说明如果 “FIND_BALL” 占比过高说明感知或搜索策略有问题如果 “ALIGN_FOR_KICK” 占比高说明对齐逻辑效率低。4.3 常见行为异常的排查顺序行为异常不要一上来就改代码按这个顺序排查先看感知数据对不对再看世界模型准不准然后看状态机转移条件最后看底层动作指令。常见现象是机器人原地转圈原因可能是头部扫描逻辑和身体转向冲突解决方法是把扫描和转向解耦先转身体再扫头。另一个常见现象是踢球踢空原因可能是球的位置估计滞后解决方法是减小滤波窗口或加入预测补偿。5. 避坑与常见问题当年我踩过的那些坑5.1 现象Agent 启动后立刻退出日志只有一行原因配置文件路径不对或字段缺失程序读不到必要参数直接 abort。解决用绝对路径传配置并在启动脚本里加set -x看实际执行的命令。另外检查配置文件编码Windows 换行符有时会让解析器读不到最后一个字段。5.2 现象机器人能连上服务器但场上不动原因底层动作指令的关节名和仿真服务器不匹配。2012 年前后不同版本的 rcssserver3d 关节命名有差异。解决对照服务器文档确认关节名或者在代码里加一层映射。我一般会先把所有关节名打印出来和服务器端对比。5.3 现象踢球时球飞向随机方向原因踢球动作的触发时机和球的位置估计不同步。解决在踢球前加一个短延时或确认帧等世界模型稳定后再执行。另一个可能是kick_power和kick_angle的符号约定反了用监视器实测一次就能确认。5.4 现象多机器人互相碰撞或抢球原因队友之间的角色分配没有协调或者通信消息丢失。解决检查团队通信逻辑确认每个机器人有明确的角色前锋、后卫、守门员。如果通信不可靠可以用基于位置的隐式协调比如离球最近的机器人自动成为主攻。5.5 现象跑一段时间后 Agent 越来越慢原因日志文件无限增长或世界模型历史数据没清理。解决给日志加滚动策略限制世界模型历史长度。这类问题在长时间测试里才会暴露建议一开始就加上资源清理逻辑。6. 进阶技巧把冠军代码改成你自己的实验平台这套 2012robocup3d 冠军南邮可执行代码最大的价值不是复现当年成绩而是把它当成一个多智能体决策的实验平台。我自己的做法是保留底层通信和动作执行把上层决策替换成可配置的策略模块。比如把状态机改成行为树或者接入一个简单的强化学习策略做对比实验。具体操作上先找到决策入口函数通常叫think()或decide()把它抽成一个接口。然后写一个适配器让新策略输出和原状态机一样的动作指令格式。这样你可以在不改动底层的情况下快速对比不同策略的表现。# 策略接口示例 class StrategyBase: def decide(self, world_model): raise NotImplementedError class FSMStrategy(StrategyBase): def decide(self, world_model): # 原状态机逻辑 pass class RLStrategy(StrategyBase): def decide(self, world_model): # 强化学习策略输出动作指令 pass逻辑说明这样抽象之后你只需要在启动时选择策略实现就能跑对比实验。参数说明world_model要包含策略需要的所有信息如果新策略需要额外感知就在世界模型更新阶段加进去。验证方法上我习惯用固定随机种子跑多轮统计进球数、控球率、传球成功率。不要只看单场结果多智能体系统波动很大。另外把每次实验的配置和结果存成表格方便回溯。最后说一个我自己的习惯每次改完代码先跑一个 30 秒的冒烟测试确认基本行为正常再跑长测试。这样能省下大量等日志的时间。这套代码虽然老但架构清晰拿来练手或者做课程设计都够用。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是2012年RoboCup 3D仿真足球世界杯冠军南京邮电大学团队的可执行代码面向机器人仿真、多智能体协同与强化学习方向的研究者与竞赛选手可用于复现冠军方案、研究决策算法与团队协作策略。压缩包共175个文件约29.13MB以rsg脚本、svn-base版本文件、rb与sh脚本为主另含apollo3d仿真环境相关文件及少量format、entries等版本控制元数据整体保留了完整的工程目录结构。资源基于Apollo Soccer Simulator平台开发涵盖球员移动、传球、射门、防守等行为的策略实现并涉及对手行为预测、多智能体协同与实时通信等关键技术。目前已有899人学习下载适合希望深入理解RoboCup 3D竞赛代码组织方式、借鉴冠军团队算法设计思路的读者参考研究。1. 2012robocup3d 冠军南邮可执行代码一份能跑起来的比赛级 Agent 底稿如果你手头正好有一份 2012robocup3d 冠军南邮可执行代码却卡在“怎么让它跑起来、跑起来之后怎么改、改了之后怎么验证”这三步上那这篇笔记就是写给你的。RoboCup 3D 仿真联赛3D Simulation League在 2012 年前后已经进入多智能体协同相当成熟的阶段南邮南京邮电大学当年拿下的这套可执行代码本质上是一份完整的 Nao 机器人 Agent 行为决策底稿——它包含感知解析、世界模型维护、跑位策略、踢球动作选择以及底层通信协议对接。很多人拿到这类比赛代码的第一反应是“先编译再说”结果往往在依赖、参数、启动顺序上连续翻车。我自己的习惯是先把它当成一个黑匣子跑通最小闭环再逐层拆开看决策逻辑。这套代码适合两类人一是想复现当年比赛级 Agent 架构的在校队员二是想把多智能体决策思路迁移到其他仿真环境的工程师。下面按“先跑通、再理解、后调优”的顺序展开。2. 先搞清楚这套可执行代码到底由什么组成2.1 从可执行文件反推 Agent 的模块划分拿到一份 2012robocup3d 冠军南邮可执行代码不要急着找源码。先看目录结构通常会有这么几类东西可执行二进制或脚本入口、配置文件.conf / .ini / .xml、动作定义文件、以及日志输出目录。当年 3D 仿真联赛的 Agent 一般通过 UDP 和仿真服务器rcssserver3d通信所以可执行代码里一定有一个主循环收感知 → 更新世界模型 → 决策 → 发指令。你可以用file和ldd先确认二进制架构和动态库依赖# 查看可执行文件类型和架构 file ./agent_binary # 查看动态库依赖缺什么补什么 ldd ./agent_binary # 如果是脚本入口看 shebang 指向哪个解释器 head -n 5 ./start_agent.sh逻辑说明file告诉你这是 x86 还是 x86_64、是 ELF 还是脚本ldd列出运行时需要的 .so缺库是新手最常见的翻车点。参数说明如果ldd输出里有 “not found”先别改代码去装对应版本的运行库注意 2012 年的代码大概率依赖较老的 libc 和 boost 版本。2.2 仿真服务器与 Agent 的通信参数怎么对齐RoboCup 3D 仿真里Agent 和服务器之间靠端口和团队名配对。可执行代码里通常有一个配置文件写着服务器 IP、端口、团队名、机器人编号。常见做法是服务器监听 3100Agent 端口和 3200监视器端口每个 Agent 用不同编号连上去。你需要确认配置文件里的字段和服务器启动参数一致# agent.conf 典型字段 server_host 127.0.0.1 server_port 3100 team_name NUPT robot_id 1逻辑说明team_name必须和服务器端允许的团队名匹配否则连上去会被踢robot_id在同一队内不能重复。参数说明如果服务器跑在本机server_host用 127.0.0.1如果跑在局域网另一台机器改成那台机器的 IP并确认防火墙放行 UDP 3100。很多人在这里踩坑服务器起来了Agent 也启动了但双方就是不在一个频道上最后发现是团队名大小写不一致。2.3 最小启动顺序先服务器再监视器最后 Agent启动顺序错了Agent 会反复重连甚至直接退出。我一般按这个顺序来# 1. 启动仿真服务器 rcssserver3d --port 3100 # 2. 启动监视器可选但强烈建议否则你只能看日志猜 rcssmonitor3d # 3. 启动 Agent传入配置文件 ./start_agent.sh --config ./agent.conf逻辑说明服务器必须先监听端口Agent 才能连上监视器用来可视化场上状态没有它排查行为异常会非常痛苦。参数说明--port要和 Agent 配置里的server_port一致如果监视器连不上检查它默认连的端口是不是 3200。这一步跑通的标准是监视器里能看到机器人出现在场上Agent 日志里出现 “connected” 或类似字样。3. 让 Agent 真正动起来从感知到动作的链路拆解3.1 感知数据解析别让坐标单位把你坑了Agent 从服务器收到的感知数据通常包含关节角度、陀螺仪、加速度计、视觉标记flag的距离和角度。2012 年前后的代码里视觉标记的距离常用球坐标表示角度单位可能是弧度也可能是度。你需要找到解析感知的那段逻辑确认单位换算。常见做法是先把原始感知打印出来和监视器里看到的实际位置对照反推单位。# 伪代码解析视觉标记并转成场地坐标 def parse_visual(percept): for marker in percept.visual_markers: dist marker.distance # 单位可能是米 theta marker.theta # 水平角弧度 phi marker.phi # 垂直角弧度 # 转成相对机器人的笛卡尔坐标 x dist * math.cos(phi) * math.cos(theta) y dist * math.cos(phi) * math.sin(theta) z dist * math.sin(phi) update_world_model(marker.name, x, y, z)逻辑说明这段代码把球坐标转成笛卡尔坐标再更新世界模型。参数说明theta和phi的符号约定不同代码可能不一样必须用监视器实测校准dist如果单位是厘米记得除以 100。血泪经验当年我调这套代码时场上机器人一直往反方向跑最后发现是theta的正方向定义和我的假设相反。3.2 世界模型维护位置估计的滤波不能省比赛级 Agent 不会直接用单帧感知做决策而是维护一个世界模型对球、队友、对手的位置做估计。2012 年南邮这套代码里常见做法是用简单的卡尔曼滤波或滑动平均。你需要找到world_model相关的更新函数看它怎么融合多帧数据。# 简化版用滑动平均平滑球的位置 class BallTracker: def __init__(self, window5): self.history [] self.window window def update(self, x, y): self.history.append((x, y)) if len(self.history) self.window: self.history.pop(0) avg_x sum(p[0] for p in self.history) / len(self.history) avg_y sum(p[1] for p in self.history) / len(self.history) return avg_x, avg_y逻辑说明滑动平均能抑制感知噪声但会引入延迟。参数说明window越大越平滑但响应越慢比赛里通常取 3 到 5。如果你发现机器人追球时总是慢半拍先检查这个窗口是不是设太大了。3.3 动作选择踢球决策的状态机怎么读可执行代码里最核心的部分是行为决策。2012 年那批 Agent 大多用有限状态机FSM或行为树。你需要找到状态定义和转移条件。常见状态包括找球、追球、调整站位、踢球、回防。每个状态对应一组底层动作指令。# 伪代码简化版踢球状态机 class KickFSM: def step(self, world): if self.state FIND_BALL: if world.ball_visible: self.state APPROACH_BALL else: self.turn_head_to_scan() elif self.state APPROACH_BALL: if world.ball_distance 0.5: self.state ALIGN_FOR_KICK else: self.walk_to(world.ball_position) elif self.state ALIGN_FOR_KICK: if self.aligned_with_goal(): self.state KICK else: self.adjust_orientation() elif self.state KICK: self.execute_kick() self.state FIND_BALL逻辑说明这段状态机展示了从找球到踢球的完整链路。参数说明world.ball_distance 0.5这个阈值需要根据机器人步长和踢球动作范围调整aligned_with_goal()的对齐精度直接影响射门成功率。我一般会先把状态转移日志打出来看机器人在哪个状态卡住再针对性调阈值。4. 参数调优与行为验证怎么判断改对了4.1 关键参数表哪些值必须按场地和机器人改这套代码里有一批参数是强依赖运行环境的不能照搬。下面是我整理的核心参数表参数名含义典型值调整依据ball_distance_threshold触发踢球的球距0.5 m机器人腿长和踢球动作范围walk_speed行走速度0.3 m/s仿真步长和关节限制head_scan_angle头部扫描角度±90°视觉传感器视野kick_power踢球力度0.7球速和精度权衡filter_window世界模型滤波窗口5 帧感知噪声水平逻辑说明这张表不是让你照抄而是告诉你每个参数背后的物理意义。参数说明walk_speed设太大机器人会摔倒设太小追不上球kick_power设太大球会飞出场外设太小传不到队友脚下。我一般会先用默认值跑一遍记录每个参数对应的行为表现再逐个微调。4.2 用日志和监视器交叉验证行为改完参数后怎么知道改对了我的做法是同时开监视器和日志让 Agent 跑 5 分钟然后对照时间戳看关键事件。比如球距小于阈值时日志里应该出现 “KICK” 状态监视器里应该看到踢球动作。如果日志有但监视器没有说明底层动作指令没发出去如果监视器有但日志没有说明状态机没进到那个分支。# 过滤关键状态转移日志 grep -E STATE|KICK|BALL agent.log | tail -n 50 # 统计各状态停留时间 awk /STATE/ {print $NF} agent.log | sort | uniq -c | sort -rn逻辑说明第一条命令看最近的状态变化第二条统计哪个状态占时间最多。参数说明如果 “FIND_BALL” 占比过高说明感知或搜索策略有问题如果 “ALIGN_FOR_KICK” 占比高说明对齐逻辑效率低。4.3 常见行为异常的排查顺序行为异常不要一上来就改代码按这个顺序排查先看感知数据对不对再看世界模型准不准然后看状态机转移条件最后看底层动作指令。常见现象是机器人原地转圈原因可能是头部扫描逻辑和身体转向冲突解决方法是把扫描和转向解耦先转身体再扫头。另一个常见现象是踢球踢空原因可能是球的位置估计滞后解决方法是减小滤波窗口或加入预测补偿。5. 避坑与常见问题当年我踩过的那些坑5.1 现象Agent 启动后立刻退出日志只有一行原因配置文件路径不对或字段缺失程序读不到必要参数直接 abort。解决用绝对路径传配置并在启动脚本里加set -x看实际执行的命令。另外检查配置文件编码Windows 换行符有时会让解析器读不到最后一个字段。5.2 现象机器人能连上服务器但场上不动原因底层动作指令的关节名和仿真服务器不匹配。2012 年前后不同版本的 rcssserver3d 关节命名有差异。解决对照服务器文档确认关节名或者在代码里加一层映射。我一般会先把所有关节名打印出来和服务器端对比。5.3 现象踢球时球飞向随机方向原因踢球动作的触发时机和球的位置估计不同步。解决在踢球前加一个短延时或确认帧等世界模型稳定后再执行。另一个可能是kick_power和kick_angle的符号约定反了用监视器实测一次就能确认。5.4 现象多机器人互相碰撞或抢球原因队友之间的角色分配没有协调或者通信消息丢失。解决检查团队通信逻辑确认每个机器人有明确的角色前锋、后卫、守门员。如果通信不可靠可以用基于位置的隐式协调比如离球最近的机器人自动成为主攻。5.5 现象跑一段时间后 Agent 越来越慢原因日志文件无限增长或世界模型历史数据没清理。解决给日志加滚动策略限制世界模型历史长度。这类问题在长时间测试里才会暴露建议一开始就加上资源清理逻辑。6. 进阶技巧把冠军代码改成你自己的实验平台这套 2012robocup3d 冠军南邮可执行代码最大的价值不是复现当年成绩而是把它当成一个多智能体决策的实验平台。我自己的做法是保留底层通信和动作执行把上层决策替换成可配置的策略模块。比如把状态机改成行为树或者接入一个简单的强化学习策略做对比实验。具体操作上先找到决策入口函数通常叫think()或decide()把它抽成一个接口。然后写一个适配器让新策略输出和原状态机一样的动作指令格式。这样你可以在不改动底层的情况下快速对比不同策略的表现。# 策略接口示例 class StrategyBase: def decide(self, world_model): raise NotImplementedError class FSMStrategy(StrategyBase): def decide(self, world_model): # 原状态机逻辑 pass class RLStrategy(StrategyBase): def decide(self, world_model): # 强化学习策略输出动作指令 pass逻辑说明这样抽象之后你只需要在启动时选择策略实现就能跑对比实验。参数说明world_model要包含策略需要的所有信息如果新策略需要额外感知就在世界模型更新阶段加进去。验证方法上我习惯用固定随机种子跑多轮统计进球数、控球率、传球成功率。不要只看单场结果多智能体系统波动很大。另外把每次实验的配置和结果存成表格方便回溯。最后说一个我自己的习惯每次改完代码先跑一个 30 秒的冒烟测试确认基本行为正常再跑长测试。这样能省下大量等日志的时间。这套代码虽然老但架构清晰拿来练手或者做课程设计都够用。希望帮到你。本文还有配套的精品资源点击获取
