先看一张路由表：任务归谁

爱游戏官网讨论多模型协作，从一张最朴素的对照表开始：不是问“哪个模型最强”，而是问“这个任务需要什么能力”。下表里的内容是设计思路，用来说明职责划分，并不是性能对比。

任务 主要负责的模型需要的核心能力 不适合交给它的事
理解“钟楼那个Boss怎么打”大语言模型（LLM） 自然语言理解、意图与实体抽取 凭记忆回答具体版本的数值
找“拿到护腕前要做哪些任务” 知识图谱与图搜索关系、依赖、路径 理解含糊的口语表达
从候选游戏里排出先后 推荐模型 大量行为数据上的排序 解释自己为什么这么排
判断玩家卡在导航还是战斗 玩家模型状态预测、不确定性估计 决定改哪个游戏参数
在允许范围内调整补给或提示 强化学习或规则策略受约束的序列决策 理解玩家的自然语言
开发端寻找异常与复现路径 测试Agent探索状态空间、记录轨迹 判断“这一关好不好玩”

可以看到，每个模型的“不适合”一栏，恰好是别的模型的强项。多模型协作的意思就在这里：用各自擅长的部分，避开各自不擅长的部分，而不是让一个模型去硬撑所有位置。

场景一：同一个玩家一句话，触发三个模型

回到导语里的那句话：“我卡在钟楼了，有没有更轻松的类似游戏。”假设这是一个虚构游戏里的真实场景，看看它怎么被路由。

  1. LLM 拆解问题。它把这句话分成两个子任务：一个是当前游戏里的卡关求助，一个是新游戏推荐；同时抽取实体“钟楼”，并注意到“更轻松”是一个偏好信号，不是硬性条件。这一步的输出是结构化的任务单，而不是最终回答。
  2. 知识图谱回答卡关问题。图谱依据玩家的存档阶段，找到钟楼区域的依赖：需要什么装备，Boss在哪个阶段，哪些前置任务未完成。输出的是带版本与来源的步骤，答案里每一步都能追到节点。
  3. 玩家模型给出状态判断。它根据近期行为估计：这位玩家是不清楚路线，还是打不过Boss。这决定了回答里是给路线提示，还是给战斗建议。
  4. 推荐模型排序替代游戏。候选先按类型、机制、难度筛出，再排序；“更轻松”是权重信号，同时保留少量探索。
  5. LLM 最后组织回答。它把三份结果整理成通顺的文字，但不改动其中的事实，也不新增没有来源的内容。

整个过程里，语言模型出现了两次，一头一尾，中间的判断分别由有据可查的模块给出。这个结构在大模型理解问题、图数据库查找关系的Graph Agent设计里有更细的拆解。

场景二：难度调整，为什么不能让聊天模型直接改

假设玩家模型判断：某位玩家在钟楼第二阶段反复失败，主要原因是资源配置不当。谁来决定“怎么办”？如果让聊天模型直接下结论，它很可能给出一个听起来合理的建议，比如“降低Boss攻击力”。但这个建议既不受游戏规则约束，也无法回滚。

更稳妥的路径是：玩家模型只输出“资源不足”的判断和置信度；策略模块（强化学习或规则）在预先划定的旋钮范围内，比如补给点刷新、提示出现时机，选择一个调整，并附上上下限；调整生效前经过规则检查，对关卡结构的改动还需要可玩性验证，这部分思路可以参考动态难度改变关卡结构时的生成加验证。LLM在这条链路里只负责把结果翻译成玩家能读懂的提示语，不参与决策。

场景三：开发端，测试Agent与规则库联手

再看开发侧。更新之后，测试Agent沿着图谱给出的依赖链去探索钟楼，主动尝试读档、重复操作、切换装备等异常路径，发现“退潮护腕重复发放”。此时需要的不同模型是：Agent负责探索并保存轨迹，规则库或断言负责判断“装备唯一来源”是否被破坏，LLM可以负责把复现步骤整理成一份可读的报告，但报告里的每一步必须对应真实轨迹，而不是“合理推测”。测试结果再回流到图谱与内容团队。这三个场景说明，同一批模型在不同任务里的角色不一样，路由必须由任务的性质决定。

接口契约与失败降级

多模型最容易出问题的地方是缝隙。爱游戏官网对模型之间的接口，设想了这样几条要求。第一，模块之间传的是结构化对象，不是自由文本：意图、实体、玩家阶段、置信度、来源、版本。第二，每个模块必须声明自己的输出格式和不确定性，下游可以拒绝不合格的输入。第三，每个环节都有明确的降级路径。

  • LLM不可用或超时：退回到关键词加图谱的基础检索，回答变朴素，但不出错。
  • 图谱查不到：明确告知“暂无核对过的内容”，不让LLM凭记忆补全。
  • 玩家模型置信度低：回答里同时给出路线与战斗两类提示，而不是押一个。
  • 推荐模型冷启动：退回到内容特征与热度的混合，并提高探索比例。
  • 策略模块越界：规则检查直接驳回，回到不调整。

为什么这些模型不能合并成一个

不同模型的运行特性差别很大，这本身就是拆开的理由。

维度 LLM图谱 推荐模型 测试Agent
延迟要求 对话中，秒级可接受 查询要快 展示前完成 离线，可以很慢
成本 单次调用较贵 查询便宜、构建贵 批量算，摊薄 算力密集
可解释性 较弱，需要外部约束强，路径可追溯 中等，需要额外生成理由 强，有轨迹
更新频率 低，重训成本高 随版本频繁更新随行为持续更新 随每个开发版本运行

更新频率的差别尤其关键。爱游戏官网上讨论的游戏内容按周甚至按天变化，把版本数据“训练”进一个大模型，意味着每次更新都要重训，或者接受它记着过期的东西。把易变的知识放进图谱，稳定的语言能力放在模型里，两边各按自己的节奏更新。这与游戏大模型不能只靠记忆的原因是同一个道理。

单一大模型的三种具体失败

  • 编造版本数据。问“退潮护腕的属性是多少”，它可能给出一个像样的数字，却是旧版本的，或者根本不存在。没有来源和版本字段，玩家无从判断。
  • 排序结果不稳定。让它“推荐五款适合我的游戏”，同一个问题问两次，可能得到不同的名单，理由也不一致。排序需要可复现、可对照的指标，这不是生成模型的强项。
  • 不可控的探索。让聊天模型充当测试员，它倾向于做“合理”的事，而不是主动去试奇怪的操作；即便去试，也没有系统的状态覆盖记录，发现问题后难以稳定复现。

各模型用不同的尺子评估

既然职责不同，评估指标也不能混用。LLM看意图与实体识别的正确率、回答与来源的一致性；图谱看边的覆盖、错边率、版本时效；推荐模型看排序质量、多样性与探索比例；玩家模型看状态预测的校准程度，即它说“七成把握”时，是否真的大约七成成立；策略模块看调整是否在约束内、是否可回滚；测试Agent看发现异常的类型与可复现率。把它们用一个“满意度”混在一起，只会掩盖真正出问题的那一环。

回到起点：爱游戏官网选择多模型协作，并不是因为模型多了显得复杂，而是因为每个任务的失败代价不同。语言模型适合做入口和组织者，而事实、排序、状态和探索，各有更合适的承担者。