兄弟们，不知道你们有没有遇到过这种情况：明明场景里摆了一堆箱子，代码里SetDestination写得贼顺，结果一运行，你那个两米高的巨人士兵愣是从一个半米宽的窗户缝里挤出去了，而旁边那个巴掌大的小蜘蛛却被一个门槛卡得原地转圈。我当时看着屏幕，手里那杯咖啡差点泼键盘上，心里就一句话：这导航，怕不是喝多了吧？

这还真不是咱技术菜，这是老版NavMesh的一个硬伤——所有NPC共用一张“地图”。甭管你是一头大象还是一只老鼠，寻路数据都是一样的，那能不出幺蛾子吗？Unity那群工程师估计也受不了这个，后来在AI Navigation包里整了个新活，也就是咱们今天要唠的，unity ai导航新增代理功能。

新增代理，咋就这么香？

咱把话说通俗点。以前的老系统，就像是全城只有一条通用道路，不管你是开大卡车还是骑小电驴，都得挤在这条道上。大卡车过不去的小巷子，它硬挤；小电驴能钻的缝，大卡车只能干瞪眼。

现在这个unity ai导航新增代理是啥意思？就是咱终于可以给不同的角色修不同的路了！给大块头修高速，给灵活的瘦子修小道，各走各的，谁也不碍着谁。

我记得第一次在Window → AI → Navigation那个Agents选项卡里点下那个“新增代理”按钮的时候，心里还挺忐忑。结果进去一看，好家伙，半径、高度、最大坡度、跳距，这些参数明明白白摆在那-1。我给那个两米高的卫兵设了个半径0.5米，高2米的Humanoid类型；给那个小蜘蛛设了个半径0.2米，高0.4米的Spider类型。完事儿在地面上挂了两个不同的NavMesh Surface，一个指定给Humanoid用，一个指定给Spider用，各自Bake一次。

运行起来那一刻，我糙，那个舒坦！ 卫兵老老实实走大门，小蜘蛛顺着墙根嗖嗖就钻过去了。这才是真实世界该有的样子嘛！

不光是走路，还得会“看路”和“让路”

光能走不同的路还不够，咱做游戏，动态障碍才是最让人头秃的。以前场景里放个箱子，你挪一下位置，就得重新Bake整个网格，CPU直接给你干满红温。现在不一样了，有了这个新增代理的配套组件，咱们可以玩点花的。

比如那个箱子，你给它挂个NavMesh Obstacle组件，把Carve模式打开-1。啥意思呢？就是这箱子要是没动，它就自动在导航网格上“挖个洞”，NPC远远看见了，直接绕道走，根本不用重新Bake整张图-2。要是箱子被人推着跑，你又不想让它频繁挖洞浪费性能，就把“Carve Only Stationary”勾上，动的时候当障碍物绕开，停的时候再挖洞-1。

我之前做过一个项目，敌人会推着油桶当掩体。用的就是这个逻辑，配合unity ai导航新增代理对不同兵种的设定，重装兵会绕开油桶走大路，敏捷型的小兵甚至会利用油桶做跳板翻越障碍。那一刻，我真觉得这帮AI活了，不再是那种傻乎乎的“寻路—碰撞—卡住”的死循环。

运行时烘焙，大世界终于不卡了

还有一个痛点，做开放世界的兄弟肯定懂——地图太大，导航网格直接吃爆内存。新版AI Navigation支持运行时烘焙-1。咱们可以在代码里直接调BuildNavMesh()方法-1，配合滑窗（Sliding Window）技术，角色走到哪，网格就动态生成到哪，只加载周围那一圈。

这就好比以前咱出门得背着一本市地图，现在有了导航APP，只看眼前那几百米。这性能消耗，直接降了一个维度。而且因为unity ai导航新增代理的存在，每个角色都只看自己需要的“那层地图”，内存复用率更高了，帧率自然就稳住了。

踩坑与吐槽

当然，新东西嘛，总有那么点小脾气。

比如那个代理的参数设置，刚开始很容易想当然。我给蜘蛛设的坡度太大，结果它老想着爬墙，在墙角疯狂抽搐。后来才发现，坡度不能光看数值，还得配合Height Mesh烘焙，不然角色走楼梯的时候是悬空的，那叫一个灵异事件-1。

再一个，Carve模式用好了是神，用不好是坑。有次我在场景里放了二十多个动态障碍，全开的Carve，结果一进游戏，帧率直接掉到个位数。后来看了官方文档才知道，得调Tile Size和Move Threshold，别让Unity每一帧都在那算挖洞-1-3。这就跟家里装修似的，你不能天天砸墙，得规划好了再动工。

现在每次用这个系统，我都会想起以前被老NavMesh支配的恐惧。那时候为了解决不同体型NPC的问题，什么歪门邪道都试过：手动分层烘焙、运行时切换网格、甚至写了一大坨判断逻辑让大个子在外面等小个子去开门……现在想想，全是泪。

