简介：机器人世界杯救援仿真竞赛（RoboCup Rescue）是检验人工智能与灾难救援技术结合的经典赛项，这份代码包正是面向该竞赛的软件开发项目。资源适合备战RoboCup仿真救援组比赛的团队，也适合希望学习自主决策、路径规划、目标识别和多智能体协作的开发者。压缩包共包含43个文件，主体为42个Java源码文件，另附1个备份文件，整体仅74KB；源码覆盖仿真环境接口、救援搜索策略、传感器数据解析和机器人控制等模块，结构清楚，便于直接阅读和二次修改。该资源已有1576人学习下载。借助这些代码，读者可以快速理解救援仿真中环境初始化、感知建模、任务分解和行动决策的完整流程；结合配置信息，还能围绕不同灾难场景开展算法实验，为后续使用仿真引擎搭建真实机器人系统打下基础。

1. 仿真救援考什么：被低估的三个得分点

仿真救援的面试题表面上围着“灭火”“寻路”打转，真正拉开差距的却是三件小事：世界模型怎么同步、信息不对称时怎么决策、多个智能体之间怎么协作。很多人背熟了A*、记住了火焰模型，一上机就被“数据从哪读、更新到哪去”这类基础问题绊倒，原因很简单——项目代码更像一套分布式决策系统，而不是单纯的算法题。这份仿真救援代码整理出的高频考点也照着这个逻辑排：先讲框架与数据流，再落地图建模、路径规划，最后用易错点收网。适合三类人：啃过仿真源码但理不清主循环的人、准备智能体/机器人方向面试的人，以及想拿一套可复现代码支撑项目讲解的人。

2. 高频考点：体系结构、数据流与感知-决策-执行框架

面试官问体系结构时，往往不是让你背架构图，而是随手指一个模块追问：“这条数据是哪来的？经过几跳？最后落到哪个结构里？”能把三层讲清的人，通常比只会背A*的人更容易过。仿真救援代码的得分点，恰好就在这套分层逻辑上。

2.1 三层结构：环境、智能体与中心各自管什么

环境层负责步进。仿真中的一切变化都以step为单位推进，火焰向邻接建筑蔓延、伤员血量随时间衰减，都发生在环境层。它每回合向外输出一份“本回合可见的数据包”，而不是一张全局真值地图。很多考生把环境层当成“游戏地图”来理解，开局就调取全图信息，这是第一处容易踩坑的地方。

智能体层是写代码最厚的一层。警察智能体负责清理道路障碍，消防员智能体负责扑灭火源，救护员智能体负责把重伤员运回救护中心。每个智能体都有自己的视野半径和通信半径，视野之外的信息一概看不到。正是这种“看不到”让仿真救援更像真实救援，也让高频考点集中在局部感知与信息融合上。回答“智能体如何协作”时，先讲视野限制，显得你真正读过仿真逻辑。

中心层做汇总。三类中心分别接收下属Agent上报的信息，整理成全局视角的态势图，再下发任务建议。注意是“建议”不是“指令”，因为仿真场景中存在通信带宽限制，中心发出的消息可能晚到甚至丢失，Agent不能完全依赖中心。面试时被问“中心有什么用”，先说汇总，再说协调，最后补一句“不可完全依赖”，分就出来了。

# 智能体主循环：一次仿真步里完成的四件事 class Agent: def step(self, world): # 1. 感知：从模拟器读本回合的可见信息 perception = world.sense(self.position, self.range) # 2. 更新：把感知写进本地世界模型 self.model.update(perception, current_step) # 3. 决策：根据世界模型选择动作 action = self.decide(self.model) # 4. 执行：把动作发给环境，等待下一回合结算 world.act(self.id, action) return action

感知是每个回合的第一步，返回结果只包含该Agent可见范围的数据。更新时机决定后续决策质量，如果把感知数据拖后一个回合写入，火焰蔓延和伤员血量早就变了，决策基于过期信息，角色会原地打转。执行只发一个动作，多数实现里动作是移动、灭火、清障、装卸伤员这类原子操作。主循环的功能区分比代码技巧更重要，面试官追问时，把四行逻辑讲清楚，胜过背十遍设计模式。

2.2 数据流：从传感器读到世界模型的“黑匣子”

数据流可以拆成三条：感知流、通信流、推断流。感知流是Agent亲眼看到的信息，可信度最高；通信流是其他Agent或中心转发来的，存在延迟和丢包；推断流是基于模型推算出来的，比如火焰下一步烧到哪里，只能作为趋势参考，不能当作已确认事实。三条流的处理优先级应当是感知最高，通信次之，推断最低。

