企业官网建设流程全解析

我最早遇到多敌人AI的锅，是在一个FPS原型里：玩家刚跳进广场，二十来个AI一窝蜂围过来，帧率直接从75掉到30，CPU Game线程长期烧在25ms以上。当时第一反应是“是不是材质太贵”，结果把场景压到只剩地面和玩家，帧率依然回不来——问题明摆着在AI身上。后来花了三周做性能剖析和分系统裁剪，才把百人级AI场景稳定在60FPS的预算线内。

这篇就以“多敌人AI场景”为例，把我实际用过的UE FPS性能优化思路、工具、参数和经验完整写一遍。适用对象是已经能搭出敌人AI、但发现人一多就卡的开发者；也包括那些刚接触性能剖析、不知道从哪下刀的UE新手。文里所有方法都不依赖特殊插件，标准UE工程就能落地。

1. 先搞清楚瓶颈在哪：多敌人AI场景里的CPU开销账单

每次有人问“AI多了卡顿怎么优化”，我第一句都是：先别看代码，先开Profiling。因为多敌人AI的性能问题很少是单一原因，你猜是行为树，实际可能是动画蓝图；你猜是寻路，实际可能是感知系统的高频射线。没有数据支撑的优化全是在碰运气。

1.1 每个AI敌人身上到底有哪些“隐形账单”

一个标准UE AI敌人，看起来只是“走来走去、看到玩家就开火”，但后台同时挂着好几套系统：

• AIController的Tick和大脑逻辑，包含行为树运行、Blackboard读写、装饰器和Service的往复计算；
• 感知组件（AIPerception）的视觉、听觉检测，视觉通常依赖LineTrace/Sweep，听觉依赖半径匹配和二次过滤；
• 寻路系统，PathFollowing组件会驱动CharacterMovement，算当前路径段、速度、转向，还要被NavMesh和避障模块反复检查；
• 动画蓝图，只要敌人处于可见范围，骨骼更新就会跑，何况每个敌人都有自己的AnimInstance。
• 还有物理、音频、特效之类的边角开销。

粗暴地说：一个完备的AI敌人，CPU单帧消耗可能是“视野射线两三条 + 行为树几十次函数调用 + 动画骨骼几百次变换计算”，再叠上移动组件的步态解析。当这个数量乘以50甚至100时，哪怕每个敌人只吃0.1ms，光Game线程就多出5~10ms，这还没算缓存未命中和线程切换的放大效应。

我的建议是先按“单敌人在不同距离、不同状态下的CPU消耗”列一个预估表。实际测试中，一个距离玩家10米内、正在战斗、播放瞄准动画的AI，可能吃到0.5ms以上；而一个站在远处发呆、只播待机动画的AI，可能只有0.05ms。性能优化的关键不是把每个AI都砍到极简，而是把“高消耗AI”的数量控制住，让低消耗AI占比尽量大。

1.2 用工具把“感觉帧率”变成“可对比的数字”

靠眼睛看帧率做优化，只能发现“卡了”，不能回答“卡在哪”。我在这个项目里用的工具链路是这样的：

第一步，先跑stat unit。这个命令能直接看到Frame、Game、Draw、GPU、RHIT几个关键耗时。AI问题几乎都出在Game线程，所以重点看Game耗时占不占Frame的大头。如果Game帧时间超过Draw/GPU，那瓶颈就在CPU模拟逻辑，而不是渲染。

第二步，跑stat cpu，按CPU消耗排序找到最贵的函数。如果看到UCharacterMovementComponent::TickComponent、FActorPerceptionBlueprintInfo一类的项目函数出现在上位，就说明问题已经锁定到AI相关模块。

第三步，用Unreal Insights做一次带帧数据的Capture。这个工具比stat命令更直观，能按线程、按时间线看到每个帧里被谁占了。配合SCOPE_CYCLE_COUNTER宏给项目里的AI函数手动插桩后，你甚至能精确到“某个AI的感知查询消耗了0.15ms”。

这里要特别提醒：不要一上来就在编辑器里PIE（Play In Editor）跑性能测试。编辑器模式自带大量额外开销，结果和独立打包后能差出3倍以上。我一般用-game -log参数启动独立进程，关闭VSync，固定分辨率，这样拿到的才是接近真实玩家的数据。

2. 分层裁剪：让AI不要每帧都抢CPU

定位到瓶颈是AI Tick相关之后，第一波优化不是改逻辑，而是改“触发频率”。这是整个性能优化里性价比最高的一步。用江湖话说：你不可能让每个AI都时刻保持满血大脑，你得让他们“在需要聪明的时候聪明，不需要的时候发呆”。

