1. 从“收权”到“放权”：LLM 进入游戏主循环的底层逻辑
把大语言模型塞进游戏里，这件事在最近一年里从“技术演示”迅速变成了“正经玩法设计”。但真正动手做过的人都知道，最难的从来不是调用 API，而是权限分配——模型到底能在游戏主循环里做多少事、说多少话、改多少状态。我见过太多项目死在“给模型太多自由”或者“把模型管得太死”这两个极端上。
所谓“收权”，指的是早期做法：LLM 只负责生成对话文本，游戏逻辑完全由传统状态机控制。模型像一个被关在笼子里的旁白，玩家说什么它都得按预设分支回应。这种做法稳定、可控、容易调试，但玩起来很假——玩家能明显感觉到“对面不是人，是个查表机器”。
所谓“放权”，则是让 LLM 直接参与主循环决策：它可以调用工具、修改游戏状态、生成任务、甚至决定 NPC 的行为策略。听起来很美好，但一旦放权过度，就会出现模型乱改数值、生成非法动作、把游戏经济系统搞崩的情况。我实测过一个原型，放权后的第三天，NPC 开始互相刷钱，整个经济系统在 20 分钟内通胀到失去意义。
所以这篇文章要聊的核心，就是如何在“收权”和“放权”之间找到那条可落地的分界线。关键词里的“合法动作掩码”和“工具调用”就是这条分界线上的两个关键路标。适合正在做 LLM 驱动游戏玩法的开发者、技术策划，以及想理解大模型如何真正进入实时交互系统的朋友。
2. 核心架构拆解：主循环、工具调用与动作掩码如何配合
2.1 游戏主循环里 LLM 的三种接入位置
在传统游戏主循环里，每一帧或每个 tick 都在跑“输入→更新→渲染”这套流程。LLM 的接入位置决定了它的权限边界。我实际试过三种方案，各有取舍。
第一种是旁路接入，LLM 只在需要生成对话时被调用，不参与状态更新。这是最收权的做法，延迟低、成本可控，但玩法深度几乎为零。适合视觉小说类或纯对话驱动的轻量游戏。
第二种是决策层接入，LLM 在主循环的“更新”阶段被调用，输出一个动作指令，再由传统逻辑执行。比如 NPC 决定“去攻击玩家”还是“逃跑”，这个决策由 LLM 做，但具体移动和伤害计算还是走原有代码。这是目前最平衡的方案，也是我推荐大多数团队起步的位置。
第三种是全权接入，LLM 直接修改游戏状态，甚至生成新的规则。这种放权程度最高，玩法上限也最高，但需要极强的约束机制。我目前只在沙盒类原型里见过相对成功的案例，商业项目里极少见。
提示：如果你刚开始做 LLM 游戏，强烈建议从第二种“决策层接入”开始。旁路接入太保守，全权接入太危险，决策层是性价比最高的切入点。
2.2 工具调用：给 LLM 装上“手”而不是“大脑”
工具调用（Tool Calling / Function Calling）是放权的第一步。模型不再只是输出文本，而是可以输出一个结构化的调用请求，比如move_to(x, y)或attack(target_id)。但这里有个关键认知：工具调用不是让 LLM 当大脑，而是让它当手。
什么意思？大脑是“决定做什么”，手是“执行具体动作”。如果你让 LLM 既决定又执行，它就会在参数里乱填数值。我踩过的坑是：让模型直接输出伤害值，结果它生成了damage: 999999，因为它在训练数据里见过太多“秒杀”描述。
正确做法是：LLM 只输出动作类型和目标，具体数值由游戏逻辑根据规则计算。比如模型输出{"action": "attack", "target": "goblin_01"}，然后由战斗系统根据角色属性、装备、buff 算出实际伤害。这样既保留了 LLM 的决策灵活性，又把数值安全锁在了传统代码里。
工具调用的 schema 设计也有讲究。我建议每个工具的参数不超过 3 个，且尽量用枚举类型而不是自由文本。比如target参数不要给字符串，而是给一个从当前场景合法目标列表里选出来的 ID。这样模型就算想乱来，也没有空间。
2.3 合法动作掩码：放权但不失控的核心机制
合法动作掩码（Legal Action Mask）是我认为整个 LLM 游戏玩法里最重要的工程手段。它的逻辑很简单：在每一轮 LLM 决策之前，游戏逻辑先计算出一个“当前合法动作集合”，然后把这个集合作为约束传给模型。
举个例子。玩家当前在战斗中，血量 30%，没有治疗药水，周围有三个敌人。那么合法动作集合可能是：[攻击敌人A, 攻击敌人B, 攻击敌人C, 防御, 逃跑]。模型只能从这个集合里选，不能生成“使用治疗药水”或“召唤巨龙”这种非法动作。
实现上，有两种常见方式。一种是硬掩码，直接在模型输出层做 logits 屏蔽，把非法动作的概率压到零。这种方式最严格，但需要你能访问模型的输出分布，对 API 调用不太友好。另一种是软掩码，在 prompt 里明确列出合法动作，并在解析输出时做校验，非法动作直接丢弃或重试。这种方式实现简单，适合大多数 API 场景。
我实测下来，软掩码 + 输出校验的组合已经能挡住 95% 以上的非法动作。剩下的 5% 主要是模型“理解偏差”，比如把“防御”理解成“原地不动”，这种就需要在工具描述里写得更精确。
| 掩码方式 | 实现难度 | 约束强度 | 适用场景 |
|---|---|---|---|
| 硬掩码 | 高 | 极强 | 本地部署、可访问 logits |
| 软掩码 + 校验 | 低 | 较强 | API 调用、快速原型 |
| 纯 prompt 约束 | 极低 | 弱 | 非关键决策、对话生成 |
3. 实操落地：从零搭建一个带掩码的 LLM 决策循环
3.1 环境准备与最小依赖
我假设你用的是 Python 技术栈，游戏逻辑可以用任意引擎，这里用伪代码表示。核心依赖只有两个：一个 LLM 调用库（比如openai或anthropic），一个用于校验的 JSON schema 库（比如pydantic）。
pip install openai pydantic如果你用的是本地模型，可以用transformers或llama-cpp-python，但要注意本地模型的工具调用能力通常弱于云端大模型。我试过 7B 级别的本地模型做工具调用，准确率大概在 70% 左右，需要更多的重试和校验。
3.2 定义工具 schema 与合法动作生成器
先定义工具。每个工具就是一个函数签名，参数尽量少且类型明确。
from pydantic import BaseModel, Field from typing import Literal class AttackAction(BaseModel): action: Literal["attack"] = "attack" target_id: str = Field(description="当前场景中合法敌人的ID") class DefendAction(BaseModel): action: Literal["defend"] = "defend" class FleeAction(BaseModel): action: Literal["flee"] = "flee"然后写合法动作生成器。这个函数接收当前游戏状态，返回一个合法动作列表。
def get_legal_actions(game_state): actions = [] if game_state["enemies"]: for enemy in game_state["enemies"]: if enemy["alive"]: actions.append({"action": "attack", "target_id": enemy["id"]}) actions.append({"action": "defend"}) if game_state["can_flee"]: actions.append({"action": "flee"}) return actions这个生成器就是“收权”的体现——它决定了模型能看到哪些选项。你可以根据游戏设计随时调整，比如血量低于 20% 时才允许“逃跑”，或者特定职业才能“防御”。
3.3 构造 prompt 并调用 LLM
Prompt 的构造直接决定模型输出的稳定性。我的经验是：把合法动作列表放在 prompt 的最后，并且用 JSON 格式明确列出。模型对“最近看到的约束”最敏感。
def build_prompt(game_state, legal_actions): return f""" 你是一个游戏中的NPC决策模块。当前游戏状态： - 玩家血量：{game_state['player_hp']}% - 敌人数量：{len(game_state['enemies'])} - 可用动作：{legal_actions} 请从可用动作中选择一个，以JSON格式输出。不要输出任何其他内容。 """调用时设置temperature=0.2，降低随机性。我试过temperature=0.8，模型会开始“创意发挥”，生成一些不在列表里的动作，虽然有趣但不可控。
import openai response = openai.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": build_prompt(game_state, legal_actions)}], temperature=0.2, response_format={"type": "json_object"} )3.4 输出校验与非法动作处理
拿到输出后，第一件事是校验它是否在合法动作列表里。这一步绝对不能省。
import json def validate_action(raw_output, legal_actions): try: action = json.loads(raw_output) except json.JSONDecodeError: return None if action in legal_actions: return action return None如果校验失败，有两种处理策略。一种是重试，把错误信息塞回 prompt 让模型重新选。另一种是降级，直接选一个默认动作（比如“防御”）。我建议关键决策用重试，非关键决策用降级，避免无限循环。
注意：重试次数不要超过 2 次。我见过模型连续 5 次输出非法动作的情况，这时候再重试就是浪费 token，直接降级更划算。
3.5 把决策接回游戏主循环
最后一步是把整个流程嵌入主循环。伪代码如下：
def game_loop(): while game_running: game_state = update_game_state() legal_actions = get_legal_actions(game_state) prompt = build_prompt(game_state, legal_actions) raw_output = call_llm(prompt) action = validate_action(raw_output, legal_actions) if action is None: action = {"action": "defend"} # 降级 execute_action(action) render()这个循环里，LLM 只负责“选”，不负责“算”。所有数值计算、状态变更都在execute_action里由传统代码完成。这就是“放权但不失控”的具体实现。
4. 常见问题与排查技巧实录
4.1 模型输出格式不稳定怎么办
这是最常见的问题。即使你要求 JSON 输出，模型偶尔还是会加一句“好的，我选择攻击”。我的解决办法是在 prompt 里加一句“只输出JSON，不要任何解释”，并且在解析时用正则先提取{...}部分。
import re def extract_json(text): match = re.search(r'\{.*\}', text, re.DOTALL) if match: return match.group() return text另外，response_format={"type": "json_object"}这个参数在支持它的模型上非常有效，能直接把输出约束成合法 JSON。如果你的模型不支持，那就只能靠 prompt 和正则了。
4.2 合法动作太多导致模型选择困难
当合法动作超过 10 个时，模型的准确率会明显下降。我试过 20 个敌人的场景，模型开始随机选，甚至选已经死亡的敌人。解决办法是分层决策：先让模型选“攻击/防御/逃跑”大类，再在选定大类里用传统逻辑选具体目标。
# 第一层：选大类 legal_categories = ["attack", "defend", "flee"] # 第二层：如果选attack，用传统逻辑选目标 if category == "attack": target = select_target_by_threat_level(game_state)这样每层决策的选项都不超过 5 个，模型准确率能回到 90% 以上。
4.3 延迟太高影响游戏体验
LLM 调用延迟通常在 500ms 到 2s 之间，对于实时战斗来说太慢了。我的做法是预生成 + 缓存。在战斗开始前，预生成一批决策结果缓存起来，实际战斗时直接读缓存。如果缓存命中率够高，玩家几乎感觉不到延迟。
另一种做法是异步决策。NPC 的决策不阻塞主循环，这一帧先用默认行为，等 LLM 返回后再下一帧生效。适合回合制或半即时制游戏。
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 输出格式不稳定 | 模型自由发挥 | JSON mode + 正则提取 |
| 动作太多选不准 | 选项过载 | 分层决策 |
| 延迟高 | API 往返耗时 | 预生成缓存 + 异步 |
| 非法动作 | 掩码不严 | 输出校验 + 降级 |
| 重复决策 | 状态未更新 | 决策后立即更新状态 |
4.4 模型“理解偏差”导致动作语义错误
这个问题比较隐蔽。比如你定义了“防御”动作，模型选了它，但它在后续对话里说“我躲到树后”。实际上游戏逻辑里“防御”只是减伤，没有位移。这种偏差不会导致崩溃，但会破坏玩家体验。
解决办法是在工具描述里写清楚每个动作的具体效果，而不是只写名字。比如：
class DefendAction(BaseModel): action: Literal["defend"] = "defend" description: str = "原地防御，减少50%伤害，不移动位置"把 description 也放进 prompt 里，模型对动作的理解会准确很多。
5. 放权程度的动态调节：让 LLM 在安全区内自由发挥
5.1 根据游戏阶段调整权限
不是所有游戏阶段都需要同样的放权程度。我的经验是：战斗和关键决策收权，探索和社交放权。
战斗时，合法动作掩码要严格，数值计算完全由传统逻辑控制。探索时，可以让 LLM 生成场景描述、NPC 对话、甚至小任务。社交时，可以让 LLM 自由生成对话内容，只要不涉及数值变更就行。
这种动态调节可以通过一个“权限等级”参数来实现。权限等级低时，合法动作列表短、工具少；权限等级高时，合法动作列表长、工具多。
def get_permission_level(game_state): if game_state["in_combat"]: return "low" elif game_state["in_dialogue"]: return "high" else: return "medium"5.2 用“沙盒”隔离高风险操作
对于确实需要放权的高风险操作，比如让 LLM 生成新任务或修改经济数值，我建议用沙盒机制。LLM 的修改先写到一个临时状态里，经过校验和模拟后再合并到主状态。
def apply_sandboxed_change(change): temp_state = copy.deepcopy(game_state) temp_state = apply_change(temp_state, change) if validate_state(temp_state): game_state = temp_state else: log_rejected_change(change)这样即使模型生成了离谱的修改，也不会直接影响玩家体验。我实测过一个经济系统，沙盒机制挡住了 3 次通胀危机。
5.3 监控与回滚：放权后的安全网
放权之后一定要有监控。我建议记录每一次 LLM 决策的输入、输出、校验结果和执行结果。一旦发现异常模式（比如某个动作被连续选择 10 次），就触发告警或自动回滚。
decision_log = [] def log_decision(state, action, result): decision_log.append({ "state": state, "action": action, "result": result, "timestamp": time.time() }) if len(decision_log) > 100: check_anomaly(decision_log)这套监控机制在早期调试阶段特别有用。我靠它发现过模型在血量低时总是选“防御”而不选“逃跑”，原因是 prompt 里“逃跑”的描述不够吸引模型。调整描述后，行为就正常了。
6. 我个人在实际操作中的几点体会
做 LLM 游戏玩法这一年多，最大的感受是：模型的能力不是瓶颈，工程约束才是。你给模型多少自由，它就能给你多少惊喜，也能给你多少麻烦。合法动作掩码和工具调用这两件事，本质上都是在“给自由画边界”。
另一个体会是，不要试图让 LLM 做所有事。传统游戏 AI 在数值计算、路径寻路、状态管理上比 LLM 强得多，也便宜得多。LLM 的优势在于语义理解和开放决策，把它用在它擅长的地方，其他地方交给传统代码。
最后分享一个小技巧：在 prompt 里加一句“如果你不确定，选择最保守的动作”。这句话能显著降低模型在模糊状态下的乱选概率。我实测下来，加了这句话之后，非法动作率从 8% 降到了 2% 左右。成本几乎为零，效果立竿见影。
