Skip to content

Agent Harness 评测

调研时间：2026-07-28。本文由 AI 辅助生成，经本人核查与修订；文中内容代表本人截至该日期的调研结论与判断。

核心结论

本文把被评测的 Agent system 分为模型、Harness 和可执行环境；Harness 内部再分为 Runtime 与 Knowledge Harness：

\[ A=M\otimes H\otimes E \]
\[ H=R+K \]
  • \(A\)：实际被用户使用和被评测的 Agent system；
  • \(M\)：固定版本、配置和推理预算的模型；
  • \(H\)：Agent Harness；
  • \(R\)：Harness 中可执行的 Runtime；
  • \(K\)：system instructions、skills、领域规则、SOP 和工具说明等 Knowledge Harness；
  • \(E\)：Harness 所操作的可执行环境及其状态。

\(\otimes\) 强调这些部分存在交互，不是可以直接相加的独立能力。

由此得到五个结论。

  1. Agent 能否完成业务任务，最终要测试 \(M\times H\) 的完整配置。 脱离模型的测试可以证明资产、协议或 Runtime 机制正确，不能单独证明业务任务可完成。

  2. Knowledge Harness 可以独立产生评判。 给定权威来源、需求边界和 rubric，可以不运行目标 Agent Runtime，判断 skills、policy 和工具说明是否正确、完整、一致、可执行且可追溯。这个 judgment 评价的是 \(K\) 本身，不是 Agent 能力。

  3. “测试 Skill”或“测试 MCP”必须先拆对象。 Skill 文件与其中的脚本、MCP 协议与 server handler 可以独立测试；发现、匹配、加载、权限和 dispatch 属于它们与目标 Harness 的接入；模型是否选择并正确使用它们属于 model–harness behavior。

  4. 测试方法由想支持的 claim 决定。 测资产质量、接入正确性、受控行为、生产质量、某次 Harness 改动或模型能力上限，需要引入的依赖不同。没有先写清 claim，就没有所谓“公平的 Harness 测试”。

  5. 控制变量实验在前，失败归因在后。 先固定模型、任务、环境、grader 和预算，比较 \(H_0\) 与 \(H_1\)；只有结果发生变化或出现失败时，才使用 trace、deterministic replay 和 intervention 诊断原因。

“整体优先”不等于所有检查都跑昂贵的端到端评测。它的含义是：先定义完整系统应该产生什么 outcome，再为快速反馈和诊断向下拆层。

Harness 边界

Agent Harness 是把模型变成可行动 Agent 的系统层，通常同时包含 Runtime，以及由 Runtime 发现和装载的 instructions、skills、工具接口与策略。

公开资料对 Harness 边界的措辞并不完全统一，但呈现出相近范围：输入与工具调用编排、context 和状态管理、工具暴露与执行、agent loop 以及错误恢复。这个归纳分别参考了 Anthropic 的 Agent eval 方法、OpenAI 的第三方评测建议和 VS Code 对其 coding harness 的拆解；这些来源用于提取共性，不把任何单一产品实现当作定义。

同行评审研究也提供了相应证据。NeurIPS 2024 的 SWE-agent直接研究了 interface design 对 Agent 行为和表现的影响：为 Agent 设计的 computer interface 改变了它进行代码编辑、仓库导航和测试执行的能力。换言之，工具和交互界面不是模型外部可忽略的包装。

为了后续测试，本文使用下面的工程分解。它用于说明组件层级，不是行业统一标准。

Agent Harness H
├── Knowledge Harness K
│   ├── System instructions 与 skills
│   ├── 领域知识与政策
│   ├── SOP 与流程约束
│   └── 工具说明与领域 guardrail
└── Agent Runtime R
    ├── Context management
    │   └── Instructions/skills 加载、retrieval、memory、history、compaction
    ├── Agent loop
    │   └── 模型调用、tool-call 循环、停止条件、预算、取消、重试
    ├── Tool execution
    │   └── Tool schema、可见性、参数验证、adapter、dispatch、结果回填
    ├── State and recovery
    │   └── Session/workspace state、checkpoint、resume、幂等、并发
    └── Governance and observability
        └── Permission、sandbox、secret、审计 trace、错误分类

规则冲突、内容未加载、tool call 错配、恢复后重复副作用等，是这些组件可能产生的测试现象，不属于 Harness 的定义。

Environment \(E\) 不属于 Harness：它包括实际的 repo、数据库、服务、浏览器及其状态；测试中通常由 sandbox、VM 或 container 提供隔离、重置和资源约束。Tool adapter 属于 Harness，adapter 最终调用的系统属于 Environment。这个边界很重要，因为测试需要分别判断“请求被错误转换”和“外部服务错误执行”。本文把环境基础设施视为评测前提，不讨论沙箱技术本身。

