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 并调用 LLMPrompt 的构造直接决定模型输出的稳定性。我的经验是把合法动作列表放在 prompt 的最后并且用 JSON 格式明确列出。模型对“最近看到的约束”最敏感。def build_prompt(game_state, legal_actions): return f 你是一个游戏中的NPC决策模块。当前游戏状态 - 玩家血量{game_state[player_hp]}% - 敌人数量{len(game_state[enemies])} - 可用动作{legal_actions} 请从可用动作中选择一个以JSON格式输出。不要输出任何其他内容。 调用时设置temperature0.2降低随机性。我试过temperature0.8模型会开始“创意发挥”生成一些不在列表里的动作虽然有趣但不可控。import openai response openai.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: build_prompt(game_state, legal_actions)}], temperature0.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 medium5.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% 左右。成本几乎为零效果立竿见影。