2.1 设计一套AI更新频率管理器

UE原生机制里，AIController默认跟着AITick走，几乎每帧都在刷新决策。但在多敌人场景里，大部分AI并不需要每帧重新思考。比如：

• 距离玩家100米外的敌人，0.5秒思考一次就够了；
• 30米外的敌人，0.1~0.2秒思考一次；
• 真正进入交战状态的敌人，才需要0.05秒甚至每帧更新。

最笨但最有效的做法，是自己写一个“更新频率控制器”。思路很简单：给每个AI的AIController挂一个周期Timer，按逻辑去执行RunBehaviorTree或Wait，而不是依赖原生的每帧Tick。核心伪代码大致是这样：

// 在AIController中为每个AI规划更新间隔 float UMyAIController::GetCurrentUpdateInterval() const { float Dist = GetDistanceToPlayer(); // 你也可以缓存这个值 if (Dist < 1500.0f) return 0.05f; // 15米内：高频战斗AI if (Dist < 3000.0f) return 0.1f; // 30米内：中频警戒AI if (Dist < 8000.0f) return 0.25f; // 80米内：低频巡逻AI return 1.0f; // 更远处：近似睡眠 }

然后用SetTimer去驱动大脑逻辑，而不是让AIController每帧Tick。这样做的直接收益是：之前100个AI每帧都在跑行为树，现在只有交战的几个在跑，其他AI每0.1~1秒才跑一次。就这一项，CPU的Game线程开销常常能砍掉一半以上。

这里有个坑必须说：当你使用低频更新时，AI的反应速度会变慢。所以必须配合“事件驱动”来补充关键判断。比如敌人被子弹击中、看到队友死亡、听到枪声，这些事件应该立刻唤醒附近的AI，而不是等下一个更新周期。用UE的AIMessage或自建事件总线是比较干净的办法，别让AI永久“变傻”。

2.2 感知系统是开销大户，先给它“瘦身”

感知组件（AIPerception）是另一个无底洞。默认情况下，每个AI的视觉感知会做周期性的LineTrace网格检查，听觉感知会持续比对刺激源。敌人越多，射线数量就指数上涨。

我的实操方案分两步。

第一步，控制感知更新间隔和范围。在UAIPerceptionComponent的SetSenseEnabled和ConfigureSense里，把视觉最大距离从默认的3000降到1000~1500，听觉范围从5000降到2000~3000。战斗FPS场景里玩家出现在1000以外还要求AI立即发现，其实没太大必要。同时把视觉检测的UpdateInterval设置为0.15~0.3秒，而不是每帧检测。

第二步，共享感知结果。比如场景有一个“感知管理器”，由它每0.2秒广播一次“是否有人类玩家可见”的结果，所有AI直接读这个共享值，而不是各自去发射射线。这在敌人数量超过20时，能省掉绝大多数的重复Trace开销。代价是AI之间不会有差异化视野，但对大多数FPS敌人来说完全可以接受。如果游戏里需要“某些敌人视野特别好”，你可以预留一个PerceptionOverride字段，让特殊Boss或精英AI走自己的独立感知。

下面是感知配置的一个简化示例，我用C++控制，避免蓝图节点每帧展开：

UAIPerceptionComponent* Perception = CreateDefaultSubobject<UAIPerceptionComponent>(TEXT("Perception")); UAISenseConfig_Sight* Sight = CreateDefaultSubobject<UAISenseConfig_Sight>(TEXT("Sight")); Sight->SightRadius = 1500.0f; Sight->LoseSightRadius = 1800.0f; Sight->PeripheralVisionAngleDegrees = 90.0f; Sight->DetectionByAffiliation.bDetectEnemies = true; Sight->AutoImplementSight = false; // 关键：改为低频感知更新，不要每一帧都扫描 Sight->UpdateInterval = 0.3f; Perception->ConfigureSense(*Sight); Please注意，`UpdateInterval`实际上是Sense内部更新频率的设定，在UE5.1以后更推荐用`UAIPerceptionSystem::SetPerceptionSystemTickFrequency`这类全局配置。但核心思路不变：降低感知刷新频率。 ## 3. 行为树与寻路：大脑和腿都要减负 感知瘦身之后，接下来大头就是行为树和寻路。这两块比较微妙：过度优化容易把AI变得肉眼可见的蠢，不优化又会被敌人数量拖死。我的经验是“按状态分层优化”，而不是一刀切禁用功能。 ### 3.1 行为树逻辑精简，避免每帧做昂贵计算 行为树本身是一个“事件驱动+频率驱动”的混合体。很多开发者写树的时候，习惯把一个距离判断放在根节点的Decorator里，让它一帧跑一次： ```ue DistanceCheckDecorator -> MoveToTask

