我在项目里第一次把AI写崩，是在一个普通近战怪身上。当时状态表看起来不多：待机、巡逻、追击、攻击、受击、死亡，六个状态，文档上写得很清楚。但“不多”是写在纸面上的，真正跑起来就发现完全不是那么回事：攻击要分接近、蓄力、挥砍、收招，受击要分轻击、重击、浮空、倒地，追击还得考虑丢失目标、被卡住、重新索敌。这么一拆，状态数量很快过了三十个，而每次新增状态，要检查的转换关系就成倍增加。后来我把这套推倒，换成分层有限状态机（HFSM），重新梳理之后，状态数量没少，但维护成本明显降了下来。这篇就聊聊落地：分层到底解决什么问题，哪些设计点决定成败，骨架代码怎么写，配置怎么拆，以及我踩过的坑。
1. 为什么你的状态机写着写着就烂掉了
1.1 状态爆炸是怎么发生的
先算一笔账。一个扁平状态机，如果状态数量是n，理论上任意两个状态之间都可能转换，最坏情况下要维护 n * (n-1) 条转换关系。三十个状态，意味着最多八百七十条转换，这已经超出人脑能稳定维护的规模了。实际项目里不可能全部两两相连，可只要业务需求复杂一点，几十条转换关系是常态。
更麻烦的是逻辑重复。格斗游戏里，角色在攻击、移动、跳跃、防御时都有可能被击中，扁平结构只能在每个状态里各自写一套“被打断并进入受击”的处理。我当时写的是每个状态都检查受击事件，后来加了“击飞”效果，就要把所有状态过一遍，漏掉一个就出Bug。这就是状态机烂掉的第一个信号：逻辑在状态之间反复粘贴，而不是被复用。
HFSM的思路其实很简单：既然这些状态都属于“战斗”这个更大的范畴，那就让它们共用一个父状态，把受击、死亡、目标锁定这些通用逻辑上提到父状态里，子状态只关心自己那点事。父状态负责通用的进入和退出，子状态负责具体的细分行为。分完层之后，转换关系就不再是全连接的网，而是一棵有归属的树。
1.2 分层分的是职责，不是动画
很多人第一次接触HFSM，容易误以为分层就是把状态包一层文件夹，叫个父名字就行。这种理解会做出“假分层”：父状态和子状态逻辑重叠，事件到处乱发，最后比扁平状态机还难查。
我自己的经验是，分层要分的是职责：父状态管“什么时候切换子状态、通用事件怎么拦截、公共数据怎么维护”，子状态管“自己这一段行为怎么表现”。一个典型的例子，角色在“战斗”父状态下，无论当前子状态是“攻击”还是“防御”，被敌人击中都该进入受击。这个拦截逻辑放在父状态里，子状态根本不需要知道。反过来，“攻击”子状态内部的连招按键节奏，只有它自己最清楚，父状态不要越俎代庖。
判断标准也很简单：如果某段逻辑会被两个以上同层子状态共用，并且语义上确实属于上一级行为，那就上提到父状态；如果一段逻辑只属于某一个具体行为，就留在子状态里。遵循这个原则，层级是天然长出来的，不是硬套的。
1.3 一个能直接看懂的层级模型
拿我之前写的近战怪物AI举例，整理后的HFSM结构大概是这样的：
MonsterAI (根) ├── Idle (待机) ├── Patrol (巡逻) └── Combat (战斗，父状态) ├── Chase (追击) ├── Attack (攻击，父状态) │ ├── Charge (蓄力) │ ├── Swipe (挥砍) │ └── Recover (收招) └── Defend (防御)这个结构里，“战斗”是一个父状态，它下面有多个子状态。敌人进入战斗后，父状态负责锁定目标、转身朝向、播放战斗待机动画；具体是追击还是攻击，由子状态自己决策。蓄力和挥砍都属于攻击过程，所以它们共享“攻击”这个父节点。转换只发生在同级或父子之间，不会出现“蓄力直接切到巡逻”这种跨级乱跳的情况，除非父状态明确放行。
层数方面我的建议是：三层以内最可控。根节点、父状态、子状态，顶多再往下加一层。超过三层，事件流转和调试复杂度都会明显上升，收益反而变小。
2. HFSM落地最容易翻车的四个设计点
2.1 事件先给谁：过滤和拦截
HFSM和扁平FSM最大的区别，就是事件有一条明确的流转路径。这条路径设计错了，系统就会变成玄学。
我见过两种主流派别。一种是“自顶向下”：事件先落到父状态，父状态判断要不要处理，不处理的往下传给子状态。另一种是“自底向上”：事件先给当前子状态，子状态不响应再往上传给父状态。两种都能跑，但适用场景不一样。
我的做法是混合式，默认自底向上，但父状态保留“事件封锁”能力。举例来说，角色在攻击蓄力时，玩家按下移动键，这个移动事件先给到蓄力子状态，蓄力状态如果允许取消，就自己处理掉；如果不允许，它可以把事件标记为未处理，上传给父状态，由父状态决定是否切入追击。而受击事件就不一样了，父状态声明“受击事件由我拦截”，那么无论当前在哪个子状态，事件都不会往下传，而是直接交给父状态的受击逻辑。
这套机制的关键，是每个事件处理函数都要返回“已处理”或“未处理”，否则父状态永远不知道子状态到底有没有消费事件。代码上我会用枚举表示这个结果，后面第三章会给完整骨架。
2.2 转换优先级：同帧多事件怎么选
扁平状态机里，状态切换往往是收到什么事件就切什么，逻辑简单，但真实玩起来很容易出问题。玩家同时按下闪避和攻击，或者攻击命中的同一帧又触发了受击，这时候谁先谁后，直接决定角色表现。
我建议所有转换都带优先级，而且优先级的分配要遵循一个基本原则：打断类事件最高，主动技能类其次，环境触发类再次，状态恢复类最低。受击、击飞、死亡属于“打断类”，它们必须能立刻打断当前行为；玩家主动发起的闪避、攻击属于“主动技能类”，优先级不能低于一般的环境事件；脚步声触发警戒、区域进入这种属于环境类，可以被高优先级事件覆盖。
这里有个容易踩的坑：不要用事件到达的顺序来决定转换，事件是异步的，到达顺序不稳定。正确做法是把同一帧所有事件收集起来，按优先级排序，只处理最高优先级的那一个。就算真有一堆事情同时发生，角色也只有一套状态，一次只能做一件事，那就得明明白白地排队。
2.3 历史状态：回到过去还是重新开始
HFSM比普通FSM多了一个好用的能力：历史状态。父状态可以记住自己退出时子状态停在哪里，重新进入时恢复。
这个能力在格斗游戏里特别有用。角色在“攻击-蓄力”时被击飞，进入受击状态，倒地起身后，只要“攻击”父状态还处于激活状态，就可以选择恢复到“蓄力”，让玩家连招不被彻底打断。没有这个机制，角色起身后只能站桩，重新蓄力，体验差很多。
实现上，历史状态通常用一个栈来记录，进入子状态时压栈，退出时弹栈。但要注意两点：一是栈深要控制，我一般最多记录两到三层，不要无限压栈，否则内存和逻辑都会失控；二是在特定节点要清空历史，比如角色死亡复活后，历史栈里不应该再残留上一局的战斗状态，否则复活的角色会莫名其妙回到战斗中。
还有一点容易被忽略：历史状态只恢复主状态，不处理并行状态的同步。如果角色同时有运动层和表现层，历史恢复只负责主状态，辅助层由外部单独管理，不然两层状态交错恢复，画面会非常诡异。
2.4 并发状态：状态机要不要拆线
HFSM解决的是串行状态的层级问题，但一个角色往往同时有多条行为线：腿在跑，手在攻击，嘴可能在说话。把这一切都塞进同一个状态树里，树会非常臃肿，事件流转也会互相干扰。
我的建议是：不要试图用一棵树搞定一切，而是在设计初期就把状态机“拆线”。运动层单独一个状态机，表现层单独一个状态机，逻辑层独立管理，各层之间通过事件或数据共享来沟通。角色移动和攻击互不阻塞，攻击动作播放时，移动层仍然可以正常响应摇杆，这只是两条并行线各自处理各自的事件。
当然，拆线不是越多越好。每新增一条线，心智负担都会翻倍。只有确实存在“同时活跃且互不干扰”的行为时，才值得拆。同一条线内部的事件依然要遵循优先级规则，只是线与线之间不再互相等待。
3. 一个可抄作业的轻量C#实现骨架
3.1 最小骨架：状态接口与状态机容器
以下代码是我在实际项目里用过的简化版本，去掉了项目业务逻辑，只保留核心结构。目标和事件相关的类型，各位可以按自己项目的骨架替换。
public interface IState { void OnEnter(); void OnUpdate(float deltaTime); void OnExit(); EventResult OnEvent(GameEvent evt); } public enum EventResult { Handled, Unhandled }GameEvent 是一个事件对象，里面至少包含事件类型和参数。接下来是状态机容器：
public class HFSM { private IState current; private HFSM parent; public IState Current => current; public void ChangeState(IState newState) { current?.OnExit(); current = newState; current?.OnEnter(); } public void Update(float dt) { current?.OnUpdate(dt); } public EventResult HandleEvent(GameEvent evt) { if (current == null) return EventResult.Unhandled; return current.OnEvent(evt); } }这个容器本身不算复杂，真正的复杂度在“层级”上。HFSM的父状态不是普通状态，它内部还挂着一个子状态机。父状态看起来是一个状态，实际上它是一个“状态 + 子状态机”的组合体。
3.2 状态切换的事务边界
我强调过很多次，OnEnter和OnExit就是状态机的“事务边界”。所有计时器的启动、动画的播放、数据的初始化，都必须在OnEnter里做；对应的停止、还原、清理，都必须写进OnExit里。这个规则雷打不动。
为什么这么重要？因为状态对象经常被复用。你切换回一个之前用过的状态，如果上次退出时没把临时数据清干净，这次进入就会带着上一局的残留。举个例子，蓄力状态记录了一个“蓄力时间”变量，退出时忘了清零，下次再进入，角色会直接按满蓄力出招。这种Bug非常难查，因为代码逻辑看着没问题，问题全在“状态刻度”上。
类比一下数据库事务：一个状态的生命周期就是一组原子操作，要进就完整地进，要出就干净地出。任何中途跳出、跳过OnExit、直接改字段的操作，都会破坏这条边界。
3.3 父状态的事件过滤
父状态的事件处理，我通常会写成一个独立的类：
public class HierarchicalState : IState { protected HFSM childFsm = new HFSM(); private HashSet<EventType> blockedEvents = new HashSet<EventType>(); public void BlockEvent(EventType type) { blockedEvents.Add(type); } public EventResult OnEvent(GameEvent evt) { // 先检查父状态是否要拦截 if (blockedEvents.Contains(evt.Type)) return OnSelfEvent(evt); // 子状态优先处理 EventResult childResult = childFsm.HandleEvent(evt); if (childResult == EventResult.Handled) return EventResult.Handled; // 子状态不处理，父状态兜底 return OnSelfEvent(evt); } protected virtual EventResult OnSelfEvent(GameEvent evt) { return EventResult.Unhandled; } public virtual void OnEnter() { } public virtual void OnUpdate(float dt) { childFsm.Update(dt); } public virtual void OnExit() { } }这个结构解决了我最头疼的“事件重复消费”问题：父状态通过BlockEvent声明自己接管的事件，子状态完全没有机会碰到它；其余事件先让子状态尝试，子状态不响应再回传到父状态。整个事件流是确定性的，打日志一查就清楚。
3.4 状态对象复用还是每次新建
每次切换状态都new一个对象，GC压力大；长期复用同一批对象，又容易残留旧数据。我的方案是对象池 + OnEnter强制重置。
对象池的好处是避免高频切换时频繁分配内存，状态切换本身是很高频的操作，一秒钟切几次十几次都正常。但池化之后，对象不会自动清空，所以OnEnter里的初始化就变成了刚刚说的“事务边界”。把这两者结合，效果很好：进入时无脑重置，退出时无脑清理，GC少，状态也不串。
这里有个反面教训：千万别把状态对象做成全局单例。单体状态一旦被两个地方共享，一个AI切状态，另一个AI也会跟着切，场面直接失控。如果非要用单例，那也要用上下文隔离，每个AI实例持有自己的状态实例。
4. 数据驱动：把状态机从代码里请出来
4.1 结构进配置，逻辑留代码
状态机写久了你会发现，真正容易变、需要频繁调的是“结构”：谁是谁的父状态、事件转到哪个状态、优先级多高。这些如果写在if-else里，每调整一次都要重新编译，而且很难让策划或者其他人参与调参。
我的做法是：状态树的结构、转换关系、事件名、优先级全部搬进配置文件；每个状态的OnEnter、OnExit、事件响应函数，仍然由代码提供，通过委托绑定。用一句话概括就是“结构进配置，逻辑留代码”。
这么做的好处是显而易见的。改一个转换目标，只要改配置，不用动代码；调试的时候打开状态图看配置，一目了然。风险也有：配置文件把状态结构暴露出来了，如果团队里有人不看字段含义乱改，很容易把状态树改成一团乱麻。所以配置文件一定要带注释模板，关键字段说明写清楚。
4.2 状态表与转换表怎么设计
我用的配置是JSON，结构大致长这样：
{ "root": "100", "states": { "100": { "name": "Combat", "type": "hierarchical", "onEnter": "on_combat_enter", "onExit": "on_combat_exit", "children": ["101", "102", "103"] }, "101": { "name": "Attack", "type": "hierarchical", "onEnter": "on_attack_enter", "onExit": "on_attack_exit", "children": ["200", "201", "202"] }, "200": { "name": "Charge", "type": "leaf", "onEnter": "on_charge_enter", "onExit": "on_charge_exit", "transitions": [ { "event": "OnHit", "target": "300", "priority": 100 }, { "event": "OnMove", "target": "102", "priority": 20 } ] } } }字段含义：type区分叶状态和父状态；children挂子状态的ID；transitions声明转换表，每条转换包含事件名、目标状态ID和优先级。onEnter、onExit里的字符串，是动作委托的名字，运行时通过一个注册表查表绑定。
设计的时候有几个细节要注意。事件名不要用裸字符串到处写，建议统一用常量名，避免拼写错误。优先级数值设一个范围约定，比如打断类100，主动类50，环境类10，这样读配置的人一看数字就知道这个转换的轻重。
4.3 运行时解析与日志可视化
配置解析大概分三步：第一步读配置，创建每个状态对象；第二步绑定动作委托，把onEnter、onExit这些字符串映射到代码函数；第三步构建父子关系，把children里提到的ID挂到对应父状态下面。
伪代码写出来就是：
foreach (var stateDef in config.states) { if (stateDef.type == "hierarchical") { var state = new HierarchicalState(); state.BindActions(stateDef.onEnter, stateDef.onExit, actionResolver); states[stateDef.id] = state; } else { var state = new LeafState(); state.BindActions(stateDef.onEnter, stateDef.onExit, actionResolver); state.SetTransitions(stateDef.transitions, states); states[stateDef.id] = state; } } foreach (var stateDef in config.states) { if (stateDef.type == "hierarchical") { var parent = (HierarchicalState)states[stateDef.id]; foreach (var childId in stateDef.children) { parent.AddChild(states[childId]); } } }这套流程写清楚之后，调试就成了关键。我在状态切换的时候会打缩进日志，层数越深，缩进越多，打开日志能直接看到一棵“活的状态树”。大概长这样：
[State] Combat -> Attack [State] Attack -> Charge [State] BlockEvent OnHit in Combat [State] Charge -> Recover [State] Combat -> Chase缩进日志看着笨，但排查AI乱跑的时候比什么工具都好使。状态乱跳？一眼看日志就知道哪个事件触发了转换，谁拦截了事件，在哪一步出了问题。发布版本记得用日志级别或者条件编译把这一层关掉，避免刷屏。
5. HFSM与其他行为方案的取舍
5.1 四类方案选型对照
状态机不是唯一选择，项目里常见的行为方案还有行为树（Behavior Tree）、GOAP（Goal-Oriented Action Planning）和Utility AI。它们各有各的脾气，选错方案的代价不比写错代码小。
| 方案 | 核心思路 | 最大优势 | 容易失控的点 | 适合场景 |
|---|---|---|---|---|
| HFSM | 状态分层，包含与转换 | 状态可控、直观、可预测 | 层数过深、事件重复消费 | 角色控制、UI流程、动画状态 |
| Behavior Tree | 决策树，节点复用 | 逻辑复用高、结构清晰 | 调试要回溯上下文 | NPC决策、复合任务协作 |
| GOAP | 目标驱动规划 | 动态应变强 | 需要写大量Action和Cost | 开放世界NPC、复杂生存AI |
| Utility AI | 加权打分选最优 | 平滑连续、容易调参 | 可解释性差 | 偏向“感觉型”AI、随机非玩家角色 |
这个表不是绝对的，但方向上差不太多。核心问题不是“哪个先进”，而是“团队里谁能维护”。引入一个只有你想得懂的系统，等于给项目埋雷。
5.2 什么时候坚持HFSM
如果需求里存在明确的、可枚举的行为状态，并且状态之间有稳定、可预期的前后关系，比如角色战斗、UI界面流转、动画状态管理，HFSM就是最优解。
HFSM最大的优势在于“可控”。你永远知道当前状态是什么，从哪儿来的，下一步有哪些可能。出Bug也好查，日志一打，状态轨迹清清楚楚。团队协作也方便，任何人打开状态图都能理解当前的行为逻辑。
我在做角色受击、硬直、倒地这些需求时，几乎无脑用HFSM。因为这些行为必须严格打断、严格恢复，不能被随机的决策逻辑干扰。状态机把所有可能的流转都约束住了，反而让复杂的格斗逻辑变得看得见、摸得着。
5.3 什么时候别硬上HFSM
反过来，如果你的AI行为是开放的、动态的，比如开放世界里NPC根据目标状态决定下一步做什么，那HFSM会非常痛苦。穷举状态、穷举转换，最后状态图比地图还复杂，维护成本直线上升。这种情况换行为树更舒服，行为树讲究的是逻辑复用，一个“检查目标是否有敌人”的节点可以在很多地方挂载，不需要每个分支都写一遍。
Utility AI则适合那些行为“讲感觉”的场景，比如NPC选择哪个宝箱更近、哪个敌人威胁更大，用加权打分来选，平滑过渡，随机感也强。缺点是决策过程不透明，出了Bug很难解释为什么选了A没选B。
还有一个判断技巧：如果需求文档描述里频繁出现“如果……那么……”，适合行为树或HFSM；如果出现“根据……的重要程度选择……”，适合Utility AI；如果出现“为了实现……目标，需要……”，那要考虑GOAP。先把需求的语言风格搞明白，方案选型就顺了。
6. 我踩过的那几个坑
6.1 典型问题速查表
| 症状 | 常见原因 | 排查建议 |
|---|---|---|
| 状态乱跳 | 多个转换条件同时成立，没有优先级 | 给转换加优先级，检查同帧多事件 |
| 状态残留 | 状态对象复用，OnExit没清干净 | 统一初始化/清空，严格执行事务边界 |
| 事件没反应 | 父状态拦截了事件，子状态没收到 | 打日志看事件走向，检查BlockEvent名单 |
| 同帧多次切换 | Update里直接调用ChangeState | 事件集中派发，状态切换排队处理 |
| 历史恢复错误 | 历史栈没有及时清理 | 关键节点清空历史栈，控制栈深 |
这张表是我初期排查问题的备忘录，几乎每个问题都真实遇到过。
6.2 印象最深的五个教训
第一个坑是状态对象复用之后忘记重置。当时角色倒地状态有个“倒地时间”字段，退出时没清零，下次被打倒会直接触发起身，表现就是角色刚倒下就弹起来。排查很久才发现是OnExit没清理，后来强制约定OnEnter初始化所有临时字段，再没犯过。
第二个坑是在Update里判断转换条件。角色攻击未结束，Update里检测到玩家按了技能键，直接ChangeState，结果攻击动画播到一半强制切走，表现异常。改成事件驱动、状态切换统一走ChangeState入口之后，流程就顺了。
第三个坑是父状态和子状态同时响应同一个事件。角色攻击时被击中，攻击子状态减血了，父状态也掉血了，血一回合扣两遍。后来引入EventResult.Handled机制，子状态一旦处理就不再向父状态传递，问题解决。
第四个坑是状态ID用裸字符串。项目中期有人把“Attack”改成“Attack01”，所有引用处全得跟着改，漏改一处就是事故。后来统一用枚举或常量类管理，重构成本大幅下降。
第五个坑是没有日志。AI跑乱了只能靠肉眼盯屏幕猜原因，效率极低。加上缩进日志之后，问题定位速度快了十倍不止。我现在所有状态切换、事件拦截必须打日志，发布版本再关，这已经是写状态机的前提条件了。
我个人在实际操作中的体会是，状态机的价值不在于它本身有多精巧，而在于它逼着你把行为拆清楚。拆得越清楚，代码越好写，Bug越好查。如果你现在的项目状态数量已经超过二十个，转换超过五十条，别急着上复杂框架，先把HFSM用起来，配好事件优先级、日志和配置化，你会发现状态机远没有传说中那么难维护。最后再分享一个小技巧：别一开始就想做一套全自动可视化编辑器，先跑通日志和数据配置，这两样东西比任何工具都实在。后续如果团队确实需要，再考虑图形化也不迟。
