企业官网建设流程全解析

AI 游戏大战的上半场，最值得关注的其实是工程化问题。过去一年，腾讯、网易、字节跳动等大厂相继把大模型接入游戏研发管线，从 NPC 对话、智能陪玩、剧情生成到 AI 竞技对战，纷纷上线了 Demo 和生产级功能。但外界讨论更多停留在“谁的产品更惊艳”，一线开发者更关心的却是另一件事：这些 AI 游戏功能背后，技术链路到底是怎么搭起来的？上下文怎么管理？结构化输出怎么保证？Agent 决策和游戏引擎如何通信？算力成本和延迟如何平衡？

这篇文章不讨论商业故事，也不做公司对比，只围绕“AI 游戏 Agent 的最小工程闭环”展开。你会看到一个可以复现的实验项目：一个内置大模型驱动的 NPC，能理解玩家自然语言指令，能根据当前游戏状态做出决策，并输出游戏引擎可以执行的 JSON 动作。同时会覆盖模型选型、提示词设计、上下文窗口管理、结构化输出、超时重试、日志评估、多智能体扩展等关键工程环节。读完以后，你可以把这套链路迁移到自己的游戏原型、AI 应用或 Agent 项目中。

1. 先理解 AI 游戏背后的技术主线

1.1 AI 游戏不是“套壳聊天”，而是交互范式的改变

传统游戏里的 NPC 交互，本质上是“选项-响应”模型。玩家在几个固定选项里选择，触发对应脚本，这种设计的可控性强，但代价是真实感有限。AI 游戏的核心变化，是让玩家可以用自然语言直接与游戏世界交互，NPC 不再从固定选项里做选择题，而是根据玩家输入、当前场景、角色性格、游戏规则和历史记忆生成回放，甚至自主决定下一步行动。

举个例子。传统 RPG 里你要找人问路，系统只允许你点击“询问前往森林的路线”，NPC 给出预设回复。AI 版本里，你可以输入“我叫阿远，刚从雾谷过来，想去森林找失踪的商队”，NPC 需要理解地点关系、人物身份、事件背景，结合自身角色设定组织语言，再判断是否触发“带路”“警告危险”“索要好处”等动作。这个链路已经超出传统对话系统，本质上是感知、理解、决策、行动、反馈的 Agent 循环。

1.2 大厂布局比拼的核心不是模型，而是工程系统

腾讯、网易、字节等公司在 AI 游戏上的动作，分开看各有侧重：有的主打高自由度 NPC，有的做 AI 对战机器人，有的把生成式 AI 放进玩家 UGC 工具。综合这些布局，可以提炼出一条共同技术判断：单独靠一个大模型无法直接变成可玩的游戏功能，模型必须被接入游戏引擎、任务系统、行为树、状态机、数据库和监控平台，形成一个可以控制的决策回路。

这也是“上半场”这个时间节点的工程含义。上半场通常意味着技术路线还没定型，大家还在验证“大模型何时适合介入”“哪些玩法交互值得重构”“效果如何评估”。对开发者来说，这段时间最适合做技术储备。现在花时间把 Agent 的游戏接入链路跑通，后面无论切入哪个方向，都能复用底层的工具链和工程经验。

1.3 AI 游戏 Agent 的整体技术栈

从技术角度看，一个可落地的 AI 游戏 Agent 通常包含四个层次：

第一层是感知层，负责把游戏世界状态变成模型能理解的文本或结构化数据，比如玩家坐标、HP/MP、场景天气、可见 NPC 列表、最近的事件日志。

第二层是理解与决策层，通常由大模型完成。模型读取感知数据、角色设定和玩家输入，输出意图、回复以及候选行为。

第三层是执行层，把模型输出映射为游戏引擎动作。这里必须做严格校验，防止模型输出非法动作导致逻辑错误。

第四层是反馈闭环，把执行结果回写历史，更新 NPC 记忆，供下一次决策使用。

这四个层次贯穿整篇文章。后面的所有代码、参数、排查和优化，都是围绕这条链路展开。

1.4 为什么“上半场”特别适合做最小闭环验证

