实战：用 StateTree 重写巡逻-追击-攻击 AI

拿第 2 章的同一个需求，看 StateTree 版本长什么样，以及两版的体感差异。

状态结构

Root
├ Patrol（巡逻）
│   ├ Task: 选下一个巡逻点
│   ├ Task: 移动到点
│   └ Task: 原地观察
├ Combat（战斗）
│   ├ Task: 追击（更新目标位置）
│   └ Task: 攻击（含冷却）
└ Search（查看）
    └ Task: 移动到最后已知位置

转换（Transition）

从 到 条件
Patrol Combat 事件"感知到敌人"（事件转换）
Combat Search "目标丢失"条件转换
Search Combat 事件"再次看到敌人"
Search Patrol "到达查看点"（状态内任务完成）

事件接入

感知组件的事件直接转发给 StateTree（它的事件入口），不用像行为树那样通过服务轮询黑板。这一步是 StateTree 最香的点：事件驱动是原生支持，而行为树需要"服务 + 装饰器"间接实现。

与行为树版的对比

维度 行为树版 StateTree 版
"当前在做什么" 要看激活的节点 当前状态一目了然（调试器高亮）
反应性 靠装饰器观察者中断 原生事件转换
资源清理 各任务的完成回调里补 状态的退出任务统一
结构阅读 树形（优先级感强） 状态图（阶段感强）
新手理解成本 低 中（要理解状态机）

结论：不是替换，是选型

  • 已有行为树的项目：留着，不用为了用 StateTree 而重写（重写本身有风险且无玩家可见收益）；
  • 新项目 / 新 AI：直接用 StateTree，长期维护收益大；
  • 复杂 Boss：StateTree（阶段多、转换多、事件多）。

无论选哪个，感知层与环境查询层（EQS）都不变。下一章讲 EQS 这个"AI 的空间推理能力"。