【Unity人群导航插件】Agents Navigation – Crowds 基于 Flow Field 的大规模人群导航方案深度解析

在 Unity 的 AI 导航领域，“少量智能体 + 精细路径规划”一直是主流思路。无论是 NavMeshAgent，还是在其之上叠加的局部避障系统，本质上都是以 Agent 为核心的计算模型。

但一旦场景规模扩大到成百上千、甚至上万单位——例如 RTS、塔防、战斗模拟、战争推演类游戏——这种思路就会迅速撞上性能天花板。

Agents Navigation – Crowds，正是为这种“巨大数量级”场景而生的一套导航扩展方案。

它不是简单优化 NavMesh，而是提供了一条完全不同的路径规划思路：Flow Field（流场）导航，并且从一开始就以 DOTS / ECS / Burst / Job System 为核心设计前提。

本文将从架构和算法层面，系统讲清楚这个插件到底是怎么工作的。

一、插件定位与整体架构

1. 插件在 Agents Navigation 体系中的位置

首先要明确一点：

Agents Navigation – Crowds 并不是一个独立导航系统它是 Agents Navigation 的扩展包

也就是说：

• 基础 NavMesh / Agent 框架 仍由 Agents Navigation 提供
• Crowds 只是新增了一套 “替代型路径计算方案”
• 两种 Agent 可以在同一场景中混合使用

这种设计非常关键，它意味着你可以：

• 精英单位 / 英雄 → 传统 NavMesh Agent
• 大规模杂兵 / 小兵 → Crowd Flow Agent

而不是被迫“全量替换”。

2. 技术栈与设计前提

Crowds 的整个实现，牢牢建立在以下技术基础之上：

• Unity DOTS / ECS
• C# Job System
• Burst Compiler
• SIMD 数学计算
• FixedUpdate 驱动逻辑

插件内部几乎所有核心系统都：

• 可并行
• 无 GC
• 数据导向（SoA）
• 面向 Cache Friendly 访问模式

这决定了它天然就不是“传统 MonoBehaviour 插件”。

二、为什么传统 NavMesh 不适合大规模人群？

在理解 Crowds 之前，必须先看清 NavMesh 的性能瓶颈在哪里。

1. NavMesh 的核心成本模型

传统导航系统中，每个 Agent 都要独立进行：

1. 路径搜索（A* / Dijkstra）
2. 路径修正
3. 局部避障（RVO / ORCA 等）
4. 转向与速度计算

这意味着：

性能成本 ≈ Agent 数量 × 单 Agent 计算成本

当 Agent 数量上升到几百、几千时：

• 即便单个 Agent 很“便宜”
• 总体成本也会指数级膨胀

2. 局部避障是最容易“炸”的部分

尤其是在高密度人群中：

• 每个 Agent 都需要感知周围多个邻居
• 相互避让容易出现振荡、卡死、抖动
• 为了解决这些问题，算法复杂度进一步上升

这也是为什么很多 RTS 或塔防项目，最终都会放弃精细避障，转而采用更“粗糙但稳定”的移动方式。

三、Flow Field：Crowds 的核心思想

1. 什么是 Flow Field（流场）？

Flow Field 可以理解为：

一张覆盖整个地图的“方向场”

其核心特征是：

• 地图被离散成规则网格（Grid）
• 每个格子只存储一个最佳移动方向向量
• Agent 不再单独算路径
• Agent 只需读取当前格子的方向即可移动

换句话说：

路径规划从“Agent 级别”上升到“空间级别”

2. 方向是怎么计算出来的？

一个完整的 Flow Field 通常包含三层数据：

1. Cost Field（代价场）

• 每个格子的移动成本
• 障碍物 = 无限大
• 地形权重可定制

2. Integration Field（积分场）

• 从目标点开始反向传播
• 每个格子存储“到目标的最小总代价”

3. Flow Field（流向场）

• 每个格子指向积分值最低的邻居
• 本质是一个梯度下降方向

Crowds 中正是采用了这套经典结构。

3. Agent 如何使用 Flow Field？

Agent 的行为极其简单：