技术路线还没固化时，最忌讳一上来就做复杂系统。比较务实的做法是先搭一个最小闭环：一个文本化游戏场景，一个 NPC，一次 LLM API 调用，一次动作执行，一条日志链路。这个闭环虽然小，但已经把 Agent 游戏运行的主干都打通了。

在 Demo 阶段跑通主干，比追求单个模块的完美更重要。因为整条链路涉及的交互点非常多，提前暴露问题，后续再替换大模型、增加游戏引擎、加入更多 Agent 时，才不会陷入“每个模块都正常，整个系统却跑不通”的困境。

2. 设计 AI 游戏 Agent 的核心架构：从事件到动作的决策回路

2.1 Game Agent 的职责边界

在正式写代码之前，先明确 Game Agent 在游戏系统里的职责。它不是聊天机器人，也不负责渲染和物理碰撞。它的核心职责是三个：

第一个，把游戏状态转换成模型可读的输入。游戏状态可以是结构化的 JSON，例如玩家位置、NPC 特征、场景对象、时间线等。

第二个，根据玩家输入和游戏上下文，生成 NPC 回复和行动意图。这一步不一定非要有一个固定格式，但为了可靠执行，输出必须被约束成结构化 JSON。

第三个，把行动意图翻译成游戏引擎可执行的动作，并处理执行结果。例如“move_to_forest”必须对应一个已被游戏系统注册的动作，如果动作不存在，Agent 需要降级处理或返回错误。

这三项职责决定了 Agent 代码里必须有三个对应模块：状态整理、模型调用、动作校验。常见设计错误是把这三个模块混在同一个函数里，最终导致某个功能变了，另外两个也跟着坏。

2.2 事件驱动的游戏循环

游戏本身是事件驱动的。玩家点击、键盘输入、定时器、碰撞检测，都会产生事件。AI Agent 要嵌入游戏循环，最自然的方式是作为事件处理器之一。

下面是标准的游戏循环时序：

玩家输入 -> 游戏引擎捕获输入事件 -> 事件总线分发事件给 AI Agent -> Agent 组装上下文并调用 LLM -> Agent 校验模型输出，生成动作列表 -> 游戏引擎执行动作 -> 动作结果写回世界状态 -> Agent 更新记忆和上下文

这个设计的价值在于，Agent 不直接拥有游戏对象，而是通过事件与游戏世界通信。后续无论是换成 UE、Unity 还是 Godot，只要事件协议不变，Agent 层就可以保持稳定。

2.3 感知状态的结构设计

为了让模型理解当前局面，感知状态必须完整且简洁。完整指的是模型决策需要的信息都包含进去了，简洁指的是不相关的 UI 渲染数据、日志噪声不要塞进提示词。

一个最小感知状态可以设计为：

{ "scene": "雾谷村口", "time": "傍晚", "weather": "小雨", "npc": { "name": "老猎人阿桑", "role": "村庄守卫", "state": "警惕", "stance": "中立" }, "player": { "name": "阿远", "hp": 80, "level": 3, "items": ["火把", "干粮"], "location": "村口东侧" }, "world_events": [ "商队失踪事件", "树林附近出现异常足迹" ], "history": [ "玩家向阿桑询问过商队去向", "阿桑提示玩家夜晚不要进森林" ] }

这个 JSON 之所以要单独设计，是因为大模型的决策质量高度依赖上下文质量。状态太简单，模型只能泛泛回答；状态太杂，模型可能被无关信息干扰，还会浪费上下文窗口。

2.4 输出协议：模型如何与游戏引擎通信

模型输出不能是一段自由文本，它需要被程序可靠解析。最稳妥的做法是使用 JSON 协议。例如：

{ "reply": "森林里有商队留下的火堆痕迹，但那里最近不太安全。", "mood": "warn", "actions": [ {"type": "give_hint", "target": "player", "data": {"hint_id": "forest_trace_01"}}, {"type": "unlock_dialogue", "target": "forest_entrance", "data": {}} ] }

其中 reply 用于玩家侧文本展示，mood 用于表情动画，actions 是引擎执行指令。动作类型不能由模型自由发明，必须由项目预先注册。模型只负责从可枚举动作集合里挑选，程序层做白名单校验，这是工程上必须守住的安全边界。

3. 环境准备与项目结构

3.1 实验环境建议