Skill 主要属于 \(K\)，但 MCP server 不能整体塞进一个节点：tool description、schema 和 server instructions 是模型可见的能力说明；Host 侧的连接、发现、筛选、权限和 dispatch 属于 \(R\)；server handler 及其调用的外部系统则是可独立测试的 capability provider。因此，“测试 MCP”必须注明被测对象是协议/server、Host 接入，还是 Agent 的工具使用。

本文使用 Knowledge Harness 指代 Harness 中最常被编辑的领域知识与行为配置。它是便于分析的局部概念，不是完整 Harness，也不是行业统一术语。

评测目标

同一个分数可以支持完全不同的结论。测试前先明确要支持哪类 claim。

Claim 主要实验 必须控制什么 可以得到的结论
Asset 本体质量 Source-grounded review、schema/协议检查、handler 单测 权威来源、义务、rubric 或协议版本 Skill、Knowledge 或 MCP server 本身是否符合标准
Asset 接入或回归 在目标 Host 中配对比较 \(s_0\) 与 \(s_1\) 固定 \(R\)；涉及行为/结果时再固定 \(M,E,D_s\) 和预算 新版本在当前 Harness 中是否改善且无已知回归
产品质量或回归 当前 \(M\times H\) 跑领域任务 Task、Environment、grader、版本、预算、trial 数 当前完整配置在该 suite 上的质量与可靠性
Harness 改动有效 配对比较 \(H_0\) 与 \(H_1\) 固定 \(M,E,D\)、预算和评分；只改 Harness 目标部分 这次 Harness 改动在当前条件下的增量效果
Harness 横向比较 多个 \(H\) 与相同 \(M\) 组合；最好扩展为 \(M\times H\) 矩阵 任务、环境、预算、模型配置、grader、重复次数 哪个 model–harness 配置在共同协议下更好
模型能力 elicitation 为每个模型使用足够强且可信的 Harness 任务和 claim 固定；允许 Harness 针对模型优化并披露预算 该系统在当前 elicitation 下展示出的能力下界

对于横向比较和能力 elicitation，一份面向第三方评测的公开方法建议进一步区分：

  • 若要做 controlled comparison，应固定任务、评分和预算，使用共享 Harness 或预先选定的一组标准 Harness；
  • 若要测试 capability under strong elicitation，应使用能合理引出该系统最佳表现的 Harness、工具和预算；
  • 当表现仍随预算或 Harness 改进而上升时，结果是当前设置下的下界，不是能力上限。

因此“固定一个最简单 Runtime，把它从 Harness 测试中排除”不总是合理。它适合测某次领域配置改动的条件效果，却可能低估完整 Harness 或模型的可用能力。

分层测试

分层标准不是“文件简单、Agent 复杂”，而是一个 claim 需要依赖哪些系统。表中的“运行模型”特指被测 Agent 的模型；L0 使用独立 judge 并不会使它升级为 Agent 行为测试。

层级 被测边界 运行模型 主要问题 典型输出
L0 Asset Skill、Knowledge、MCP server 本体 否 资产、语义、协议和 handler 是否正确 Verdict、缺口、conformance、单测
L1 Integration Asset + 目标 Runtime 否 是否被发现、暴露、检索、加载和正确 dispatch Recall@k、请求快照、事件序列
L2 Behavior \(M\times H\) + 受控工具 是 模型是否选择并正确使用 Skill/tool Trigger、selection、参数、adherence
L3 Outcome \(M\times H\) + 隔离环境 是 完整 Agent 能否可靠完成任务 Outcome、可靠性、成本、trace
L4 Production 真实用户和生产近似流量 是 离线任务外是否仍有效 A/B、监控、人工 review

L0：资产

L0 不运行目标 Agent Runtime，但并不只做 syntax lint。给定权威来源 \(S\)、待覆盖义务 \(O\) 和 rubric \(C\)，Knowledge Harness 可以独立得到判断：

\[ J_K=\operatorname{Eval}(K\mid S,O,C) \]

这个 judgment 可以是一组 verdict，而不必压成总分：

维度 判断内容
Correctness 规则、知识和示例是否有来源支持
Completeness 已声明的义务、输入、例外和输出是否覆盖
Consistency 规则之间是否冲突，优先级是否明确
Actionability trigger、前置条件、停止条件和允许动作是否可执行
Traceability source、version、owner 和更新时间是否可追踪

