1. 项目概述：从蓝图到行为树，构建一个会“思考”的敌人

在虚幻引擎5（UE5）里做一个会追着玩家跑的AI敌人，听起来像是游戏开发的入门课，但要把这个“追逐”做得既有智能感又性能高效，里面的门道可不少。很多新手教程会教你拖几个节点，让AI动起来，但往往忽略了背后的决策逻辑和状态管理，结果就是AI要么像个“傻子”一样直愣愣地冲过来，要么在复杂地形里卡住不动。今天，我们就来深度拆解一个基于蓝图和行为树的AI感知与追逐系统，这不仅仅是让AI“看到”并“跑向”玩家，更是要构建一套完整的感知、决策、执行循环。

这个系统的核心价值在于它的模块化和可扩展性。通过蓝图，我们可以快速搭建AI的感官（视觉）和反应逻辑；通过行为树，我们则能清晰地定义AI在不同情境下的行为优先级和状态切换。比如，AI在巡逻时应该悠闲漫步，一旦发现玩家则加速狂奔，如果玩家脱离视线，AI不会立刻“失忆”，而是会前往玩家最后出现的位置搜寻，一段时间无果后才放弃并回归巡逻。这套逻辑，用纯蓝图状态机也能实现，但代码会迅速变得臃肿且难以维护。行为树的优势就在于，它以树状结构清晰地表达了“选择”与“序列”，让AI的“思考过程”一目了然。

接下来，我会带你从零开始，一步步搭建这个系统。我们将重点放在几个核心环节：如何用AIPerception组件让AI“看见”玩家；如何用黑板（Blackboard）作为AI的“记忆”，在不同任务间传递关键信息；以及如何用行为树（Behavior Tree）优雅地组织“巡逻”和“追逐”这两种核心状态及其切换条件。我会分享我在实际项目中踩过的坑，比如为什么要在角色蓝图里封装速度更新函数，而不是在行为树任务里直接修改组件属性，以及如何正确设置装饰器（Decorator）的“观察者中止”逻辑，避免AI行为出现诡异的抽搐。无论你是刚接触UE5 AI的开发者，还是想优化现有AI逻辑的进阶者，这篇实战解析都能给你提供可直接复用的蓝图和深入骨髓的原理理解。

2. 核心系统架构与设计思路

2.1 为何选择“蓝图+行为树”的组合拳？

在UE5中实现AI，你有多种选择：纯蓝图、行为树、环境查询系统（EQS）乃至C++。对于大多数中小型项目或原型开发阶段，“蓝图+行为树”是平衡开发效率、灵活性和性能的最佳组合。蓝图负责处理具体的感知触发、数据设置等事件驱动逻辑，而行为树则负责高层的、基于条件的任务调度。

蓝图（AIController）的角色：你可以把AIController理解为AI的“大脑皮层”，它负责接收外部刺激（如视觉、听觉），并做出最原始的反应。在我们的系统里，AIController中的AIPerception组件检测到玩家后，会立刻将“看到玩家”这个事实以及玩家对象，写入到黑板（Blackboard）中。这是一个即时、事件驱动的过程。蓝图在这里的优势是处理这种离散事件非常直观。

行为树（Behavior Tree）的角色：行为树则是AI的“决策中枢”。它像一个持续的循环，不断地根据黑板中的当前状态（记忆）来决定现在应该执行哪个行为分支。它的核心是“选择器（Selector）”和“序列（Sequence）”节点。选择器会从左到右尝试执行其子节点，直到有一个成功；序列则会按顺序执行所有子节点，直到有一个失败。这种结构天生适合表达“优先级”。在我们的设计中，高优先级的“追逐玩家”分支在左侧，低优先级的“巡逻”分支在右侧。行为树会持续检查条件，驱动AI做出移动、旋转等具体动作。

黑板（Blackboard）的角色：黑板是连接蓝图“感知”和行为树“决策”的桥梁，是AI的“短期记忆”。它是一个简单的键值对存储。例如，键HasLineOfSight（布尔值）存储是否看到了玩家，键EnemyActor（对象引用）存储看到的玩家是谁，键PatrolLocation（向量）存储下一个巡逻目标点。蓝图负责写入，行为树负责读取并据此决策。这种解耦使得逻辑清晰，调试方便——你可以在运行时直接查看黑板里的值，一眼就知道AI现在“知道”什么。

2.2 系统工作流与状态切换设计

整个系统的工作流是一个清晰的闭环：感知 -> 更新记忆 -> 决策 -> 执行 -> 再感知。