学习阶段不需要非常昂贵的显卡，因为推理可以在远端完成，本地只需要运行 Agent 编排逻辑。一个可以运行 Python 3.10+ 的普通开发机即可。如果希望完全本地化部署，至少需要一张显存足够容纳 7B 级别量化模型的显卡，但推理速度、上下文长度和并发能力会明显受限。

需要说明的是，如果你的项目环境无法访问外部模型 API，建议使用本地可部署的开源模型，或者选择你所在公司内部已接入的模型服务。这里给出的代码通过 base_url 和 api_key 两个参数实现模型服务地址的切换，改成本地推理服务同样适用。

3.2 项目目录结构

ai_game_agent/ ├── agent/ │ ├── __init__.py │ ├── llm_client.py # 模型调用封装 │ ├── prompt_builder.py # 提示词组装 │ ├── game_agent.py # Agent 主逻辑 │ ├── action_validator.py # 动作校验器 │ └── memory.py # 记忆和上下文管理 ├── game/ │ ├── __init__.py │ ├── world_state.py # 游戏世界状态 │ ├── event_bus.py # 事件总线 │ └── actions.py # 动作注册表 ├── logs/ │ └── agent.log ├── tests/ │ └── test_agent.py ├── requirements.txt ├── .env.example └── main.py

目录划分的关键原则是 agent 层不依赖具体游戏引擎。动作注册表在 game 模块里，agent 层只调用 action_validator 校验动作，再由 event_bus 通知游戏引擎执行。这样后续接真实引擎时，agent 层几乎不需要改。

3.3 依赖安装

依赖尽量精简。核心只需要 openai SDK 和 python-dotenv，测试阶段用 pytest。启动一个控制台模拟游戏时不需要 FastAPI。

cd ai_game_agent python -m venv .venv source .venv/bin/activate pip install openai python-dotenv pytest

requirements.txt 里可以锁定版本，便于复现：

openai>=1.30.0 python-dotenv>=1.0.0 pytest>=8.0.0

随后在项目根目录创建 .env 文件，写入模型服务访问信息：

MODEL_API_KEY=your-api-key MODEL_BASE_URL=https://your-model-service.example.com/v1 MODEL_NAME=your-model-name

需要强调的是，不要把 .env 提交到 Git，生产环境应使用公司的密钥管理系统或配置中心。

4. 实现一个最小可运行的 AI NPC

4.1 用控制台模拟游戏世界

为了让实验足够纯粹，这一版不引入 Pygame 或 UE。我们先用控制台模拟一个村庄场景，玩家通过命令行输入自然语言指令，NPC 生成回复并执行动作，动作结果直接打印在控制台。这个简化版能验证 Agent 链路是否通，之后再替换成真实引擎。

world_state.py 负责维护世界状态：

import json from dataclasses import dataclass, field, asdict @dataclass class WorldState: scene: str = "雾谷村口" time: str = "傍晚" weather: str = "小雨" player_name: str = "阿远" player_hp: int = 80 player_level: int = 3 player_items: list = field(default_factory=lambda: ["火把", "干粮"]) player_location: str = "村口东侧" events: list = field(default_factory=lambda: ["商队失踪事件", "树林附近出现异常足迹"]) history: list = field(default_factory=list) def to_prompt_json(self) -> str: return json.dumps(asdict(self), ensure_ascii=False, indent=2)

这个类的核心价值是让 Agent 感知世界的方式统一：所有状态都通过 to_prompt_json 序列化为字符串，模型看到的是可读文本，代码里拿到的是结构化对象。

4.2 封装模型调用

llm_client.py 做两件事：拼接 ChatCompletion 请求，解析响应。这里采用 OpenAI SDK，并将输出强制设定为 JSON 格式。如果你的模型服务不支持 response_format，也可以退化为在提示词里要求输出 JSON，然后由代码严格解析并重试。

import json import logging import os from openai import OpenAI logger = logging.getLogger(__name__) class LLMClient: def __init__(self): self.client = OpenAI( api_key=os.getenv("MODEL_API_KEY"), base_url=os.getenv("MODEL_BASE_URL"), ) self.model = os.getenv("MODEL_NAME", "gpt-4o-mini") def chat(self, messages, temperature=0.7, max_tokens=1024): response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=temperature, max_tokens=max_tokens, response_format={"type": "json_object"}, ) content = response.choices[0].message.content try: return json.loads(content) except json.JSONDecodeError: logger.error("模型输出不是合法 JSON: %s", content) raise ValueError("模型输出解析失败")

