1. 从“收权”到“放权”一个游戏主循环的架构演变第一次把 LLM 塞进游戏主循环的时候我犯了一个很典型的错误把 LLM 当成了“万能决策器”。玩家输入一句话我直接把整段游戏状态序列化丢给模型让它返回下一步动作。结果就是延迟爆炸、token 烧得飞快而且模型经常返回一些游戏里根本不存在的动作解析器直接崩溃。后来我意识到问题不在于 LLM 不够聪明而在于我把控制权交得太彻底了。游戏主循环有自己的节奏——每帧要更新物理、每 tick 要处理输入、每个回合要结算状态。LLM 的推理是异步的、概率性的、有延迟的它天然不适合直接驱动一个要求确定性帧率的循环。所以这篇文章想聊的是我在实际项目里踩过一圈坑之后总结出来的一套思路从收权到放权。先让游戏引擎牢牢握住主循环的控制权把 LLM 限制在一个受控的“决策沙盒”里等这套机制跑稳了再逐步把更多权限下放给 agent让它真正参与玩法而不是当一个外挂的聊天框。这套东西适合谁看如果你正在做 LLM 驱动的游戏 NPC、想做 agent 参与玩法决策、或者单纯想搞清楚“工具调用”在游戏场景里到底怎么落地那下面的内容应该能帮你少走不少弯路。核心关键词就几个LLM、游戏玩法、主循环、工具调用、agent我会围绕它们把整个架构拆开讲。2. 为什么不能让 LLM 直接接管主循环2.1 主循环的确定性要求和 LLM 的概率性本质冲突游戏主循环的本质是什么是一个固定时间步长的状态机。以 60 FPS 为例每 16.6 毫秒要完成一次输入采样、逻辑更新、渲染提交。哪怕你的游戏是回合制的主循环也要求“这一帧结束时世界状态必须是确定的、可序列化的、可回放的”。LLM 的推理过程恰恰相反。同样的输入温度参数不为零时输出会波动网络请求的延迟从几百毫秒到几秒不等返回的内容是自然语言需要解析才能变成结构化动作。你把这些东西直接塞进主循环等于在一个要求硬实时的系统里插入了一个软实时的黑盒。我实测过最极端的情况让模型每帧决定 NPC 的移动方向。结果是帧率从 60 掉到 8而且 NPC 的行为像喝醉了一样因为模型每次返回的“向左”“向右”并不连贯。这不是模型的问题是我用错了地方。2.2 收权把 LLM 关进“决策沙盒”所谓收权就是明确划分边界主循环归引擎决策归 LLM但决策的触发时机、输入范围、输出格式全部由引擎控制。具体做法是引入一个“决策请求”机制。引擎在需要 LLM 介入的时候才组装一个精简的上下文通过工具调用的方式发给模型。模型返回的不是自由文本而是一个符合预定义 schema 的工具调用请求。引擎收到后先校验校验通过才执行。这样做的好处很直接主循环的帧率不受模型延迟影响因为决策是异步的引擎可以继续跑模型的输出被约束在有限的动作空间里不会出现“我想飞到天上”这种无法解析的指令token 消耗可控因为每次只发必要的信息而不是整个游戏状态。提示工具调用的 schema 一定要严格。我见过有人用自然语言描述动作结果模型返回“我建议 NPC 往东走”解析器直接懵了。用 JSON Schema 定义动作类型、参数范围、必填字段模型会老实很多。2.3 放权的前提先证明收权是稳的收权不是目的是手段。它的真正价值在于当你把 LLM 的决策过程变得可观测、可校验、可回放之后你才有资格谈放权。我自己的节奏是这样的第一阶段LLM 只能做“选择型”决策比如从三个预设对话里选一个第二阶段LLM 可以做“参数型”决策比如指定移动目标点第三阶段LLM 可以组合多个工具调用形成一个小型行为序列。每一步放权都建立在上一步的日志和回放数据证明“它不会乱来”的基础上。3. 工具调用LLM 和游戏世界之间的唯一通道3.1 为什么是工具调用而不是直接生成代码或 DSL有人会想让 LLM 直接生成游戏脚本不是更灵活吗我试过结论是在玩法层面灵活等于不可控。生成代码的问题在于你无法在运行前知道它会生成什么。哪怕你做了沙箱解析和执行的成本也很高。而工具调用本质上是“函数签名 参数”的结构化输出模型只需要填参数不需要发明语法。这对游戏这种动作空间有限的场景来说匹配度极高。另一个原因是工具调用天然支持“拒绝”。如果模型返回的参数不合法引擎可以直接拒绝执行并把这个拒绝信息作为下一轮上下文的一部分反馈给模型。这就形成了一个闭环模型提议引擎校验模型根据反馈调整。3.2 工具集的设计原则少而精语义清晰我见过一些项目一上来就定义几十个工具结果模型选择困难经常调错。我的经验是初始工具集控制在 5 到 8 个每个工具的语义要足够清晰参数要尽量少。以我做过的一个 NPC 行为系统为例核心工具只有这几个工具名作用关键参数move_to移动到指定坐标x, y, speedinteract与指定对象交互target_id, action_typespeak播放对话line_id, emotionwait等待指定时长durationquery_state查询自身或环境状态query_type每个工具的参数都做了范围限制。比如 move_to 的 x、y 必须在当前地图的可行走区域内speed 只能是预设的几档。模型返回越界参数时引擎直接拒绝并返回错误码。3.3 工具调用的执行流程和错误处理一次完整的工具调用流程是这样的引擎检测到需要 LLM 决策的事件组装上下文上下文包含当前状态摘要、可用工具列表、最近几次决策的历史通过 API 调用模型要求返回工具调用格式引擎解析返回校验工具名和参数校验通过则执行执行结果写入日志校验失败则生成错误信息作为下一轮上下文的一部分重新请求。这里有个细节很重要错误信息要具体。不要只说“参数错误”要说“move_to 的 x 参数 1500 超出地图宽度 1200”。模型看到具体错误后修正的成功率会高很多。注意不要在一次请求里让模型连续调用多个工具。我试过让模型返回一个工具调用数组结果它经常把顺序搞反或者依赖前一个调用的结果但参数写的是猜测值。一次一个工具调用执行完再请求下一个虽然多几次往返但稳定性高得多。4. Agent 的引入从单次决策到持续行为4.1 Agent 和单次工具调用的区别单次工具调用是“你问我答”agent 是“我给你一个目标你自己想办法”。在游戏玩法里这意味着 LLM 不再只是响应事件而是可以主动规划一系列行为。但这里有个陷阱很多人一上来就做全自主 agent结果 agent 在游戏里乱跑玩家体验极差。我的做法是给 agent 加一个“行为预算”——比如每 30 秒最多执行 10 个工具调用或者每个目标最多尝试 3 次。预算耗尽后agent 必须回到 idle 状态等待新的触发。4.2 记忆机制agent 需要记住什么不需要记住什么Agent 的记忆不是越多越好。我一开始把所有的对话历史都塞进上下文结果 token 消耗巨大而且模型经常被无关信息干扰。后来我改成三层记忆短期记忆最近 5 次工具调用的结果用于避免重复失败中期记忆当前目标的进度摘要比如“已经走到门口还没进去”长期记忆玩家的关键交互记录比如“玩家之前帮过我”。长期记忆用向量库存储只在相关的时候检索。中期记忆是纯文本摘要每次请求都带上。短期记忆就是最近几次的调用记录。这样下来上下文长度可控模型也不会被淹没。4.3 Agent 的终止条件什么时候该停下来Agent 最怕的是“死循环”——反复尝试同一个失败的动作。我在引擎层加了几个硬性终止条件连续 3 次工具调用返回相同错误强制终止单个目标执行超过 20 个工具调用强制终止总 token 消耗超过预算强制终止。终止后agent 会进入一个“冷却”状态同时把失败原因写入日志。这些日志后来成了我调优 prompt 的主要依据。5. 实操一个最小可运行的 LLM 游戏决策模块5.1 环境准备和依赖我用 Python 做原型核心依赖就几个pip install openai pydantic游戏引擎那边我用的是一个简单的 2D 网格世界模拟器自己写的不到 200 行。重点不在引擎在于 LLM 决策模块怎么和引擎对接。5.2 定义工具 schema用 Pydantic 定义工具参数这样校验和序列化都省事from pydantic import BaseModel, Field from typing import Literal class MoveToParams(BaseModel): x: int Field(ge0, le100, description目标X坐标) y: int Field(ge0, le100, description目标Y坐标) speed: Literal[slow, normal, fast] normal class SpeakParams(BaseModel): line_id: str Field(description对话ID) emotion: Literal[neutral, happy, angry, sad] neutral每个工具对应一个参数模型引擎在执行前用 Pydantic 校验。5.3 组装请求和解析响应请求的组装逻辑def build_decision_request(state_summary, available_tools, history): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: f当前状态{state_summary}\n f可用工具{available_tools}\n f最近决策{history}} ] return messagesSYSTEM_PROMPT 里明确要求模型只返回工具调用不要返回自然语言解释。实测下来加上“只返回 JSON”的约束后解析成功率从 70% 提升到 95% 以上。5.4 执行循环和日志记录执行循环的核心逻辑while not done: request build_decision_request(...) response call_llm(request) tool_call parse_tool_call(response) if validate(tool_call): result execute(tool_call) log(tool_call, result) else: log_error(tool_call, validation failed) update_state()日志我建议用结构化格式比如 JSON Lines每行一条记录包含时间戳、请求摘要、响应、校验结果、执行结果。后面排查问题的时候直接 grep 就行。6. 常见问题与排查技巧实录6.1 模型返回的工具名不存在这是最常见的问题。原因通常是工具列表在 prompt 里描述得不够清晰或者模型“幻觉”了一个听起来合理的工具名。解决办法在 SYSTEM_PROMPT 里把工具名用代码块包起来并且明确说“只能从以下工具中选择”。另外引擎收到未知工具名时不要直接崩溃而是返回一个错误信息把可用工具列表再发一次。6.2 参数类型错误比如模型返回x: 五十而不是x: 50。Pydantic 会直接报错这时候把错误信息反馈给模型让它重新生成。我实测过加上类型错误反馈后第二次请求的修正率在 80% 左右。6.3 延迟过高导致体验卡顿如果模型响应要 2 秒而游戏需要即时反馈那就要做“预测执行”。我的做法是在等待模型响应的时候引擎先执行一个默认行为比如 idle 动画等响应到了再切换。这样玩家感知不到卡顿。6.4 上下文过长导致 token 爆炸定期压缩历史。我的策略是保留最近 5 次完整记录更早的只保留摘要。摘要用规则生成比如“第 3 次调用 move_to 成功第 4 次调用 speak 成功”。6.5 排查速查表现象可能原因排查方向工具名不存在prompt 描述不清检查工具列表格式参数类型错误模型输出不稳定加类型约束和错误反馈延迟高模型推理慢异步 预测执行token 超限历史未压缩检查上下文组装逻辑死循环无终止条件加预算和错误计数7. 放权的边界哪些决策可以交给 agent哪些必须留在引擎放权不是全放。我的原则是影响游戏核心规则和玩家公平性的决策必须留在引擎影响表现层和叙事层的决策可以逐步下放。比如伤害计算、碰撞检测、资源结算这些必须由引擎确定性执行。而 NPC 的对话选择、情绪表达、非关键路径的移动可以交给 agent。这样既保证了游戏的确定性底线又让 agent 有了发挥空间。我现在的项目里agent 负责的是“氛围层”——让 NPC 看起来有性格、有记忆、有反应。核心玩法逻辑还是引擎说了算。这个边界我调了很久目前是比较稳的状态。最后分享一个小技巧给 agent 加一个“观察者模式”。在不影响实际游戏的情况下让 agent 在后台对同一场景做决策把它的决策和引擎的实际决策做对比。这样你可以持续评估 agent 的决策质量而不需要真的让它上线。这个模式帮我发现了不少 prompt 里的问题。