Unity AI Navigation实战指南：从NavMesh烘焙到Agent寻路避障

1. 先把它想清楚：AI Navigation 到底帮你解决了什么

做Unity3D游戏开发，凡是涉到角色移动、怪物追踪、NPC巡逻，基本逃不开一个话题：寻路导航。早些年大家喜欢自己写A*、写网格寻路，后来Unity出了内置的NavMesh（导航网格），再到2021版本正式把AI Navigation整合进来，整体方案已经非常成熟了。我最早接触这个是做一款俯视角生存游戏，敌人要绕过各种障碍物追玩家，那时候自己手搓A*，地图一复杂就疯掉，换到AI Navigation之后，多了一整个可以反复打磨的完整寻路方案。

这套东西能解决什么问题，一句话说清楚：让角色在动态或静态场景中自动避开障碍物、找到通向目标的可行路径。你不用手动规划路径点，不用处理障碍物碰撞检测，只要把场景标记好、烘焙出导航网格，再给角色挂一个Agent组件，给它一个目标，它就能自己跑。适合谁？只要你做的是3D游戏、俯视角2.5D游戏，或者任何需要NPC、怪物、单位移动的项目，这套系统都值得花时间吃透。

我用过的版本跨了2018到Unity 6，AI Navigation包从早期RuntimeNavMesh到现在稳定版，接口变化不算大，核心思路完全一致。所以不管你现在用的是哪个Unity版本，下面这套内容基本都能直接套用。

1.1 它和你自己写A*寻路的区别

不少人有疑问：我自己写A*不是也能跑通吗？为什么非要用Unity的AI Navigation？我反过来跟你分享一点：自己写寻路，最大的坑不在路径算法本身，而在后续维护成本。

A算法本身不难理解，开放列表、关闭列表、估算代价，网上教程一抓一大把。但放到你真项目里，麻烦事特别多：地图变化了要重新生成网格数据、障碍物动态移动怎么更新、多个角色同时寻路性能怎么控制、角色转弯半径和路径平滑怎么处理。这些问题你自己写代码都要一点一点解决，工程量远远超过那一二百行的A核心逻辑。Unity的AI Navigation厉害在哪？它把从烘焙到寻路再到避障的整套链路都打包好了，而且和Unity物理系统、场景系统天然打通，烘焙一次、全局可用，运行时也能用NavMeshSurface动态更新局部区域。

当然，也不全是一味吹捧。这套方案也有它的边界：高度动态的场景（比如满地都是能连续改变形状的物体）它处理起来吃力，这时候得靠运行时局部烘焙和寻路失败重试来兜底。另外如果你做的是超大规模的RTS游戏，比如同时几千个单位寻路，可能还得自己上流场算法（Flow Field）、HPA*之类的东西，Unity自带方案这时候不够看。但绝大多数中小项目里，AI Navigation就是最省心的一条路。

1.2 整个系统的组成与核心概念

要玩转这套东西，你得先在脑子里建立一个总览图，知道有哪些零件、各自干嘛的。拆开来看，就三个层次：

• NavMesh（导航网格）：场景被烘焙后生成的凸多边形网格，标记出"角色能走的区域"。相当于把复杂地形简化成了一张可由程序处理的路径图。
• NavMeshAgent（代理）：挂在角色身上的组件，负责在NavMesh上移动、寻路、避障。它是角色跟导航网格之间的桥梁。
• 配套组件与模块：NavMeshObstacle管动态障碍物；Off-Mesh Link管跳跃、攀爬这类特殊连接；NavMeshSurface负责运行时动态烘焙；Area用来区分不同成本的区域。

这三个层次的理解深度，决定了你后面排坑的速度。举个很常见的例子：你烘焙完场景，发现角色走不过某扇门，大概率不是Agent参数的问题，而是那扇门的区域压根没被标记为可行走，或者是门的碰撞体挡住了烘焙。这种问题不建立全局认知，你会在各个参数之间瞎调半天。

还有一个必须知道的概念叫Area（区域）。NavMesh里每个面都归属一个Area，Area有编号和成本（Cost）。成本越高，寻路时越不愿意走这块区域。系统默认有三个：Walkable（可行走，成本1）、Not Walkable（不可行走）、Jump（跳跃用）。你可以自己加Area，比如"沼泽地""泥地""危险区"，通过设高成本让AI绕开。这个机制特别实用，你不需要写任何代码，光调Area成本就能改变AI的行为偏好。

2. 动手之前的准备：NavMesh 烘焙与模型处理

很多人一上来就创建Agent组件、设置目标点，结果角色原地不动或者走向莫名其妙的方向，最后发现是根本没烘焙导航网格。记住：没有NavMesh，Agent就是个废物。