这里要把两个错误分开考虑：一个是网络或 API 错误，需要在调用层重试；另一个是模型输出不是合法 JSON，应该走返回重试或降级提示，不能盲目重试，否则会浪费 token 且可能反复得到同样错误。

4.3 组装提示词

prompt_builder.py 负责把世界状态、NPC 人设、可用动作列表、历史记忆组装成一个完整对话上下文。提示词设计直接决定输出质量，不要图省事只写“你是游戏 NPC”。

SYSTEM_PROMPT_TEMPLATE = """ 你是一个叫{name}的游戏NPC，身份是{role}。 性格:{personality} 当前场景:{scene} 当前时间:{time} 天气:{weather} 你在决定回应时，必须考虑以下世界事件: {events} 你的历史记忆: {history} 你可以执行的动作集合: {actions} 输出要求: 1. 回复玩家时使用中文，语气符合人设。 2. 输出必须是 JSON 对象，包含 reply、mood、actions 三个字段。 3. 只能从动作集合中选择动作，不要发明动作。 4. 如果当前行为不合适执行动作，actions 可以返回空数组。 """ def build_messages(player_input, world_state, memory_items, actions_schema): system_prompt = SYSTEM_PROMPT_TEMPLATE.format( name="老猎人阿桑", role="雾谷村口的守卫，熟悉森林地形", personality="谨慎、沉默，但对陌生人有基本防备心", scene=world_state.scene, time=world_state.time, weather=world_state.weather, events="\\n".join(f"- {e}" for e in world_state.events), history="\\n".join(f"- {h}" for h in memory_items[-10:]), actions=actions_schema, ) messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": player_input}, ] return messages

这里有一个容易忽视的点：history 只取最近 10 条。这不是随手写的数字，而是为了控制上下文长度。游戏对话会随时间增长，如果无限追加历史，最终会超出上下文窗口，还会增加单次请求延迟和费用。

4.4 动作注册与校验

actions.py 定义可执行动作注册表，action_validator.py 负责校验模型输出。严格校验是个非常重要的工程约束，因为大模型可能生成“未注册动作”，如果直接交给游戏引擎执行，轻则功能不正常，重则引发状态污染。

# game/actions.py REGISTERED_ACTIONS = { "give_hint": { "description": "给玩家一个关于特定对象的提示", "params": {"hint_id": "string"} }, "unlock_dialogue": { "description": "解锁某个场景的额外对话", "params": {"target": "string"} }, "set_mood": { "description": "切换 NPC 当前情绪状态", "params": {"emotion": "string"} }, "open_quest": { "description": "给玩家开启一个任务", "params": {"quest_id": "string"} }, } # agent/action_validator.py class ActionValidator: def __init__(self, registered_actions): self.registered_actions = registered_actions def validate(self, actions): if not isinstance(actions, list): return [] valid_actions = [] for action in actions: if not isinstance(action, dict): continue action_type = action.get("type") if action_type not in self.registered_actions: continue schema = self.registered_actions[action_type] params = action.get("data", {}) if self._check_params(schema, params): valid_actions.append(action) return valid_actions def _check_params(self, schema, params): for key, expected_type in schema["params"].items(): if key not in params: return False if expected_type == "string" and not isinstance(params[key], str): return False return True

4.5 Agent 主逻辑

game_agent.py 把前面几个模块串起来，形成完整的决策循环。这里要增加异常处理和重试逻辑。