很多考生翻车的地方，是把三条流混在一起，答题时直接说“地图是全局已知的”。实际上仿真代码里只有三种格子：“我走过并确认的格子”“队友告诉我但可能有延迟的格子”“我完全没信息、只能靠猜的格子”。面试官听到你主动区分这三类，就愿意继续往下问，因为这说明你知道世界模型不是一张静态图，而是逐步维护出来的状态。

class WorldModel: def __init__(self): self.confirmed = {} # 感知过，可直接用于规划 self.reported = {} # 通信获得，记录来源与步数 self.predicted = {} # 模型推断，仅用于风险预判

读写这套模型时，每条记录都要附带时间戳或步数。地图更新不是“有一个地图对象被刷新”，而是逐格确认置信度：query时先查confirmed，查不到回退到reported，最后再看predicted。这样设计的好处是，路径规划不会被“半真半假”的格子带偏。面试里讲到这一步，几乎等于告诉对方，你踩过这个项目的坑，并且已经补好了。

2.3 真题演练：Sense-Think-Act 顺序为何不能调换

真题形态：主循环里为什么必须先感知、再决策、最后执行？直接把感知和行动的顺序调换会怎么样？

答题按三层来。先行动等于用上一回合的地图做这一回合的决策，动态障碍会让Agent撞墙、走进火场、踩上新出现的封锁点，表现就是角色来回抖动。先决策后感知等于闭着眼睛做计划，所有路径规划用的都是旧参数，行动落地时世界早已变化。仿真的“步进结算”发生在环境更新阶段，Agent的动作不会立刻反馈给自己，顺序颠倒会让本回合结果不可复现。

再往下追问，通常会变成：“感知到道路被封，要不要每步都重规划？”标准答法是不要。先判断剩余路径是否经过被封区域，且是否存在绕行代价更小的替代路径，再决定局部绕行还是全局重规划。重规划触发得越频繁，动作越抖动，反而暴露你没做状态管理。面试官想听的，其实就是一句“重规划要有明确触发条件，而不是无脑重算”。

3. 高频考点：地图勘探与状态建模，把未知地图变成可算的图

仿真救援的真正开端不是救人，而是“把地图建出来”。开局时大多数区域是黑的，什么都不清楚。这道题不考你会不会写BFS，考的是你能否让一群互通信件有限的Agent，用最短步数把地图变成可规划的图。地图建模的准确度直接影响后面所有决策，这个顺序面试官会反复追问。

3.1 占领栅格与分区探索：把未知地图变成可算的图

常见做法是把地图按二维网格切块，每个Agent认领一个区块进行边界探索。边界探索的核心是“沿未探测格子的边缘走”，每走一步，把新看到的格子标记为已确认。为了防止多Agent扎堆探索同一个区域，分区策略很关键：每个Agent只负责自己范围内的边界格，本区探完再去支援邻区。

def explore(border_cells, known_map): # 把当前所有边缘格子入队，逐层外扩 frontier = deque(sorted(border_cells, key=lambda c: c.dist_to_center)) while frontier: cell = frontier.popleft() for n in neighbors(cell): if n not in known_map: known_map[n] = 0.5 # 标记为待确认 frontier.append(n)

边界格子按“距中心距离”排序，是为了优先探索开阔区域，避免一开局就扎进建筑群迷路。known_map里的值不是朴素的0和1，而是置信度：0.5表示听说过但没亲眼确认，1.0表示真实走过。路径规划只允许使用高置信度格子，低置信度格子只提供参考。这段代码讲完后，主动补一句“地图状态是分级的，不是布尔量”，面试官就能确认你理解仿真与普通寻路Demo的区别。

3.2 火焰蔓延模型：预测火势从哪一步开始

火焰蔓延是按格点传播的：一个格子是否被点燃，取决于自身当前温度、周围邻居传给它的热量、以及该建筑的可燃度。预测的价值在于，消防队需要在“最佳灭火窗口”前到场，而不是等到火势铺开后被动响应。仿真救援里算的是“还有几步会烧到关键建筑”，不是“此刻哪里在冒烟”。

def next_burn(temp_current, temp_neighbors, fuel): # 超过阈值的邻居会把火传给当前格 induced = max(temp_neighbors) * 0.3 temp_next = min(temp_current + induced, fuel.ignition) return temp_next >= fuel.ignition # 达到点火阈值则被点燃

这段代码里，induced是邻居热度贡献，max(temp_neighbors)取四邻域最高温，0.3是传播系数，ignition是点火阈值。预测结果常用于两件事：给路径规划提供风险权重，给灭火队估算最晚到达步数。0.3不是固定值，不同建筑材质差异很大。调参不要凭手感，那种“看着差不多就行”的做法很容易被面试官一句“你的参数是怎么标定的”问住。正确做法是回看竞赛日志或离线回放，把预测燃烧结果和实际燃烧结果对齐后再确定系数。

3.3 真题演练：地图不完全时，消防队的重规划时机