烘焙听起来挺简单：选中Window > AI > Navigation，点Bake就完事。但实际项目里，烘焙结果能不能用，跟你场景预处理关系极大。我早期做的一个项目，地形上摆了一堆植物和碎石，直接用默认参数烘焙，结果角色经常走螺纹线、绕大圈，后来发现是那些细小物体被当成可行走区域了，Agent卡在缝隙里反复转向。这问题怎么解决，下面细说。

2.1 烘焙前的场景预处理

烘焙之前，你得想清楚一件事：哪些物体角色能走，哪些不能走？我有个很好用的判断方法——凡是Agent碰撞体应该撞上去的东西，就应该挡住烘焙；凡是Agent应该绕开但可以被视觉穿透的细节，就应该从烘焙里剔除或者标记成障碍。

具体到操作上，有几类东西要特别注意：

• 静态障碍物：墙壁、箱子、大石头，这些是主要阻挡体，确保它们带有Collider（通常MeshCollider或BoxCollider），并且勾选了Static。
• 装饰性小物体：草、花朵、碎石、路沿、铁丝网，这些如果全参与烘焙，导航网格会变得非常碎，寻路开销暴增。正确做法是：要么把它们从Obstacle层里排除，要么用NavMeshModifier把它们标记为Not Walkable且不参与烘焙。
• 地形上的坑、悬崖、水域：这些区域要手动用NavMeshModifier标记为Not Walkable。地形烘焙默认会把坡度太陡的地方自动排除，但垂直的坑边缘常被忽略，建议人工检查一遍。
• 动态物体：门、电梯、可破坏的障碍物，这类不该进静态烘焙，应该用NavMeshObstacle组件在运行时控制。

我见过不少人把整个场景所有物体一股脑设成Static然后烘焙，结果NavMesh生成了几十万个三角形，性能惨不忍睹。我的经验是：**烘焙用的几何精度只要能支撑角色移动判断就行，不需要和渲染模型完全一致。**比如一面墙的装饰柱子在渲染上有几十个面，给烘焙用的Collider就用一个Box，干净利落。

还有一个细节常被忽视：碰撞体类型影响Agent寻路精度。MeshCollider虽然精确，但烘焙慢、三角形多；BoxCollider、CapsuleCollider底面积规则，烘焙结果整洁。能用基本几何体当Collider的，就别上MeshCollider。

2.2 烘焙参数逐个过一遍

打开Navigation窗口，切到Bake页签，你会看到一堆参数。每一个都值得花几分钟理解，我把关键的过一遍：

Agent Radius：代理的半径，通俗点说就是"角色占多粗"。这个值决定了可行走区域的外扩范围，缝隙比这个半径窄的话，烘焙时会被直接抹平，Agent过不去。我一般设为角色CapsuleCollider半径的0.9倍左右，留一点余量。

Agent Height：代理高度，决定头顶净空。低于这个高度的矮洞、矮屋檐会被排除。别和碰撞体高度直接划等号，要结合角色动画姿态来，比如蹲伏动作如果能通过矮通道，那烘焙高度就该按蹲下后的高度算。

Max Slope：最大爬坡角度，超过这个角度的斜坡视为不可行走。默认45度，但实际游戏里角色爬坡能力通常弱一些，我经常调到30度到35度，更自然。

Step Height：最大台阶高度，低于这个高度的台阶，烘焙时会帮你"抹平"，角色可以直接走上去不用跳跃。这个值别忘了调，否则只有几厘米的马路牙子会把角色挡住。

生成参数里还有个Accurate Link Direction，一般勾上，能让Off-Mesh Link的连接方向更精确。

烘焙完，你会看到一个蓝紫色半透明的网格覆盖在场景上。网格覆盖到的地方就是AI能走的地方，网格边界就是AI能到达的最远范围。养成一个习惯：每次烘焙完，先在Scene视图转一圈，肉眼检查一遍覆盖区域，特别是门洞、桥、狭窄通道这几个位置。别直接运行测试，Scene视图里发现问题比运行半天再发现要快得多。

2.3 动态场景的烘焙方案

静态场景烘焙一次就够了，但你做项目大概率会遇到动态变化的地形。比如玩家建了一座桥、砍倒一棵树、放了一个路障，这些变化要求NavMesh跟着变。Unity有几种处理方式：

NavMeshObstacle是最轻量的方案。给动态障碍物挂上这个组件，设置好Shape和大小，运行时它会在NavMesh上"凿个洞"，Agent会自动绕开。注意默认情况下NavMeshObstacle只挡路径规划，不挡物理碰撞，所以物体本身最好再挂一个Collider，否则角色可能物理上穿透、但路径上绕路，出现穿模的诡异效果。

Carve模式：把NavMeshObstacle的Carve属性勾上，障碍物会在其周围切割出对应区域的"空洞"，这个模式适合大型动态障碍物，比如移动的卡车、巡逻的炮塔。Carve有更新开销，障碍物一多要注意性能。我一般限制同时Carve的Obstacle数量在30个以内，超过就考虑合并。