具体到 Skill，可以独立检查 SKILL.md 格式、引用资源、脚本单测、规则语义和安全边界。使用专家或另一个模型做 source-grounded review，评价主体仍然是 Skill，而不是目标 Agent。

MCP server 也有大量与 Agent 无关的测试：

  • initialization、capability negotiation、tools/list、tools/call、resources 和 prompts 是否符合协议；
  • input/output schema、错误结构和 pagination 是否正确；
  • handler 对已知输入是否返回正确结果；
  • authentication、authorization、side effect、幂等和失败恢复是否符合 server contract。

MCP Conformance已经将 client/server initialization、tool listing 和 tool invocation 做成独立测试框架。这能证明 server 或 client 符合协议，不能证明模型会选中正确工具。

L0 不能证明资产会被目标 Harness 发现、加载和使用。\(O\) 怎样代表业务需求，仍由 Golden Test 研究讨论；这里回答的是在 \(S,O,C\) 已给定后，如何评价资产本身。

L1：接入

一旦 claim 涉及“目标 Harness 看见了什么”，就进入 L1。这里运行真实 Runtime，但用 scripted model、direct client 或固定请求排除模型决策。

Skill 接入可以检查：

  • 安装路径和 scope 是否被发现；
  • name、description 和依赖是否进入可见 catalog；
  • 显式调用能否加载完整正文和引用资源；
  • context budget、同名覆盖和禁用规则是否符合预期。

MCP 接入可以检查：

  • Runtime 能否连接、初始化并获得允许的 tools；
  • tool metadata 是否按 Host 规则进入 context 或检索索引；
  • deferred tool search 是否返回标注的相关工具；
  • 参数、call ID、permission 和 tool result 是否正确 dispatch 与回填。

如果 Host 使用 BM25、dense retrieval 或 reranker，使用带相关性标签的 (query, tool) 数据测 Recall@k、MRR/nDCG、误召回、延迟和 context cost。这测的是该 Host 的 tool discovery，不是 MCP server 本体。ToolRet在 4.3 万个工具上显示，普通信息检索表现不能直接代表工具检索表现，而且 retrieval error 会降低后续任务通过率。

例如要测试“tool result 是否正确回填”，可以让 scripted model 固定发出一个 tool call，受控工具返回固定结果，然后断言 schema exposure、dispatch、call ID、下一轮 context、超时和终止事件。LangGraph、OpenCode 和 Codex 的开源测试都包含这类 Runtime contract 测试；MCP Inspector 和 MCP Conformance 则提供协议侧的 direct client 测试。

L2：行为

只要被测决策是“模型是否应该加载 Skill、选择工具或遵循说明”，就必须运行目标 model–harness 配置。典型测试包括：

  • Skill 对 should-trigger、should-not-trigger、间接表达、信息不全和冲突场景的 activation；
  • 在相似或干扰工具中选择正确工具，并生成正确参数；
  • Skill 加载后是否遵循步骤、边界和输出要求；
  • 是否利用 tool result，而不是忽略结果或自行编造；
  • 高风险动作是否请求确认或被 permission policy 拦截。

这里分别报告 activation precision/recall、false-trigger rate、tool selection、argument accuracy、instruction adherence 和 safety violation。由于模型决策具有随机性，需要重复 trial。

Agent Skills建议用带 should_trigger 标签的正负 prompt 评测 description；这已经是 Host 与模型的触发测试，不是简单的静态关键词检查。Google ADK、LangSmith和 Microsoft Agent Framework也分别提供 tool selection、argument、single-step 或 trajectory 级评测。

判断 L1 还是 L2 的规则是：

  • Host 明确定义了确定性的 lexical/BM25 matcher：matcher 的检索质量属于 L1；
  • Host 把 name/description 交给模型，由模型决定是否加载：trigger accuracy 属于 L2；
  • 静态 keyword coverage 可以作为 L0 诊断信号，但不能替代真实触发率。

以 Codex 的开源实现为例，deferred tool search使用 BM25，因此它可以在 L1 直接测检索排序；Skill catalog则把 name 和 description 放进模型可见列表，由模型依据匹配规则决定是否读取正文，因此实际 trigger 应在 L2 测。源码中另有多种 lexical/BM25 skill selector 的 shadow experiment，但代码明确说明它不改变 model-visible catalog，不能把实验候选算法写成当前触发语义。

Skill 对比与回归

比较两个 Skill 不需要独立方法论。把 Skill 视为 \(K\) 中唯一被替换的变量即可。

