1. 为什么你的游戏AI总像个“木头人”？试试FSM吧！

不知道你有没有遇到过这种情况：辛辛苦苦做出来的游戏NPC，要么像个傻子一样在原地发呆，要么追着玩家跑起来动作僵硬、反应迟钝。我之前做一个塔防游戏的小Demo时就吃过这个亏，敌人只会沿着固定路线走，遇到障碍物也不会绕开，玩家稍微放个技能，整个AI逻辑就乱套了。后来我才明白，问题出在AI的逻辑控制上——代码里全是if-else，状态一多，逻辑就缠成了“意大利面条”，根本没法维护和扩展。

这时候，有限状态机（Finite State Machine， FSM） 就该登场了。你可以把它想象成一个智能灯的开关：灯有“关闭”、“常亮”、“闪烁”几种状态。你按一下开关（触发条件），灯就从“关闭”变成“常亮”；再按一下，可能变成“闪烁”。灯在任何时刻都只处于一种明确的状态，并且根据你的操作，在几个固定的状态间切换。FSM的核心思想就是这么简单：定义有限个状态，规定好状态之间转换的条件，让对象的行为变得清晰、可控。

在Unity游戏开发里，FSM简直是AI行为的“万金油”。无论是敌人的巡逻、追击、攻击、逃跑，还是游戏角色的待机、行走、奔跑、跳跃，甚至是一个UI界面的打开、关闭、加载中，都可以用FSM来优雅地管理。它把复杂的行为拆解成一个个独立的状态模块，每个模块只管自己该做的事，状态之间的切换逻辑也一目了然。这样写出来的代码，不仅你自己半年后还能看懂，交给团队其他小伙伴接手也毫无压力。

接下来，我就结合自己踩过的坑和实战经验，带你从零开始，在Unity里搭建一个灵活、高效、易于维护的FSM框架，并分享几个能让你的游戏AI瞬间变“聪明”的优化技巧。

2. 告别“面条代码”：手把手搭建你的第一个FSM框架

光说理论可能有点虚，咱们直接动手。我会用一个经典的“敌人AI”作为例子，它包含巡逻（Patrol）、追击（Chase）、攻击（Attack）、死亡（Dead）四个基本状态。目标是构建一个清晰、可复用的框架。

2.1 核心四件套：状态、条件、转换表与状态机

一个完整的FSM框架，离不开四个核心部分，咱们一个个来拆解。

首先，是状态（State）。这是FSM的灵魂。一个状态至少包含三部分：进入状态时做什么（比如追击状态开始播放跑步动画）、在状态持续期间每帧做什么（比如每帧向玩家位置移动）、离开状态时做什么（比如停止跑步动画）。在代码里，我们通常会定义一个抽象的状态基类，让具体的状态（如攻击状态）去继承和实现它。

其次，是转换条件（Trigger/Condition）。这是状态切换的“扳机”。比如，“发现玩家”这个条件成立，就会从“巡逻”切换到“追击”；“玩家超出视野”条件成立，则可能从“追击”切回“巡逻”。条件应该被设计成独立的类，只负责判断某件事是否成立，而不关心状态本身。

然后，是最关键的——状态转换表。这是FSM的“大脑”或“说明书”。它用一张表（或者字典）明确规定了：在A状态下，如果条件C满足，就切换到B状态。把这种逻辑从代码的if-else里抽离出来，变成可视化的配置，是FSM管理复杂逻辑的秘诀。我习惯用一个简单的txt文本文件来存储这个表，后面会展示如何动态读取。

最后，是状态机（State Machine）。它是FSM的“总指挥”。负责管理所有状态对象的生命周期，根据转换表在正确的时机切换状态，并在每帧驱动当前状态执行Update逻辑。在Unity里，状态机通常是一个挂载在GameObject上的MonoBehaviour脚本。

下面这个表格，清晰地展示了我们示例敌人AI的状态转换逻辑：

当前状态	触发条件	目标状态
巡逻 (Patrol)	发现玩家 (FindTarget)	追击 (Chase)
追击 (Chase)	丢失目标 (LostTarget)	巡逻 (Patrol)
追击 (Chase)	进入攻击范围 (InAttackRange)	攻击 (Attack)
攻击 (Attack)	目标死亡 (TargetKilled)	巡逻 (Patrol)
攻击 (Attack)	目标超出范围 (OutOfRange)	追击 (Chase)
任意状态 (AnyState)	自身死亡 (NoHealth)	死亡 (Dead)

有了这张“地图”，我们写代码时心里就特别有底，再也不会迷路了。