NavMeshSurface是可以把场景中指定部分实时烘焙的组件。用法是给某个区域挂一个NavMeshSurface，设置好采集范围，运行时可以调用Update()重新烘焙局部。这个方案开销比Obstacle大不少，适合地图结构会频繁变化、幅度又大的场景。比如圈的营地系统，每天定时重建围墙和防御工事，用NavMeshSurface最合适。

还有一种常见场景：动态地面块、传送带之类的东西，它们本身就在持续运动且会影响导航区域。遇上这种情况，机制上我建议别硬跟Unity系统死磕，要么把运动的地面做成"不受导航影响"的独立传送逻辑，要么用脚本定期触发NavMeshSurface更新烘焙区域，控制好触发频率比如每0.5秒一次，视觉和性能能找到一个可接受的平衡点。

3. NavMeshAgent 设置：让角色动起来的核心组件

烘焙好NavMesh之后，重头戏就是主角NavMeshAgent了。你可以在Inspector里给角色添加这个组件，也可以在代码里动态添加。它是所有寻路行为的执行者，参数特别多，但真正需要逐个人工校准的核心参数大概就是速度、加速度、转弯那几件事。

新手最容易犯的毛病，是把Agent当成一个移动组件，同时自己也写一套Transform.position更新逻辑，两边打架。记住这个原则：Agent负责移动，你负责下达意愿。 只要赋值了SetDestination()，剩下的路径规划、移动、避障都交给Agent自己去跑。你要是非得自己在Update里改Transform的位置，Agent内部的路径计算就会乱套，角色表现为抽搐、抖动、原地打转。

3.1 Agent组件关键参数与调参经验

我来逐个过一遍Inspector里Agent组件那些参数，附上我用下来比较舒服的节奏：

Speed：Agent移动速度。直接决定角色赶路速度。如果你有移动动画，它的数值需要和动画播放速度匹配，不然会出现"走路滑冰"的违和感。

Angular Speed：转向角速度，单位是度/秒。这个值太低，角色会走圆角路径绕远路；太高则转向生硬，像在跳机械舞。我处理普通NPC一般是360度每秒左右，偏写实的游戏会降到180~240。

Acceleration：加速度。决定从静止到满速的时间。默认值8对大多数角色够用，但如果你做的是偏硬核的追逐战，想让敌人起步快、追得凶，调高这个值效果很明显。

Stopping Distance：停止距离。Agent在到达目标点后，与目标点保持的最小距离。做近战敌人时这个值设成攻击距离；做NPC对话触发时设成对话的最短距离。注意：如果这个值设成0，Agent会一直试图把位置精确顶到目标点，反而在目标点附近乱扭，所以别设0，留一点回旋余地。

Radius与Height：这俩是Agent的物理占位尺寸，会影响它跟障碍物的避障表现。一般与Collider一致就可以，也可以略小一丢丢，让角色贴着障碍物走的时候不那么"虚"。

Auto Braking：是否开启自动刹车。勾选后，角色接近目的地时会提前减速停下，比较自然。如果你希望角色冲到目标点立即急停再转身（比如快速攻击的敌人），可以把这项关掉，然后自己在状态切换时控制速度归零。

Priority：避障优先级，数值低代表优先级高。多个Agent挤在一起时，高优先级的会推着低优先级的让路。这个值在处理大量敌人时很关键，我记得一个原始丛林场景，大量野怪从窄桥上涌过来堵成一团，后来把玩家同阵营的Agent优先级调高、敌人调低，整个场面立刻流畅了。

还有一个新手特别容易忽略的：Agent在Inspector里会显示一个绿色的线框，线框中心有个小圆柱。这个线框的位置要对齐角色的脚底中心。 如果Agent挂载在角色身上但中心点偏了，整个寻路都会有偏移感，尤其过窄门时特别明显。我建议Agent不要挂到角色骨架根节点上，而是单独挂在一个空物体上，位置对齐到脚底，角色模型作为该空物体的子物体。

3.2 移动代码与动画同步

这里给一份最基础的移动代码，几乎每个项目都能用上：

csharp复制using UnityEngine;
using UnityEngine.AI;

public class MoveToTarget : MonoBehaviour
{
    [SerializeField] private Transform target;
    private NavMeshAgent agent;

    void Start()
    {
        agent = GetComponent<NavMeshAgent>();
    }

    void Update()
    {
        if (target != null)
        {
            agent.SetDestination(target.position);
        }

        // 动画同步
        Animator animator = GetComponent<Animator>();
        if (animator != null)
        {
            animator.SetFloat("Speed", agent.velocity.magnitude);
        }
    }
}

这段代码里有几个关键点。每次Update把目标位置重新赋给SetDestination当然能用，但如果目标点是静止的，更聪明的做法是只在目标变化时赋值一次，否则每帧产生一次寻路请求，浪费CPU。我在实际项目里会加一个判断：目标位置距离上次设置超过0.1米才更新。

