仿真救援多智能体：世界模型、任务分配与路径规划实战

简介：Robocup仿真救援代码面向参加RoboCup Rescue仿真救援竞赛的队伍，以及希望了解救援机器人软件架构的学习者，围绕虚拟灾害场景中的自主决策、搜索导航、环境危险评估与任务执行，提供可研读的代码样本。压缩包共43个文件，以42个Java源码和1个Java备份文件为主，整体约74KB，体积轻便，适合按类阅读和二次整理。代码组织涉及仿真环境构建、搜索与路径规划等算法、传感器数据处理、控制指令生成、日志评估及配置定义等环节，可帮助读者理解从环境建模到机器人行为落地的完整链路。现有1579人学习或下载，适合作为竞赛入门、课程项目参考和算法实现对照材料，也便于团队据此拆解模块、讨论设计取舍并积累排错思路。

1. 仿真救援赛题到底考什么：先算分，再写代码

仿真救援这类赛题（多智能体在城市搜救场景里跑分数）最反直觉的一点是：它不是算法竞赛，是资源调度竞赛。不少人上来就堆 A* 和强化学习，跑完一看总分没动——因为评分公式里救出平民数、存活时间、建筑损毁、道路疏通各占权重，你的算法只影响其中一两项。拿分逻辑很朴素：每个时间片的动作预算固定，谁能在信息不完整、通信被限流的条件下把最贵的动作放在最值钱的地方，谁的分就高。这套仿真救援代码适合三类人：正在备战仿真救援赛题的队伍、做多智能体与路径规划方向、要面机器人或算法岗的。后面按「世界模型 → 任务分配 → 路径执行 → 易错点 → 押题模板」的顺序拆，每一段都能直接拿去练。

2. 地图与通信层：世界模型、带宽限流、地图合并三件事

仿真救援代码翻车最高频的地方不是决策算法，而是世界模型。地图怎么表示、实体怎么存、时间片怎么推进，这三件事一旦定死，上面的决策层才能随便换；反过来，如果世界模型把「传感器看到的」和「自己推出来的」混在一个字典里，跑十分钟就会出现幽灵平民和幽灵火点，排查起来纯靠玄学。这一章的三块内容是所有后续模块的地基，也是面试里最爱追问细节的部分。

2.1 世界模型三件套：地图、实体、时间片

先说地图。仿真救援里常见两种表示：节点-边图（路口是节点、道路是边，边带长度和通行状态）和栅格图。选节点-边图的理由是路径规划和寻路开销可控，且天然能表达「道路被阻塞」这类状态；栅格图更适合做局部避障和覆盖探索。仓库里两类结构通常同时存在，节点-边图做全局路由，栅格做局部决策，别指望一张图打天下。

再说实体。Agent、建筑、平民、道路，字段差别很大，但有几项是共通的：全局 id、类型、坐标、属性字典、最后一次被观测到的时间片（tick）。最后这个字段是很多人漏掉的，它决定你的世界模型是「活的」还是「死的」——没有它，一个三分钟前看到的火点会被当成正在燃烧，消防车跑过去扑空。

第三件是时间片。仿真按 tick 推进，每个 tick 你的 Agent 只能读一次感知、发有限条消息、下一个动作指令。这意味着任何一层逻辑超时，整个决策链就断。血泪经验是把世界模型写成纯数据层，禁止在里面调用寻路、禁止在里面做搜索，只允许读感知、写状态、出快照。

# world_model.py 只做三件事：吃感知、存状态、出快照 from dataclasses import dataclass, field @dataclass class Entity: eid: int kind: str # 'fire' / 'police' / 'ambulance' / 'civilian' / 'building' / 'road' pos: tuple # 世界坐标 (x, y) props: dict = field(default_factory=dict) # hp / buried / fiery / blocked / severity last_seen: int = -1 # 最后一次被观测到的 tick，用来算置信度衰减 class WorldModel: def __init__(self, graph): self.graph = graph # 节点-边图：节点带坐标，边带长度与通行状态 self.known = {} # eid -> Entity，只放本 Agent 亲身观测过的 self.shared = {} # 通过通信拿到的公共黑板，条目数受带宽约束 self.tick = 0 def update(self, percepts, tick): self.tick = tick for p in percepts: # percepts 只包含传感器半径内的实体，天然是局部的 e = self.known.get(p['eid']) if e is None: self.known[p['eid']] = Entity(p['eid'], p['kind'], p['pos'], dict(p['props']), tick) else: e.pos, e.props, e.last_seen = p['pos'], dict(p['props']), tick self._decay(tick) def _decay(self, tick, half_life=30): # 超过 half_life 个 tick 没再看到的实体，置信度按半衰期往下掉 for e in self.known.values(): e.props['confidence'] = round(0.5 ** ((tick - e.last_seen) / half_life), 3)