“哪个 Skill 一般意义上更好”要分成两部分：

  • L0 可以比较 correctness、completeness、consistency、actionability、traceability 和维护成本；
  • 一旦比较“更容易触发、输出更好或任务成功率更高”，结论就依赖 model、Runtime、任务和预算，不再是无条件的 Skill 排名。

在目标 Harness 中比较 \(s_0\) 与 \(s_1\) 时，固定其他条件：

\[ \Delta_s= P(\mathrm{success}\mid M,R,K[s\leftarrow s_1],E,D_s) - P(\mathrm{success}\mid M,R,K[s\leftarrow s_0],E,D_s) \]

最小 regression slice 包含：

  1. 应触发的直接和间接请求；
  2. 不应触发的相邻请求；
  3. 信息不全、多个 Skill 冲突等边界；
  4. Skill 加载后的关键 outcome 和禁止行为；
  5. 此 Skill 曾经导致的线上或评测失败。

分别比较 no skill、旧版本和新版本，可以回答三个不同问题：Skill 是否有贡献、更新是否有增量、旧能力是否回归。应使用相同的 \(M,R,E,D_s\) 和预算，并对含模型决策的 L2/L3 重复运行。若要声称 Skill 跨 Harness 可移植，则必须增加 Runtime 或 model–harness 矩阵。

低风险文字修订可以只跑 L0 和少量受影响 smoke cases，不必为每个 Skill 建大型独立 benchmark；但没有 paired behavior/outcome 结果时，只能说“静态检查通过”，不能声称“更好”或“没有 regression”。

Anthropic 实践

Anthropic skill-creator公开的不是一个单一分数，而是两套循环：主循环比较 Skill 对任务结果的增量，description optimizer 单独测试触发。前者是缩小到单个 Skill 的 L3 型配对实验，后者是特定 model–Host 上的 L2 行为测试。

映射到本文的分层后，完整形态是：

Skill change
├── L0：格式、引用资源、脚本和规则
├── L1：候选能否被真实 Host 发现并隔离加载
├── L2：description 是否正确触发
└── L3：Skill 是否改善实际任务结果

其中 L1 在公开方法说明中不突出，但公开实现暴露的问题说明它不能省略。

任务增量。 初始流程先与用户确认 2–3 个真实任务 prompt，再对每个任务同时运行两组配置：

  • 新建 Skill：with_skill 对 without_skill；
  • 更新 Skill：新版本对旧版本快照；
  • 两组使用相同 prompt 和输入文件，输出保存在独立目录；
  • 新一轮修改后重跑全部任务和 baseline，而不是只跑曾失败的 case。

执行结果不只看最终回答。Grader读取 transcript 和实际产物，逐条判断 expectation，要求给出证据，还会验证输出中的隐含事实、读取 executor 主动记录的不确定性，并指出“文件存在但内容错误”这类没有区分度的 assertion。能程序化检查的结果优先写脚本，主观质量则交给人工 review。

多次运行后，benchmark.json按配置聚合 expectation pass rate、时间和 token 的 mean、standard deviation、min、max，并计算新版本相对 baseline 的 delta。Analyzer 继续查找聚合值会掩盖的模式，例如两组都总能通过的无效 assertion、高方差 case，以及准确率提升所增加的时间和 token。默认 viewer 让用户同时检查产物、逐条评分和成本；需要更严格比较时，还可以让 comparator 在不知道 A/B 对应哪个版本的情况下先选结果，再由 analyzer 解盲并分析差异。

因此，这套主流程的判断顺序是：

L3 outcome delta
  -> L2 transcript diagnosis
  -> 修改 Skill
  -> 重跑 paired suite

它达到本文 L3 的前提，是任务真的运行于可隔离、可重置的工具环境，并由 artifact 或最终状态判分。若只比较文本回答，或两个 trial 共享会变化的 workspace，它最多是 L2 或较弱的 outcome proxy，不能仅因目录名叫 outputs 就视为 L3。

默认的 2–3 个任务更像快速的 formative eval，不是足以支持发布声明的统计 benchmark。Assertions 在任务启动后、结果返回前起草，可以减少针对已见输出补写标准，但 Skill、测试和 grader 仍可能来自相近模型，存在 correlated bias。正式回归门禁还需要扩充历史失败和任务家族、重复 trial、冻结 grader，并保留未参与迭代的最终测试集。

触发优化。 Description optimizer使用另一套数据和目标：

  • 约 20 条 query，正例和负例各 8–10 条；
  • 正例包含间接表达、少见用法和与其他 Skill 竞争的情况；
  • 负例重点选择共享关键词的 near miss，而不是明显无关问题；
  • 用户先审查 query 与 should_trigger 标签；
  • 按标签分层切成 60% train 与 40% held-out，每条默认运行三次；
  • 最多迭代五轮，只把 train 失败交给改写模型，并按 held-out 正确数选择 description；
  • 报告 precision、recall、accuracy 和逐 query trigger rate。