动画同步这个点很多人翻过车。你在Animator里看到的运动速度和Agent实际速度对不上，会出现"走路滑冰"或"原地跑步"。一个好用的技巧是：animator.SetFloat("Speed", agent.velocity.magnitude, 0.1f, Time.deltaTime);这样会做平滑过渡，动画切换不会生硬跳变。

还有一个问题容易被忽略：Agent沿路径走的时候，角色面朝方向是可以单独控制的。如果你希望角色在巡逻时边走边看向某个方向，不用旋转整个Agent，而是把模型子物体的rotation朝向目标即可，Agent的转向让Agent自己去处理，模型朝向由你手动控制。这样做的好处是，战斗转身和行走转向解耦，手感会清爽很多。

3.3 避障与防卡死策略

避障是AI Navigation里最微妙的部分。默认情况下，多个Agent会相互作用，自动绕开对方。但避障不等于不会卡死，我在做丧尸围城场景时遇到过一堆Agent在狭窄通道里互相顶牛，谁也不让谁。

我的解决思路是分三层：

第一层，让走路时有天然的错峰。给不同Agent设置不同的Speed和Stopping Distance，比如巡逻兵1速度2.1，巡逻兵2速度1.9，慢的先走一步、快的从侧边绕过去，卡死概率大大降低。

第二层，代码层面加一个"卡死检测"。连续2秒内Agent的速度都小于某个阈值（比如0.1），就判定为卡住，然后随机清空路径、呼叫一次新的SetDestination到原目标附近的一个随机偏移点。这是比较暴力的解法，简单有效：

csharp复制private float stuckTimer = 0f;
private float stuckThreshold = 0.1f;
private float stuckDuration = 2f;

void Update()
{
    if (agent.velocity.magnitude < stuckThreshold)
    {
        stuckTimer += Time.deltaTime;
        if (stuckTimer >= stuckDuration)
        {
            stuckTimer = 0f;
            agent.ResetPath();
            agent.SetDestination(RandomPointNear(agent.destination));
        }
    }
    else
    {
        stuckTimer = 0f;
    }
}

第三层，调整OffMeshLink和避障参数，让局部NPC的移动自然度提升。比如把Agent的ObstacleAvoidanceType设成HighQuality，虽然耗一点性能，但全局移动会顺滑很多。低端手机平台我建议用LowQuality或者MediumQuality，避障解析度太低反而容易出现抖动偏移，需要结合实际设备测一下。

还有一个跟物理相关的细节：Agent一般不要直接用CharacterController驱动物理碰撞，你挂了CharacterController反而会和Agent的移动逻辑冲突。 正确姿势是给角色挂一个Collider（通常CapsuleCollider）但不要用它的Move方法移动，让Agent用自己内部的移动逻辑走，Collider只负责物理碰撞反馈。如果搞混了，角色会频繁抖动甚至被物理引擎反向踢出去。

4. 真正实战：巡逻、追击与回归路径的完整实现

理论知识讲再多，不如上手做一遍。这一节我带你搭一个简单的实战案例：一个敌人AI，它有三种状态——巡逻、追击、回归。

巡逻：按设定路径点依次走，到达一个点就休息一会、再走向下一个点。
追击：当玩家进入它的感知半径，切换到追击状态，不断设置新目标点。
回归：追击丢失玩家目标，回到巡逻路径的某个点上，继续巡逻。

这个案例基本覆盖了大部分游戏AI场景。代码不复杂，但状态切换的细节挺磨人的。

4.1 巡逻逻辑实现

巡逻最简单也最稳定的方式，是在Unity场景里放一排空物体作为巡逻点，把它们拖进数组里。AI从当前巡逻点走向下一个巡逻点，走到之后就等待几秒再前往下一个。

核心代码大致这样：

csharp复制public class EnemyAI : MonoBehaviour
{
    public Transform[] patrolPoints;
    public float waitTime = 2f;
    public float chaseRadius = 10f;
    public Transform player;

    private NavMeshAgent agent;
    private int currentPatrolIndex = 0;
    private float waitTimer = 0f;
    private bool isWaiting = false;
    private Vector3 homePoint;

    void Start()
    {
        agent = GetComponent<NavMeshAgent>();
        homePoint = transform.position;
        GoToNextPatrolPoint();
    }

    void Update()
    {
        float distToPlayer = Vector3.Distance(transform.position, player.position);
        if (distToPlayer < chaseRadius)
        {
            ChasePlayer();
            return;
        }
        else if (isWaiting)
        {
            waitTimer -= Time.deltaTime;
            if (waitTimer <= 0f)
            {
                isWaiting = false;
                GoToNextPatrolPoint();
            }
            return;
        }
    }

    void GoToNextPatrolPoint()
    {
        if (patrolPoints.Length == 0) return;
        agent.SetDestination(patrolPoints[currentPatrolIndex].position);
    }

    public void OnDestinationReached()
    {
        isWaiting = true;
        waitTimer = waitTime;
        currentPatrolIndex = (currentPatrolIndex + 1) % patrolPoints.Length;
    }
}