import logging import time from agent.llm_client import LLMClient from agent.prompt_builder import build_messages from agent.action_validator import ActionValidator from agent.memory import Memory logger = logging.getLogger(__name__) class GameAgent: def __init__(self, world_state, actions_schema): self.llm = LLMClient() self.world_state = world_state self.actions_schema = actions_schema self.validator = ActionValidator(actions_schema) self.memory = Memory(max_len=10) def handle_input(self, player_input): messages = build_messages( player_input, self.world_state, self.memory.to_list(), self.actions_schema ) output = self._call_with_retry(messages) reply = output.get("reply", "") mood = output.get("mood", "neutral") raw_actions = output.get("actions", []) valid_actions = self.validator.validate(raw_actions) # 把本次交互写入记忆 self.memory.add(f"玩家说:{player_input}") self.memory.add(f"NPC回复:{reply}") return { "reply": reply, "mood": mood, "actions": valid_actions, "raw_actions": raw_actions } def _call_with_retry(self, messages, retry=2): last_error = None for attempt in range(retry + 1): try: result = self.llm.chat(messages) if "reply" not in result or "actions" not in result: raise ValueError("输出缺少必要字段") return result except Exception as e: last_error = e logger.warning("模型调用失败，第 %s 次重试: %s", attempt + 1, e) time.sleep(0.5 * (attempt + 1)) raise last_error

4.6 事件总线和入口

如果后续接真实游戏，事件总线会比直接调用更合理。下面给一个简单的 event_bus.py：

class EventBus: def __init__(self): self.handlers = {} def register(self, event_type, handler): self.handlers[event_type] = handler def emit(self, event_type, payload): handler = self.handlers.get(event_type) if handler: handler(payload) else: raise ValueError(f"未注册的事件类型: {event_type}")

main.py 启动控制台循环：

import logging import os from dotenv import load_dotenv from agent.game_agent import GameAgent from game.world_state import WorldState from game.actions import REGISTERED_ACTIONS load_dotenv() logging.basicConfig( level=logging.INFO, format="%(asctime)s | %(levelname)s | %(message)s", handlers=[ logging.StreamHandler(), logging.FileHandler("logs/agent.log", encoding="utf-8") ] ) logger = logging.getLogger(__name__) def main(): world_state = WorldState() agent = GameAgent(world_state, REGISTERED_ACTIONS) print("进入雾谷村口，你遇到了守村人阿桑。输入 exit 退出。") while True: player_input = input("你: ").strip() if player_input.lower() in {"exit", "quit"}: break result = agent.handle_input(player_input) print(f"阿桑: {result['reply']}") print(f"[情绪] {result['mood']}") if result["actions"]: print(f"[执行动作] {result['actions']}") else: print("[执行动作] 无") if __name__ == "__main__": main()

5. 运行验证与输出结果分析

5.1 正常输入流程

启动程序后，输入“你好，你是守村人吗？”。

预期输出类似：

你: 你好，你是守村人吗？ 阿桑: 我是雾谷村的守村人阿桑。你从哪来？这个时间点，村里很少会有外人。 [情绪] neutral [执行动作] 无

这里动作为空是合理的，因为没有触发任何需要改变状态的行为，NPC 只是完成一次寒暄。

再输入“我听说商队在森林里失踪了，你能告诉我什么线索吗？”。

预期输出可能变为：

你: 我听说商队在森林里失踪了，你能告诉我什么线索吗？ 阿桑: 森林深处确实有商队留下的火堆痕迹，但那里最近不太安全。你最好天亮再去。 [情绪] warn [执行动作] [{'type': 'give_hint', 'target': 'player', 'data': {'hint_id': 'forest_trace_01'}}]

这时 Agent 成功完成了从理解、决策到动作映射的完整链路。NPC 不仅回复了文本，还给出了一个引擎可执行的 give_hint 动作。

5.2 非法动作降级测试

为了验证校验逻辑，可以在测试中直接构造一个包含非法动作的输出：

def test_action_validator_rejects_unknown_action(): validator = ActionValidator(REGISTERED_ACTIONS) actions = [ {"type": "give_hint", "target": "player", "data": {"hint_id": "forest_trace_01"}}, {"type": "teleport_to_moon", "target": "player", "data": {}} ] valid = validator.validate(actions) assert len(valid) == 1 assert valid[0]["type"] == "give_hint"

这个测试的价值在于，非法动作不会进入游戏引擎。即使模型产生了幻觉，程序也能正确处理，而不是直接抛出异常。

5.3 日志验证

日志是排查 Agent 问题的第一手段。建议至少把三个信息写入日志：

第一条是请求摘要，记录当前消息数量、token 预估、这次调用使用的模型名。