看起来没问题，但如果这棵树的根节点上有多个类似Decorator（距离、血量、武器冷却、队友数量），每帧全部执行一遍，100个AI就是几百次计算。更麻烦的是，有些Decorator内部还做LineTrace、Range查询，一个AI一帧能吃掉0.2ms。

我的优化路径是：

• 把所有“低频且稳定性高”的判断改成低频更新。比如“目标是否离开警戒距离”这种判断，放在一个Service节点上，每0.2秒执行一次并写入Blackboard，而不是作为每帧Decorator。
• 把“昂贵的场景查询”独立出来。比如“附近是否有可用的掩体”、“队友是否在战斗”，这些可以交给一个专门的UEnvQuery请求，只在AI状态切换时跑一次，结果缓存到Blackboard。
• 尽量避免在Task里做等待循环。例如某个Task需要“等枪声消失”，如果用Wait节点+每帧检查耗时太久，不如让事件系统直接发Signal切断树。
• 善用行为树本身的Interruptable模式：低频大树负责长期目标，高频小树负责应急反应。外围巡逻AI跑低频大树，只有收到攻击事件才切换小树。

另外注意，Service和Task里的TickInterval要设置非零值。UE里UAITask自带TickInterval，不填的话默认每帧Tick。我见过不少项目把Service忘写间隔，优化半天结果白费。

3.2 寻路避障：别让所有AI同一帧挤进NavMesh

大量AI同时移动，避障和路径重算会成为“隐形炸弹”。尤其是当玩家放了一颗手雷，所有AI同时重新寻路的时候，那几帧会突然出现巨坑。处理思路有四个：

第一，分散寻路请求。不要在同一帧让所有AI都RequestMove。给每个AI的寻路请求加一个小随机延迟（0.05~0.2s），就能明显削平峰值。听起来很基础，但在实测里经常能消掉50%以上的寻路尖峰。

第二，合理使用Crowd。UE自带的DetourCrowd适合大量同类AI，它把避障计算从个体寻路中抽出来，统一用集群解算。代价是控制力下降，比如移动时与玩家的穿插表现不如单Agent自然。如果项目对FPS手感要求高，建议只在远程杂兵身上用Crowd，近战精英保留独立寻路。

第三，限制动态NavMesh修改。运行时频繁Add/RemoveUNavModifierComponent、调整障碍物，会触发NavMesh局部刷新。这在一两个场景还行，多AI战斗里就是灾难。尽量把障碍物状态固定在“静态”或“阻挡盒”层面，别用动态修改去表现“门被炸开”“墙被打破”。

第四，调整PathFollowing参数。AI到达目标后一直抖动，很多是因为AcceptanceRadius太小，导致它反复小步修正。把这个值从默认的10~20改成30~50，配合bStopMovementOnFinish开启，可以让批量移动更稳定。下面是几个常用参数猜测，具体以你自己的项目为准：

3.3 让“远处AI”用简化逻辑代替完整大脑

第三个大方向是AI LOD。UE引擎并没有一个官方统包的“AI LOD系统”，但我们可以自己把AI分成三档：

• LOD0（交战）：距离玩家15米内，被看到或正在战斗。完整行为树、完整感知、高频更新。
• LOD1（警戒）：距离15~50米，用一半行为树，感知隔0.2~0.3秒，寻路请求频率减半。
• LOD2（远处）：超过50米，放弃行为树复合逻辑，只保留一个简单的“移动Actor”脚本，可能连AIController都不创建。播放远处待机或巡逻动画即可。

在点“创建敌人”的时候，先别急着把AIController和完整AI组件都挂上。你可以先生成只带Mesh和Animation的“外观Actor”，当玩家靠近到LOD1距离时，再动态挂载AI组件并初始化。反过来，敌人远离玩家后，又可以把AI大脑“摘掉”，只保留低功耗外观。这套思路在很多游戏里叫“AI Prespawn/Actor Pooling”，实际效果比单纯调频率来得更显著，因为省掉的不是一次Tick，而是整条AI链路。

4. 动画和移动组件：多敌人场景里的隐性CPU杀手