这里面有个细节：怎么判断"走到了"？一种方式是每帧检测到达距离：

csharp复制if (!agent.pathPending && agent.remainingDistance <= agent.stoppingDistance)
{
    OnDestinationReached();
}

注意pathPending的判断很重要。SetDestination()调用后，寻路计算可能需要几帧才完成，在路径结果出来之前remainingDistance是不可靠的。至少等到pathPending == false再去判断剩余距离，否则会过早触发"走到了"的逻辑。

另外，巡逻权重不太建议太均匀：用,让它先快速跑到上一个巡逻点附近，返回路线会更自然。这里有个小技巧：把homePoint的记录位置放在Start里储起来，它不需要作为巡逻点数组里的一个元素。

4.2 追击与丢失目标后的回归

追击的核心是持续更新目标位置。但是每帧SetDestination会有性能开销，而且容易导致路径抖动。我的做法是设置一个更新间隔，只有目标移动超过一定距离才重新寻路：

csharp复制private float lastUpdateTime = 0f;
private float updateInterval = 0.3f;

void ChasePlayer()
{
    if (Time.time - lastUpdateTime >= updateInterval)
    {
        agent.SetDestination(player.position);
        lastUpdateTime = Time.time;
    }

    // 如果目标距离太近，可以停止移动且面向目标
    if (agent.remainingDistance <= agent.stoppingDistance)
    {
        agent.isStopped = true;
        FaceTarget();
    }
    else
    {
        agent.isStopped = false;
    }
}

追击还有另一层考量：要不要让Agent不撞到其他单位？ 追击时让敌人开启避障是应该的，但如果多个敌人追击同一个目标，它们会互相卡位，非常难看。我一般会把这几个敌人分到不同Speed，前排快、后排稍慢，各自走不同的到达路径，能稍微好一些。

回归逻辑更简单但容易踩坑。我见过不少人直接把HomePoint设成SetDestination，结果NPC回归的时候碰到障碍物或者玩家又出现了，不知道该往哪走。我的做法是，在追击丢失目标时设置一个"回归点"中间值，先回到离玩家最近的那个巡逻点，再从那里恢复巡逻：

csharp复制private void ReturnToPatrol()
{
    agent.SetDestination(homePoint);
    // 等待到达或者角度够近
    if (!agent.pathPending && agent.remainingDistance <= agent.stoppingDistance)
    {
        isWaiting = true;
        waitTimer = 0;
    }
}

有一个坑值得注意：如果玩家一直绕着障碍物跟你躲猫猫，remainingDistance可能永远大于StoppingDistance，NPC就会一直追目标，回归逻辑永远不触发。这个问题我处理方式是加一个"丢失计时器"：当目标离开感知范围持续超过5秒，不管路径还有多久没走完，都强制切换到回归状态，把当前路径清掉、重新规划回巡逻点。别跟电脑过不去，绕来绕去只会浪费状态切换资源。

4.3 多层导航与Off-Mesh Link

做有高低差场景的游戏，光靠NavMesh的地形烘焙还不够。比如有一座断桥，桥面和地面之间有段距离，Agent默认是不会自己跳的，除非你配置了Off-Mesh Link（脱离网格链接）。

Off-Mesh Link生成有两种方式：手动放置一个空物体挂OffMeshLink组件，把Start和End指定为两个空物体（它们必须附着在NavMesh边缘上）；或者用代码在运行时动态创建。对大多数项目，手动放置就够了。

配置Off-Mesh Link时有几个细节：

• Link两端必须是NavMesh上离实际地面很近的点，Unity会找出这些点所在的面。如果你的端点悬空了，链接不会被激活。
• 链接方向很重要。OffMeshLink组件上有Bi Directional（双向）勾选项。单向跳跃例如"从高处跳下但爬不回去"，就把双向取消，这样只有从高处到低处可以走。
• Agent走Off-Mesh Link时，实际上是在链接两端执行一个瞬间移动。系统默认是直接传过去，看起来像瞬移。如果你想播放跳跃动画、飞行轨迹，就得用脚本监听NavMeshAgent的OnNavMeshProcessing和链接执行消息，在过程中插值Transform位置。这块工作量不小，但效果好，比如角色跳过一个沟、翻过一面矮墙。

还有一个高级更新：现在的Unity AI Navigation支持NavMesh Surface上设置多个Area的值，而每个Area可以对应不同的Agent类型（人形、马车、飞行单位）。烘焙时勾选不同的Agent Type，生成不同版本的NavMesh，Agent会根据自己的Agent Type找对应层级的网格。做多单位玩法的时候特别好用，一辆马车不会试图走人行道上的楼梯，而小人能走马车过不去的楼梯通道。

