开启Benchmark的Harness时代：15家学术机构联合发布HarnessEval

来源：市场资讯

（来源：机器之心Pro）

8 月 13 日，DeepSeek 开源 Agent Harness dsh，将 “Harness” 这个原本更偏工程语境的概念，推到了整个 AI 行业讨论的中心。

模型之外，为什么还需要 Harness？

答案其实来自 Agent 正在发生的重要变化。

今天一个 Agent 的最终能力，早已不能简单等同于底层模型能力。模型之外还有上下文管理、工具调用、记忆、任务拆解、执行环境、权限管理和结果验证。真正决定一个 Agent 能不能稳定完成复杂任务的，是这些组件能否被组织成一套稳定、可执行的工作流系统。

Harness 描述的，正是这一层能力。

显然，如果只把 Harness 理解为 Coding Agent 一种产品形态，其实严重低估了它的意义。几乎所有复杂智能流程，都需要一个负责规划、协调与验证的系统层。Agent 如此，Evaluation 同样如此。

近日，MirroS 联合清北，Berkeley， MIT，xbench，英伟达等研究机构共同发布 HarnessEval，将 Harness 这一概念进一步带入评测系统。它试图回答一个比 “如何让模型完成任务” 更基础的问题：

HarnessEval 给出的答案，不是增加一组指标，也不是引入一个更大的 Judge 模型。它要为 Evaluation 建立自己的 Harness。

如果说 Agent Harness 负责组织模型如何完成任务，那么 Evaluation Harness 负责组织评测如何形成可信判断：理解案例、规划路径、选择技能、调用工具、搜集证据、验证推理，并让每一个分数都可以被追溯。这也是 HarnessEval 想推动的范式变化：

从 Metric 到 Harness，从静态 benchmark 到可执行的评测系统

01｜当模型成为系统，Evaluation 也必须成为系统

过去，我们习惯把模型看成一个函数：输入 prompt，得到 output，再用一组指标比较结果。这种评测方式适合边界清晰、答案确定的任务。但 Agent 与交互式生成系统不再是一次性的输入输出映射。它们可能读取文件、检索网络、执行代码，在多个工具之间传递状态；可能把一个长期任务拆解为数十个阶段，并根据环境反馈不断修改计划；也可能调度多个 sub-agent，分别负责规划、执行和验证。

这时，评测面对的不只是 “最终答案对不对”，而是一整段动态过程：

传统 benchmark 往往预先定义好一套相对固定的评测流程：一组测试数据、一套固定 rubric、若干指标，以及最终的聚合分数。对于复杂任务，这种方式越来越容易遇到一个根本矛盾：不同案例真正需要检查的问题并不相同。一套统一 Rubric 如果覆盖得足够全面，就会包含大量与当前案例无关的检查；如果为了自动化而不断简化，又容易遗漏真正依赖上下文、时序关系与因果理解的关键判断。

而人的评测实际并不是这样开展的。面对一个复杂案例，我们通常会先理解发生了什么，再决定最值得检查的问题；根据问题定位目标、寻找证据，必要时调用额外工具；如果证据不足，就继续调查，而不是仅凭一眼整体感觉给出一个确定答案。

换句话说，评测本身也是一个需要理解、规划、调查和验证的过程

HarnessEval 的出发点，正是将这种原本隐含在人类专家判断中的过程显式化：把评测拆解成可规划、可调用、可验证的模块，再交给智能体系统执行。

Evaluation 因此不再只是执行一套预先写好的规则，而开始拥有自己的reasoning process

02｜不是更长的 rubric，而是一套评测工作流

HarnessEval 的核心不是用 LLM 替换某个传统指标，而是重构 benchmark 的执行方式。面对每一个测试案例，评测智能体首先理解案例上下文与评测意图，再从可复用的 Skill Library 中选择真正适用的技能。每个高层问题会继续被拆解为可测量的子问题，交给不同的 sub-agent 或诊断工具执行。主智能体检查返回证据是否充分、各项判断是否真正回答了原问题，最后才完成聚合与评分。

整个过程可以概括为四个阶段。

Plan｜先理解案例，再决定测什么： 评测智能体读取初始状态、动作、任务类型和评测目标，生成与当前案例对应的评测计划。

Route｜选择适用技能，而不是跑完所有指标：系统从 Skill Library 中调用适合当前案例的 skill，并记录为什么启用某项检查、为什么跳过另一项检查。

Decompose｜把抽象判断拆成可验证证据：高层问题被拆成目标定位、状态追踪、时序变化、因果顺序、结构保持等子问题，再由专门的 sub-agent 或工具分别处理。

