一、从「套路脚本」到「节点框架」：为什么状态机写不下去上一篇讲了行为树的原理（见《行为树 Behavior Tree：游戏 AI 背后的决策机制》），本篇用 C# 从零实现一套核心决策逻辑与引擎解耦的 BT（Behavior Tree，行为树）框架，示例用 Unity 集成，端到端跑通一个「巡逻-追击-攻击-逃跑」的敌人 AI。如果直接拿 if/else 写敌人 AI，10 个状态以内还能勉强维护，但当状态数翻倍、出现「追击时如果玩家开火则转为闪避，否则如果血量低于 30% 则逃跑，否则如果背后有掩体则迂回」这种多层嵌套逻辑时，if/else 集合就会迅速退化为一团意大利面，每次策划改规则程序员都得心惊胆战地全文检索。行为树通过三个工程化设计解决这个困局：节点即职责：每个节点只关心一件事（做动作 / 判条件 / 串联子节点），行为组合交给组合节点；Tick 契约统一：所有节点都实现同一个Tick()方法返回NodeState，调用方不用关心节点类型；组合模式（Composite Pattern）递归：Composite（组合节点）持有一组子节点，叶子节点不持子节点，遍历方式对调用方完全一致。这套设计在工业界经过 20 年迭代（从《Halo 2》到《地平线：零之曙光》），已经沉淀出非常稳定的接口形态。下面就用约 300 行 C# 代码复刻这套接口。二、