这段骨架的关键在last_seen和confidence两个字段。half_life的取值直接对应「你多久没看到就认为它变了」：地图小、Agent 多的配置可以给 20，地图大、通信差的配置给 40 到 60，否则刚探完的区域会被自己的衰减逻辑判成未知，白白重复探索。known和shared分开存，是为了让「我亲眼所见」和「别人告诉我的」在冲突时有明确的优先级，合并策略放在 2.3 讲。

时间片预算也得落到代码里。设一个 tick 的计算上限（比如主循环里计时，超过阈值就降级到只跑贪心决策），比任何优化都管用，因为仿真环境对超时的惩罚是跳步，跳一步可能就错过一次救人窗口。

2.2 通信被限流：消息优先级与增量同步

仿真救援的通信不是无限的，常见配置里每个 Agent 每个时间片能发的消息条数是个位数，字节数也有限。绝大多数队伍的默认写法是「每个 tick 把自己知道的全部广播一遍」，前 30 个 tick 就跑满了带宽，后半程全员失联。真正稳的做法是三层：只发变化量、按优先级排队、按需拉取。

优先级怎么定，判断标准只有一条：这条消息晚发 5 个 tick，会不会导致有人跑错方向。平民状态和任务租约属于「晚发必炸」，位置心跳属于「晚发无所谓」。增量同步的写法是给每个实体记一个version，只有版本变了才进待发队列，队列按优先级排序后截断到带宽上限：

def flush(self, budget): # 待发队列按 (优先级, 版本号) 排序，超预算的留在本地等下一个 tick queue = sorted(self.outbox.values(), key=lambda m: (m['prio'], m['ver'])) sent = [] for m in queue[:budget]: send(m['payload']) sent.append(m['key']) for k in sent: self.outbox.pop(k, None)

budget是每 tick 的消息条数上限，prio越小越优先。注意这里没做「重传」，因为救援场景里旧消息的价值衰减极快，与其重传一条五秒前的火情，不如把这个名额让给新发现的平民。这条取舍在面试里被问到「你怎么保证信息一致性」时，是最有说服力的回答：不追求一致，追求新鲜。

2.3 真题演练：局部地图合并的四步作答模板

真题长这样：「两个 Agent 各自维护一张局部地图，如何合并成全局地图？冲突怎么办？」这题在笔试和面试里出现频率都很高，答得好不好，一听就知道你有没有真跑过仿真。

标准四步：第一步坐标变换，用 Agent 自身位姿把局部坐标转到全局坐标；第二步近邻去重，半径内已有点不再新增；第三步证据叠加，同类别用概率累积而不是简单覆盖；第四步冲突消解，类别不同时按置信度择优，置信度接近时保留观测时间更新的那条。

import math def to_global(pose, pt): """pose=(x, y, theta)；把局部坐标 pt 变换到全局坐标，theta 为 Agent 朝向""" x, y, th = pose lx, ly = pt return (x + lx * math.cos(th) - ly * math.sin(th), y + lx * math.sin(th) + ly * math.cos(th)) def merge_map(local_feats, global_map, pose, conf_th=0.6, radius=0.5): """local_feats: [(局部坐标, 类别, 置信度)]；global_map: {(gx, gy): [类别, 置信度]}""" for pt, cls, conf in local_feats: g = to_global(pose, pt) key = nearest_key(global_map, g, radius) # 半径内查已有点，实现用网格哈希即可 if key is None: if conf >= conf_th: # 低置信度的新点先不入图，避免污染 global_map[g] = [cls, conf] continue old_cls, old_conf = global_map[key] if cls == old_cls: global_map[key][1] = 1 - (1 - old_conf) * (1 - conf) # 证据叠加：两次独立观测 elif conf > old_conf + 0.2: # 冲突时留出容差，避免来回抖动 global_map[key] = [cls, conf] return global_map

radius是去重半径，取值跟定位精度挂钩：噪声大就给 0.8 到 1.0，噪声小给 0.3 到 0.5，给太小会在地图上叠出一堆重复点，给太大会把相邻的两个路口合并成一个，路径规划直接穿墙。conf_th是入图门槛，火灾场景里建议给高一点，因为把没火的建筑标成火点，会让消防车白跑一趟，成本远高于漏标一次。