1. 感知阶段：AI身上的AIPerception组件（配置了视觉）持续检测周围。当玩家进入视野，组件触发OnTargetPerceptionUpdated事件。
2. 记忆更新阶段（蓝图）：在AIController的蓝图里，响应上述事件。验证目标是玩家后，立即向黑板写入：HasLineOfSight = True,EnemyActor = 玩家对象。同时，清除之前可能存在的“丢失计时器”。
3. 决策阶段（行为树）：行为树每帧（或按设定频率）从根节点开始执行。根节点是一个选择器，它先检查左边的“追逐”分支。该分支上挂着一个“黑板装饰器”，条件是HasLineOfSight是否为True。如果条件满足，就进入追逐分支。
4. 执行阶段（行为树）：在追逐分支内，是一个序列：首先执行“旋转面向黑板条目”任务，让AI转身面对EnemyActor（玩家）；然后执行自定义的“追逐玩家”任务，这个任务会调用AI角色蓝图里的函数，将其移动速度提高到追逐档；最后执行“移动至”任务，让AI向玩家当前位置移动。
5. 状态切换：当玩家跑出AI视野，AIPerception组件会再次触发事件，但这次成功感知标志为False。蓝图逻辑会启动一个延时（例如4秒），延时结束后，才将黑板中的HasLineOfSight设为False。这个延时给了AI一个“犹豫期”，模拟短暂的记忆。一旦黑板值变为False，行为树中“追逐”分支的装饰器条件不再满足，选择器就会失败，转而执行右侧的“巡逻”分支。
6. 巡逻阶段：巡逻分支也是一个序列：先执行“寻找随机巡逻点”任务，在AI周围随机找一个可达位置，写入黑板的PatrolLocation；然后AI以较慢的巡逻速度“移动至”该点；到达后“等待”几秒；之后循环回“寻找随机巡逻点”，开始下一次巡逻。

这个设计的精妙之处在于延迟状态切换和基于条件的任务中止。如果没有4秒的延时，AI会在玩家离开视野的瞬间立刻“失明”，行为会显得很突兀。而装饰器的“观察者中止（Observer Aborts）”设置为“两者（Both）”，确保了当HasLineOfSight从True变False时，正在执行的追逐任务会被立即中止（防止AI对着空气冲刺），同时当值从False变True时，低优先级的巡逻任务也会被中止，立即响应高优先级的追逐。

3. 关键组件详解与蓝图实现

3.1 AIPerception组件：让AI拥有“眼睛”

AIPerception组件是UE5 AI系统的感官输入接口。它可以配置视觉、听觉、伤害感知等多种感官。对于追逐系统，视觉（Sight）是最核心的。

配置要点： 在AIController蓝图中添加AIPerception组件后，需要在细节面板中为其添加一个AISightConfig。这里有几个关键参数：

• 视觉半径（Sight Radius）和失明半径（Lose Sight Radius）：通常后者大于前者。这决定了AI能看多远，以及目标需要跑出多远才会从“视野边缘”彻底消失。失明半径大于视觉半径可以避免目标在边界反复横跳导致的频繁状态切换。
• 视场角（Peripheral Vision Angle Degrees）：AI的正前方视野角度。180度意味着前方半球都能看见。
• 检测归属（Detection by Affiliation）：这用于实现阵营系统。默认情况下，所有Actor都是“中立（Neutral）”。为了让AI能“看到”玩家，你必须勾选“检测中立（Detect Neutrals）”。更专业的做法是设置Actor的GenericTeamId，让AI只敌对特定阵营，这样更灵活。

事件绑定与数据处理： 你需要将AIPerception组件的OnTargetPerceptionUpdated事件绑定到自定义蓝图逻辑上。这个事件会返回被感知的Actor和一个AIStimulus结构体。AIStimulus里有一个SuccessfullySensed布尔值，至关重要：True表示“刚刚发现”或“持续看见”，False表示“刚刚丢失”。

注意：SuccessfullySensed为False并不直接等同于“没看见”，而是“这次更新事件是因为丢失目标而触发的”。因此，我们的逻辑是：当SuccessfullySensed为True时，立刻更新黑板并清除计时器；当为False时，启动一个延时计时器，延时结束后才更新黑板为“未看见”。这模拟了AI短暂的注意力留存。

3.2 黑板（Blackboard）：AI的共享记忆库

黑板资产本质上是一个变量定义表。在内容浏览器中创建BB_Enemy后，我们需要定义三个键：