我见过不少项目把AI模块撸到飞起，帧率依然不行，最后发现卡在最容易被忽略的地方：动画蓝图的每帧计算。多敌人场景里，每个敌人都有骨骼网格体，骨骼一多，CPU一样会爆。

4.1 动画蓝图优化：别让每个敌人都做完整IK和状态机更新

一个常见FPS敌人动画蓝图里，往往挂着“移动速度混合 + 射击蒙太奇 + 手部IK + 脚步IK”等一大堆功能。单独看一个敌人还好，但20个敌人同时播放骨骼动画、做射线检测来贴合地形，那就是一场灾难。

优化顺序我建议这样：

1. 把动画蓝图的Try Get Pawn Owner、Get Velocity等节点尽量缓存，不要在AnimGraph里每帧重复调用。减少蓝图节点本身就是减负。
2. 关闭不必要的Trace。脚步IK、视线IK、武器贴合IK，每一个都需要开销。FPS里只有近战精英需要脚步IK，远程杂兵完全禁用。
3. 用Fast Path优化动画蓝图属性绑定。能用EvaluateGraphExposedInputs处理的，别绕道蓝图函数。
4. 远距离敌人直接切到UAnimationSharing插件。这个插件可以让多个相同骨骼网格的敌人在远处共享动画序列，甚至共享AnimInstance，实测能削掉60%以上的骨骼更新开销。

中对动画共享有一个常见误解：用了它敌人会看起来“整齐划一”。实际上只要在低LOD下启用，玩家根本察觉不到远处敌人的动画差异。我的配置是“15米内全部独立动画，15~50米穿插使用混合，50米以上启用共享播放”，同时保留动画LOD。

4.2 可见性剔除与骨骼网格LOD设置建议

渲染和动画是两回事，但它们都会占用CPU。多敌人AI场景中，骨骼的Transform更新、布料模拟、阴影投射，都会随着敌人数线性增长。

• 给敌人骨骼网格设置合理的LOD，比如LOD0是4万面，LOD1是2万面，LOD2是8千面。在材质Shader复杂的情况下，远距离LOD的收益很可观。
• 开启Mesh Component Update Invisible：离开视野的敌人，直接停止骨骼更新。这个开关默认可能是关闭的，但多敌人场景建议打开。
• 用CullDistanceVolume尤其是“分距离剔除”功能，把敌人网格在150米外整个剔除，改播一个极简粒子或静态框。

这里有个小技巧：在项目设置里开启r.SkeletalMeshBoneRadiation或者对单独的SkeletalMeshComponent调用SetMinLOD，可以避免低端电脑渲染过多骨骼节点。不过要注意LOD切换时的视觉瑕疵，最好用材质透明度或距离过渡掩饰。

4.3 物理、布料与音频也要“抓典型”

多敌人AI场景里，每个敌人如果都挂了物理碰撞体，或者穿了带布料的服装（风衣、裙子、旗帜），开销会非常可观。布料模拟本身在CPU上跑，20个穿风衣敌人就是20个布料解算器。

我的经验是：

• 普通小兵的碰撞体换成单纯胶囊体，别挂复杂的物理资产。
• 远离玩家的敌人全部禁用布料模拟，启用bDisableClothSimulation。
• 音频方面，限制同时播放的脚步声和语音数量。UE里可以在GameUserSettings或AudioMixer里设置并发限制，别让100个AI同时喊话。

5. 一套从测试到上线的性能优化流程

优化做完不是结束，得有一套能复现、能验证的流程。不然你会在“觉得变好了”和“上线后还是卡”之间来回摇摆。

5.1 建立可复现的压力测试场景

我通常会准备三档测试场景：

• 轻度：20个敌人，模拟巷战小规模交火；
• 中度：50个敌人，模拟玩家进入营地；
• 重度：100~150个敌人，模拟Boss战或尸潮。

每个场景固定玩家出生点、固定敌人分布、固定行为模式（尽量拉满），然后记录以下指标：

跑测试时我会用stat unit确认帧时间预算，再用Unreal Insights取一帧完整Profile。重点是“重度和中度”场景，因为我发现很多项目轻度场景跑得很顺，一上重度就原形毕露。

5.2 从火焰图到优化落地的验证循环

我的工作循环是：

1. 记录当前基线数据，包括Game线程耗时、每个AI子系统的占比、平均帧率和P95帧。
2. 做一次“单点优化”，比如把AI Tick间隔从每帧改成0.1秒。
3. 重新跑同一个场景，对比基线数据。只保留收益明显的改动。
4. 如果帧率没变化，立刻回滚这个方案，不要恋战。