这里我得提醒一句：Off-Mesh Link不是自动生成的，它必须手动布置或者写编辑器工具批量生成。 如果你做了一个开放世界的大地图，手动摆放几千个跳跃点会累死人。我当时的方法是写了一个编辑器批处理脚本，把断开的NavMesh边缘按距离阀值自动配对生成OffMeshLink，能用但后期维护很麻烦。后来转到用NavMeshComponets官方扩展包之后，它自带的编辑器工具支持某些自动链接生成，我建议优先用官方包，减少手搓。

5. 性能优化与常见坑：这些坑我踩过就不想你踩

AI Navigation的性能问题通常出现在三个方面：烘焙数据本身太大、Agent数量过多、运行时动态更新太频繁。逐个排查有套路，但一句话总结就是"用尽量小的数据量支撑尽量可靠的行为表现"。

5.1 性能瓶颈与优化思路

先说烘焙数据的优化。NavMesh三角形数量直接决定寻路查询时间和内存占用。我的参考标准是：一张50x50大小的游戏地图，NavMesh三角形数控制在1到3万以内比较合理；如果你的地图更大，要做分块烘焙。

减少三角形数量最直接的手段，一是把装饰性小物体的Collider从烘焙里剔除（用NavMeshModifier设成No Adit），二是把大面积静态地面细分降低、合并Collider，三是使用多个BoxCollider代替复杂的MeshCollider。记住烘焙参照的是Collider几何，不是模型几何，只要你Collider够精简，NavMesh就不会变大。

然后说Agent数量优化。每一个需要寻路的Agent，如果每帧都调用SetDestination，会产生大量的寻路请求。Unity内置的NavMesh寻路其实是单线程的，过多查询会卡主线程。我的做法是用以下技巧：

• 降低路径更新频率：SetDestination不每帧调，按需调用。追击目标时每0.3秒更新一次，巡逻时到达后再更新。
• 目标点缓动：如果目标位置变化不大，可以小更新间隔内不重新寻路，只微调转向。比如目标的移动速度不高时，你可以只让Agent沿当前路径走一段再重新规划，避免频繁重算。
• 避免所有Agent同时发起寻路：用随机偏移错峰，比如把UpdateDestination时间加上一个Random(0,0.2)的偏移。
• 减少避障配对计算：Agent之间避障计算的开销随Agent数量平方增长。大量Agent（比如80个以上）同时追击，尽量分组或者让一部分Agent关闭避障（obstacleAvoidanceType = None），整体流畅度提升会非常明显。

运行时动态更新相关的优化，上面已经提到过NavMeshSurface批量更新的思路。再补充一点：别写一个Update每帧调NavMeshSurface.Update()，这是最典型的性能杀手。动态烘焙尽量间隔触发，比如每3秒或者事件触发。还有烘焙范围要用小区域，不要整个场景重新烘焙，能覆盖动态变化就行。我见过有人为了临时给一堵可破坏的墙更新导航，把整个100x100的地图重新烘焙了一遍，掉帧掉到没法玩，改成局部区域更新后性能完全OK。

最后提一个很多人不知道的API：NavMesh.CalculatePath()。它能在不创建Agent实例的情况下单独算一条路径。这个功能适合做"AI预判"：你可以让一个没有实体Agent的"虚拟单位"试算一条路径，如果路径不可达或者距离过长，AI就会提前决策去别的路线，不用走到死胡同再回头。比如敌人巡逻时，如果通往目标的路径大于某个阈值（比如绕过一道墙），就切换状态。这和Agent的SetDestination配合使用，AI的表现明显更有脑子。

5.2 常见问题速查表：症状、原因与解法

我把自己做项目时遇到过的典型问题整理成一张速查表，希望能帮你少走弯路：

排查这类问题时，我的习惯是先在Scene视图里打开NavMesh可视化，把Agent的agentTypeID、areaMask一起检查一遍。很多时候问题不在代码而在配置，只有把Scene视图的网格、Agent线框、Link标识全打开来，才能真正看清这个角色在导航系统眼里的世界长什么样。

还有两个小习惯挺重要。第一，每次改动NavMesh配置或场景障碍物后，记得重新烘焙，不然会带着旧数据排半天问题，项目大了之后踩这种坑尤其消耗时间。第二，发现角色走到奇怪的位置，不要只在Game视图盯着看，切到Scene视图把AI的path可视化出来，看看它规划的路径到底长什么样，一眼就能定位是寻路问题还是移动问题。

5.3 我用了多年的几个调参心得

篇幅有限，但有几个心得不吐不快，它们不属于那一套速查表，更多是手感层面的东西。

第一个心得是对"碰撞体与半径"的处理。角色能过的通道宽度，物理上Collider和Agent的Radius两套数据都要考虑进去。我通常留出一些冗余：Agent Radius = 碰撞体半径 * 0.85，烘焙Agent Radius再乘0.9，三个数值层层缩水，角色走窄通道时会顺畅很多，不容易出现"能看的过去但实际过不去"的诡异卡位。当然了，缩水幅度不能太大，否则角色会明显穿模。