所以说，Unity这个AI导航新增代理，真的不只是加了个按钮那么简单。它让咱们这帮做游戏的，能把更多精力放在玩法上，而不是跟这些底层逻辑死磕。行了，废话不多说，我知道你们肯定也有自己的糟心事，咱评论区唠唠？

网友问1： “博主你好，我按照你的方法设置了两个Agent Type，也分别Bake了两张网格。为啥我的小怪还是走大怪的路？明明我给小怪的Agent组件已经选了Spider类型了！”

回复： 哎，兄弟，你这问题我当初也踩过，当时差点把键盘砸了。你想想，你给地面挂的那两个NavMesh Surface，是不是都忘了指定对应的Agent Type？

是这样的，Surface组件上有个“Agent Type”的选项，默认是“Humanoid” -2。你要是只给地面Bake了一次，那这张网格就是给Humanoid走的。你虽然给小怪身上挂了Spider的代理，但它脚下踩的还是Humanoid的地图啊！这就像你给小电驴装了GPS，但地图给的是大卡车专用高架桥，它可不就懵了吗？

解决办法很简单：你需要在地面上再挂一个新的NavMesh Surface组件，在这个新Surface的Inspector面板里，把Agent Type从Humanoid改成你新建的那个Spider -2-1。然后选中这块地面，点Bake。这时候你就会看到场景里出现了两层不同颜色的网格（可能叠在一起，仔细看）。大怪走Humanoid那层，小怪走Spider那层，这才算真正“分道扬镳”了。

另外提一嘴，有时候你Bake了两层，但小怪还是走大怪的路，可能是小怪的NavMesh Agent组件里的“Agent Type”没改过来。这玩意儿默认也是Humanoid，你得手动给它掰到Spider上去。这俩地方但凡有一个没设对，你就等着看NPC集体梦游吧。别问我是怎么知道的，都是血泪史。

网友问2： “博主说的Carve模式能挖洞，性能影响大吗？我项目里可能有几十个可移动的箱子，全用Carve会不会卡爆？”

回复： 哈哈，几十个箱子？你这是要做仓库管理员模拟器吗？说正经的，Carve模式确实是性能杀手，但你只要懂它的脾气，它也能变乖。

首先你得明白，Unity不是每时每刻都在那挖洞。它有一个“Move Threshold”阈值-1。比如你设了0.5米，那箱子挪动距离小于0.5米，它就当你没动过，不重新挖。所以那些因为物理效果轻微晃动的箱子，给它设个稍大的阈值，能省不少事儿。

你千万别让移动中的箱子也挖洞。那个“Carve Only Stationary”选项一定要勾上-1。意思就是箱子在移动过程中，它就是个普通的“阻碍物”，代理们用RVO（互惠速度障碍）算法临时躲开它就行了-2。等它停下来了，再在网格上挖个洞，让后来的代理彻底绕道。这逻辑多聪明，你要是让飞驰的箱子边走边挖洞，那就等于让修路队跟着飙车党后面铺沥青，不卡才怪。

最后还有个压箱底的技巧：调小Tile Size。在NavMesh Surface的高级设置里，把那个默认的256改小点，比如64-1。这就好比把大块的瓷砖切成小马赛克，哪块坏了换哪块，不用把整个客厅地板都撬了。我做过测试，优化前后帧率能差出一倍。对付几十个箱子，这么整绝对稳。

网友问3： “我做的游戏里有飞行单位和地面单位，飞行单位无视地形。用这个新增代理系统能实现吗？需不需要单独搞一套逻辑？”

回复： 你这问题问到点子上了，很多做RTS或者塔防的兄弟都会遇到。

对于无视地形的飞行单位，其实不太适合硬套NavMesh那套逻辑。因为NavMesh本质是“贴地行走”的，你给飞行单位加代理，它会傻乎乎地跟着地形起伏飞，明明面前是空的，它非得绕个山包，看着贼蠢。

但咱也不是完全不用这个系统。我自己的做法是“双轨制”：
地面单位，老老实实用咱们上面聊的unity ai导航新增代理那一套，针对不同体型做区分。
飞行单位，我一般不挂NavMesh Agent，而是用简单的射线检测 + 平滑转向自己写个简单的飞行逻辑。因为天上没有障碍物（除了山脉和建筑），只需要判断目标点直线过去会不会撞墙就行，这样效率最高，动作也更自然。

如果你非要让飞行单位也用导航系统，也不是没办法。你可以在场景高空单独Bake一张NavMesh，把这张网格的Agent Type设成“Flyer”，并且把地面的碰撞体都排除掉。然后让飞行单位的代理用这张网格寻路。但说实话，有点杀鸡用牛刀，而且处理不好，飞行的姿态会很僵硬。

所以我的建议是：让地面的归地面，让天空的归天空。各用各擅长的玩法，玩家看着舒服，你写代码也省心。