面试官最想听的其实是第四步里的「容差」两个字——说明你知道多源观测必然冲突，且冲突不能靠一刀切解决。如果你还能补一句「合并后的图要回灌给每个 Agent 的黑板，但只回灌差异部分，否则带宽扛不住」，这题基本就满分了。

3. 任务分配与多智能体协作：拍卖、分区、冲突消解

世界模型建好以后，第二层是「谁去做哪件事」。仿真救援里 Agent 类型不同、能力不同、位置不同，一个平民被埋在建筑里，救护车要先去，警察要先疏通路，消防要压住火势不让蔓延——这是典型的多约束分配问题。这一章按「出价 → 分区 → 冲突」三层递进，每一层都对应一道常考题。

3.1 拍卖算法的四个参数与出价函数

拍卖（auction）是仿真救援里最常用的分配机制：任务挂出来，各 Agent 按自己的成本出价，价低者得。听起来简单，实际调参能把人逼疯。四个必须显式定义的参数是出价函数、轮次上限、冷却期、任务粒度。

出价函数决定分配质量。最低配的写法是「距离越近越便宜」，但救援场景里至少得叠三项：距离成本、紧迫度、能力匹配。紧迫度来自实体的severity字段，能力匹配是一个硬约束——救护车抢到灭火任务就是纯浪费。

def bid(agent, task, world, w): # 出价越低越可能中标：距离拉高成本，紧迫度和能力匹配压低成本 dist = world.graph.shortest(agent.pos, task.pos) # 节点-边图上的最短距离 urgency = task.props.get('severity', 0.0) # 0~1，来自世界模型的置信度加权 capability = 1.0 if task.kind in agent.can_handle else 0.1 return w['dist'] * dist - w['urg'] * urgency - w['cap'] * capability

w['dist']给 1.0 是基准，w['urg']给 3 到 5 才能让紧迫任务真正插队，w['cap']给 2 左右保证类型不匹配的 Agent 基本抢不到。三个权重的相对大小比绝对值重要，调参时先固定dist为 1，只动另外两个。

轮次上限和冷却期是为通信带宽服务的。轮次上限一般给 2 到 3，再多也收敛不了多少；冷却期是同一个任务被释放后多久才能重新挂出，给 5 到 10 个 tick，防止两个 Agent 反复抢同一个任务把带宽烧光。任务粒度最容易忽略：把一个建筑拆成「灭火」「救人」「探查」三个子任务，比整栋建筑打包挂出来灵活得多，但也更容易产生碎片，一般按建筑内平民数量决定要不要拆。

3.2 分区策略与重复探索的代价

分区解决的是「一群 Agent 别都往一个方向跑」。常见三种：按网格硬切、按 Voronoi 就近划分、按信息熵动态划分。硬切实现最省事，缺点是边界处容易空跑；Voronoi 按 Agent 当前位置生成责任区，开局很漂亮，但 Agent 一移动就要重算，重算开销会吃掉收益；动态划分按「哪块区域最不确定」分配，效果好但需要全局信息，通信差的时候退化成随机。

重复探索率是这一块唯一值得盯的指标：统计一段时间内被两个以上 Agent 观测过的格子占比。经验值在 15% 以下算健康，超过 30% 说明分区失效，先查世界模型的未知区域标记是不是没更新，再查任务释放逻辑是不是漏了。

收益递减这件事必须写进决策里。一个区域探了 80% 以后，剩下 20% 的边际收益远低于去支援一场火情。很多队伍的分区逻辑是静态的，前 200 个 tick 表现很好，后面全在空转。做法是给每个区域算一个「剩余价值」，价值和距离一起进拍卖，让 Agent 自己决定要不要换区。

3.3 面试题：重复指派和死锁怎么答

题面通常是：「多个 Agent 同时选中同一个目标，导致互相等待或重复劳动，你怎么解决？」这是多智能体协作的经典题，答得好不好看她有没有分层。

第一层，说清原因。三类：信息不同步（各自的世界模型不一致）、出价函数同质（成本算出来一样，自然抢同一个）、缺少占用状态（没人记录「这个任务已被认领」）。能主动拆出这三类，说明你 debug 过。

第二层，给解法。信息不同步靠增量同步加版本号；出价函数同质靠加噪声或加 Agent 维度的惩罚项（比如已认领任务加一个固定成本）；缺少占用状态靠任务租约——认领时写一个到期 tick，到期没完成自动释放，避免某个 Agent 卡死后任务永久锁死。

