虽然我们在本章花了大量的时间来讨论BTs的问题，但也可以认为这些问题并不是BT技术本身的问题，而是由于我们对BT技术的滥用而导致的问题。BTs可以被定义为一个计划执行的数学模型[Wikipedia 18]，这个定义的含义是，BT是一个已经确定的计划的执行系统。这直接将BTs置于AI代理模型的驱动层，而在游戏中，我们通常倾向于将其作为决策层的一部分。我们还倾向于以一种将激励与决策过程相结合的方式来使用它，从而进一步使整个问题复杂化。回想一下我们之前关于决策本质的观点，在使用无循环有向图(BT)来建模循环问题时，存在一个基本的逻辑断层。
通过强制使用BT来模拟循环行为，我们最终人为地夸大了我们试图解决的问题的复杂性。我们最终违反了行为和逻辑的封装，并在整个代理模型中不相关的行为之间隐式地创建了不必要的依赖关系。在这一点上，在一个已经很复杂的BT中引入新行为的成本可能会呈指数级增长。因此，使用BT作为决策层会严重影响原型和迭代时间。
如果我们远离使用BT作为决策工具的想法并把它纯粹作为致动器(即一个动作执行脚本),我们打开门技术更适合实际的决策以及允许我们建立和验证驱动行为的独立决策。这还意味着必须增加操作的粒度。在使用BTs作为决策工具时，常常将操作的粒度设置得很低，这通常是为了减少复杂性和树的大小。例如，不让BT任务执行诸如移动、查看、重新加载等动作，而是执行诸如“从位置战斗”等整个行为。不幸的是，在这个粒度级别上，该树将从本质上退化为一个复杂的决策树，从而进一步降低了首先使用BT的效用。
如果我们希望将BT作为执行器而不是决策者，我们需要了解哪些决策需要从BT中移除，哪些决策可以保留。
让我们使用图4中的“Fight from Cover”分支的例子，如果我们扩展这个分支，我们可以想象有三个单独的操作需要执行(同样假设使用了低粒度的操作)。图6a显示了扩展的“从掩蔽处开始战斗”分支的示例版本。
在查看图6a中的BT时，决策层显然需要“FindValidCover”和“IsCoverValid”操作，以便在代理没有有效的覆盖时能够终止分支。另一方面，“MoveToCover”和“CoverCombat”动作只与代理的动作有关。作为第一步，让我们去掉决策层的任务，只关注执行任务。剩下的两个驱动任务都可以被认为是简单的行为:“MoveToCover”负责移动和进入一个掩体，而“CoverCombat”负责已经在掩体中的战斗循环。这两个任务都是使用BT建模的完美候选者。
让我们关注“MoveToCover”执行任务，并尝试将其表示为具有更高粒度操作的BT。得到的BT如图6b所示。我们会立即注意到它仍然存在一定程度的决策:是否射击玩家的选择，一个在特定环境下完全有效的决定。这里的区别是，所做的决策只影响代理的执行，而不能影响整个代理的状态，也就是说，我们当前执行的是哪种行为，这种行为是否仍然有效，等等。
我们并不是主张取消BT的所有决策，而是将其限制在执行给定任务所需的决策上。决策应该只涉及选择一个目标(即决定一个行动过程)。到目前为止，我们看到的BTs的实际应用是一种决策树/执行树的混合，这违反了关注点分离原则。因此，我们强烈建议AI程序员和设计师停止将BTs作为一种决策工具，并避免使用它们。
利用行为树实现驱动和原型多样性
在我们所见过的大多数游戏AI架构实现中，致动是最有可能出现在代码中的层，并穿插着决策过程。这使得我们在创作的时候很难同时解决两个问题，我们的条件和边界情况都很混乱，例如，这个边界情况是由于决策问题还是驱动有问题。把驱动问题从代码转移到数据中可以获得很多东西，这就是BTs发挥作用的地方。我们可以很容易地构建一组通用的动作BT节点，然后将它们组合在一起来创建复杂的动作行为。由于每个驱动行为都有一个明确的单一目标和一组明确的输入，它们自然会保持相当小的值。这些较小的行为可以很容易地通过基本的测试工具进行测试，并且我们可以很容易地验证一个代理的驱动层是否如预期的那样工作，而不需要将决策制定或感觉层加入其中。
此外，随着这些更小的驱动行为的数量的增长，我们可以很容易地在游戏中根据不同的原型对它们进行变化。我们甚至可以用同样的高层决策来增加挑战和多样性。例如，在《射击游戏》中，较低级别的代理可能只具有“MoveToCover”行为，即只具有具有最高速度设置的move-to节点。更高级别的代理可能有这种行为的一个版本，其中他们也可以在移动的同时进行盲射动作，而我们最先进的AI可能会在移动的时候扫射，并在移动的顶部有一个瞄准射击分支(例如图6b)。如果这三种变体都使用相同的决策结构，我们将以非常低的生产成本在最终AI的行为上有明显的不同。同样重要的是要注意,与相同的BT节点集,我们用于构建各种“MoveToCover”行为,我们可以建立一整套其他战斗行为例如‘FightFromPosition’,‘CoveringFire’,‘AdvanceOnPosition’,等。
最后一个好处,我们花了很多时间解释如何大把决策从驱动,反过来也一样。在消除了驱动问题后，决策就变得非常容易解决了。它还允许我们更容易地试验各种决策方法。如果我们有一棵巨大的树，包含了人工智能的整个决策和驱动逻辑，我们将很难说服管理层允许我们破坏一切，只是为了试验一种新方法。现在，在我们的驱动行为是独立构建和测试的情况下，我们可以很容易地替换决策，甚至并行地构建决策。同时，在测试具有相同驱动行为集的新决策系统时，可以通过消除驱动执行过程中可能存在的差异来更容易地判断决策的质量。
总结
最后，我们讨论了行为树在行业中是如何被普遍使用的，以及与这种使用相关的问题。我们已经讨论了BTs表现出的静态优先级和反应/转换的固有问题，以及为什么我们应该在我们的AI架构中停止使用它们作为决策者。我们进一步讨论了代理驱动的问题，并提出行为树可能是对代理驱动行为建模的完美选择。我们希望这一文章将成为使用和复兴谦卑行为树的一个转折点，在过去的几年里，由于我们对它的不当使用，它获得了不公平的坏名声。