这个设计有两个重要含义。第一，触发率不是 Skill 的通用属性：脚本要求使用实际会承载该 Skill 的模型，因为决策来自模型看到 name/description 后的行为。第二，这里的 held-out 用于多个候选版本的选择，严格说属于 validation set；若要对最终版本作无偏声明，还需要一份从未参与改写和选优的 final test。

实现风险。 截至本次审计所用 commit，公开 trigger runner 的方法目标值得借鉴，但其分数不能未经校准直接作为门禁：

  • Issue #556报告 runner 把候选写入 .claude/commands/，而 claude -p 中该对象可能没有进入模型可触发的 skills catalog，导致正例长期为零；
  • Issue #1352显示默认并发 worker 在共享目录写入多个同 description、不同 UUID 的候选，某个 worker 即使触发了 Skill，也可能命中另一个 UUID，使观测率近似退化为 \(1/N\)；
  • Issue #1478指出异常会被记为 False。对负例而言，基础设施崩溃因此会被错误计成“正确未触发”。

相关修复在公开快照中仍有未合并 PR。可靠实现应先增加 L1 calibration gate：确认候选 metadata 确实进入模型可见 catalog；每个 trial 使用隔离目录；验证 serial 与 parallel 结果等价；将 timeout、process error 与合法 non-trigger 分开；并用一个已知正例校准 headless runner 与真实交互路径。只有这些检查通过，后面的 L2 precision/recall 和 description optimization 才有意义。

这套实践最值得迁移的不是具体脚本，而是四个原则：用 no skill 或旧版本建立反事实 baseline；把 trigger 与 outcome 分开测；同时检查质量、方差与成本；让人工查看真实产物而不是只接受汇总分数。它的公开缺陷同样说明，L3 是 Skill 价值判断的主层，但 L0/L1 是 L2/L3 结果可信的前置条件。

开源实践

开源 Skills 项目可以按仓库实际承担的责任分成两类，而不是按维护者是不是产品公司分类。GitHub 这样的产品公司也可以维护集合型仓库；关键是项目是否拥有领域真值、运行环境和 Skill 的发布责任。下面是截至 2026 年 7 月 28 日对公开仓库、CI 和 PR 的抽样审计。

产品配套型项目先有产品或开发工具，Skills 是其产品知识和工作流的交付形式：

  • Anthropic Skills公开了一套详细的作者评测工作流，但这不等于仓库中每个 Skill 都受同一套 CI 门禁；其设计和当前实现边界见上一节。
  • NVIDIA Skills由各产品仓库维护再同步到 catalog，公开发布门槛包含 eval dataset、BENCHMARK.md、skill card 和签名。其单 Skill 数据包含显式触发、隐式触发和负例；示例报告同时报告多个 Agent 上相对 no-skill baseline 的 security、correctness、discoverability、effectiveness 和 efficiency。PR #340则记录了一个 router Skill 因重复内容和隐式调用安全边界被 gate 拦截、修订后重跑评测的过程。这比“仓库里有 evals.json”更强，但报告中的任务数、单任务重复次数和 grader 可靠性仍需逐项审查，不能仅凭 PASS 结论判断无回归。
  • 其他产品型仓库公开门禁的覆盖面不同，更多证据停留在 L0 或资源验证。OpenAI Skills的 quick_validate.py检查 frontmatter、必填字段和命名，skill-creator再建议以真实任务人工迭代；Cloudflare Skills的仓库级 CI 主要是 Semgrep，但个别改动如 PR #83会做独立语义 review、脚本 smoke test 和跨产品副本一致性检查。在本次公开快照中，没有发现这两个仓库对所有 Skill 统一执行 old/new/no-skill 的行为回归门禁；这只能说明“没有公开证据”，不能推断其内部没有评测。

集合与分发型项目拥有的是 catalog 或安装链路，通常没有每个 Skill 的领域 oracle：

  • Vercel skills CLI有大量测试，但覆盖的是 source parsing、安装、symlink、lock、update 和不同 Agent 的目录兼容性；其 CI甚至忽略 Markdown-only 变更。这些是分发工具的正确测试，不是 Skill 行为评测。
  • GitHub awesome-copilot虽由产品公司维护，仓库职责仍是社区内容集合。它对变更运行 Vally lint PR gate，本地 validator 还检查 frontmatter、名称、description 和资产大小；这些属于 L0 内容与结构门禁，没有运行目标任务来证明 L2/L3 效果。
  • VoltAgent awesome-agent-skills明确只收录外部链接，准入依据是公开仓库、文档、社区使用和人工 review。它可以评价条目是否适合进入目录，却不拥有被链接 Skill 的代码、环境和行为回归 suite。