第二条是模型原文输出。无论输出是否合法，都先记录，方便事后分析模型为什么出错。

第三条是动作校验结果。如果存在非法动作，标记出来，便于判断是指令词问题还是提示词约束不够。

围绕这个需求，可以在 GameAgent 的 handle_input 里加上关键日志：

logger.info("player_input=%s", player_input) logger.info("model_raw_output=%s", output) logger.info("valid_actions=%s, raw_actions=%s", valid_actions, raw_actions)

后续接入生产时，这些日志可以自动汇入链路追踪系统，与玩家 ID、会话 ID 关联。

5.4 常见可观察指标

6. 关键参数与工程细节详解

6.1 模型选择与 temperature 参数

游戏 NPC 的场景分为两类，选择模型时目标不同。

一类是偏角色扮演和情绪表达的对话场景，模型需要有较强的中文能力，回复要自然，此时 temperature 可以设置在 0.7 到 0.9 之间，给模型更多随机性。

另一类是偏规则执行的任务场景，比如副本陪练、AI 裁判、任务引导，需要行为稳定可预测，temperature 应调低到 0.2 左右。

注意 temperature 不是越高越好，过高的 temperature 会让 NPC 在关键任务上偏离规则，产生前后矛盾的行为。

6.2 上下文窗口管理与记忆策略

游戏会话是长对话场景，玩家可能和同一个 NPC 持续交互几十轮。如果每次请求都把完整历史塞给模型，很快就会触及上下文窗口上限。常见策略有三种。

第一种是滑动窗口，只保留最近 N 条对话。特点是实现简单，缺点是过于久远的信息会被完全遗忘，可能导致 NPC 后期忘记早期的重要事件。

第二种是摘要压缩，把旧对话定期让模型生成摘要，再用摘要 + 最近 N 条完整对话构成上下文。特点是记忆容量更大，但每次摘要生成会增加一次模型调用，且摘要本身可能丢失细节。

第三种是结构化记忆库，把关键实体、事件、关系抽离成结构化数据存入数据库或向量库，需要时检索出相关记忆补充进提示词。这是生产环境更推荐的做法，但开发成本较高。

6.3 结构化输出的两种做法

模型输出必须可解析。目前主流做法两种：JSON mode 和提示词约束。

JSON mode 依赖模型服务对 response_format 的本地支持，输出稳定性高，但不是所有模型都支持。提示词约束则要求模型从 instruction 和示例中理解输出格式，稳定性和模型能力高度相关。

这里推荐“JSON mode + 失败重试 + 示例引导”的组合。即便模型服务支持 JSON mode，也建议在 system prompt 里给出一个具体输出示例，大幅减少字段遗漏和类型错误。

输出示例: {"reply": "...", "mood": "neutral", "actions": []}

6.4 超时与重试的取舍

游戏场景对延迟敏感。如果模型调用超时，玩家会明显感受到卡顿。超时时间不能设置太长，一般单次模型调用等待 5 到 10 秒已经是上限。超出后直接告知玩家“NPC 暂时没有回应”，并提供再次尝试入口，比长时间转圈体验更好。

重试策略需要注意“幂等性”。如果第一次调用已经成功但网络超时，重试可能造成重复输出动作。因此在动作执行层要做幂等校验，比如检查 action 的 request_id 是否已经被处理过。

在最小示例里，可以给 LLMClient 增加 timeout 参数：

self.client = OpenAI( api_key=os.getenv("MODEL_API_KEY"), base_url=os.getenv("MODEL_BASE_URL"), timeout=10.0, )

6.5 缓存：减少相同输入的重复调用

同一玩家在短时间内重复输入同一句话，或者不同玩家对同一 NPC 问同一个问题，都可能产生相同的决策结果。此时用缓存可以显著减少模型调用成本。

缓存键可以设计为：

cache_key = hash(model_name + system_prompt + player_input + world_state_version)

缓存过期策略建议按场景区分：普通寒暄缓存 5 分钟，涉及世界状态变化的对话不缓存。注意缓存和记忆系统需要协调，否则可能出现“模型记住了刚才的对话，但玩家看到的是缓存旧回复”的错乱。

7. 常见问题排查

7.1 排查链路总览