1. EnemyActor(Object类型，基类Actor)：用于存储当前感知到的玩家对象引用。在行为树的任务中，可以作为“移动至”或“面向”的目标。
2. HasLineOfSight(Bool类型)：核心状态标志。为True时，行为树执行追逐分支。
3. PatrolLocation(Vector类型)：存储下一个巡逻目标点的世界坐标。

黑板的使用哲学：黑板只应存储最精简、必要的状态信息。避免把复杂的对象或者需要频繁计算的数据放进去。它的数据应由一个权威来源（通常是AIController）写入，由多个消费者（行为树中的任务）读取。在AIController蓝图中，通过Get Blackboard节点获取黑板引用，然后使用Set Value as ...系列节点进行写入。

3.3 行为树（Behavior Tree）：AI的行为决策流

创建BT_Enemy后，首先在根节点（Root）的属性里指定黑板资产BB_Enemy。我们的树结构如下：

Root └── Selector (命名为 "AI Root") ├── Sequence (命名为 "Chase Player") │ ├── [Decorator: Blackboard] (条件: HasLineOfSight == True) │ ├── Task: Rotate to Face BBEntry (目标: EnemyActor) │ ├── Task: BTT_ChasePlayer (自定义任务，提高速度) │ └── Task: Move To (目标: EnemyActor) │ ├── Sequence (命名为 "Patrol") │ ├── Task: BTT_FindRandomPatrol (自定义任务，找点并降低速度) │ ├── Task: Move To (目标: PatrolLocation) │ └── Task: Wait (等待4秒) │ └── Task: Wait (等待1秒，保底行为)

节点解析：

• Selector (AI Root)：它是整棵树的调度器。它先尝试执行“Chase Player”序列。如果该序列上的装饰器条件不满足（即没看见玩家），或者序列中某个任务失败，Selector就会转而尝试下一个子节点“Patrol”。如果“Patrol”也失败（比如找不到巡逻点），则会执行最后的“Wait”任务，让AI发呆1秒后重新决策。
• Sequence (Chase Player/Patrol)：序列确保其中的任务按顺序执行。对于追逐序列，必须先转身，再加速，最后移动。如果“移动至”任务因为路径被阻挡而失败，整个序列失败，控制权会返回给Selector。
• 装饰器（Decorator）：附着在“Chase Player”序列上。我们使用“Blackboard Based Condition”类型。关键属性设置：
  • 观察者中止（Observer aborts）：设置为“两者（Both）”。这是实现灵敏响应的核心。当HasLineOfSight值改变时，它不仅会中止当前分支（如果条件变假），也会中止更低优先级的兄弟分支（如果条件变真），让高优先级分支立刻抢占执行。
  • 黑板键（Blackboard Key）：选择HasLineOfSight。
  • 关键值观察（Key Query）：选择“已设置（Is Set）”。这意味着我们只关心这个键是否有值（非空），对于布尔键来说，就是是否为True。你也可以选择“值等于（Is Equal to）”并指定True，效果类似。

4. 自定义任务节点深度实现

4.1 BTT_ChasePlayer：动态调整移动状态

内置的“Move To”任务只能让AI移动，但不会改变其移动属性。为了让AI在追逐时跑得更快，我们需要自定义任务。

创建与事件： 在行为树编辑器中点击“新建任务”，创建BTT_ChasePlayer。打开其蓝图，首要节点是Event Receive Execute AI。这个事件在行为树执行到此任务时触发。它提供两个关键参数：Owner Controller（执行该任务的AIController）和Controlled Pawn（该AIController所控制的Pawn，即我们的AI角色）。

最佳实践：通过接口或函数调用修改属性： 一个常见的错误是直接在任务蓝图里，通过Controlled Pawn获取CharacterMovement组件并修改其Max Walk Speed。这虽然能工作，但破坏了封装性，使得行为树任务与具体的Pawn实现紧密耦合。更好的做法是让任务通知Pawn自身去改变速度。

1. 在AI角色蓝图中创建函数：打开Enemy_Character蓝图，创建一个名为UpdateWalkSpeed的公共函数，添加一个float类型的输入参数NewWalkSpeed。
2. 函数内部实现：在函数内，获取自身的CharacterMovement组件，调用Set Max Walk Speed节点，将输入参数NewWalkSpeed传递进去。
3. 在任务中调用：回到BTT_ChasePlayer任务，在Event Receive Execute AI后，将Controlled Pawn转换为Enemy_Character类型（使用Cast To节点）。转换成功后，调用该角色的UpdateWalkSpeed函数，并传入一个值，比如500.0。
4. 任务结束：调用Finish Execute节点，并将Success引脚设为True，标记任务成功完成。务必处理转换失败的情况，连接Cast Failed引脚到另一个Finish Execute节点，并将Success设为False。

