NPC 的智能程度往往决定了一款游戏的沉浸感。脚本化的巡逻和固定触发式攻击虽然实现简单，但玩家很快就能找到规律，失去挑战乐趣。想让 NPC 根据弹药剩余量、掩体位置、敌方可见度等信息动态调整行为，就需要在决策层引入 AI 推理机制。所谓 AI 推理，并不是让 NPC 拥有真正的意识，而是让它在当前世界状态下，通过一系列规则或算法推导出最合理的目标与行动序列。本文从行为树、效用 AI、目标导向行动规划以及黑板架构几个方面，拆解如何在游戏设计中落地 NPC 智能行为。
一、为什么固定脚本和有限状态机不够用
有限状态机（FSM）是早期 NPC 行为的主流方案。一个敌人可能包含巡逻、追击、攻击、死亡等状态，并在满足条件时切换。这种实现直观、性能开销低，但随着行为复杂度上升，状态之间的转换关系会迅速膨胀。例如给敌人增加寻找掩体、呼叫增援、撤退、拾取武器等行为时，每个新状态都要考虑与其他所有状态的关系，状态转换图最后会变成一张难以维护的网。
更深层的问题在于，状态机只能描述“当条件满足时切换状态”，缺乏对目标本身的推理。它不会比较不同目标的价值，也不会根据环境变化提前规划多步行动。玩家遇到这种 NPC 时，往往感觉它们只是按照固定剧本反应，缺少真实生物的决策感。AI 推理的作用正是补上这一层：从当前世界状态出发，让 NPC 自己回答“我现在最应该做什么”以及“怎么做才能达成目标”。这并不意味着完全抛弃状态机，而是把状态切换放在更高层的决策逻辑之下。
在实际项目中，可以把状态机作为动作执行层保留，把推理模块放在其上层。例如巡逻、移动、射击等动作仍然由状态机控制，但“该进入哪个状态”由效用评分或规划器决定。这样既保留了底层执行的稳定性，又提升了决策的灵活性。
二、行为树与效用AI：用可解释的方式做推理
行为树（Behavior Tree）是目前商业游戏中使用最广泛的 NPC 决策框架之一。它由组合节点、装饰节点和叶子节点构成，从左到右或按优先级遍历。与状态机相比，行为树更容易模块化，设计者可以像搭积木一样组合条件判断和行为。比如一个敌人行为树的根节点可以是一个选择器，先判断是否处于低血量，如果是则执行撤退，否则继续判断是否发现玩家。这种结构天然支持一定程度的优先级推理。
不过行为树仍然以静态结构为主，条件判断通常是布尔值，很难表达程度差异。比如同样是“血量低”，20% 的血量和 5% 的血量可能触发相同分支，但实际紧迫程度完全不同。效用 AI（Utility AI）则通过为每个候选行为打分来解决这个问题。每个行为会根据自己的多个考虑因素计算一个效用值，NPC 选择总分最高的行为执行。例如撤退行为的效用可以这样计算：血量越低、敌人距离越近，撤退分数越高；进攻行为则相反。这样 NPC 就能在连续的数值空间中做出更细腻的决策。
下面是一段 C# 示例，展示效用 AI 中如何为不同行为计算分数。这里使用了简单的加权求和，实际项目可以根据需要换成曲线函数。
public class UtilityAction
{
public string Name;
public Func<NpcContext, float> ScoreFunc;
}
public class UtilityAI
{
private List<UtilityAction> actions = new List<UtilityAction>();
public UtilityAction SelectBestAction(NpcContext context)
{
UtilityAction best = null;
float bestScore = float.MinValue;
foreach (var action in actions)
{
float score = action.ScoreFunc(context);
if (score > bestScore)
{
bestScore = score;
best = action;
}
}
return best;
}
}
// 使用示例
var ai = new UtilityAI();
ai.actions.Add(new UtilityAction
{
Name = "Retreat",
ScoreFunc = ctx => (1f - ctx.HealthRatio) * 80f + ctx.EnemyDistance * 5f
});
ai.actions.Add(new UtilityAction
{
Name = "Attack",
ScoreFunc = ctx => ctx.HealthRatio * 60f + ctx.WeaponDamage * 2f
});
NpcContext ctx = new NpcContext { HealthRatio = 0.2f, EnemyDistance = 10f, WeaponDamage = 25f };
var action = ai.SelectBestAction(ctx);
效用 AI 的优势在于打分规则直观、易调试，策划可以单独调整某个行为的权重。但它的局限也很明显：每个行为独立评分，很难表达“先移动到掩体再装弹再反击”这样有先后依赖的行动序列。要解决多步规划问题，需要引入目标导向行动规划。
三、目标导向行动规划：让NPC自己拼出行动序列
目标导向行动规划（Goal-Oriented Action Planning，简称 GOAP）把 NPC 的决策过程拆成目标、行动、状态三个部分。每个行动有自己的前置条件和效果，规划器会从当前世界状态出发，寻找一个能够到达目标状态的行动序列。例如目标状态是“敌人死亡”，而当前状态是“弹药为零、敌人有掩体”，规划器可能会先生成“寻找弹药”行动，再执行“移动到射击位”，最后执行“开火”。这个过程不是由设计者预先写死的脚本，而是由规划算法动态生成的。
GOAP 通常使用 A* 或其他图搜索算法来做规划。状态由一组键值对表示，行动的代价可以设置为时间、风险或体力消耗。规划器会不断扩展可行行动，直到某个行动序列的效果满足目标条件。这样 NPC 就能在环境发生变化时重新规划，比如弹药被打断后自动插入寻找弹药的行动。相比行为树，GOAP 更接近“推理”，因为它能根据目标反推行动，而不只是按树形结构做条件分支。
下面是一个简化的 GOAP 行动定义示例。每个行动包含前置条件和效果字典，规划器可以利用这些信息构建搜索空间。
public class GoapAction
{
public string Name;
public Dictionary<string, object> Preconditions = new Dictionary<string, object>();
public Dictionary<string, object> Effects = new Dictionary<string, object>();
public float Cost = 1f;
}
public class GoapActionSet
{
public List<GoapAction> Actions = new List<GoapAction>();
public void BuildDefaultActions()
{
Actions.Add(new GoapAction
{
Name = "FindAmmo",
Preconditions = { { "hasAmmo", false } },
Effects = { { "hasAmmo", true } },
Cost = 3f
});
Actions.Add(new GoapAction
{
Name = "MoveToCover",
Preconditions = { { "inCover", false } },
Effects = { { "inCover", true } },
Cost = 2f
});
Actions.Add(new GoapAction
{
Name = "ShootEnemy",
Preconditions = { { "hasAmmo", true }, { "inCover", true } },
Effects = { { "enemyDead", true } },
Cost = 1f
});
}
}
在实际工程中，GOAP 的复杂度需要控制。状态键过多会让搜索空间爆炸，因此通常只把影响决策的关键状态放入规划，其余细节仍由底层行为处理。比如 NPC 的动画播放、具体移动路径计算不需要进入 GOAP，这样可以保证规划器在每帧或低频更新中都能快速返回结果。
四、黑板架构与感知系统：让推理基于真实世界状态
无论是效用 AI 还是 GOAP，推理的质量都取决于输入数据的质量。如果 NPC 只能读取硬编码的血量和玩家坐标，它永远无法理解“玩家刚刚换弹”或“侧翼有脚步声”这类复杂信息。感知系统负责把环境中的原始数据转换成决策可用的状态，而黑板（Blackboard）则作为共享数据存储，让不同模块都能读写同一份信息。
一个常见的做法是给 NPC 挂载多种感知组件，比如视觉、听觉、记忆。视觉组件负责在视锥范围内检测玩家，听觉组件监听枪声和脚步声，记忆组件保存最后已知位置。这些组件把结果写入黑板，推理模块再从黑板读取。例如当 NPC 失去玩家视野时，它不会立刻忘记玩家，而是根据最后已知位置和记忆进行搜索，这正是推理的体现。
下面这段代码展示了黑板如何作为中间层解耦感知与推理。推理模块不需要知道视觉或听觉组件如何工作，只需要从黑板读取布尔值或坐标。
public class Blackboard
{
private Dictionary<string, object> data = new Dictionary<string, object>();
public void Set<T>(string key, T value)
{
data[key] = value;
}
public T Get<T>(string key)
{
if (data.TryGetValue(key, out object value))
{
return (T)value;
}
return default;
}
public bool HasKey(string key)
{
return data.ContainsKey(key);
}
}
// 感知组件写入黑板
blackboard.Set("canSeePlayer", visionSensor.IsPlayerVisible());
blackboard.Set("lastKnownPlayerPos", visionSensor.LastKnownPosition);
blackboard.Set("heardGunshot", audioSensor.LatestSoundType == "gunshot");
// 推理模块读取黑板
bool canSee = blackboard.Get<bool>("canSeePlayer");
Vector3 lastPos = blackboard.Get<Vector3>("lastKnownPlayerPos");
通过黑板和感知系统的配合，NPC 的推理能够建立在连续更新的世界状态之上。这种架构也让 AI 逻辑更容易测试：可以手动向黑板写入特定状态，观察 NPC 是否做出预期决策。相比把感知代码直接塞进每个行为节点，分离后的系统更清晰，也方便替换不同感知实现。
五、大语言模型在NPC推理中的落地策略
近段时间大型语言模型在游戏 AI 领域引起不少讨论。理论上，LLM 可以理解自然语言描述的场景，并生成符合世界观的角色反应。比如在对话系统中，NPC 可以根据玩家输入的文本进行推理并给出有上下文关联的回答。但对于实时战斗或高频决策，直接调用 LLM 存在延迟、成本和不可控性问题。更务实的做法是把 LLM 放在低频率、高层级决策上，比如任务选择、对话策略、长期记忆总结，而高频行为仍然使用效用 AI 或 GOAP。
一个混合方案是让 LLM 输出结构化指令，再由传统推理模块执行。例如在剧情节点，LLM 根据玩家过去的选择生成一个任务目标，NPC 的 GOAP 规划器接收该目标并规划具体行动。这样既利用了 LLM 的泛化理解能力，又保证了实时行为的稳定性。工程上需要注意对 LLM 输出做校验，确保生成的目标不会破坏游戏规则。可以要求 LLM 只返回 JSON 格式的结果，并在解析前进行模式匹配和字段检查。
目前来看，LLM 更适合作为 NPC 推理的增强层，而不是完全替代传统决策系统。游戏项目需要根据自身玩法选择合适的技术组合。无论是行为树、效用 AI 还是 GOAP，核心思路都是让 NPC 从当前状态推导下一步行动，而黑板和感知系统则保证了推理基于真实、可追踪的信息。理解这些机制的差异与适用场景，才能设计出既聪明又可控的 NPC 智能行为。