把画面套进 harness 再交给智能体：交互式评测的中间层设计
一、中间层是评测对象的一部分，不是格式转换器
据公开报道，有研究团队做了一个视觉侧的评测 harness，让模型在与环境持续交互的过程中自己摸清规则并完成任务，评测结果因此发生明显变化。这类工作里最值得工程团队拿走的东西，不是那个变化后的结果，而是它把一层平时不被审视的东西挪了位置。
过去做视觉智能体评测，主流做法是先把画面转成文字描述或者结构化表征，再交给被测模型。转换这一步太顺手，顺手到大家把它当成“输入预处理”，写进数据管道，然后就不再管它。可是这一层同时决定了三件事：智能体能看见什么、能改什么、改完能得到什么反馈。观测格式、动作空间、反馈粒度这三项设定的取值，比模型参数量更早决定了评测结论能迁移到哪里。同一个模型，中间层一换，结论可以翻面，而我们常常把它记成“模型变强了”。
洹拓内部现在把这条写成硬规矩：评测报告里必须单列 harness 的三项设定，不许只写模型版本。理由很朴素，读数的人要能判断这个结论是模型的还是夹具的。
二、三条路线各自丢掉什么
把画面送进智能体，只有三条主路。每条路都在丢东西，丢的位置不一样，风险也就不一样。
| 中间层路线 | 保住了什么 | 丢了什么 | 适合什么时候用 |
|---|---|---|---|
| 纯像素输入 | 空间关系、数值精度、瞬时效果、没被预料到的线索 | 样本效率，与语言先验的对接能力，调试可读性 | 任务成败确实取决于看到细节 |
| 转成文字描述 | 便宜、可读、能直接接语言模型 | 空间与数值精度，以及描述者没打算写的那部分 | 画面信息本身就以文字为主 |
| 转成结构化状态 | 最省算力、最稳定、最容易判定 | 一切不在 schema 里的信息，以及设计先验之外的可能性 | 状态口径已被业务确认 |
三条路的丢法有一个共同特点：损失模式由设计者决定，不由任务决定。文字描述的损失最隐蔽，因为描述看着完整，实际是一次有损压缩，压缩规则藏在写提示词的人的直觉里。结构化状态的损失最彻底，因为它把设计者的先验焊死在字段表里，字段之外的世界对被测智能体永久不可见，这时候测出来的更像是“它有没有按我们写的状态转移规则行事”。纯像素保留了全部细节，代价是样本效率低、失败难归因、调试成本全落在人身上。
一个可用的判据：如果一道题的正确解必须用到某个字段之外的信息，而那个字段恰好是我们顺手加上的，那么这道题测的是我们的先验，不是模型的能力。
三、harness 要先定义的六件事
中间层不是“选一个表征”就完事，它是一组接口约定。下面六项要写在环境启动之前，一项含糊，结论就不可解释。
- 观测格式与采样率。每一步给什么，多长一帧，分辨率与裁剪范围多大，观测相对上一次动作延迟多久返回。采样率是最容易被偷偷改掉的一项，改了以后任务难度会变。
- 动作空间与粒度。离散按钮集合还是连续量，参数允许范围，能不能组合动作，一次动作占多少环境时间。粒度的粗细直接决定步数，步数决定探索成本。
- 终止条件。成功怎么算，失败怎么算，超时的步数与墙钟上限各是多少，中途允不允许放弃。终止条件不明确的时候，模型会学会不出手。
- 奖励或判定信号。稠密还是稀疏，给不给部分分，判定权必须在 harness 手里，绝不能由被测模型自述。自述判定等于让考生自己批卷。
- 环境随机性来源与种子控制。哪些环节带随机，能不能外部注入，同一道题重复跑结果的方差多大。没有这一项，多次运行只是在测运气。
- 失败样本的导出方式。导出什么、什么格式、能不能离线复盘、能不能直接进回归库。导出这一项平时没人管，等到要做失败分析才发现只能拿到最后一句回复。
四、可复现的四条与它们的落盘字段
这四条看着像运维细节，实际决定了这套评测能不能当基线用。
- 固定种子，并把随机性注入点逐条写进配置，而不是只有一个总种子。总种子相同但注入顺序不同，跑出来的仍是两个环境。
- 记录环境版本。环境自身更新一版，分数就不可比，而更新往往不带版本号。
- 记录 harness 版本。观测字段、动作集合、判定容差任何一处改动，都要有独立版本标识，改动量要能在报告里对照出来。
- 把动作序列与观测一起存下来。只存观测无法复盘“它当时为什么这么按”，只存动作则看不出输入是否真的相同。
实践中复现失败最常见的原因有三个：环境在无人登记的情况下改了素材或关卡；观测采样率被顺手调低；判定信号的容差被调松过。三件事都不体现在模型版本里，所以版本记录必须覆盖环境与夹具两层。
一条合格的 harness 版本记录至少要有五个字段：夹具标识与版本号、观测字段清单的摘要、动作集合的标识、判定信号的口径与容差、环境构建产物的校验值。字段清单和判定口径之所以要单独列，是因为这两项最容易在“只是修了个小 bug”的名义下改变任务难度。改完之后旧分数与新分数不是同一个量，报告里要写清从哪一版起口径断开，否则历史曲线会被读成能力进步或退步。
五、这套评测在测谁：四条有效性判据
分数好看和结论可信是两件事。判据我们只认四条。
第一条，同一模型换一套 harness，分数变化多大。变化量大，说明测的是表征与任务的匹配度，而不是能力本身。这个变化量要主动测出来并写进报告，不能等别人问。第二条，是不是在测设计者的先验。检查方式是反向的：把正确解所需的信息列出来，逐条问“这条在我的观测里存在吗，是谁决定让它存在的”。第三条，有没有留出一批不对外公开的场景。全部题目公开，评测就会退化成面向题集调参的比赛。第四条，有没有防数据污染的安排。素材与公开语料的重叠要查，题目要按周期更换，必要时掺入带标识的样本，用来识别有没有人直接背答案。
四条里最难的是第一条，因为它要求团队接受“我们的结论对夹具敏感”这个事实，并且愿意为它做一次对照实验。
六、从游戏基准回到业务，要故意保留哪些难看设定
游戏基准和业务环境的落差是结构性的，不是难度级的。真实业务里动作代价高，一次下单、一次对外发消息、一次配置变更都不给重来；反馈延迟且带噪声，结果可能几小时后才回来，而且未必是这一步动作造成的；状态是部分可观测的，我们永远看不到全部；失败不可撤销，错误恢复本身要花钱。
因此把评测搬到业务侧的时候，不要把“难看”的设定当噪声优化掉。稀疏且延迟的判定信号要留着，观测缺失与噪声注入要主动加，不可撤销动作要在环境里真的不可撤销，恢复成本要计入总分。把这些抹平，评测就变成了一个在理想世界里跑得漂亮、在现实里没法用的分数。
内部落地按三步走：
- 给每个要评的业务任务写出观测、动作、判定三元组，写不满三项的任务不许进评测集。
- 建一个最小可交互环境，不追画面逼真，只追状态可判定；同时建失败样本库，失败必须能原样重放。
- 每次改 harness 都重跑基线，把变化量记进版本日志，三元组与版本一起进版本库，交接的时候别人能复现。
这三步走完，我们才敢说一个分数是在描述能力，而不是在描述夹具。