游戏Agent接口设计陷阱，隐藏答案如何通过回执字段意外泄露

当一个游戏Agent尚未看到迷宫中的宝箱，却准确走向正确房间时，问题未必出在它的视觉理解能力上——更可能是接口设计让答案提前“走漏”了风声。这不是真实测试中的异常现象，而是一个被构造出的典型接入失败案例，它揭示了一个常被忽视的工程细节：在向Agent提供游戏环境反馈时，隐藏状态的隔离边界不能仅依赖于观察函数（observe）的输出内容。

这一问题源于当前主流强化学习框架（如Gymnasium）对observation与info的分离设计。Gymnasium的Env.step()方法明确允许info字段携带“观察中隐藏的变量”（variables that are hidden from observations），用于调试或内部诊断。该机制本身合理，但一旦接入层为方便排障将整个返回对象（含info）序列化并送入大语言模型上下文，原本仅供宿主内部使用的敏感数据便可能成为Agent的解题提示。

作者在个人研究稿中提出的GameEval接口草案，也面临类似挑战。其ActionReceipt.observedEffect与GameEvent.payload均定义为任意JSON结构，虽提升了跨游戏兼容性，却未明确界定“哪些字段可向玩家公开”。例如，在一次wait动作后，回执中若包含observedEffect.hiddenChest: {x: 8, y: 3}，即便画面仅显示一扇关闭的门与走廊，Agent仍能据此直接定位宝箱——后续选择正确路径已无法单独归因于画面推理能力。

这种泄漏并非仅限于显式坐标。即使回执不直接给出位置，写入“距离目标还差三步”或“当前动作更接近目标”，同样构成画面外的连续方向提示。关键不在于禁止此类信息，而在于清晰声明其用途与接入前提：若评测宣称Agent仅凭视觉输入决策，则任何非画面衍生的反馈都应视为额外能力测试项，而非默认可用的“普通排障信息”。

更隐蔽的泄漏路径存在于异步消息链中。例如，一次等待动作的正常回执未含坐标，但下一轮工具调用结果追加“生成宝箱成功”，或玩家报错后系统自动推送“检查房间八号”的恢复建议，都可能间接暴露真值。此时，仅审查单次接口返回已不够用；必须沿最终进入模型的完整消息流回溯，确认每条提示的生成时点是否早于对应信息的合法公开时机。

这引出一个核心原则：不应仅按字段名过滤敏感数据，而应依据事件语义与可见条件动态判断。同一字段可在探索前保密、探索后公开。例如，当玩家已打开房门并在画面中看见宝箱，随后公开事件再发送相同坐标，通常不构成越界；但若在探索前就由系统主动推送，则属违规。简单地对字段名（如hiddenChest）拉黑，既可能误删合法反馈（如探索后的确认信息），也会漏掉改名伪装的提示（如targetOffset或proximityDelta）。

为应对上述风险，作者提出一种更稳健的消息投影策略：在从宿主结果生成玩家消息时，应显式挑选字段，而非“全量展开+黑名单删除”。例如，针对act(wait)回执，推荐仅保留actionId、accepted、endTick等必要状态，而将observedEffect中的隐藏字段留在宿主侧用于规则校验，不参与玩家消息构建。

值得注意的是，部分现有方案试图通过命名规避问题——如将诊断对象命名为oracle或inspectTruth——但若该对象仍被全局注入（如Browser globals like window and document can be used in evaluate），则换名无效。真正的隔离需依赖作用域控制与显式授权，而非语义混淆。

为系统化管理数据流向，作者进一步建议采用“同一回传审查”机制：将observe、receipt、events、errors四类接口的返回统一接入过滤器，进行显式字段投影。其中，仅允许如actionId、accepted、endTick、releaseInputsConfirmed等通用许可字段透传至玩家；其余字段（如observedEffect、诊断payload）保留在宿主端，仅用于断言验证与结果判定。

该设计的关键在于区分两类责任：接口边界负责数据隔离，策略评估负责能力归因。不能因Agent走对了路就反推其必然作弊（它可能猜中），也不能因走错就断定无泄漏（提示可能未被使用）。评测体系需确保：所有进入Agent上下文的信息，均可追溯至其合法可见来源；而宿主持有的隐藏状态，仅用于事后核验，不参与实时决策输入。

目前，GameEval仍处于草案阶段，并非已落地的SDK或行业标准。但其暴露的问题具有普遍性：随着Web游戏评测平台兴起，越来越多研究者尝试将LLM Agent接入真实交互环境，若缺乏对数据流边界的审慎设计，评测结果的可信度将面临根本性质疑。尤其在构建基准测试集（benchmark）时，微小的接口泄漏可能导致整个评估体系失效——因为Agent学到的不是“理解游戏”，而是“解析调试日志”。

未来，理想的接口规范应强制要求开发者声明每条回传字段的可见前提与时效条件，类似权限系统中的“基于属性的访问控制”（ABAC）。例如，某字段可标注为“仅当玩家已进入房间X时可见”，系统在生成消息时自动执行该条件判断。这比静态黑名单更灵活，也更贴近游戏逻辑本身的动态性。

在技术落地层面，第一版接入不必强求统一状态模型，优先实现的是消息投影的最小可行机制：明确哪些字段属于玩家可观测范围，哪些仅用于宿主内部校验。这看似是工程细节，实则是保障AI游戏评测有效性的基石——毕竟，当答案从回执里悄悄溜进上下文，再强大的模型也只是在做一道早已给出选项的选择题。