因此，产品关联度不是质量标签，而是能否构造高层评测的条件。产品团队通常更容易提供领域真值、fixture、sandbox 和历史故障，因此有机会做到 L2/L3；集合型项目更适合验证 provenance、格式、安全、可安装性和跨 Host 接入。实际工程可以组合两派方法：

  1. 对所有 Skill 先执行集合型项目擅长的 L0/L1 门禁；
  2. 对目标 Host 执行正例、近邻负例和冲突 Skill 的 activation 测试；
  3. 对高价值 Skill 由产品 owner 维护 no skill、旧版、新版的 paired outcome suite；
  4. 审查 eval 是否进入 PR gate，并记录模型、Host、重复次数、held-out、环境隔离和 grader，而不是只检查仓库中是否存在测试文件。

L3：结果

真正回答“Harness 能否支撑领域任务”的是 L3。一个任务至少需要：

User goal
Initial state
Policy / knowledge exposed through the production path
Tools and their state-changing behavior
Outcome grader and forbidden-state checks
Turn / token / time / cost budget

每个 trial 必须从隔离且可重置的环境开始。评分优先检查最终状态和安全约束，而不是相信 Agent 的最终文字，也不应把所有正确轨迹限制成唯一 tool-call 序列。

垂直领域公开 benchmark 已经采用了相近结构：

  • \(\tau\)-bench给 Agent 领域 policy 和 API tools，让模拟用户与 Agent 多轮交互，最终比较数据库状态与目标状态；
  • \(\tau\)-Knowledge在金融客服环境中加入非结构化知识库，要求 Agent 组合检索证据、工具结果和业务规则，而不是只回答 RAG 问题；
  • ToolSandbox覆盖 stateful tool execution、工具间隐式状态依赖、on-policy 用户交互，并对任意合法轨迹检查中间和最终 milestone；
  • ACL 2024 的 AppWorld在可控的多应用世界中提供 750 个交互式任务，以环境状态而非固定 action sequence 评价结果；
  • STATE-Bench为每个企业任务提供 task-local sandbox database、领域工具、模拟用户和状态断言；它的 Agent Learning Track 在相同 simulator、tools、judges 和 metrics 下比较 memory、skills 或 prompt optimization。

这些 benchmark 的共同点是：知识检索、工具使用、业务流程和模型决策最终在同一个可执行场景中验收。单独的 retrieval recall 或 policy lint 只能作为诊断信号。

L4：生产

离线 eval 不能覆盖真实用户表达、长期状态、外部服务故障和产品交互。完整质量闭环还需要：

  • Production monitoring 发现真实错误和副作用；
  • A/B test 判断 Harness 改动是否改善真实体验；
  • 人工抽查 transcript 和 outcome，校准自动 grader；
  • 将线上故障转成新的 regression task。

公开的产品评测实践也会把 offline eval 与生产监控、A/B 和人工反馈组合使用，而不是把 benchmark 当成唯一真值，具体可见 Anthropic 的评测方法和 VS Code 的 Harness 实践。

评测方法

本节主要面向包含模型决策的 L2/L3。Skill 或 MCP 的局部 paired eval 使用同样的版本固定、重复运行和 outcome 原则，只把任务集缩小到受影响范围；L0/L1 则优先使用确定性 verdict 和 contract assertion。

版本

一次结果至少绑定以下版本：

model + provider + reasoning/sampling
harness commit + configuration
knowledge/policy/tool versions
task suite + environment image + grader
turn/token/time/cost budgets
trial count

只有这些信息一起固定，结果才可以重跑，也才能判断分数变化来自 Harness 还是评测环境。

重复运行

同一 task 的成功是随机变量。至少分别报告：

指标 回答的问题
Task completion / pass@1 单次尝试成功的平均概率怎样
\(\mathrm{pass}^k\) 同一任务连续 \(k\) 次都成功的可靠性怎样
Failure rate by task family 失败集中在哪类业务或 Harness 压力上
Cost / tokens / latency 取得成功所需资源怎样
Expected cost per successful solve 允许重试时，实际得到一次成功要付出多少
Safety / forbidden action rate 是否存在不能被总成功率掩盖的违规动作