2.2 从零开始：编写可复用的FSM核心代码

理论说够了，直接上干货。我们来写一套基础但足够强大的FSM框架代码。这套代码的特点是与游戏逻辑解耦，你可以把它直接拷贝到任何新项目里使用。

首先，定义状态和条件的唯一标识ID。用枚举（Enum）最合适，清晰又避免拼写错误。

// 状态ID枚举
public enum FSMStateID
{
    Patrol, // 巡逻
    Chase,  // 追击
    Attack, // 攻击
    Dead    // 死亡
}

// 条件ID枚举
public enum FSMTriggerID
{
    FindTarget,     // 发现目标
    LostTarget,     // 丢失目标
    InAttackRange,  // 进入攻击范围
    OutOfRange,     // 超出攻击范围
    TargetKilled,   // 目标死亡
    NoHealth        // 自身无生命值
}

接着，创建条件基类（FSMTrigger）。它是一个抽象类，核心是那个判断条件是否满足的HandleTrigger方法。

public abstract class FSMTrigger
{
    // 每个条件都必须有自己的唯一ID
    public FSMTriggerID TriggerID { get; set; }

    protected FSMTrigger()
    {
        Init();
    }

    // 子类必须实现初始化，为自己赋予ID
    protected abstract void Init();

    // 核心方法：判断条件是否成立。参数是状态机，方便获取游戏世界信息
    public abstract bool HandleTrigger(FSMBase fsm);
}

然后，是状态基类（FSMState）。这里的设计稍微复杂一点，但非常精妙。每个状态对象内部都维护着一个小型的“转换地图”，知道自己遇到什么条件该跳转到什么状态。

using System;
using System.Collections.Generic;

public abstract class FSMState
{
    public FSMStateID StateID { get; set; }

    // 核心：转换映射表。Key是条件ID，Value是目标状态ID。
    private Dictionary<FSMTriggerID, FSMStateID> _triggerStateMap;
    // 存储当前状态需要监听的所有条件对象
    private List<FSMTrigger> _triggers;

    protected FSMState()
    {
        _triggerStateMap = new Dictionary<FSMTriggerID, FSMStateID>();
        _triggers = new List<FSMTrigger>();
        Init();
    }

    // 子类必须实现初始化，为自己赋予ID
    public abstract void Init();

    // **关键方法**：由状态机调用，为当前状态添加一条转换规则
    public void AddMap(FSMTriggerID triggerID, FSMStateID stateID)
    {
        _triggerStateMap.Add(triggerID, stateID);

        // 利用反射，根据条件ID动态创建对应的条件对象
        // 这就要求条件子类命名必须规范：`条件ID` + "Trigger"
        Type triggerType = Type.GetType(triggerID.ToString() + "Trigger");
        if (triggerType != null)
        {
            FSMTrigger trigger = Activator.CreateInstance(triggerType) as FSMTrigger;
            _triggers.Add(trigger);
        }
    }

    // 每帧由状态机调用，检查所有条件，判断是否需要切换状态
    public void Reason(FSMBase fsm)
    {
        foreach (var trigger in _triggers)
        {
            if (trigger.HandleTrigger(fsm)) // 如果某个条件满足
            {
                FSMStateID nextStateID = _triggerStateMap[trigger.TriggerID];
                fsm.ChangeActiveState(nextStateID); // 通知状态机切换状态
                return; // 一次只处理一个有效的转换
            }
        }
    }

    // 以下三个虚方法，子状态按需重写
    public virtual void EnterState(FSMBase fsm) { }
    public virtual void ActionState(FSMBase fsm) { }
    public virtual void ExitState(FSMBase fsm) { }
}

注意：AddMap方法里使用了反射动态创建条件对象。这虽然带来了一点运行时开销，但换来了巨大的灵活性——我们只需修改配置文件，就能改变AI行为，无需重新编译代码。这是一种典型的“用空间换时间，用配置换灵活”的设计权衡。

最后，是状态机控制器（FSMBase）。它继承自MonoBehaviour，是连接Unity引擎和FSM逻辑的桥梁。

using System;
using System.Collections.Generic;
using UnityEngine;

public class FSMBase : MonoBehaviour
{
    private List<FSMState> _states; // 所有状态的列表
    public FSMStateID defaultStateID; // 初始状态
    private FSMState _currentState; // 当前活跃状态

    [SerializeField] private TextAsset _configFile; // 在Inspector中拖入配置文本文件

    void Start()
    {
        ConfigFSM(); // 根据配置文件初始化所有状态和转换规则
        InitDefaultState(); // 设置并进入默认状态
    }