参数化设计： 为了让任务更通用，不应把速度值500.0写死。选中这个浮点常数，右键选择“提升为变量”，命名为ChaseSpeed。然后，在变量的细节面板中，勾选“实例可编辑（Instance Editable）”。这样，在行为树编辑器中选中BTT_ChasePlayer任务节点，就能在细节面板里直接修改ChaseSpeed的值，方便对不同类型敌人进行差异化配置。

4.2 BTT_FindRandomPatrol：智能寻路与容错

巡逻任务的核心是找到一个AI可以走到的随机位置。

实现步骤：

1. 同样基于Event Receive Execute AI开始。
2. 转换Controlled Pawn为Enemy_Character，并调用UpdateWalkSpeed函数，传入一个较小的值（如125.0），将其提升为变量PatrolSpeed。
3. 获取AI当前位置（Get Actor Location）。
4. 使用GetRandomReachablePointInRadius节点。该节点需要输入一个Origin（原点，即上一步获取的位置）和一个Radius（半径，例如1000）。它将尝试在原点指定半径的导航网格（NavMesh）上，寻找一个随机可达点。这是一个关键节点，它确保了生成的位置是AI实际可以行走到的，避免了卡在墙里或掉下悬崖。将半径值也提升为变量PatrolRadius以便调整。
5. 该节点返回两个值：一个布尔值bResult表示是否成功找到点，一个向量RandomLocation表示找到的位置。
6. 使用Branch节点判断bResult。如果为真，使用Set Blackboard Value as Vector节点，将RandomLocation写入黑板键PatrolLocation。如果为假（例如，AI处在一个非常狭小或被包围的空间），作为一种容错策略，可以将AI的当前位置（Get Actor Location）写入PatrolLocation，这样AI会在原地等待下一次巡逻决策。
7. 最后，无论哪种情况，都标记任务成功（Finish ExecutewithSuccess = True）。同样需要处理角色转换失败的逻辑。

实操心得：GetRandomReachablePointInRadius的性能开销比简单的随机向量要大，因为它需要查询导航网格。如果场景很大且AI很多，频繁调用可能成为瓶颈。一种优化策略是：在BTT_FindRandomPatrol任务中，成功找到点后，不仅写入本次的PatrolLocation，还可以预计算并存储下一个或下几个备选点到一个数组中（存储在AIController或角色上），在下次执行巡逻任务时直接从中选取，减少实时寻点调用。当然，对于大多数情况，直接使用该节点是完全可行的。

5. AI控制器蓝图的事件逻辑编排

AIController蓝图（Enemy_Controller）是整个系统的指挥中心，它负责初始化行为树和处理感知事件。

5.1 初始化：绑定行为树

在Event BeginPlay或Event On Possess事件中（后者在控制器占据一个Pawn时触发，更推荐），添加Run Behavior Tree节点，并指定资产为BT_Enemy。这样，当这个AIController生效时，对应的行为树就开始运行了。

5.2 感知事件处理：核心状态机

这是蓝图部分最复杂的逻辑，直接决定了AI反应的灵敏度和真实感。

1. 事件触发：将AIPerception组件的OnTargetPerceptionUpdated事件拖入图表。
2. 目标过滤：首先，需要确认感知到的Actor是玩家。有两种常用方法：
   • 标签（Tag）检查：使用Actor Has Tag节点，检查感知到的Actor是否拥有“Player”标签。你需要在玩家角色蓝图的细节面板中为其添加这个标签。这种方法简单直接。
   • 类（Class）检查：使用Cast To节点，尝试将Actor转换为你的玩家角色类（如ThirdPersonCharacter）。这种方法类型安全，但如果你有多种玩家类型，可能需要检查多个类。