真题形态：队伍按全局规划好的路径前进，前路突然发现被封锁，智能体应该怎么办？

第一层答案是路径失效判断。先检查剩余路径是否经过已知封锁格，如果经过，再确认是否有绕行边。第二层是重规划策略：优先局部绕行，绕行距离超过安全余量时再全图重算，全部不可行才考虑叫警察清障。第三层是信息回传：重规划完成后把新路径广播出去，不然队友还在按旧地图画圈。

这类题最容易答漏的是“信息回传”。很多考生答到“重算路径”就停下来，实际上仿真救援的扣分点在于，你的Agent重算了，队友不知道，整个队伍还是乱的。面试官最想听的是：“重规划后的路径要写入世界模型，并通过通信分发给受影响队友。”加上这句话，这道题基本就稳了。

4. 高频考点：路径规划与多智能体协作，算法题和调度题一次答全

到了这里才算进入很多人以为的“正题”。路径规划考的不只是A*，任务分配考的不只是贪心。仿真救援里的路是会堵的，火是会蔓延的，伤员窗口是会关闭的。面试题往往把算法和调度揉在一道场景题里，要求你先说策略，再落到具体函数。

4.1 路径规划：A*之外还要处理路障、门禁与拥堵

传统A假设所有格子通行代价一致，仿真救援里道路可被封、桥梁可被毁、火场边缘风险高，只写一个裸A显然不够。要维护一个动态风险场：把已知封锁格加入blocked，把火焰预测热度折算成路径代价，靠近火源的格子不是不能走，而是代价很高。

def a_star_with_risk(grid, start, goal, blocked_cells): frontier = PriorityQueue() frontier.put((0, start)) came_from, cost_so_far = {}, {} while not frontier.empty(): cur = frontier.get()[1] if cur == goal: break for nx in neighbors(cur): if nx in blocked_cells: continue risk = grid.risk(nx) # 来自火焰预测模型 new_cost = cost_so_far[cur] + 1 + risk if new_cost < cost_so_far.get(nx, 1e9): cost_so_far[nx] = new_cost frontier.put((new_cost, nx))

关键点在risk这一行。risk不是当前可见热度，而是世界模型里预测出的热度，它会把路径整体向安全区域带偏。真正需要回答的是“防火路径”，不是“最短路”。如果面试官追问“没有安全路怎么办”，答：允许以代价形式穿过风险区，但穿越前先判断剩余血量是否撑得住。仿真救援不允许“绝对绕行”，因为有些任务必须穿过轻微风险区才能到达伤员。

4.2 任务分配：救人、救火、清障的优先级公式

任务分配可以看成“带时间窗的最小损失问题”。三个子任务——救人、救火、清障——不可能同时完成，必须排序。常用方案有三种：中心统一分配，简单但通信依赖强；市场竞拍，各Agent对任务报价，适合分布式；优先级矩阵打分，速度快，最适合面试讲解。

def task_score(task, agent_time, agents): # 前置条件：能否在有效窗口内到达 if agent_time > task.deadline: return -1 # 收益：受影响人数 + 紧急度 - 救援难度 score = task.people * 2 + task.urgency * 3 - task.difficulty return score

agent_time是通过路径规划算出来的到达步数，deadline是伤员存活时间或火势蔓延窗口。deadline一旦算错，后面所有分数都失去意义。所以这类函数一定先把“可到达性判断”放在最前面，再谈收益。面试里讲到这，要主动强调“先判可行性，后算最优性”，这句话能贯穿绝大多数场景题。

4.3 真题演练：两支队伍、三个目标，怎么分

真题形态：只有两支消防队，三个火源，先救哪一个？

最容易翻车的答案是直接挑“火焰最大”或“距离最近”的目标。正确的是把每个火源换算成“队伍到达后的预计损失”。火源蔓延速度、旁边有没有医院或关键通道、火灾是否会阻断救护路线，都要纳入计算。火源A离队伍最近，但周围没有建筑，燃烧损失有限；火源B虽然远，却能阻断通往医院的必经之路，那B必须排在前面，因为阻断逃生路线的损失更大。

另一个高频变体是：警察清障和消防灭火先做哪个？答案是“看目的地是否可到达”。如果灭火路径被堵，消防队到了也只能等着，先让警察清障再让消防队进场，顺序颠倒等于白跑一趟。如果时间窗口很紧，则让警察清障与消防队绕行并行。面试官要的不是标准答案，而是你能把“时间窗口、任务收益、可达性”三个变量系统排进去的思考过程。

5. 易错点：仿真救援最容易失分的四个地方

仿真救援项目跑不通，面试答不准，大多是栽在几个“想当然”上。下面的四条是历年考生翻车率最高的位置，每一条都按“错在哪、为什么错、怎么答对”拆开。讲解项目时能主动指出其中一条，比背十道算法题都更能体现真实项目经验。

