爱游戏AI模型研究组问一个游戏AI“它能看到什么”，得到的答案通常是“画面”。这个答案至少漏掉了六七种东西：游戏音效、队友的语音、屏幕上的文字、手指和摇杆的动作、游戏引擎内部的状态，还有当前任务走到了哪一步。这些输入的性质相差很大，有的每秒变化几十次，有的几分钟才变一次；有的几乎不会错，有的必须靠猜；有的天然涉及隐私。把它们混在一起叫“多模态”，等于什么都没说。
这篇文章换一个角度：不讨论它们怎么融合，而是把输入清单本身认真过一遍，回答两个实际问题，模型到底需要多少输入才够，以及多出来的输入什么时候反而是麻烦。
先把输入摊开：七类信号，七种脾气
从工程角度看，游戏大模型可能接入的输入大致有七类。下表只做定性比较，不含任何实测数据。
| 输入 | 能回答什么 | 变化节奏 | 可靠度 | 隐私敏感度 |
|---|---|---|---|---|
| 视频（游戏画面） | 谁在哪里、做什么动作、环境如何 | 连续、高频 | 中，依赖视角与特效 | 低到中 |
| 游戏音效（Audio） | 画面外的威胁、事件提示、方位 | 连续、高频 | 中，易被混音掩盖 | 低 |
| 语音与聊天（ASR） | 队友意图、玩家自己的表达 | 断续、随说话而来 | 中低，受噪声与口音影响 | 高 |
| 屏幕文字（OCR） | 资源数字、任务提示、系统消息 | 低频、随界面更新 | 数字类较高 | 聊天窗口内容较高 |
| 控制输入（手柄、键鼠、触屏） | 玩家此刻在做什么 | 极高频 | 高 | 中 |
| 游戏状态（Game State） | 血量、坐标、冷却等精确数值 | 随游戏而定 | 最高，但取决于游戏是否开放接口 | 低到中 |
| 任务状态（Quest State） | 当前目标、进度、约束 | 低频 | 高 | 低 |
把这张表读一遍，会发现一个反直觉的事实：最难获得的输入往往最可靠。游戏内部状态是最精确的，因为它直接来自游戏本身，不需要“看”和“猜”；但大部分游戏并不对外提供这样的接口，所以模型常常只能退而求其次，从画面里把同样的信息重新读出来。这解释了为什么 OCR 与视觉识别在游戏场景里不是“锦上添花”，而是很多时候不得不用的替代手段。
采样与对齐：每一路输入都活在自己的时钟上
输入种类多了，第一个麻烦不是理解，而是时间。控制输入几乎是实时的，画面按帧刷新，音频按采样块流入，ASR 要等一句话说完才能出结果，OCR 往往只在界面变化时才运行，任务状态可能几分钟才更新一次。它们各有各的时钟。
如果把这些信号直接拼成一段“当前情况描述”，很容易出现时间错位：一句已经说完的话被当成正在发生的事，一个几秒前的画面被配上了此刻的操作。所以在爱游戏的设计思路里，每一路输入进入模型之前，都要带着统一的时间戳，并标注它的延迟特性。模型面对的不是一段描述，而是一条按时间排序的事件流：什么时候、哪一路、发生了什么、有多大把握。如何在更长的时间上使用这条事件流，可以参考长视频游戏推理那一篇的讨论。
Self、Other、World：把输入按“回答谁的问题”重新归类
按信号类型分类是工程视角，按要回答的问题分类则是理解视角。ACL 2026 收录的 GameplayQA 基准围绕 Self（自己）、Other Agents（其他角色）、World（世界）三元结构组织问题，这个划分对输入设计同样有启发：
- Self：玩家自己的状态和意图，主要来自控制输入、资源栏文字、第一人称画面。
- Other Agents：队友、敌人和 NPC 在做什么，主要来自画面、事件音效和队伍语音。
- World：地形、资源、任务目标、时间限制，主要来自任务状态、小地图和环境画面。
同一路输入可能同时服务于多个类别。画面既提供玩家自己的视角，也提供其他角色的动作；语音既可能是玩家的表达，也可能是队友的报点。因此，输入清单的价值在于回答一个检查性问题：模型要判断“队友为什么没有跟上”，手里到底有没有关于队友的证据？如果只有玩家自己的操作和资源，那么它该做的是承认不知道，而不是根据自己的画面去推断别人的想法。
模拟场景：四人合作生存局里，一个“再多一路输入”的诱惑
下面是一个模拟场景。四名玩家在一款合作生存游戏里守一座据点，玩家A开着游戏助手，询问“我们现在是不是撑不住了”。
假设助手能拿到的输入有：A 的画面、A 的控制输入、屏幕上的物资与任务文字。基于这些，它可以说出“A 的物资只剩一点，任务要求再坚守一段时间，A 正在频繁修补墙体”。这个回答有依据，但只覆盖 Self 与部分 World。至于另外三个人是否已经倒下、弹药是否共享，它没有证据。
这时有人提议：把三位队友的画面和语音也都接进来。信息看似更完整了，实际上多了三个问题。其一，成本，四路视频与语音同时处理，比一路重得多；其二，噪声，四个人同时说话，ASR 的错误会成倍增加，而且很难判断某句话指的是谁；其三，也是最关键的，授权，队友并没有同意把自己的画面与语音交给 A 的助手。这类“更多输入”并不是技术上能做就应该做。合理的做法是：只使用 A 自己的输入和游戏内本来就公开的队伍状态，比如队友的血量条、位置标记，这些是所有玩家都能看到的信息。回答也相应变得诚实：“你这边物资偏紧，队伍公开状态显示两位队友血量较低，我看不到他们的具体情况。”
输入越多越好吗？三种代价
从上面的例子可以总结出额外输入的三种代价。
- 噪声代价。每增加一路输入，就增加一路可能出错的信号。多路信号冲突时，模型需要额外的规则去判断谁可信。信号少而准，常常比信号多而杂更有用。
- 算力与延迟代价。游戏辅助的价值取决于能否在玩家下一次决策之前给出信息。输入越多，处理越重，等结果出来时局面可能已经变了。
- 授权与隐私代价。语音、聊天、他人画面、房间环境声都属于敏感数据。技术上能采集，不代表应该采集，更不代表可以上传。
另一方面，输入不足也有代价。缺失控制输入，模型无法确认玩家的意图；缺失任务状态，模型可能把一次合理的撤退判定为失误。所以问题不在于“越多越好”还是“越少越好”，而在于每个输入是否对应一个具体的问题，并且能回答“没有它会怎样”。
按需启用、缺失降级、随时可关
在爱游戏对游戏大模型输入的设计里，有三条比较明确的取向。
第一，按需启用。想让助手回答“该不该撤退”，才需要接入资源、任务与操作；只想做赛后回顾，画面与事件时间线就足够；需要语音助手时，才请求麦克风。各类权限应在用到时申请，而不是一次性要齐。
第二，缺失降级。任何一路输入不可用，模型都应当能给出较低置信度的结论，并说明缺了什么。“没有听到队友语音，所以无法判断他们是否已经沟通过”，比一个自信的错误建议更有价值。
第三，敏感输入由玩家掌握。语音与聊天需要明确授权，能在本地处理的尽量本地处理，需要上传时必须清楚提示，并且随时可关闭。这与多模态游戏模型为什么必须同时听、看、读、理解操作里强调的原则一致：多一路能力，就多一份需要交代的责任。
好的输入清单，是一份写明“我不看什么”的清单
回到最初的问题：游戏大模型到底要看多少东西？答案不是一个数量，而是一份带有理由的清单。每一项输入要写明它回答什么问题、可靠度如何、是否敏感、缺失时怎么办。这份清单越清楚，模型越容易被检查，也越容易被玩家信任。
更进一步，这份清单里最有价值的一栏，往往是“不看什么”：不看队友的私人语音，不看与游戏无关的窗口，不长期保存原始画面。能把边界说清楚的模型，才谈得上被放心地放在玩家身边。
