简介：一份广东工业大学硕士学位论文《基于Unity3D游戏人工智能的研究与应用》，面向游戏开发者、AI研究者及Unity3D学习者，探讨如何提升游戏NPC的智能性与灵活性。针对有限状态机与行为树可控但灵活性不足的问题，研究将行为树与机器学习（强化学习）相结合，并在射击游戏中落地验证。资源包仅1个PDF文件，大小约2MB，正文包含完整的研究背景、相关技术、行为树NPC感知设计（视觉/听觉）、强化学习训练投篮机器人案例、射击游戏开发与对比实验等内容，目前已有1032人学习下载。通过这份PDF，读者可系统掌握行为树与机器学习在游戏AI中的协同设计思路，包括NPC感知建模、强化学习训练加速方法（课程学习与好奇心）、以及行为树与策略模型融合的实践案例。适合想将AI技术应用到Unity3D游戏开发中的中高级开发者参考。
1. 用 Unity3D 做游戏人工智能：先别写追人脚本，先想清楚这是一套系统
一个只会「朝玩家位置移动」的敌人，在平整空地上能用，一旦地图里出现一堵墙、一扇门、一个高台，它就当场报废。Unity3D 里做游戏人工智能，从来不是写一段if (distance < 5) 追击这么简单，它是由决策架构、感知系统、寻路与避障、动画反馈协同组成的闭环。这篇笔记会把从零搭一套可用 AI 的路径拆开讲清楚，包含可复制的 C# 代码、NavMesh 关键参数、以及我在多个项目里踩过的真实坑。适合正在做敌人 AI、NPC 行为或需要 AI 系统化的 Unity3D 开发者，目标只有一个：照着做能跑，跑起来不翻车。
2. 从有限状态机到行为树：先选定决策架构，再谈实现
2.1 有限状态机：单体敌人 AI 的及格线，也是理解更复杂架构的地基
有限状态机（FSM）是游戏人工智能里最经典、也最容易被看轻的方案。它的核心思路非常直白：一个角色在任意时刻只处于一个状态（巡逻、追击、攻击、死亡），每个状态有独立的进入、更新、退出逻辑，状态之间通过明确的条件互斥地切换。
我见过不少团队一上来就上行为树，理由是「行为树高级」。但实际开发里，一个只和玩家单挑的近战敌人，用 FSM 写 200 行代码就能收工；同样的需求用行为树，光搭节点和黑板配置就可能超过 200 行，还多出一层调试成本。选择决策架构的第一原则是匹配需求复杂度，不是匹配简历上的技术关键词。
FSM 的边界也很清楚：当行为之间存在大量组合关系（比如「有队友阵亡且玩家血量低且自身武器为远程时」才触发某个策略），状态图会迅速膨胀，变成一个谁都改不动的意大利面。这时候就该考虑行为树或下文提到的 Utility AI。
2.2 行为树：控制权反转，适合复杂组合行为与策划频繁调参
行为树的核心是把决策逻辑拆成节点，由根节点以固定频率（通常是每帧或每 0.1 秒）从上到下执行整棵树。它和 FSM 最本质的区别是控制权反转：FSM 由角色自己记住当前状态并按条件转移；行为树由树结构自上而下问「我该做什么」，每个行为节点执行完返回 Success、Failure 或 Running。
这个差异带来的工程优势很明显。策划要调整行为逻辑时，不需要翻代码找状态转移条件，直接拖节点就能改树的执行顺序；新增一个行为也不必改动原有状态机，挂一个新节点上去即可。Unity 生态里最常用的行为树实现是 Behavior Designer 和 Node Canvas，两者都支持可视化编辑、运行时调试和黑板变量共享。
但行为树有一个隐蔽代价：它把逻辑的复杂度转移给了数据。节点间的数据传递依赖黑板（Blackboard），一个「追击敌人」的节点可能需要从黑板读目标位置、读攻击范围、写自身移动速度。项目一大，黑板里几十个变量互相读写，查找问题的难度不比 FSM 的意大利面低。我见过最典型的翻车现场是：两个行为树插件各写各的变量名，同一个目标位置一个叫targetPos一个叫destination，调试时怎么都对不上。
2.3 FSM 落地：巡逻 - 追击 - 攻击的最小状态机代码
先看一份可直接放进 Unity 工程的最小 FSM 骨架，它覆盖了巡逻、追击、攻击三个最基础的状态：
public enum AIState { Patrol, Chase, Attack } public class MinimalFSM : MonoBehaviour { public float chaseRange = 8f; // 进入追击的距离阈值 public float attackRange = 2f; // 进入攻击的距离阈值 public float loseRange = 12f; // 丢失目标的距离阈值，防止左右横跳 public Transform player; // 玩家目标 public float moveSpeed = 2f; public float patrolRadius = 5f; private AIState currentState = AIState.Patrol; private UnityEngine.AI.NavMeshAgent agent; private Vector3 patrolTarget; void Start() { agent = GetComponent<UnityEngine.AI.NavMeshAgent>(); PickNewPatrolPoint(); } void Update() { float distance = Vector3.Distance(transform.position, player.position); // 状态转移条件集中判断，避免每个状态里到处改状态 switch (currentState) { case AIState.Patrol: if (distance < chaseRange) currentState = AIState.Chase; else PatrolMove(); break; case AIState.Chase: if (distance < attackRange) currentState = AIState.Attack; else if (distance > loseRange) currentState = AIState.Patrol; else ChaseMove(); break; case AIState.Attack: if (distance > attackRange * 1.2f) currentState = AIState.Chase; else AttackAction(); break; } } void PatrolMove() { if (!agent.pathPending && agent.remainingDistance < 0.5f) PickNewPatrolPoint(); agent.SetDestination(patrolTarget); } void ChaseMove() => agent.SetDestination(player.position); void AttackAction() => agent.isStopped = true; // 攻击时停下，具体攻击逻辑另行挂载 void PickNewPatrolPoint() { Vector2 rand = Random.insideUnitCircle * patrolRadius; patrolTarget = transform.position + new Vector3(rand.x, 0, rand.y); } void LateUpdate() { // 每次状态切换后重置代理速度，防止残余状态影响下一次移动 if (agent.isStopped) agent.isStopped = false; } }这段代码的逻辑要点有三个。第一，所有状态转移条件集中在Update的switch里，而不是分散在各自状态方法内，好处是调整 AI 行为时一眼能看全转移关系，新增状态时不会漏改分支。第二，追击的丢失阈值故意大于追击进入阈值（loseRange大于chaseRange），这是防抖的关键——否则玩家在边界附近晃动时，AI 会不停地在巡逻和追击间来回切换，表现就是抽搐。第三，PatrolMove里用agent.pathPending和remainingDistance双重判断，确保寻路路径生成完才开始计算剩余距离，这个细节很多人会忽略，导致巡逻点永远差 0.5 米不换点。
攻击状态里我直接isStopped = true让代理停下，实际项目里通常还会同步播放攻击动画、触发伤害判定。FSM 的一个实用原则是：每个状态只负责决策和调用，具体动作（攻击动画、音效、特效）由独立组件接收状态变化去执行，不要在状态里直接播放动画，否则后期加一个「受击硬直」状态时要改的东西太多。
3. 感知系统：让 AI 看见和听见玩家，而不是隔墙读坐标
3.1 视野感知：OverlapSphere 加角度判断，拼出一个视锥
很多入门教程教玩家追踪 AI 时，直接让 AI 每帧读玩家transform.position，然后SetDestination。这种写法在 AI 眼里玩家等于一个上帝坐标，隔着墙也知道你在哪。真实游戏里的 AI 必须有感知限制，否则绕后、潜行、掩体这些玩法全都不成立。
Unity3D 里实现视野感知的常见做法是用Physics.OverlapSphere找出范围内所有带碰撞体的对象，再用Vector3.Angle过滤出视野角度内的目标，最后加一次Raycast做遮挡检测。三段式判断，每一段都是对前一段结果的精确化：
public class VisionPerception : MonoBehaviour { public float viewRadius = 10f; // 视觉半径 public float viewAngle = 60f; // 半角，总视野 120 度 public float detectionInterval = 0.2f; // 检测频率，避免每帧开销 public LayerMask targetMask; public LayerMask obstacleMask; public Transform currentTarget; private float lastDetectTime; public void Detect() { // 1. 范围粗筛：球体检测拿到所有候选目标 Collider[] targets = Physics.OverlapSphere(transform.position, viewRadius, targetMask); foreach (Collider col in targets) { Vector3 dirToTarget = (col.transform.position - transform.position).normalized; // 2. 角度过滤：目标在视野锥内才继续 if (Vector3.Angle(transform.forward, dirToTarget) < viewAngle) { // 3. 遮挡检测：有障碍物挡住就视为看不见 if (!Physics.Raycast(transform.position, dirToTarget, Vector3.Distance(transform.position, col.transform.position), obstacleMask)) { currentTarget = col.transform; return; } } } currentTarget = null; } void Update() { if (Time.time - lastDetectTime > detectionInterval) { Detect(); lastDetectTime = Time.time; } } }这里三个参数是调试最频繁的：viewRadius决定感知距离，viewAngle是半角而不是全角，很多人误填 120 结果视野变成 240 度。detectionInterval是性能与灵敏度的平衡点，单机 10 个敌人用 0.2 秒很稳，竞技类游戏可以压到 0.1 秒，再低就没必要了——人眼对 AI 反应速度的感知上限大约也就是 0.1 秒的延迟。
ObstacleMask只勾选墙、门这类真正会挡住视线的物体，千万别用Default层，否则地面上一个小碎石就能让 AI 瞎掉。视线检测的 Raycast 距离用Vector3.Distance每次计算一次即可，因为目标已经在范围内了，没必要用Mathf.Infinity。
3.2 听觉感知：声音事件驱动，比轮询更省性能
听觉感知不适合用轮询方式做。如果每个 AI 每帧都去扫描周围有没有声音，性能开销是 O(AI 数量 × 声音源数量) 的乘法关系。常见做法是反过来做事件驱动：发声源发出一个带位置和半径的「声音事件」，由听觉管理器分发给范围内的 AI。这也是大型项目里 Audio Perception 的标准思路。
public struct SoundEvent { public Vector3 position; public float radius; public float intensity; // 音量强度，越大代表越容易被听到 } public class AudioPerception : MonoBehaviour { public float hearingMultiplier = 1f; public bool CanHear(SoundEvent sound, Vector3 listenerPos) { float distance = Vector3.Distance(sound.position, listenerPos); // 距离加上强度偏移，音量大的声音能传更远 float effectiveRadius = sound.radius * (1f + sound.intensity * hearingMultiplier); return distance < effectiveRadius; } }事件驱动的好处是发声时只广播一次，AI 侧只做一次距离判断，性能消耗为 O(声音源数量 × 受影响 AI 数)，比每帧全量轮询低一个量级。另一个好处是语义清晰——「脚步声」「枪声」「开门声」天然适合做成不同半径和强度的事件，策划可以通过调参数直接控制各个声音的传播距离，不用改代码。
3.3 感知数据如何驱动状态切换：接上 FSM 的输入
感知系统产出的是一片可被查询的数据，应该统一缓存，而不是让决策系统直接调用感知函数。我在项目里通常建一个AIPerception组件，把视觉和听觉结果汇总为感知数据缓存，供决策层读取：
public class AIPerception : MonoBehaviour { public VisionPerception vision; public AudioPerception audioListener; public Transform chaserTarget; public bool lastHeardSound; public void Refresh(Transform self, SoundEvent[] activeSounds) { // 视觉检测 vision.Detect(); if (vision.currentTarget != null) { chaserTarget = vision.currentTarget; return; } // 视觉丢失时用听觉补位 foreach (var s in activeSounds) { if (audioListener.CanHear(s, self.position)) { chaserTarget = s.position.ToTransformReference(); // 抽象：用位置临时目标 lastHeardSound = true; return; } } chaserTarget = null; } }这样 FSM 的Update里只需要读取chaserTarget是否为 null，判断「我是否知道玩家在哪」——这比在 FSM 里直接跑感知检测干净得多，也让「看到但没听到」「听到但没看到」这种策略差异只需改感知层配置即可实现。感知与决策的分离，是中等规模 Unity3D 游戏 AI 代码里性价比最高的架构决策。
4. NavMesh 寻路落地：地图烘焙、动态障碍与三个必调代理参数
4.1 地图烘焙前置：从几何数据到可行走区域，坑都在边界
NavMesh 是 Unity3D 里游戏人工智能寻路的事实标准方案，它的导航网格是离线烘焙出来的，分静态导航网格和动态障碍物两部分。烘焙前需要先做好三件事：
第一，地面和障碍物全部标记为Static（或至少 Navigation Static），烘焙时 Unity 才会把它们纳入计算。很多新手 AI 一到某些区域就原地转圈，检查下来是那块地面漏标了 Static，压根没进入导航网格。
第二，在 Navigation 窗口里把可行走物体的 Area 设置为Walkable，把墙、深水、悬崖这类物体设为Not Walkable。这一步要和碰撞体区分开——碰撞体管物理碰撞，Area 管寻路代价。两者不一致的最典型问题：你设置了碰撞体但没设置 Area，角色不会撞穿墙，但寻路路径会直接穿过墙，因为寻路计算时墙可以被忽略。
第三，烘培参数里最容易被忽视的是Agent Radius和Max Slope。Agent Radius要设成实际角色胶囊体的半径，设太大角色会绕远路，设太小角色会试图钻过狭窄缝隙而卡住。Max Slope表示 AI 能爬的最大坡度，别以为设 90 度就万能——NavMesh 生成的是投影网格，坡度过陡时网格会出现重叠和断裂，角色直接掉下去。
完成设置后，在 Navigation 窗口点 Bake，生成结果可以打开NavMesh Visualization可视化看到绿色可行走区域。我建议烘焙后一定做一遍全图巡检：把摄像机压低到角色高度，沿每一条路径走一次，确认墙角和门洞的边界符合预期。这一步很费时间，但能在运行期省下大量排查卡墙的功夫。
4.2 NavMeshAgent 的三个必调参数：从移动到避障的行为控制
NavMeshAgent 组件是运行时寻路的核心，挂上角色组件并设置参数后，用SetDestination即可驱动角色移动。三个参数是项目里最容易翻车的：Speed、Angular Speed和Stopping Distance。
Speed控制移动速度，这个没有悬念。但要注意它和动画速度的同步——移动动画的播放速率应该等于实际移动速度除以动画导入速度，否则角色会出现「滑步」或「踩空」的违和感。Angular Speed是角色转向的角速度，它决定 AI 转向玩家时是干脆利落还是像坦克一样掉头慢。建议近战敌人设 360 以上，远程单位设 120 左右，让角色在移动中还能转向开火。
Stopping Distance是角色到达目的地后与目标保持的距离，默认值 0。对近战攻击的敌人，这个值应该设成攻击距离的 80% 左右，否则角色会不断挤压到玩家脸上进入攻击状态后马上退开，显得很呆。实测经验是：攻击距离 2 米，Stopping Distance设 1.6 米，配合 FS M 里的攻击切换阈值，手感会比较顺滑。
public class NavAgentController : MonoBehaviour { public UnityEngine.AI.NavMeshAgent agent; public float moveSpeed = 3.5f; public float angularSpeed = 360f; public float stoppingDistance = 1.6f; void Start() { agent = GetComponent<UnityEngine.AI.NavMeshAgent>(); agent.speed = moveSpeed; agent.angularSpeed = angularSpeed; agent.stoppingDistance = stoppingDistance; } public void MoveTo(Vector3 destination) { agent.isStopped = false; agent.SetDestination(destination); } public void Stop() { agent.isStopped = true; agent.velocity = Vector3.zero; // 清零残余速度，防止停下的瞬间滑步 } }这里有个现场问题：agent.isStopped = true之后角色如果还带着惯性，会原地再滑一小段。所以停顿时手动清零velocity，这个细节能让攻击前的定身动作干净很多。另外AutoBraking默认是开的，它会让角色在接近目标时自动减速。做巡逻 AI 时建议AutoBraking = false，否则角色会在每个巡逻点附近「飘」一下再掉头。
4.3 动态障碍、局部避障与 NavMeshObstacle 的选择时机
游戏运行时地图会变化：门开了、箱子倒了、墙塌了。这些变化无法靠静态烘焙解决，需要障碍物系统动态更新。Unity3D 提供NavMeshObstacle组件处理这类情况，它会实时把自身几何推入寻路计算，让路径绕开动态障碍。
但NavMeshObstacle有一个明显的坑：
NavMeshObstacle默认的形状是 Box，而不是 Mesh。如果直接用 Mesh 形状且物体面数高，每帧的避障计算开销会飙升。实践里我一般用 Box、Capsule 这类低面数几何体包住障碍物，视觉模型只做显示，不参与寻路计算。
另一个常见问题是：NavMeshObstacle只能做「推挤式」避障，也就是让路径避开它，不能让 AI 真正和障碍物做物理互动。如果 AI 需要推开箱子、撞破门，别用NavMeshObstacle做，应该用 Rigidbody + Collider 自己做物理交互，再在交互结束后重新评估路径，否则会出现 AI 对着箱子反复走但永远绕不过去的情况。
还有个多人项目常见问题：多个 AI 同时寻路同一目标时，它们会互相撞成团。NavMeshAgent自带AvoidancePriority和Radius做局部避障，但效果有限。当超过 10 个敌人同时挤一个门口时，纯粹依赖 NavMesh 的局部避障必然堵塞，需要手动给 AI 加上「队形偏移」逻辑或改用流场寻路。小规模项目可以先用AvoidancePriority降低玩家附近 AI 的优先级，让玩家周边的敌人优先让路，效果能撑住大部分场景。
5. Unity3D 游戏 AI 避坑笔记：翻车现场的 5 条排查记录
5.1 现象：AI 在斜坡上滑行下坡，姿态像滑板
巡逻 AI 走到一个有 20 度倾斜的山坡时，角色模型始终保持直立但整个人沿着坡面往下滑，双脚悬空。原因在NavMeshAgent的Base Offset和UpdatePosition的配合：代理跟随导航网格高度位置，但角色模型是独立物体。斜坡上网格的高度采样点和角色transform.position之间出现误差，模型被迫按网格位置移动，又没有重力参与，就产生了「滑行」。
解决：将角色模型的根节点和 NavMeshAgent 放在同一物体上，或者给模型套一层空物体做Base Offset修正。更稳的做法是开启agent.updateRotation设为 true 并让代理的baseOffset值为 0，然后用agent.velocity的方向驱动模型做transform.rotation插值，让模型贴合坡面。
5.2 现象：20 个敌人同屏，AI 感知导致掉帧严重
从 FPS 掉到 30，而且按住 Tab 开背包时能明显卡顿。定位发现VisionPerception.Detect()里的Physics.OverlapSphere每帧执行，20 个敌人 × 每帧一次球形检测 × 每次球体范围内可能七八个候选目标，光物理查询就吃掉了大量 CPU 开销。加上部分用[ExecuteInEditMode]标记的感知组件在编辑器里也每帧跑，就更卡。
解决：感知检测从Update每帧改为定时检测，detectionInterval设在 0.15 到 0.3 秒之间；同时把Physics.OverlapSphere改为非分配版本Physics.OverlapSphereNonAlloc，配合预分配数组。这一步实测开销能降到原来的十分之一。还有一点：开背包时如果打开的是 UI 且场景里的敌人还在正常运行，可以在 UI 打开时暂停 AI 更新，这也符合实际体验——玩家开背包时没人期待背后敌人还保持实时反应。
5.3 现象：AI 隔墙锁定玩家，透视墙打人
追踪 AI 在墙后直接把玩家锁为目标，隔着墙进入攻击状态。定位到问题是感知检测里没有遮挡检测，或者遮挡检测用了错误的 LayerMask——障碍物没被包含进去或者碰撞体没有挂在指定的层上。
解决：确认obstacleMask勾选了墙、门、柱子、箱子等静态遮挡物；确认这些遮挡物有自己的 Collider，且 Collider 所在的 GameObject 层被obstacleMask匹配。如果项目里用了NavMeshObstacle处理动态障碍，记得把NavMeshObstacle的carve开启——它会参与遮挡检测，帮助视线被动态障碍挡住时正确地失去目标。典型反例是只在obstacleMask里勾了墙，结果一扇车门挡住视线时 AI 依然能看到玩家。
5.4 现象：AI 在目标附近来回切换巡逻和追击，原地抽搐
玩家站在chaseRange边缘，AI 一会儿进入追击，一会儿回巡逻，表现是角色来回转身、动画频繁切换。原因是状态转移的阈值没有滞回——追击进入距离 8 米，追击丢失距离也是 8 米，玩家在 8 米附近轻微移动就触发状态抖动。另一个常见来源是感知检测和状态切换不在同一帧运行，感知刚刷新时距离还在范围内，但状态切换时距离已经超出了。
解决：把追击进入阈值设为 8 米，追击丢失阈值设为 12 米（即loseRange大于chaseRange），并保证感知检测结果和状态切换读取的是同一帧数据。我给 FSM 做了个字段：canSwitchState用[SerializeField] private bool stateLocked标记冷却时间——状态切换后 0.3 秒内力不做反向切换，这个强制冷却比单纯调阈值更能治本。
5.5 现象：外部导入的 SolidWorks 模型烘焙 NavMesh 后，生成区域支离破碎
项目用到从 SolidWorks 导出的机械设备模型作为地图场景，烘焙后 NavMesh 出现大面积空洞，AI 走到平台边缘直接掉落。检查发现模型面数极高且包含大量细碎不规则几何体——SolidWorks 导入的模型往往有数千个小平面和倒角结构，超出 NavMesh 烘焙的精度范围，生成时直接忽略小区域。
解决：这类外部模型进入 Unity 后先做减面（把面数控制在十万以内），烘焙前用MeshCollider替代原始碰撞体，把碰撞体层设为Walkable。更稳的做法是：在大面积平台区域手动加一个透明 Plane 标记为Walkable作为寻路地面，让角色路径走在 Plane 上而不是依赖零碎的模型几何。这也是为什么很多工厂类场景项目里，「寻路底盘」是独立于视觉模型的一套简化网格。
6. 继续做深：从状态机到 Utility AI 的平滑迁移
当 AI 需要同时考虑血量、距离、武器状态、队友情况等多个因素做决策时，FSM 的状态爆炸已经无法收拾。这时候可以逐步引入 Utility AI（效用人工智能）：给每个行为算一个评分，选最高分执行。它把决策从「硬状态转移表」变成一个「多因子评分函数」，策划可以对着参数调权重，不需要改逻辑结构。
public class UtilityAIBehaviour : MonoBehaviour { public float EvaluateAttack(Transform self, Transform target, float healthPercent) { // 攻击评分 = 距离因子 * 血量因子 * 技能可用因子 float distance = Vector3.Distance(self.position, target.position); float distanceFactor = Mathf.Clamp01(1f - distance / 10f); float healthFactor = Mathf.Clamp01(healthPercent); // 血量越低越倾向攻击（拼了）或撤退（保守），按需调整 return distanceFactor * 0.6f + healthFactor * 0.4f; } public AIAction Decide(Transform self, Transform target) { float attackScore = EvaluateAttack(self, target, 0.8f); float retreatScore = EvaluateRetreat(self, target, 0.8f); return attackScore > retreatScore ? AIAction.Attack : AIAction.Retreat; } }这个评分结构的优势是：新增一个行为只需写一个EvaluateXX函数，并在Decide里比较分数，不需要像 FSM 那样新增状态时还要检查所有转移条件。调试时把每个评分值Debug.Log出来，可以清楚看到 AI 为什么选了攻击——是距离分高还是血量分高。
我个人的迁移路径是：先用 FSM 把基础 AI 跑通，收集数据（敌人通常会在什么条件下做什么），然后对决策点做评分化改造，一次只改一个决策点，改完跑一段测试看行为是否正确。这样做的好处是每一版都有可对比的行为变化，不会出现「迁移完 AI 集体发疯」的失控场面。
最后一件事：不管用哪种架构，AI 的行为输出都必须有可观测性。在OnDrawGizmos里画视野范围、画当前状态、画评分条；出错时先看 Gizmos 再翻代码，这比我经历过的任何「盲猜原因 + 改参数碰运气」都高效。希望这篇笔记能帮你少走几个项目里最常见的弯路，祝你的 AI 早日不再卡墙。
本文还有配套的精品资源，点击获取
