1. 从收权说起为什么大多数 LLM 游戏项目死在了第一版做 LLM 驱动游戏玩法的团队十个里有八个经历过同一个剧本Demo 惊艳上线崩盘。玩家输入我要去酒馆打听消息模型给你返回一段文采飞扬的独白然后——没有然后了。NPC 没有真的移动任务状态没有更新背包里的金币没扣。模型在讲故事游戏在装死。这个问题的根源几乎从来不是模型不够聪明而是架构上把主循环的控制权整个交给了 LLM。我把它叫做全放权架构玩家的自然语言输入直接喂给模型模型输出一段文本前端把这段文本渲染出来就算完成了一次交互。听起来很顺但它有三个致命伤。第一状态不可信。LLM 是概率模型它说你获得了 50 金币但游戏世界的真实状态里金币数没变。下一次对话它可能又说你获得了 30 金币两次说法互相矛盾。玩家一旦发现 NPC 在编造自己的资产沉浸感瞬间归零。第二延迟不可控。一次完整的 LLM 推理哪怕是流式输出首 token 延迟通常在几百毫秒到数秒之间。如果游戏主循环的每一帧、每一次玩家操作都要等模型返回操作手感会烂到无法忍受。动作游戏里 100ms 的延迟都能被玩家感知何况是秒级。第三行为不可预测。模型可能拒绝执行、可能输出格式错误的 JSON、可能调用一个根本不存在的工具。你没法像对待确定性代码那样对待它。生产环境里任何模型应该会……的假设都是定时炸弹。所以真正跑通的 LLM 游戏走的都是同一条路先收权再放权。收权是把游戏的核心状态机、物理模拟、数值结算牢牢握在确定性代码手里放权是在这些确定性边界之内把表达和决策建议交给 LLM。这个顺序不能反。我见过太多团队一上来就想让模型自主决策一切结果三个月后推倒重来。这篇文章想聊的就是这条从收权到放权的完整路径主循环该怎么切分职责、工具调用该怎么设计才不会被模型玩坏、Agent 的记忆和状态该怎么和游戏世界对齐、以及那些只有真正上线过的人才会知道的坑。适合正在做 LLM 游戏玩法、Agent 开发或者任何想把大模型接进实时交互系统的同学。2. 主循环的职责切分哪些交给代码哪些留给模型2.1 把主循环拆成确定性层和表达层游戏主循环main loop的本质是一个不断重复的循环读取输入、更新状态、渲染输出。传统游戏里这三步全是确定性代码。引入 LLM 之后我的做法是把循环拆成两层。确定性层负责所有不能错的事情玩家位置、血量、背包、任务进度、NPC 的物理存在、时间流逝、战斗结算。这一层用普通代码写帧率稳定状态可序列化可回放可测试。表达层负责所有可以错一点的事情NPC 说什么话、任务描述怎么措辞、玩家输入的自然语言怎么理解、下一步可能想做什么。这一层交给 LLM允许它偶尔抽风因为抽风的代价只是这句话说得不好而不是游戏崩了。关键在于表达层的输出必须经过确定性层的校验才能生效。模型说NPC 给了你一把剑这只是个意图真正把剑放进背包的是确定性层的代码。模型说我要攻击那个哥布林这只是个动作请求真正扣血、判定命中、计算伤害的是战斗系统。我通常会在代码里画一条清晰的线玩家输入 → [LLM 意图解析] → 结构化动作请求 → [确定性校验与执行] → 状态变更 → [LLM 表达生成] → 渲染注意这里 LLM 出现了两次一次在入口做理解一次在出口做表达。中间那段最关键的执行完全不给模型碰。这个结构我用了很久稳定性比模型全权处理高一个数量级。2.2 意图解析让模型输出动作而不是结果新手最容易犯的错是让模型直接输出结果。比如玩家说我打开箱子模型返回箱子里有一把生锈的钥匙和 20 金币你拿走了它们。这句话里包含了三个状态变更箱子被打开、钥匙进背包、金币增加。但模型只是说了没有做。正确做法是让模型输出一个结构化的动作请求比如{ action: open_container, target: chest_01, intent: player wants to open the chest }然后由确定性代码去查chest_01里到底有什么执行开箱逻辑更新状态。模型只负责理解玩家想干什么不负责决定发生了什么。这个转变听起来简单但它彻底改变了系统的可靠性。因为动作请求是可以校验的目标存不存在玩家够不够得着有没有权限这些检查全在代码里模型再离谱也越不过这道墙。我在实际项目里会维护一张动作白名单模型只能从这张表里选动作。表外的任何输出一律拒绝并回退到一个默认的我不太明白响应。这张表通常长这样动作类型参数校验点失败回退move_totarget_id目标可达、路径存在提示走不过去attacktarget_id目标存活、在攻击范围提示够不着use_itemitem_id, target物品在背包、可使用提示没有这个物品talk_tonpc_idNPC 存在、可对话提示没人在那query_infotopic话题在白名单返回通用回答这张表是收权的核心。它把模型的自由度限制在一个有限动作空间里既保证了安全又让模型有足够的表达余地。2.3 表达生成把事实翻译成人话出口这一侧模型的工作是把确定性层产生的事实翻译成符合角色设定的自然语言。比如战斗系统算出玩家对哥布林造成 12 点伤害哥布林剩余 8 点血模型要把它变成你的剑划过哥布林的肩膀它踉跄后退血从伤口渗出。这里有个技巧给模型喂结构化的事实而不是让它自己编。我会把这一帧发生的所有事件打包成一个事件列表连同 NPC 的性格设定、当前情绪、上下文一起喂给模型。模型的任务只是润色不是创作事实。{ events: [ {type: damage, source: player, target: goblin, amount: 12}, {type: hp_change, target: goblin, from: 20, to: 8} ], npc_profile: {name: 哥布林斥候, tone: 惊恐、好斗}, recent_context: 玩家刚刚冲进营地 }这样生成出来的文本既生动又不会和真实状态打架。我实测下来这种事实驱动表达的方式玩家察觉不到 NPC 在编造的概率几乎为零因为所有数字都对得上。2.4 一个容易忽略的点主循环的节奏LLM 推理是慢的游戏主循环是快的这两者必须解耦。我的做法是异步事件队列玩家的输入进入队列后台异步调用模型做意图解析解析结果回到主循环后由确定性层执行。玩家在等待期间游戏世界照常运转可以给个思考中的动画或者让 NPC 做个待机动作。千万别在主循环里同步等模型返回。我踩过这个坑帧率直接从 60 掉到个位数玩家体验灾难。异步化之后即使模型要 2 秒才返回游戏画面依然流畅玩家感知到的只是NPC 反应慢了点而不是游戏卡死了。3. 工具调用给模型的手但缰绳在你手里3.1 工具调用的本质是受控的副作用工具调用tool calling是 LLM Agent 的核心能力也是游戏玩法里最容易出事的地方。模型可以调用工具意味着它可以改变世界。这既是威力所在也是风险所在。我的原则是每一个工具都必须是一个纯函数式的、可校验的、有边界的操作。所谓纯函数式是指给定相同输入必然产生相同输出或者至少是确定性的状态变更可校验是指调用前能检查参数合法性有边界是指它只能影响世界的一小块。反面例子是一个叫modify_world的工具参数是任意 JSON模型想改什么改什么。这种工具等于把整个游戏世界交给模型迟早出事。正面例子是一组细粒度的工具move_entity、set_hp、add_item、set_flag每个都只做一件事参数明确边界清晰。3.2 工具设计的三个层次我把游戏里的工具分成三层从下到上权限递增。第一层查询类工具。只读不改状态。比如get_npc_info、get_inventory、get_quest_status。这类工具最安全可以放心让模型随便调。它们的作用是给模型提供当前世界的事实避免模型瞎猜。第二层表达类工具。改变的是表现不是状态。比如play_animation、set_expression、emit_sound。模型调用它们NPC 会做个表情、放个音效但游戏逻辑状态不变。这类工具即使被滥用代价也只是表现有点怪不会破坏游戏。第三层状态类工具。真正改变游戏状态。比如deal_damage、give_item、complete_quest。这类工具必须严格校验而且我通常不允许模型直接调用而是让模型输出意图由确定性代码决定是否执行。这个分层的好处是你可以根据场景灵活放权。探索阶段可以多给查询和表达权限让 NPC 更生动战斗阶段收紧到只允许意图输出保证数值准确。3.3 参数校验模型最爱在这里翻车模型调用工具时参数经常出问题。我统计过自己项目里的失败案例大概分布是这样的失败类型占比典型表现应对参数类型错35%该传 int 传了 stringschema 强校验 自动转换目标不存在25%引用了一个不存在的 NPC id调用前查存在性参数越界20%伤害值传了 99999范围钳制格式错误15%JSON 缺字段、多逗号严格 schema 重试逻辑冲突5%对已死目标攻击状态前置检查应对这些的核心是schema 校验 前置检查 优雅降级。schema 用 JSON Schema 或者 Pydantic 这类工具定义模型输出后先过一遍校验不通过就让它重试带上错误信息。前置检查是在真正执行前确认目标存在、状态合法。优雅降级是当一切都不行时返回一个合理的默认响应而不是抛异常。我特别想强调范围钳制。模型对数值是没有概念的它可能觉得造成 99999 点伤害很酷。所有数值参数都要有上下界超出就钳到边界值。这个简单的措施能挡掉大量离谱行为。3.4 工具调用的循环控制Agent 调用工具往往不是一次性的而是调用→看结果→再调用的循环。这个循环必须有步数上限和超时控制。我见过模型陷入死循环反复调用同一个工具几十次把 token 烧光。我的默认配置是单次玩家输入最多触发 5 轮工具调用总耗时不超过 10 秒。超过就强制中断返回当前已有的结果。这个上限要根据游戏类型调解谜类可以放宽动作类要收紧。还有一个细节工具调用要有幂等性设计。如果模型因为超时重试同一个give_item被调了两次玩家就白得一个道具。解决办法是给每次调用带一个唯一 id确定性层记录已执行的 id重复的直接忽略。4. Agent 的记忆与状态别让模型活在自己的幻觉里4.1 短期记忆对话窗口的管理Agent 的短期记忆就是对话历史。游戏里这通常是一个 NPC 和玩家的最近若干轮对话。问题在于对话历史会越来越长而模型的上下文窗口是有限的。我的做法是滑动窗口 摘要压缩。保留最近 N 轮完整对话N 通常取 10 到 20更早的对话压缩成一段摘要。摘要由模型生成但摘要里的事实必须来自确定性层不能让模型自由发挥。比如摘要不能是玩家似乎对 NPC 有好感而应该是玩家在本轮对话中完成了 3 次交易总金额 150 金币NPC 好感度从 20 升到 35。前者是模型的猜测后者是确定的事实。4.2 长期记忆向量检索还是结构化存储长期记忆比如 NPC 记得玩家三天前做过什么是 LLM 游戏的一个难点。常见方案是向量数据库 RAG把历史事件嵌入后检索。但我在游戏场景里发现纯向量检索不够可靠。原因是游戏事件有强结构谁、在什么时候、对谁、做了什么、结果如何。这些用结构化存储比如关系数据库或者事件日志更合适。我的混合方案是结构化存储作为真相源向量检索作为召回辅助。具体来说每个重要事件都写进事件日志带时间戳、参与者、类型、结果。当 NPC 需要回忆时先用结构化查询捞出相关事件比如和这个玩家有关的所有事件再用向量检索在事件描述里找语义相关的两者合并后喂给模型。这样既保证了事实准确又有语义灵活性。实测下来NPC 的记忆一致性比纯 RAG 方案好很多。4.3 状态对齐模型认知和世界状态的同步最隐蔽的坑是模型认知和世界状态不同步。比如 NPC 在模型眼里还活着但确定性层里它已经被玩家杀了。或者模型以为玩家在酒馆实际玩家已经走到森林了。解决办法是每次调用模型前注入当前世界状态的关键切片。不是把整个世界塞进去太大而是塞和当前交互相关的部分当前场景、在场 NPC、玩家关键属性、最近事件。{ scene: tavern, present_npcs: [barkeep, mysterious_stranger], player: {hp: 80, gold: 120, location: tavern}, recent_events: [player entered tavern, player ordered ale] }这个切片是确定性层生成的模型只能基于它来表演。这样模型永远不会以为玩家在别的地方因为它看到的状态就是真实的。4.4 记忆的写入也要受控模型不能随便往记忆里写东西。如果模型说NPC 记住了玩家欠他 100 金币但实际玩家没欠这就污染了记忆。我的做法是记忆的写入由确定性层决定模型只能建议。比如模型输出一个remember意图确定性层检查这个事件是否真实发生过在事件日志里确认后才写入长期记忆。这样记忆永远是可信的。5. 放权的艺术什么时候该松手松到什么程度5.1 放权的前提是收权到位前面讲了这么多收权但 LLM 游戏玩法的魅力恰恰在于放权——让模型带来传统脚本写不出的涌现行为。关键在于放权必须建立在收权到位的基础上。当你的确定性层足够健壮能挡住所有非法操作能校验所有状态变更能优雅处理所有异常这时候你就可以放心地把更多决策权交给模型。因为即使模型犯错系统也不会崩。我通常的放权路径是先只让模型做表达说什么话稳定后放开意图解析想做什么再稳定后放开策略建议建议做什么最后才考虑放开自主决策自己决定做什么。每一步都要有充分的测试和回退机制。5.2 涌现行为的价值放权带来的最大价值是涌现行为。传统游戏里NPC 的行为是脚本写死的玩家玩几次就摸清了套路。LLM 驱动的 NPC 可以产生脚本写不出的反应。我印象很深的一次测试玩家在游戏里反复骚扰一个 NPC传统脚本 NPC 只会重复别烦我。但 LLM 驱动的 NPC 在第三次被骚扰时突然说你再这样我就叫守卫了然后真的触发了叫守卫的动作。这个行为不是我们写的是模型根据上下文想出来的。玩家当时的反应是这 NPC 成精了。这种涌现是 LLM 游戏的核心竞争力。但它只有在收权到位的前提下才能安全地发生——因为叫守卫这个动作最终还是要经过确定性层校验和执行。5.3 放权的边界哪些永远不能放有些东西我永远不会交给模型。数值结算不能放因为模型算不准而且玩家对数值公平性极度敏感。核心剧情节点不能放因为模型可能把主线带偏。玩家资产不能放因为一旦出错就是事故。反作弊相关不能放模型太容易被诱导。这些边界要在架构设计阶段就划清楚写进文档让所有开发者都知道。我见过团队因为边界不清不同模块对模型能做什么理解不一致最后集成时一堆冲突。5.4 用评测驱动放权决策放权不是拍脑袋决定的要用数据说话。我会为每个放权点建立评测集一组典型的玩家输入加上期望的行为。每次调整放权程度就跑一遍评测看通过率。评测指标通常包括意图识别准确率、工具调用成功率、状态一致性模型说的和实际发生的是否一致、玩家体验评分人工标注。只有这些指标都达标才考虑进一步放权。这套评测体系是放权决策的依据也是回归测试的保障。没有它放权就是赌博。6. 实战中那些文档不会写的坑6.1 模型对时间没有概念游戏里的时间流逝白天黑夜、回合数、冷却时间模型是感知不到的。它可能在你告诉它现在是夜晚之后下一句又说阳光明媚。解决办法是每次注入状态时都带上时间信息并且在表达生成时明确约束当前是夜晚描述要符合。6.2 并发调用的状态竞争多个 NPC 同时被触发 LLM 调用时可能出现状态竞争。比如两个 NPC 同时想给玩家同一个道具。解决办法是状态变更串行化所有写操作走一个队列逐个执行。读操作可以并发写操作必须排队。6.3 模型输出的过度承诺模型很喜欢承诺它做不到的事。比如 NPC 说我这就带你去宝藏所在地但游戏里根本没有这个功能。解决办法是在表达生成的 prompt 里明确列出NPC 当前能做的事并约束不要承诺列表外的行为。6.4 成本控制LLM 调用是花钱的。一个活跃玩家每小时可能触发几十次调用。我的经验是能缓存的就缓存能批量的就批量能用小模型的就别用大模型。意图解析这种任务小模型往往够用只有表达生成这种需要文采的才值得上大模型。6.5 降级方案模型服务会挂网络会抖API 会限流。必须有降级方案模型不可用时回退到预设的脚本响应。降级不是失败是保证游戏可玩性的底线。我通常准备一套离线台词库模型挂了就用它玩家顶多觉得 NPC 变笨了但游戏不会卡死。7. 我个人的一些体会做了几个 LLM 游戏项目之后我最大的体会是LLM 在游戏里的角色更像是一个即兴演员而不是导演。导演确定性层定好剧本框架、场景、规则演员LLM在这个框架里自由发挥。演员可以演出剧本没写的精彩细节但不能改剧本、不能改结局、不能改道具数量。收权和放权不是对立的而是同一件事的两面。收权收得越干净放权才能放得越大胆。因为你知道无论模型怎么发挥系统都兜得住。反过来如果确定性层千疮百孔你只能把模型管得死死的那 LLM 游戏玩法的价值也就没了。还有一个反直觉的点模型的能力不是越强越好而是越可控越好。一个稍微笨一点但输出格式稳定、行为可预测的模型往往比一个聪明但经常抽风的模型更适合游戏。因为游戏是实时交互系统稳定性比单次表现的上限更重要。最后分享一个我常用的调试技巧把每次 LLM 调用的输入状态切片、prompt和输出意图、表达都完整记录下来做成可回放的日志。出问题时你可以精确复现当时模型看到了什么、输出了什么、系统怎么处理的。这个日志在排查NPC 为什么说了奇怪的话这类问题时价值无可替代。我甚至用它做过 A/B 测试对比不同 prompt 策略下的玩家行为差异。这套从收权到放权的思路不限于游戏。任何把 LLM 接进实时交互系统的场景——客服、教育、陪伴类应用——都能用。核心就一句话让模型做它擅长的理解和表达让代码做它擅长的执行和校验两者之间用结构化的接口隔开。想清楚这条线画在哪项目就成功了一半。