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

机器之心发布 8 月 13 日，DeepSeek 开源 Agent Harness dsh，将 “Harness” 这个原本更偏工程语境的概念，推到了整个 AI 行业讨论的中心。 模型之外，为什么还需要 Harness？ 答案其实来自 Agent 正在发生的重要变化。 今天一个 Agent 的最终能力，早已不能简单等同于底层模型能力。模型之外还有上下文管理、工具调用、记忆、任务拆解、执行环境、权限管理和结果验证。真正决定一个 Agent 能不能稳定完成复杂任务的，是这些组件能否被组织成一套稳定、可执行的工作流系统。 Harness 描述的，正是这一层能力。 显然，如果只把 Harness 理解为 Coding Agent 一种产品形态，其实严重低估了它的意义。几乎所有复杂智能流程，都需要一个负责规划、协调与验证的系统层。Agent 如此，Evaluation 同样如此。 近日， MirroS 联合清北，Berkeley， MIT，xbench，英伟达等研究机构共同发布 HarnessEval ，将 Harness 这一概念进一步带入评测系统。它试图回答一个比 “如何让模型完成任务” 更基础的问题： 如果被评测的 AI 已经从一个模型变成了一套复杂系统，什么样的 Evaluation 才足够有效？ Blog: https://mirros.ai/blog/harnesseval Code: https://github.com/mirros-lab/harnesseval-w Project Page: https://mirros-lab.github.io/HarnessEval-W 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 这里的重点并不是建立一张更长的指标清单，而是把每一个 S