第三层，说清仲裁规则。两个 Agent 同时认领成功时，按「能力匹配度 > 距离 > id 字典序」三级比较，最后一级纯粹是为了确定性，保证复盘时结果可复现。这句「用 id 兜底是为了可复现」很少有人讲，但它是加分项。

最后补一句实测结论，比如「租约给 30 个 tick 比给 10 个 tick 稳，给太短会出现任务反复释放、Agent 来回改目标」。面试官要的就是这种带参数的结论。

4. 路径规划与执行层：A* 变形、重规划触发、拥堵代价

第三层是「怎么走过去，以及走不过去怎么办」。仿真救援的路径规划和课本上的 A* 差别很大：图是动态的（路会被塌方堵死）、代价是时变的（拥堵、火势蔓延）、而且你永远只有部分地图。这一章的三个考点在笔试里出现频率极高，代码题也基本从这里出。

4.1 A* 的三个变形与选用场景

选型逻辑很直接：tick 预算够就上拥堵感知 + 增量重规划，预算紧就加权 A* 加简单避让。判断预算够不够的方法是在主循环里打点，看单次寻路占了多少毫秒，超过 tick 时长的三分之一就必须降级。

拥堵感知里最容易被忽略的是「惩罚要衰减」。如果一条边被三个 Agent 占了就永久加惩罚，最后整张图所有边都被标脏，寻路结果退化成随机。正确做法是惩罚项按 tick 衰减，或者干脆每 tick 重算一次占用表。

4.2 移动失败与重规划触发条件

仿真里经常出现「指令下了但没动」：路被堵、目标边塌了、前面有别的 Agent 卡住、剩余时间不够走过去。不处理这些，Agent 会站桩站到比赛结束，这就是没有后悔药的典型。

重规划触发条件至少四条：连续 N 个 tick 位置没变（N 给 2 到 3）、收到消息说目标边阻塞、当前路径包含已阻塞边、到达目标所需时间超过任务剩余时间。四条里前两条是硬触发，后两条是软触发。

软触发要配退避策略。同一条路堵了，第一次重规划绕远路，第二次还堵就换任务，别在原地无限重算。做法是给每个 Agent 一个重试计数，超过阈值就主动释放当前任务回拍卖池，让别的 Agent 接手——释放比死磕划算得多。

还有一个细节：重规划要基于「最新世界模型」而不是「上次寻路时的快照」。很多实现里寻路函数直接吃缓存图，结果阻塞信息更新了但路径没变，Agent 一头撞上去。

4.3 代码题：带拥堵代价的路径规划

题面：「给定节点-边图、阻塞边集合、每条边当前的 Agent 数量，求从起点到终点的最小代价路径。」这题是笔试常客，考的就是能不能把动态代价正确塞进 A*。

import heapq def astar_congestion(graph, start, goal, blocked, crowd, w=1.5): # blocked: 不可通行边集合；crowd: {(u, v): 该边当前 Agent 数}；w: 拥堵惩罚系数 open_heap = [(0.0, start)] g_cost = {start: 0.0} parent = {} while open_heap: _, u = heapq.heappop(open_heap) if u == goal: break for v, base_len in graph.neighbors(u): if (u, v) in blocked: continue # 硬约束：阻塞边直接跳过 step = base_len * (1 + w * crowd.get((u, v), 0)) # 拥堵代价随占用数线性上升 ng = g_cost[u] + step if ng < g_cost.get(v, float('inf')): g_cost[v] = ng parent[v] = u heapq.heappush(open_heap, (ng + heuristic(v, goal), v)) return rebuild_path(parent, start, goal) # 回溯路径，无解时返回空列表

w是最关键的一个参数。给 0 就是普通 A*，全员挤最短路；给 1.5 到 2.0 能让 Agent 主动错峰，实测拥堵率下降明显；给到 5 以上会过度绕路，长距离任务反而变慢。heuristic用欧氏距离并乘一个略小于 1 的系数，保证可采纳性不破坏太多。crowd表要每 tick 刷新，否则惩罚是滞后的。

笔试答题时别只贴代码，补一句「无解时返回空列表，上层捕获后触发任务释放」，这一句能体现你考虑过失败路径。

5. 常见失分点：五类一跑就翻车的实现细节

代码能跑和能拿分是两回事。下面五类问题是复盘时最常见、也最容易被面试官追问的，每一条都按「错在哪 → 为什么错 → 怎么答对」拆开。

5.1 感知与决策耦合：一改就全崩