\(\tau\)-bench使用 \(\mathrm{pass}^k\) 表达多次运行的一致性；STATE-Bench对每个任务运行五次，同时报告平均完成率、\(\mathrm{pass}^5\)、UX 和成本。对于每次运行都需要正确完成的任务，可靠性比“多试几次至少成功一次”的 pass@k 更重要。

METR 的 time horizon则展示了另一种聚合方式：用任务的人类完成时间近似难度，再拟合成功概率随难度的变化。它适合异质的软件任务；迁移到其他领域时，可以按状态转移、工具依赖或风险等级分层，但必须先验证所采用的任务难度表示。

结果与轨迹

建议将结果分开报告：

Outcome:
  task completion
  final state
  forbidden side effects

Reliability:
  per-task trials
  pass^k
  confidence / variance

Efficiency:
  turns
  tool calls
  tokens
  latency
  cost

Diagnostics:
  first observable deviation
  tool / context / recovery events

Trace 很适合解释“发生了什么”，但不应因为轨迹与人工预想不同就直接扣分。只有法律、权限、确认、幂等等必需过程约束，才应作为独立 grader。

Harness 比较

只用一个模型比较两个 Harness，得到的是条件效果：

\[ \Delta_H(M)=P(\mathrm{success}\mid M,H_1,E,D)-P(\mathrm{success}\mid M,H_0,E,D) \]

如果希望判断改进能否跨模型成立，应运行一个最小矩阵：

\(H_0\) \(H_1\)
\(M_0\) repeated trials repeated trials
\(M_1\) repeated trials repeated trials

解释方式是：

  • \(H_1\) 在多个模型上都提高结果：支持“这是较稳健的 Harness 改进”；
  • 只在一个模型上提高：存在 model–harness interaction；
  • 两个模型上的 Harness 排名反转：不能再报告独立的“Harness 排名”；
  • 某个 Harness 绑定专有模型，无法填满矩阵：只能做 system-to-system comparison。

横向比较还需要区分两种协议。

协议 做法 支持的 Claim
Normalized comparison 尽量固定模型、context window、reasoning effort、工具访问、MCP、预算和任务 在共同约束下哪个 Harness 更好
Native / optimized comparison 保留每个 Harness 的默认或针对模型优化的行为，完整披露差异 用户实际拿到的系统或 strong elicitation 哪个更好

二者都合理，但不能混成同一排行榜。

Harness-Bench在共同 task environment、budget 和 evaluation protocol 下运行多组 model–harness 配置，同时保留各 Harness 的原生执行行为。GitHub Copilot 的横向评测则固定模型和 benchmark，并尽量统一 context、reasoning effort、tool 和 MCP 设置；每个 agent–model 配置至少重复五次，再同时观察完成率、成本和 run-to-run variance。

Knowledge Harness 的条件效果需要通过控制变量实验估计，不能从完整系统分数中直接扣除 Runtime 的影响。

如果 Harness 是在测试反馈上反复搜索或自动优化出来的，还要增加两项控制：

  1. 搜索、选择和最终报告不能只使用同一组任务，必须保留 held-out task family；
  2. 与 baseline 比较时，要匹配模型调用、反馈次数和推理成本，避免把更多 test-time search 误报成更好的 Harness。

Rethinking the Evaluation of Harness Evolution在匹配反馈和推理预算后发现，自动 Harness evolution 并不稳定优于简单 test-time scaling，且在 held-out tasks 上泛化有限。因此，“候选版本在反复调试过的公开 suite 上涨分”本身不能证明获得了可迁移的 Harness 改进。

失败诊断

失败诊断发生在整体评测之后，用于解释失败或版本差异。

排除评测故障

在归因给 Harness 或 Model 前，先检查：

  • Reference solution 是否能通过 grader；
  • Environment 是否可解、能重置且没有共享状态；
  • Tool 和依赖是否出现基础设施故障；
  • 任务说明是否包含 grader 实际要求；
  • 多个 trial 是否被同一个外部故障关联影响。

否则“Harness failure”可能只是 broken task。

首次偏离

观察 下一步最小测试
资产无法解析，MCP server 不符合协议 L0 schema / conformance test
规则缺失、错误或相互冲突 L0 source-grounded asset judgment
内容存在，但没有进入模型请求 L1 scripted turn + request snapshot
模型给出合法 tool call，但 dispatch 或回填错误 L1 fixed tool call + fake/controlled tool
timeout、resume 后出现重复副作用 L1 fault injection + final-state assertion
内容已送达，但 Skill 未触发或工具选错 L2 activation / selection eval
受控行为通过，但业务 outcome 仍失败 L3 repeated trials，检查状态与环境交互
Agent 实际完成任务却被判错 Reference solution、outcome 和 grader audit