第二个心得是Stacking（人叠人）问题的处理。大量敌人同屏时，人叠人几乎是必然的，避障只能解决一部分。我处理方式分两种：若敌人数量低于30，全开避障，用HighQuality；超过30，把一个批次敌人的避障关掉，让它们沿路径直线走，NPC之间的穿插会好一些。如果你要的不仅仅是穿插的视觉效果，而是更高层级的阵型逻辑，建议研究一下RVO（Reciprocal Velocity Obstacles）方案，不过真正上阵的话比较复杂，我这里就点到为止。

第三个心得是不要把Agent的Roation与模型动画耦合得太死。很多新手在代码里让模型旋转直接跟着Agent走，但到了Off-Mesh Link跳跃或者原地攻击时，旋转就突然生硬了。比较舒服的做法是：正常寻路时模型朝向跟随Agent的转向，进入攻击、互动状态时把Agent的转向和模型解耦，模型单独播放动画、旋转到目标角度。状态切换时把Agent的angularSpeed临时调低，整体视觉会平滑不少。

最后再说一个小技巧：如果场景里有多个Agent需要同时寻路，不要每帧都调用agent.pathStatus去做调试打印，太消耗性能。需要看路径情况时，写一个专门的Debug模式，按F键再显示路径线，避免常规帧循环里干这种事。

6. 把AI Navigation再往前推一步：扩展与集成实战思路

当你把基础玩法跑通之后，AI Navigation往往还需要跟其他系统配合，比如状态机、行为树、任务系统。这一节聊聊我是怎么把AI Navigation嵌进更大系统的，希望对你在项目里做扩展时有参考。

6.1 用状态机封装导航行为

不是所有游戏都需要复杂的BehaviorDesigner或PlayMaker，但给AI做一个简单状态机，真的会让你的代码清爽很多。我在个人项目里写过一种很轻量的状态机：每个AI用枚举记录当前状态，状态切换时重设Agent参数，Update里根据状态做不同的设定目标逻辑。

记住状态机里有一个关键的职责划分：状态负责决策"去哪"，Agent负责执行"怎么去"。千万别在状态代码里密集控制Agent移动，那是把两个责任混在一起，改一个时会牵连另一个。

举例来说，追击状态里你只更新Agent的目标点、调整追赶时的Speed与AngularSpeed；如果玩家被甩丢了，状态切换回回归状态时，再把Speed调回巡逻的速度。这样做的好处是，后面你想让AI进入"狂暴追击"状态，只需要加一种Speed参数组合，逻辑边界很清楚。

6.2 与动画系统、音效系统的联动

AI Navigation和动画系统的联动，核心就是状态切换时的表现要跟得上行为。我的做法是：在状态切换代码里同时触发动画状态和音效，比如进入追击时播放"激活"音效、切换动画层（从Idle到Move到Run），而不是让网格系统的状态独立驱动动画，那样容易出现"AI已经变了状态、模型还在播上一个状态动画"的延迟感。

还有一个常被忽视的点：Agent的转角会和动画物理混合出问题。 比如你在Animator里做了转身动画，同时Agent在快速旋转，两套旋转叠加容易导致角色"鬼畜"。我建议，当Agent的转向速度超过一个阈值时，禁用混合树里的转身图层，让Agent直接控制模型朝向，避免两套旋转互相打架。

6.3 多线程与高级扩展思路

Unity AI Navigation自带的寻路在CPU单线程上运行，巨大地图上百个Agent同时寻路会有压力。虽然这里要说的不涉及具体代码实现，但这个方向值得了解。你没看错，官方寻路API不支持你自己开线程去并发计算路径，所有NavMesh.CalculatePath都是引擎内部串行执行。所以遇到性能瓶颈，优先从减少调用频率和Agent数量入手，而不是去找并行的方案。

更高阶的方案是：使用Ecs和JobSystem配合NavMesh来做大批量单位的目标点更新。如果你做的是千人同屏小兵冲锋，可以考虑用Batch式寻路：把Agent分成小组、共享路径关键点，再做局部避障。我试过混合方案，效果比纯原生要好很多，但没有额外的插件支持时，工程成本可不小，适合有经验的团队再动手。

最后，如果你还没用过官方的com.unity.ai.navigation包，强烈建议尽快升级到它。它是传统NavMesh的下一代形态，支持运行时的NavMeshSurface、更加模块化，还带示例场景和文档。2022 LTS和Unity 6上这个包已经相当稳健。我最近从一个老项目迁移过来，改动量很小，收益却很直接：动态烘焙不再受限于场景里的单一Bake对象，可以按区域自由增删导航表面。这算是我这几年在Unity导航这块觉得最值得的一笔更新。

6.4 一份可以直接抄的完整示例代码

为了让你更直观地看到这套东西怎么组装起来，我把上面的思路整理成一个简化但完整的例子。它包含AI状态机、巡逻、追击、回归、以及Debug可视化：