错在哪：感知结果直接进决策函数，决策函数里又顺手改世界模型，跑起来看着没事，一调参就出现状态不一致，日志里全是互相矛盾的火点。

为什么错：仿真救援的世界模型是多方共享的间接状态，任何一层都能写就意味着没人对正确性负责。而决策层最怕的就是「读到的世界在算的过程中变了」。

怎么答对：强制分层，感知层只写known，决策层只读快照，写操作一律走单一入口。答题时用一句话概括：「我把世界模型做成只读快照给决策层，写只发生在感知回调和通信回调里。」这句话在面试里价值很高。

5.2 单步超时：算得太久，时间片直接跳过

错在哪：为了追求分配最优，在主循环里跑全量搜索，某些 tick 算了几百毫秒，仿真直接跳步，Agent 少动一次，后面全乱。

为什么错：仿真环境对超时的容忍度接近零，它不会等你算完。而且超时往往发生在 Agent 数量多、任务密集的关键时刻，恰好是最不能跳步的时候。

怎么答对：主循环加计时，超过预算的 60% 就降级到贪心策略，超 90% 直接返回上次的动作。同时把重计算放到缓存里，能复用就复用。答题时给出具体的降级梯度，比说「我会优化性能」有用得多。

5.3 把通信当无限带宽用

错在哪：每 tick 广播全量世界模型，前几十个 tick 就把带宽配额吃干净，后面全员静默，协作直接崩。

为什么错：带宽是硬约束，不是性能问题。很多人把它当优化项，等发现的时候架构已经改不动了。

怎么答对：从第一版就按「只发变化量 + 优先级队列 + 带宽预算截断」写，别等到出问题再补。答题时把带宽当成设计约束讲，而不是当成 bug 讲。

5.4 路径规划没有失败回退

错在哪：寻路返回空列表就return，Agent 原地不动，日志里一行报错都没有，复盘时完全看不出发生过什么。

为什么错：动态图里寻路失败是常态而不是异常，把它当异常处理，就等于默认它不会发生。

怎么答对：失败必须走三条回退——先换邻接目标重试，再换任务，最后释放任务回拍卖池。同时打日志记录失败原因（阻塞、无解、超时），这是复盘唯一的事实来源。

5.5 只盯救人数，忽略建筑与道路

错在哪：所有 Agent 都去追平民，火势蔓延导致建筑倒塌，最后平民被埋，总分反而更低。

为什么错：评分是多目标的，救人是显性收益，压火和疏通是隐性但更基础的收益。把显性收益最大化，往往是局部最优。

怎么答对：给每类任务算一个「止损价值」——建筑快塌时压火的价值高于救一个远处的平民。答题时讲清权重怎么定、什么时候切换优先级，比单纯说「我会综合考虑」强。

6. 押题思路：把仓库拆成三份能背的模板

到了考前最后阶段，再刷题收益有限，真正能提分的是把已有代码压成三份可以当场复述的模板：口述模板、代码模板、参数模板。这三份东西的用途不同，别混着背。

口述模板的骨架是固定的：先说场景（多智能体在城市搜救仿真里做任务分配与路径规划），再说分层（感知与世界模型、通信与同步、分配与执行），最后落指标（重复探索率、任务完成率、单步耗时）。这三句说完，面试官基本知道你不是背概念来的。

代码模板别贪多，三个函数足够应付绝大多数手写题：世界模型的update、带拥堵代价的 A*、拍卖的bid。写的时候注意两件事，一是注释写清楚每个参数的业务含义而不是语法含义，二是留一个「失败回退」的分支。白板上写代码，评审看的从来不是你能不能跑，而是你有没有把边界想全。

参数模板是拉开差距的地方。多数人只能说出「我调过参数」，说不出调到了多少、为什么是这个值。把半衰期 30 到 60、带宽预算每 tick 个位数、任务租约 30 tick、拥堵系数 1.5 到 2.0 这几组数记住，并且能解释每个数的上下界从哪来，追问就变成了你的主场。

押题方向我只押三条：多智能体重复指派与死锁、动态图下的重规划触发条件、带宽受限时的信息同步策略。这三条覆盖了协作、执行、通信三个层面，任何一条被问到，都能用上面三份模板拼出答案。

最后说个习惯。早些年我第一次被追问「你这个半衰期为什么是 30」，卡了十几秒，最后憋出一句「试出来的」，场面很难看。从那以后我每次改完参数，都强制走一遍「取值、上下界、失效表现」三问，写不进三问的参数一律视为没调过。这个习惯比多刷十道题有用。希望帮到你。

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