这里的 trace 只是选择下一项实验的索引。

Who&When也说明不能把 trace 上听起来合理的解释当作根因：其最佳方法定位责任 agent 的准确率为 53.5%，定位 decisive step 只有 14.2%。这是 multi-agent 数据集上的结果，不能直接外推到所有 Harness，但足以否定“让另一个 LLM 读日志即可可靠归因”的假设。

干预

如果普通重放仍不能区分问题，可以对同一失败做最小替换：

  • 注入 gold document，绕过 retrieval；
  • 注入固定合法 action，绕过模型决策；
  • 返回固定 tool result，绕过外部服务；
  • 使用 reference Runtime，绕过当前 loop/dispatch 实现。

一次“救回”只是一条线索。只有相同干预在多个 trial 和同类任务上重复改变 outcome，才支持较强的因果判断。

Causal Agent Replay把这种思路形式化为对 Agent step 做 counterfactual intervention，再向前重跑并比较 outcome distribution。它提供了比静态 trace judge 更强的研究方向，但当前验证主要来自带 planted ground truth 的合成因果模型，因此本文只采用“干预后重复测量”的原则，不把自动因果归因当成已成熟能力。

最终结论也不必强迫为单一 owner。应分开写：

observed failure:
  first deviation and violated contract

conditional effect:
  which replacement changed outcomes, under what model and tasks

repair location:
  where the lowest-risk fix should be implemented

Model 与 Harness 的 interaction 很常见。缺陷发生在哪个边界、谁对结果有因果贡献、工程上改哪里最合算，可能是三个不同答案。

工程流水线

测试层级应该由改动触发，而不是每次都跑全矩阵。

触发 必跑 可延后
Knowledge 或 Skill 变更 L0 asset judgment；相关 L2 trigger/use；关键 L3 paired eval 跨 Harness 矩阵
MCP server 或 tool schema 变更 L0 conformance/handler；L1 Host integration；相关 L2 smoke 完整跨模型矩阵
Context、compaction、adapter、loop 变更 L1 deterministic suite；相关 L2/L3 regression 大型 capability suite
Model 或 reasoning 配置升级 L2 behavior + L3 outcome；关键 \(M\times H\) 矩阵 非关键领域长尾任务
Release candidate L3 风险、reliability、成本和安全门槛 无关研究 benchmark
线上新故障 先复现，再补对应 L0–L3 regression 泛化到未知业务空间

一个最小流水线可以这样运行：

PR
  -> L0 asset judgment / conformance
  -> L1 host integration tests
  -> affected L2 behavior tests
  -> affected L3 outcome tasks
  -> compare candidate vs baseline
  -> merge gate

scheduled / release
  -> broader L2/L3 regression suites
  -> repeated trials
  -> selected model × harness matrix
  -> variance / cost / safety report

production
  -> L4 monitoring + A/B + human review
  -> failures flow back to regression tasks

VS Code 已公开一套相近的实践：涉及 core tool、system prompt 或 Agent 行为的 PR 会被打上 eval assessment 标签；流水线构建该 PR、发布绑定 commit SHA 的 eval agent、运行 benchmark，再把分析链接回写到 PR。这说明 Harness eval 可以成为变更门禁，而不是脱离开发流程的研究项目。

适用边界

这套方法仍不能回答：

  1. 一个测试集在多大程度上代表完整业务空间；
  2. 不兼容的专有 Harness 怎样做到完全公平的横向比较；
  3. 如何用少量 trial 稳定识别很小的改进；
  4. 如何自动判断一个失败的唯一因果 owner；
  5. 离线 sandbox 与真实外部系统之间存在多大 validity gap；
  6. Harness 与模型持续共同升级时，held-out suite 应多大、多久轮换，才能持续抑制 benchmark overfitting。

当前可以做的，是把结论严格限制在可复现配置上：

\[ P(\mathrm{success},\mathrm{safety},\mathrm{cost}\mid M,H,E,D,B) \]

\(D\) 是任务 suite，\(B\) 是资源预算。任何省略这些条件的“Harness 分数”都容易被误读。

参考资料

这些资料的证据角色不同：SWE-agent、AppWorld、ToolSandbox 和 ToolRet 是经过同行评审的研究；MCP、Agent Skills 和各框架文档用于说明公开 contract 与实践，不证明经验规律；2026 年的 Harness-Bench、Harness evolution 和 Causal Agent Replay 仍是预印本；开源代码只用于核验具体实现。

Comments