    void Update()
    {
        // 每帧：1. 检查状态转换 2. 执行当前状态的行为
        _currentState?.Reason(this);
        _currentState?.ActionState(this);
    }

    private void ConfigFSM()
    {
        _states = new List<FSMState>();
        // 这里需要解析_configFile文本内容，构建出状态转换表
        // 假设我们通过一个解析器得到了一个字典：Map<状态名, Map<条件名, 目标状态名>>
        var configMap = ParseConfigFile(_configFile.text);

        foreach (var stateEntry in configMap)
        {
            string stateName = stateEntry.Key;
            // 根据状态名反射创建具体的状态对象（例如："Patrol" -> PatrolState）
            Type stateType = Type.GetType(stateName + "State");
            FSMState stateObj = Activator.CreateInstance(stateType) as FSMState;
            _states.Add(stateObj);

            // 为这个状态对象配置所有的转换规则
            foreach (var rule in stateEntry.Value)
            {
                FSMTriggerID triggerID = (FSMTriggerID)Enum.Parse(typeof(FSMTriggerID), rule.Key);
                FSMStateID targetStateID = (FSMStateID)Enum.Parse(typeof(FSMStateID), rule.Value);
                stateObj.AddMap(triggerID, targetStateID);
            }
        }
    }

    private void InitDefaultState()
    {
        _currentState = _states.Find(s => s.StateID == defaultStateID);
        _currentState?.EnterState(this);
    }

    // 公开给状态调用的状态切换方法
    public void ChangeActiveState(FSMStateID newStateID)
    {
        _currentState?.ExitState(this);
        _currentState = _states.Find(s => s.StateID == newStateID);
        _currentState?.EnterState(this);
    }

    // 这里需要实现ParseConfigFile方法，以及提供一些游戏世界查询方法（如FindTarget）
    // 供具体的条件类（如FindTargetTrigger）调用
    public bool FindTarget() { /* ... 实现寻找目标的逻辑 ... */ }
}

至此，一个高度解耦、可配置的FSM框架核心就完成了。你会发现，具体的游戏逻辑（比如怎么移动、怎么攻击）都被封装在了各个具体的FSMState子类（如AttackState）和FSMTrigger子类（如FindTargetTrigger）里。而框架本身只关心状态和规则的管理，非常干净。

3. 让FSM如虎添翼：高级技巧与性能优化实战

框架搭好了，但直接用在复杂项目里，可能会遇到性能瓶颈或者管理上的麻烦。下面这几个技巧，都是我实际项目中总结出来的“宝藏”。

3.1 告别硬编码：用ScriptableObject实现可视化配置

每次都去改txt配置文件，还要确保格式正确，有点麻烦，而且不利于策划或团队其他非程序员成员调整AI行为。Unity的ScriptableObject（SO） 在这里可以大放异彩。

我们可以创建一个FSMConfigSO资产类，直接在Unity编辑器里像填表一样配置状态转换。

[CreateAssetMenu(fileName = "NewFSMConfig", menuName = "AI/FSM Configuration")]
public class FSMConfigSO : ScriptableObject
{
    [System.Serializable]
    public class StateTransition
    {
        public FSMStateID fromState;
        public FSMTriggerID trigger;
        public FSMStateID toState;
    }

    public List<StateTransition> transitions = new List<StateTransition>();
    public FSMStateID defaultState;
}

然后在FSMBase中，不再读取文本文件，而是引用这个FSMConfigSO资产。在ConfigFSM方法里，遍历这个transitions列表来为每个状态配置转换规则。这样做的好处是：

1. 可视化：在Inspector窗口清晰看到所有转换关系。
2. 易调整：策划可以自由拖拽、修改，无需接触代码。
3. 可复用：一个配置资产可以轻松应用到多个同类型敌人Prefab上。

3.2 性能提升关键：避免每帧遍历所有条件

在基础的Reason方法里，我们每帧都要遍历当前状态下的所有条件对象，并调用其HandleTrigger方法。如果条件判断本身很耗时（比如进行物理检测Physics.OverlapSphere），或者一个状态监听的条件很多，这就会成为性能热点。

优化策略1：条件分级与延迟检查 不是所有条件都需要每帧检查。我们可以把条件分为：

• 即时条件：需要每帧检查，如“自身死亡(NoHealth)”。
• 事件驱动条件：由外部事件触发，如“被击中(Hit)”。可以在受到伤害时，直接设置一个标志位，条件类只检查这个标志位。
• 低频条件：如“目标是否在视野内”，可以每5帧或10帧检查一次。