AI 游戏 Agent 出现问题时，先不要急着改提示词。按照“输入 -> 状态 -> 模型输出 -> 校验 -> 执行”的顺序排查，效率更高。

7.2 提示词写不好导致的现象

提示词约束不足时，常见表现是模型输出字段名混乱。比如模型可能输出 text，而不是 reply。还有可能把 action type 写成中文描述。这些都属于“格式漂移”。

解决方式不是引入更复杂的正则，而是在 system prompt 里给一个上述的标准输出示例，并且在代码解析失败时把原始输出记录到日志，方便持续观察。

7.3 上下文阻塞问题

当对话超过上下文窗口限制时，不同模型表现不同。有的直接报错，有的忽略超长部分，有的在中间截断。排查时需要关注请求日志里的 token 数是否接近模型上限。如果持续增长，应该尽早引入摘要压缩或滑动窗口。

7.4 动作执行副作用

AI 动作可能改变世界状态，例如给玩家加好感度、开启新任务、切换 NPC 情绪。这些副作用如果重复执行，会导致游戏数据异常。生产环境必须在动作执行层加幂等标识，比如每个动作带有 request_id，数据库唯一索引约束 action_request_id，重复提交直接忽略。

7.5 安全与内容边界

游戏 NPC 是面向玩家的公开内容出口。虽然开发阶段可以用“无违禁词”这类要求做提示词约束，但工程上不能只依赖提示词。生产环境建议增加一道内容审核服务，对模型生成的 reply 和 actions 做异步审核，并把高风险输出标记或拦截。这一层与模型无关，是独立的安全能力。

8. 从 Demo 到生产：扩展方向与最佳实践

8.1 多智能体协作

单 NPC 跑通后，下一步通常是把多个 NPC 接入同一场景。此时 Agent 之间有两种协作模式。

一种是共享世界状态，每个 NPC 独立决策，但读取同一个世界对象。这种模式下要注意并发写冲突，例如两个 NPC 同时尝试修改玩家任务状态。

另一种是 NPC 之间互相通信，比如 A 请求 B 提供线索，再由 A 把线索转达给玩家。这种模式下，Agent 之间需要消息队列和权限控制，复杂度明显提升。

建议生产项目先做共享世界状态模式，把事件总线升级为具备事务能力的消息中间件，再逐步引入 NPC 间通信。

8.2 流式输出与游戏体验

大模型推理是逐步生成 token 的，如果等到全部生成完毕再返回给玩家，等待时间会很长。生产环境建议使用流式输出，让玩家先看到部分文本，避免等待焦虑。

但流式输出与动作执行存在兼容问题。动作必须在最终结果确定后执行，不能边生成边执行，否则可能出现文本已经描述“我打开门”，但动作并没有真正发生。

推荐的做法是：reply 文本走流式展示，actions 在完整 JSON 返回后执行。

8.3 评测体系

AI 游戏功能上线前，必须建立可重复的评测集。评测集包含三类用例：核心任务用例、角色扮演用例、边界安全用例。

每个用例包含输入、预期行为、可接受回复区间、不可触发的动作。使用固定的 temperature=0，跑 N 次，统计通过率。如果通过率下降，要能追溯到是哪次提示词调整或模型版本变更引起的。

一个最小的评测脚本结构：

def run_evaluation(agent, test_cases): passed = 0 for case in test_cases: result = agent.handle_input(case["input"]) check = evaluate(case, result) if check: passed += 1 return passed / len(test_cases)

8.4 生产环境检查清单

8.5 下一步学习路径

如果你是新手，建议按这个顺序继续深入：

先做提示词工程，理解不同模型对格式指令的敏感度。再学函数调用或工具调用，体验模型如何选择工具。然后实现一个简单的多 Agent 对话系统，接触消息传递和并发。最后研究向量数据库和记忆检索，把 NPC 长期记忆做厚。

到了这个阶段，再回头看各家公司发布的技术方案，你会发现核心差异往往不在于模型参数，而在于谁把状态管理、记忆、动作校验、评测这些工程环节打磨得更稳。

AI 游戏的上半场，比的是谁能先把“模型能力”转化为“可控的游戏体验”。这条路上，提示词只是开始，工程化才是真正的分水岭。