csharp复制using UnityEngine;
using UnityEngine.AI;

public enum AIState
{
    Patrol,
    Chase,
    Return
}

public class EnemyAIController : MonoBehaviour
{
    public Transform[] patrolPoints;
    public Transform player;
    public float chaseRadius = 10f;
    public float loseRadius = 15f;
    public float patrolSpeed = 2f;
    public float chaseSpeed = 4.5f;
    public float waitTime = 2f;

    private NavMeshAgent agent;
    private AIState currentState = AIState.Patrol;
    private int patrolIndex = 0;
    private float waitTimer = 0f;
    private Vector3 homePos;

    void Start()
    {
        agent = GetComponent<NavMeshAgent>();
        homePos = transform.position;
        SwitchState(AIState.Patrol);
    }

    void Update()
    {
        CheckStateTransitions();
        ExecuteCurrentState();
    }

    private void CheckStateTransitions()
    {
        float distToPlayer = Vector3.Distance(transform.position, player.position);

        switch (currentState)
        {
            case AIState.Patrol:
                if (distToPlayer < chaseRadius)
                    SwitchState(AIState.Chase);
                break;
            case AIState.Chase:
                if (distToPlayer > loseRadius)
                    SwitchState(AIState.Return);
                break;
            case AIState.Return:
                if (distToPlayer < chaseRadius)
                    SwitchState(AIState.Chase);
                else if (ReachedDestination())
                    SwitchState(AIState.Patrol);
                break;
        }
    }

    private void ExecuteCurrentState()
    {
        switch (currentState)
        {
            case AIState.Patrol:
                ExecutePatrol();
                break;
            case AIState.Chase:
                ExecuteChase();
                break;
            case AIState.Return:
                ExecuteReturn();
                break;
        }
    }

    private void ExecutePatrol()
    {
        if (ReachedDestination() && !agent.pathPending)
        {
            waitTimer -= Time.deltaTime;
            if (waitTimer <= 0f)
            {
                patrolIndex = (patrolIndex + 1) % patrolPoints.Length;
                agent.SetDestination(patrolPoints[patrolIndex].position);
                waitTimer = waitTime;
            }
        }
    }

    private void ExecuteChase()
    {
        agent.SetDestination(player.position);
    }

    private void ExecuteReturn()
    {
        if (!agent.pathPending && agent.remainingDistance < 0.5f)
        {
            agent.isStopped = true;
        }
        else
        {
            agent.isStopped = false;
        }
    }

    private bool ReachedDestination()
    {
        return !agent.pathPending && agent.remainingDistance <= agent.stoppingDistance;
    }

    private void SwitchState(AIState newState)
    {
        currentState = newState;
        switch (newState)
        {
            case AIState.Patrol:
                agent.speed = patrolSpeed;
                agent.isStopped = false;
                if (patrolPoints.Length > 0)
                    agent.SetDestination(patrolPoints[patrolIndex].position);
                break;
            case AIState.Chase:
                agent.speed = chaseSpeed;
                agent.isStopped = false;
                break;
            case AIState.Return:
                agent.speed = patrolSpeed;
                agent.isStopped = false;
                agent.SetDestination(homePos);
                break;
        }
    }
}

这段代码放在你的工程里，挂到敌人预制体上，再配置巡逻点、玩家引用和几个半径参数，它就能完全跑起来。我故意没有把性能优化细节写进去（比如更新间隔、卡死检测），是为了保持示例的清晰度，你实际使用前把它们加上就好。

平时调这个脚本的时候，我会把chaseRadius和loseRadius这两个值通过Inspector拖动，观察Gizmos实时变化。建议在Scene视图里画两个球体或圆来显示感知范围，省得每次靠猜去看范围感不感觉得对。

如果你希望这套Controller后续能在项目里被复用，考虑把它改成分层的：状态切换逻辑放上层，Agent参数配置放下层，中间用接口通信。不过如果只是小游戏或者原型验证，上面的写法足够简单直接，不要过早抽象。

我个人在实际项目里最满意的一次应用，是结合行为树和AI Navigation做了一组护送NPC的任务：主角在护送模式下会自己寻路到指定地点，同时沿途动态避开敌人的临时巡逻区域；敌人每次巡逻转弯时用NavMesh.CalculatePath预判前方路线，如果路线被封就绕路。那次迭代下来，AI主角的移动自然度明显上了一个台阶。

回到我自己的经验来说，AI Navigation最大的价值在于，它把"寻路"这个抽象的问题转化成了三个具体可调的东西：网格、Agent参数、Area成本。只要把这三样吃透，在Unity里做像样的AI角色移动就真的不难了。最后分享一个小技巧：如果你不确定自己的Agent参数设计合理不合理，先把所有参数调成中间值跑一次，再逐一往极端方向拉，看看每种极端下的行为表现，远比背参数表管用。祝你在Unity里做出满意的智能角色。