• 获取当前位置所在的 Grid Cell
• 读取该 Cell 的 Flow Direction
• 将该方向作为期望速度（Desired Velocity）
• 叠加少量物理或动画修正

没有路径缓存、没有路径重算、没有邻居查询。

四、Crowds 性能模型解析

1. 性能成本从“Agent 数量”转移

这是 Crowds 最关键的优势：

性能成本 ≈ Grid 大小 × Group 数量

而不是：

Agent 数量 × 路径复杂度

这带来的直接结果是：

• 100 个 Agent 和 10,000 个 Agent
• 在同一 Flow Field 下，几乎没有数量级差异

只要他们：

• 使用相同目标
• 属于同一个 Group

2. Group（群组）是核心概念

Crowds 并不是“完全自由”的系统。

它引入了一个非常重要的约束：

同一 Flow Field = 同一 Group = 同一目标

也就是说：

• 每新增一个目标
• 就需要重新计算一整张 Flow Field

如果 Group 数量失控：

• 性能优势会迅速下降
• 甚至不如传统 NavMesh

这也是插件文档中反复强调的设计前提。

五、Crowd Flow 如何解决避障问题？

1. 路径与避障的“天然融合”

在传统系统中：

• 路径规划：全局
• 避障：局部
• 两者经常互相打架

而 Flow Field 中：

• 障碍物已经体现在 Cost Field 中
• 流向本身就是“避开障碍的结果”

这意味着：

Agent 根本不需要“思考避障”

2. 为什么更不容易卡死？

因为：

• 所有 Agent 在同一格子内方向一致
• 不会出现“你往左我往右”的对冲
• 群体行为趋向“水流”而非“个体博弈”

代价是：

• Agent 个性被弱化
• 群体行为更明显

但这正是 RTS、塔防、战阵模拟最需要的特性。

六、DOTS / ECS 下的系统拆分

从架构上看，Crowds 采用了高度模块化的 ECS 系统设计：

1. 核心系统类型

• Grid 构建系统
• Cost Field 计算系统
• Integration Field 扩散系统
• Flow Direction 生成系统
• Agent Movement 系统

每个系统：

• 运行在 FixedUpdate
• 可独立 Job 化
• 支持 Burst 编译

2. 多层 API 设计

插件提供了：

• 低层 ECS API
  
  ：用于深度定制、自定义行为
• 中层行为模块
  
  ：常见 crowd 行为的组合
• 高层 Hybrid 接口
  
  ：面向 GameObject 使用者

这也是它能同时支持：

• 纯 ECS 项目
• 传统 OOP 项目

的关键原因。

七、Hybrid 模式：非 ECS 项目的现实选择

1. GameObject 与 Entity 同步

Hybrid 模式下：

• GameObject 作为“表现层”
• Entity 作为“逻辑与计算层”
• Transform 数据在两者之间同步

你可以：

• 用 Animator、MonoBehaviour
• 但把最重的导航计算交给 ECS

2. 性能代价与使用建议

官方也非常坦率：

• Hybrid ≠ 免费性能
• 同步本身有成本

但即便如此：

• 在 500+ Agent 规模下
• 仍然远优于纯 NavMesh

八、适用游戏类型总结

Crowds 并不是“万能导航方案”，它非常明确地偏向以下类型：

• 塔防（大量单位涌向同一目标）
• RTS（编队、集群推进）
• 战斗模拟（战线、阵型）
• 城市人群模拟

不太适合：

• 小规模精细 AI
• 高度个性化路径行为
• 强个体智能需求的 RPG

九、总结：这不是“更快的 NavMesh”

Agents Navigation – Crowds 的本质并不是优化，而是范式转换。

它用 Flow Field 把问题从：

“我该怎么让每个 Agent 更聪明？”

变成：

“我该怎么让空间本身更有引导性？”

如果你正在做的，是真正意义上的“大规模单位”游戏，并且已经开始被 NavMesh 性能拖后腿，那么 Crowds 很可能就是你一直在找的那条路。

它要求你：

• 接受群体优先于个体
• 接受目标共享
• 接受 DOTS 思维方式

但作为回报，它能带来的是：

数量级级别的性能提升与稳定性飞跃。

资源获取方式：公众号主页