Verify｜先审计证据，再交付分数：主智能体验证各分支的证据质量与逻辑关系。最终输出的不只是一个标量分数，而是一棵完整的 evidence tree。

这棵证据树记录了：测了什么、为什么要测、调用了什么工具、找到了什么证据，以及这些证据如何支持最终结论

因此，HarnessEval 交付的是两层结果：

Benchmark 不再只是一个离线计算器，而成为一套真正运行起来的评测系统。

03｜以世界模型作为 HarnessEval 第一块试验场

HarnessEval 首先落地于交互式世界模型，因为这类模型正是检验 Evaluation Harness 的一块高压试验场：

相比判断一段文本是否正确，评估一个生成世界要困难得多。一段视频可以画面精美，却执行了错误动作；可以完成眼前的变化，却在镜头离开后遗忘整个场景；可以产生看似合理的运动，却违反却违反接触关系、速度变化或因果顺序；甚至可能在没有提示的情况下，凭空增加人物、物体或事件。人类能够自然地定位对象、追踪状态、理解动作意图，并判断世界在时间中是否保持一致。但现有自动化评测往往只能粗粒度地衡量画面质量、运动流畅度或文本匹配度，却很难回答这些真正涉及交互、时序与因果的问题。

针对这些高度依赖上下文、时空证据和具体失败模式的问题，Mirros 开源 HarnessEval-w：从观测质量、状态转移正确性和世界持续性三个维度组织评测，并根据案例动态选择，组合和验证不同 Skill。案例不同，Harness 组织出的评测路径也不同。

Agent 可以根据场景动态选择使用哪些 skills

这里的重点并不是建立一张更长的指标清单，而是把每一个 Skill 都拆解成一系列更容易被验证，被解释的子问题。例如，面对一次指定物体状态变化，系统可能依次检查：目标是否真实存在且清晰可见，变化是否发生在正确对象上，预期状态是否最终成立，关键场景锚点是否保持，以及过程中是否出现了无关变化。面对一次物理碰撞，它则可能调用目标追踪、时间交叠验证、速度估计与因果顺序检查。每个子智能体返回的证据最终由主智能体统一汇总、验证，并形成最终结论。

每一个 skill 都会衍生出来一系列 subagents 来拆解复杂问题，从不同角度衡量模型能力

HarnessEval-W 的最终目标并不仅仅是输出一个数字得分。我们希望最终形成一棵层级式的证据树（evidence tree），完整记录到底测了什么、哪个具体工具提供了视觉证据、以及支撑最终分数的完整逻辑链。有了这条可执行、可追溯、可验证的证据链，研究者不仅能准确定位错误来源，也能据此改进下一阶段的模型设计与训练。

04｜Harness for Eval，意味着什么

HarnessEval-w 不只是一套新的世界模型 benchmark，更代表评测形态的升级：benchmark 的核心资产将从数据与指标，扩展到技能路由、工具调用、证据验证和持续生长的 Skill Library。

模型可以通过 test-time scaling 提升能力，评测器也应投入更多计算，进行更深入的搜索与验证。同时，不同任务需要不同的评测 Skill，通过按需组合专业能力，Eval 才能覆盖代码、搜索、机器人、世界模型等复杂场景。

评测结果也将从单一 score 走向可追溯的 evidence。当系统遇到能力边界之外的问题时，还应主动暴露自身的技能与证据缺口。由此，benchmark 不再是一套固定规则，而成为能够持续扩展和自我完善的 living system。

结语｜通向 RSI，下一代 Eval 不应只是一把尺子

Harness 的走红，意味着行业正在重新认识模型之外的系统价值。但 Harness 时代不只属于 Model，也属于 Eval。

当 AI 逐步走向 RSI（Recursive Self-Improvement，递归式自我改进），评测就不再只是模型之外的一把尺子，而会成为自我改进闭环中的关键反馈。评测关注什么，模型就会朝什么方向优化；评测忽略什么，系统也可能在反复迭代中放大什么。没有可靠的 Eval，RSI 就可能失去方向。

世界模型是 MirroS 选择的第一块试验场，也是迈向 Physical RSI 的重要一步。未来，Eval 不仅要理解上下文、规划评测、组合技能、调度工具和验证证据，还要审视自身、发现能力缺口，并与被评模型共同进化。

这正是 MirroS 联合多家机构发布 HarnessEval 的意义：从 Metric 到 Harness，从固定 rubric 到可执行工作流，从排行榜数字到透明的 evidence tree

让评测不仅衡量智能，也成为推动智能持续进化的系统

Eval 的 Harness 时代，正在开启。