3. 解析刺激：从事件的Stimulus引脚拉出Break AIStimulus节点，获取SuccessfullySensed布尔值。
4. 分支逻辑：
   • 如果SuccessfullySensed为True且目标是玩家：这意味着AI刚刚看到或持续看着玩家。
     • 清除旧计时器：首先，检查是否存在一个之前因为玩家丢失而设置的延时计时器（我们将其句柄存储在一个变量中，如EnemyTimerHandle）。如果存在，使用Clear and Invalidate Timer by Handle节点将其清除。这防止了旧的“丢失计时”干扰新的“发现”事件。
     • 更新黑板：立即将黑板中的HasLineOfSight设为True，将EnemyActor设为当前感知到的玩家Actor。
   • 如果SuccessfullySensed为False且目标是玩家：这意味着玩家刚刚离开了AI的视野。
     • 设置延时计时器：使用Set Timer by Event节点，设置一个延时（例如4.0秒）。将延时时间和返回的计时器句柄都提升为变量以便管理。这个计时器绑定到一个自定义事件（例如OnLostSightTimeout）。
     • 在延时事件中：将黑板中的HasLineOfSight设为False。注意：此时不要清除EnemyActor的引用。保留这个引用，可以用于后续扩展，比如让AI移动到“最后已知位置”。

graph TD A[AIPerception OnTargetPerceptionUpdated] --> B{Actor是玩家?}; B -- 否 --> C[忽略]; B -- 是 --> D{SuccessfullySensed?}; D -- True: 发现/持续看见 --> E[清除旧的丢失计时器]; E --> F[更新黑板: HasLineOfSight=True, EnemyActor=玩家]; D -- False: 刚刚丢失 --> G[设置延时计时器]; G --> H[延时结束]; H --> I[更新黑板: HasLineOfSight=False];

这个延时机制是让AI行为显得“智能”而非“机械”的关键。没有它，玩家只要在视野边界一闪，AI就会立刻停止追逐，显得很蠢。有了延时，AI会表现出“我好像看到那边有动静，再找找看”的迟疑感。

6. 常见问题、调试技巧与性能优化

6.1 调试：让AI的“思考”过程可视化

UE5提供了强大的AI调试工具，一定要善用。

• 显示行为树：在编辑器运行模式下，打开“窗口（Window）-> 调试（Debug）-> 行为树（Behavior Tree）”。选择你的AI角色，可以看到行为树正在实时执行，当前活跃的节点会高亮显示。这是理解AI决策流程最直观的方式。
• 显示黑板：在行为树调试窗口，通常可以同时看到关联的黑板及其当前键值。你可以确认HasLineOfSight、EnemyActor等值是否按预期变化。
• 显示导航网格和AI调试信息：在视口中按“P”键可以显示/隐藏导航网格（绿色区域）。在运行模式下，在“输出日志（Output Log）”窗口输入控制台命令ShowDebug AI，可以在AI头顶显示其当前状态（如“Chasing”、“Patrolling”）和黑板键值。

6.2 常见问题与解决方案

6.3 性能优化与扩展思路

• 降低Tick频率：行为树和AIPerception组件默认每帧（Tick）都更新。对于大量非活跃的AI（如远离玩家的敌人），这是不必要的开销。可以在AIController或行为树组件上设置Tick Interval，比如0.2秒更新一次，能显著提升性能。
• 感知系统优化：AIPerception的视觉检测（尤其是射线检测）开销较大。可以通过调整AISightConfig中的Auto Success Range（在此范围内自动视为可见，无需射线检测）和Point Of View Backward Offset（将检测原点从AI脚底后移，更符合“眼睛”位置）来优化。对于大量AI，可以考虑分帧进行感知更新。
• 扩展功能：
  • 听觉感知：在AIPerception中添加AIHearingConfig。当玩家开枪或奔跑时，发出一个Noise Event，AI可以听到并前往声源位置（更新黑板中的InvestigationLocation），增加游戏的策略性。
  • 最后已知位置：在玩家离开视野时，不仅启动延时，还可以将玩家最后被看到的位置存入黑板（如LastKnownLocation）。然后修改追逐分支的“移动至”任务，目标不是EnemyActor，而是LastKnownLocation。这样AI会跑到玩家最后出现的地方进行“搜查”，显得更真实。
  • 巡逻路径点：替换随机的GetRandomReachablePointInRadius，使用预设的巡逻路径点（Spline或Actor数组）。创建一个新的行为树任务，让AI按顺序或随机访问这些路径点，形成固定的巡逻路线。
  • 攻击行为：在追逐分支的“移动至”任务后，添加一个“检查距离”的装饰器或服务。当AI与玩家距离小于某个值时，中止移动，执行一个新的“攻击”序列（播放攻击动画、造成伤害等）。攻击完成后，根据是否还能看到玩家，决定继续追逐还是回归巡逻。