我们可以修改FSMTrigger基类，增加一个CheckFrequency属性和一个内部计时器，在HandleTrigger内部实现按频率检查。

优化策略2：利用Unity的协程或Update管理器 对于真正耗时的检测（如寻路计算、复杂视线判断），不要放在Update里。可以将其放入协程（Coroutine）中异步执行，或者注册到一个自定义的、分帧执行的UpdateManager中，避免在同一帧造成CPU尖峰。

优化策略3：状态机池与共享配置 如果你的游戏中有大量同类型的敌人（比如一群小兵），不要让每个敌人都独立解析一次配置文件或SO。应该使用工厂模式或单例模式创建一个FSMConfigManager，所有同类型敌人共享同一份配置数据的引用。状态对象本身也可以考虑对象池化，尤其是频繁创建销毁的状态（但通常状态对象很轻量，池化收益需权衡）。

3.3 应对复杂逻辑：分层状态机与并行状态机

当AI行为变得非常复杂时，基础的FSM可能会变得臃肿。比如一个“战斗”状态，内部可能又有“格挡”、“闪避”、“连招”等子状态。这时候就需要更高级的模式。

分层状态机（Hierarchical FSM）：允许一个状态内部包含一个完整的子状态机。比如“战斗”是一个父状态，它有自己的子状态机来管理格挡、攻击等。当父状态活跃时，其子状态机才运行。这极大地增强了状态机的表现力和组织性，你可以像搭积木一样组合复杂行为。

并行状态机（Parallel FSM）：允许一个游戏对象同时运行多个独立的状态机。比如，一个角色可以同时运行一个管理“移动”（走、跑、跳）的状态机，和另一个管理“情绪”（平静、愤怒、恐惧）的状态机。两者并行不悖，共同决定角色的最终行为表现。在Unity中实现，通常就是在一个GameObject上挂载多个FSMBase组件，每个负责一个独立的维度。

实现这两种高级状态机超出了本文的范畴，但它们的思想是相通的：通过组合和分解来管理复杂性。当你觉得基础FSM不够用时，这就是下一步的探索方向。

4. 真实项目避坑指南：从Demo到产品的经验之谈

纸上得来终觉浅，最后分享几个把FSM从Demo玩具用到真实项目时，最容易踩的“坑”。

第一个坑：状态爆炸与转换混乱。 随着需求增加，状态和条件越来越多，转换表变得极其复杂，难以维护。对策：严格遵守“单一职责”，一个状态只做一件事。多使用分层思想，将相关的小状态聚合到一个父状态下。在绘制状态转换图时，如果发现某个状态到其他状态的箭头太多，就要考虑是不是这个状态设计得太“胖”了，需要拆分。

第二个坑：状态切换时的“帧同步”问题。 比如在AttackState的ActionState里发射了子弹，同时在ExitState里停止了攻击动画。但如果切换状态发生在同一帧的某个微妙时刻，可能导致子弹已发出但动画被错误停止。对策：确保状态切换是原子操作，并且在ChangeActiveState方法中，严格保证执行顺序是：当前状态.ExitState -> 切换状态变量 -> 新状态.EnterState。对于动画、音效等与引擎帧紧密相关的操作，要特别小心。

第三个坑：过度设计。 不是所有AI都需要一个完整的、配置驱动的FSM。对于一个只有“待机”和“巡逻”两个状态的简单NPC，用几个布尔值和if语句可能更简单快捷。FSM是一种工具，而不是信仰。 我的经验法则是：当状态超过3个，或者状态间的转换逻辑开始出现复杂的if-else嵌套时，就是引入FSM的好时机。

第四个坑：调试困难。 当AI行为异常时，如何快速知道它当前在什么状态？为什么切换失败了？对策：一定要在FSMBase中加入调试信息。比如，在ChangeActiveState时打印日志（Debug.Log($“{gameObject.name} 从 {_currentState.StateID} 切换到 {newStateID}”)）。更高级的做法是，在编辑器下绘制一个Debug GUI，实时显示当前状态、所有条件是否满足等信息。这能为你节省大量的排查时间。

说到底，FSM的魅力在于它用一种符合直觉的方式（状态和转换）来建模行为。它可能不是最强大、最高效的AI方案（行为树、效用AI等在某些场景下更优），但它一定是最易懂、最易上手、最易维护的方案之一。尤其对于小型团队或项目初期，一个稳健的FSM能为你打下坚实可靠的基础。希望这些实战经验和代码能帮你少走弯路，做出行为更自然、更有趣的游戏AI。