先说结论：HarnessEval-W 想解决的不是“再做一张世界模型排行榜”，而是让评测从一组静态指标，升级为一套会理解案例、规划检查路径、调用工具、搜集证据并验证结论的 Agent 系统。最终交付的不只是一项分数，还有一棵可以回看和审计的证据树。
项目已建立站内入口：HarnessEval-W 项目介绍与使用入口。如果想先理解 Agent Harness 的概念，可以配合阅读 DeepSeek Harness 导航页。
一、为什么今天的 Benchmark 也需要 Harness？
传统模型评测常被抽象成“输入—输出—指标”：准备测试集，让模型生成答案，再通过固定指标计算结果。这种方法适合答案边界明确、执行过程简单的任务。但当被测对象变成会读文件、调用工具、执行代码、维护状态并持续行动的 Agent 或世界模型时，最终结果只是整个过程的最后一帧。
一个复杂系统失败，可能来自模型理解错误，也可能来自工具选择、状态丢失、计划顺序、环境观测或评测方法本身。如果所有案例都套用同一套 Rubric，检查项过多会产生噪声，检查项过少又会漏掉真正关键的时序和因果问题。
HarnessEval 的核心判断：评测本身也是需要理解、规划、调查与验证的工作流，因此评测器也应该拥有自己的 Harness。
二、HarnessEval-W 如何完成一次评测？
HarnessEval-W 把每个案例当成独立调查任务，而不是机械跑完所有指标。完整过程可以归纳为四步：
- Plan：先理解案例。读取初始世界、动作、任务类型和评测意图，明确这次真正要检查什么。
- Route：选择适用 Skills。从技能库中启用与当前案例相关的检查，并记录其他技能为什么被跳过。
- Decompose：拆成可验证子问题。把“这个动作是否正确”拆成目标是否存在、变化是否发生、时序是否合理、无关对象是否被改变等问题。
- Verify：审计证据再评分。父级 Agent 检查子智能体返回的证据是否足够、是否真正回答问题，最后才聚合分数。
这种流程的关键，不是用了多少 Agent，而是每一次分工都有明确问题、工具与证据，最终判断可以沿着证据链反向追溯。
三、Evidence Tree：让一个分数说得清“为什么”
普通排行榜只告诉你模型 A 得 80 分、模型 B 得 76 分，却不一定解释差距来自哪里。HarnessEval-W 的案例卡会记录：测了什么、为什么要测、调用了哪个 Skill、使用了什么诊断工具、找到了哪些视觉证据，以及这些证据如何支持最终结论。
这棵 Evidence Tree 同时服务两类用户：
- 研究者：定位失败属于视觉质量、状态转移、物理因果还是长期一致性。
- 模型开发团队：把可复查的失败模式转化为数据构造、训练和系统设计的下一步行动。
四、为什么先拿世界模型做“高压测试”？
世界模型生成的内容不仅要“看起来像”，还要在时间中保持正确。一个视频可能画面精美，却执行了错误动作；可能短期完成变化，却在镜头离开后忘记场景；也可能出现接触关系错误、速度变化不合理、物体凭空增加等问题。
人类很容易注意到这些违和，但自动化指标往往更擅长计算画质、运动流畅度和文本匹配，难以回答“哪个对象在什么时刻发生了什么变化，以及这个变化是否符合因果关系”。这正适合用 Agent 分解问题、调用目标追踪与时序诊断工具，再汇总证据。
五、三大评测轴：不仅看画质，还要看变化与持续性
| 评测维度 | 核心问题 | 典型失败 |
|---|---|---|
| Observation Quality 观测质量 | 画面是否真实、连贯、结构合理 | 闪烁、畸变、不可读、运动不顺 |
| Transition Correctness 转移正确性 | 指定动作是否在正确时间作用于正确对象 | 改错对象、动作延迟、物理反应不合理 |
| World Persistence 世界持续性 | 长时间和离屏状态是否保持一致 | 场景漂移、回访不一致、离屏过程冻结或重置 |
“持续性”并不等于所有东西都静止不变。真正需要保持的是稳定属性；会随时间演化的对象，则要按照动作与因果继续变化。
六、当前公开规模：330 个案例与 5940 条评分轨迹
2026 年 8 月公开版本包含 330 个评测案例，覆盖探索式、意图式与物理状态转移，以及漂移、回访和离屏演化等场景；技能库提供 11 个专业评测 Skills，并对 18 个代表性世界模型完成评测，共形成 5940 条带完整推理轨迹的评分 rollout。
论文报告显示，在最困难的意图式和物理转移场景中，系统判断与人类偏好具有较高一致性。不过，这些数字应理解为特定数据快照和实验配置下的结果，不能直接推导为所有世界模型任务上的普遍性能。
七、它和“更强的 LLM Judge”有什么区别？
仅把 Judge 模型换大，仍可能是在执行固定提问和固定 Rubric。HarnessEval-W 改变的是评测系统的组织方式：
- 案例不同，评测计划与启用的 Skills 可以不同；
- 高层问题会继续拆成可测量子问题；
- 工具负责提供视觉、时序或几何证据；
- 父级 Agent 负责检查证据质量，而不是直接凭整体印象评分；
- 结果同时包含标量分数和可审计的推理结构。
因此，它更像一个“评测调查团队”，而不是单个裁判模型。
八、Living Benchmark：评测系统也要持续生长
模型能力持续变化，固定测试集容易被训练数据覆盖，固定 Rubric 也可能跟不上新任务。HarnessEval-W 把案例、Skills、工具与评测流程都设计为可扩展组件，社区可以补充新的世界、动作、失败模式和专业技能。
但“可扩展”也带来治理问题：新增 Skill 是否公平、不同工具版本是否可复现、路由是否受被测模型信息影响、证据链是否真的足够支持结论，都需要持续审计。项目特别强调路由只依赖案例上下文，避免不同模型面对不同问题。
九、开发者如何开始使用 HarnessEval-W？
项目采用 Apache 2.0 许可证并开放完整评测流程。当前安装主要面向具备 Python、Conda 和命令行经验的研究或工程用户：
- 从站内 HarnessEval-W 导航页进入项目官网与代码入口。
- 按官方说明分别创建主程序、指标后端和物理合理性后端环境。
- 复制环境变量示例，配置模型凭据与本地路径。
- 先运行仓库自带的示例结果，确认环境和指标后端正常。
- 再导入自己的生成视频、Manifest 与评测计划，运行 eval 和 verify。
安全提醒：API Key 应存放在本地环境变量文件中，不要提交到代码仓库；第三方模型输出、数据集和视频还需要核对授权与隐私边界。
十、Harness for Eval 对 AI 行业意味着什么？
如果未来的 AI 系统通过测试时扩展、工具调用和多 Agent 协作获得更强能力，那么评测器也必须投入更多计算进行搜索、诊断和证据验证。Benchmark 的核心资产将不再只有数据与指标，还会包括技能路由、诊断工具、证据结构和可复现的执行环境。
更重要的是，评测决定优化方向。当 AI 逐步进入自动改进闭环，错误或片面的评测会把模型推向错误目标；可信、透明、能暴露自身盲区的评测系统，才可能成为长期迭代的稳定反馈机制。
常见问题
HarnessEval-W 是什么？
它是一套面向世界模型的 Agent 化开源评测系统，会根据案例规划评测、选择 Skills、调用工具并生成可追溯证据树。
它只输出一个排行榜分数吗？
不是。除聚合分数外，它还保存案例级问题、工具证据、子智能体判断和父级验证过程。
HarnessEval-W 能评测普通聊天模型吗？
当前公开实现重点面向交互式世界模型；其 Harness 思路可以启发其他评测任务，但不能直接等同于通用聊天模型 Benchmark。
普通用户能直接在线使用吗？
当前主要是开源研究与工程项目，需要 Python、Conda、模型凭据和命令行环境，托管式提交服务仍以项目后续进展为准。
证据树是否意味着评测一定正确？
不是。证据树提高了可解释性与可审计性，仍需检查工具误差、路由偏差、数据覆盖和人类抽检结果。