5.1 错把仿真时钟当真实时间

错在哪：计算伤员剩余时间或火焰蔓延窗口时，直接用真实世界秒数去估算。

为什么错：仿真环境按step推进，一次step对应真实时间可能是几百毫秒，也可能是几十毫秒。救人窗口应当由“剩余步数”决定，而不是由gettimeofday这类真实时间决定。用真实时间计算，决策会偏早或偏晚，代码在自己机器上正常，换到服务器上行为完全漂移，成了玄学。仿真救援的时间轴从来不是“每秒一步”，而是“每步一决策”。

怎么答对：初始化时记录步长与真实时间的换算关系，所有优先级计算统一使用仿真步数。答题时主动说“我所有时间变量都是step_tick”，并解释原因：step是仿真环境唯一的推进单位，火势、血量、通信延迟都按它变化。这样回答，面试官会立刻明白你读过主循环逻辑。

5.2 误把“我方地图”当全局已知

错在哪：主循环里拿到的world对象看起来像“全局地图”，于是直接当成无损信息参与规划。

为什么错：Agent视野有限，world里只有自己感知过的区域和通信带回来的信息。把未知区域默认成可通行，会让路径直接穿越未探索区，结果撞墙、撞上封锁道路，甚至在建筑里卡住。很多仿真救援代码一开局就乱动，原因不是A*没写好，而是地图可信度没有分级。

怎么答对：写地图时把每个格子标记为confirmed、reported、predicted、unknown四种状态。路径规划只在confirmed和reported上计算，predicted只用于风险提示，unknown根本不能进入寻路图。这一条写进项目说明里，面试时讲出来，会让你的代码显得很“有工程感”。

5.3 只算全局最优，不算到达时间够不够

错在哪：一门心思把路径优化到“最短步数”，却忽略了伤员存活窗口或火势蔓延窗口。

为什么错：仿真救援的比赛评分基于救援结果，不是路径长度。一条路径再优美，如果到达时间已经超过伤员存活步数，规划就是无效的。许多考生把大量时间花在调A*的启发函数上，最后却栽在“能到达”与“来得及到达”不是一回事上。

怎么答对：先判可行性再谈最优。把当前步数与预计到达步数相加，与目标时间窗口比较。若超窗，至少有三条出路：换一个更近的Agent、降低该任务优先级、拆分子任务分批完成。答题时把这三条备选方案说出来，就能跳出“只会调路径”的刻板印象。

5.4 把通信当成“免费午餐”

错在哪：认为中心的消息能瞬间、无损地送到每个Agent手上。

为什么错：仿真里通信有带宽和丢包设定。中心广播给全体、各Agent又同时往中心汇报地图，通信队列会拥塞甚至丢消息。现场表现为消息延迟、重复和乱序，Agent如果按旧消息行动，会在地图已更新的情况继续走老路。项目里看起来像“不同智能体行为不一致”，本质是消息没有带时间戳。

怎么答对：Agent本地保留“消息步数”，只处理比本地决策步更新的消息；中心控制广播频率，防止一回合内塞入大量重复地图报文；关键消息丢失后，下一回合主动重发，而不是让Agent进入等待状态。答题时说出“我只处理新于本地决策步的消息”，这短短一句，就是通信模块的完整答案。

提示：以上四条不是理论安全，而是仿真救援面试最常见的追问点。能主动暴露自己踩过的坑并用代码逻辑解释，比罗列十个算法名更有效。

6. 押题思路与答题模板：三类必考题的标准动作

仿真救援的面试题翻来覆去其实只有三类：可行性、信息不完整、多智能体冲突。与其背资料，不如记住三套标准动作，考试和面试都能直接套。

外加一套兜底答题框架：“先做可行性判断，再做最优选择，最后补一个备份方案。”这一句话能应对大多数场景题。可行性解决“能不能到”，最优选择解决“到哪去”，备份方案解决“信息变化了怎么办”。仿真救援所有题目，几乎都是这三层里的某一层。

用这个框架去重读代码，就一个习惯：别急着堆高级算法，先跑通最小闭环。最小闭环只有四步——一条感知更新、一个决策函数、一次动作执行、一轮本地日志记录。先保证这四步在单个仿真步内完整跑通，再去加火焰预测、市场竞拍、动态避障。很多仿真救援代码崩掉，不是算法不行，而是主循环还没稳就上了复杂模块。

我最初调这类代码时，把一整天都花在把火焰蔓延参数调得“很像真实”，后来才明白，竞赛服务器不会因为你参数像真实就给分，它只看决策是否在时间窗口内落地。从那以后，我拿到任何一套仿真救援代码，都强制先画一遍数据流，再跑一遍最小闭环，最后才开始调参。希望帮到你。

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