有些优化手段表面看着合理，实际因为瓶颈转移，反而没效果。比如你把AI感知从每帧改成0.3秒，结果帧率只提升了0.5ms，那说明感知本来就不是真正瓶颈。这时候应该重新看Profiling，别硬做。

这里还要强调：性能优化是多系统合力的事。你减掉AI 2ms，但动画蓝图没动，总Game耗时还是超线。所以每轮优化后，我都会再跑一次stat cpu看当前Top函数，确保下一个目标选对对象。

5.3 多敌人AI场景的参数配置参考表

下面是我在实际项目中整理出的参数配置参考，不是唯一标准，但可以直接抄去试：

这里有个原则：这些值不是越小越好。AcceptanceRadius设太大，AI会“走过头”；感知间隔设太长，FPS敌人会显得反应迟钝。所以优化时一定要配合手感测试，尤其是战斗AI，宁可损失一点CPU，也不要让玩家觉得敌人“瞎”了。

6. 我踩过的几个多敌人AI性能坑

最后分享几个我实际被坑过的点，每个都是血泪。

6.1 小量敌人也能卡：问题在加载而非AI

有一阵我测试的敌人数量只有20只，却依然掉帧。开Profiling发现卡顿来自FAsyncLoading和AssetCache，一看日志：每个敌人Spawn时都动态加载了武器Mesh和贴图，第一次碰面硬卡了500ms。后来统一改用对象池，敌人Spawn前把武器资源预加载到内存，运行时只做UObject复用，卡顿直接消失。

对象池在多敌人场景中几乎是必须的，尤其FPS会频繁“刷怪/死亡”。用UPooledActor封装，Spawn/Despawn时只设置激活状态，而不是反复Load资源，这个习惯越早养成越好。

6.2 避障让AI“原地发抖”

把避障频率调低后，AI偶尔会在窄路口抖动，看起来像卡住。这个问题的本质是AcceptanceRadius和AvoidanceRadius的配合不当。我的解决办法是：保留CrowdAgent的避障更新，但把AvoidanceRadius从60降到30，同时把AcceptanceRadius调大到40以上。如果还抖，检查NavMesh的Agent Radius是不是小于胶囊体半径。

6.3 优化后AI变“傻”了，该怎么补救

把感知频率降到0.3秒后，玩家绕到AI身后，AI要等0.3秒才发现，手感上非常迟钝。这个问题的解法不是把全局感知频率调高，而是给“玩家开火、AI被击中、队友被击倒”这类事件加一个即时唤醒。我用项目管理器监听这些事件，触发时立即对该区域AI强制做一次NotifyPerception。这样既保证正常状态下低频省钱，又保证战斗关键时刻反应速度足够。

6.4 小心引擎侧的隐藏开关

性能优化时，别忽略引擎通用配置。比如AsyncLoadThread、MotionBlur、DynamicShadow这些。多敌人场景尤其建议关闭动态阴影的复杂自阴影，或者把Shadow Map分辨率调低。一个常见的坑是开启r.VolumetricFog后，AI数量和场景范围一大，GPU也会被拖得很惨。说好的“AI优化”，最后变成全局画质调优。

最后分享一个我常用的“优化验证小工具”

我喜欢在项目里放一个控制台命令，用来一键生成压力测试敌人：

static FAutoConsoleCommand SpawnAICmd( TEXT("MyGame.SpawnAI"), TEXT("Spawn N AI at random nearby location"), FConsoleCommandWithArgsDelegate::CreateLambda([](const TArray<FString>& Args) { int32 Count = FCString::Atoi(*Args[0]); for (int32 i = 0; i < Count; ++i) { // 调用你自己的Spawn函数，并用对象池创建 } }) );

这样我在调参数时，可以直接在打包后的游戏里输入MyGame.SpawnAI 100，配合stat unit观察，不用来回跑编辑器。这个小工具帮我省了大量来回切窗口的时间，也让我能快速验证“这一版优化到底提升了多少”。

多敌人AI场景的UE FPS性能优化，说到底不是单一技巧，而是一套取舍体系：大脑降到什么频率，寻路削到什么程度，动画砍到哪一档，渲染压到多少。关键是每一步都要用Profiling的数据来决策，在自己的目标和手感之间找平衡。如果读者也在面对类似的问题，最直接的建议就是从“降低AI Tick频率”和“感知瘦身”开始，这两刀见效最快，也相对安全。