为什么要区分"谁的错"
做 AI Agent 的人都有过这种体验：Agent 在线上跑着跑着就出错了——调用了错误的 API、幻觉了一段不存在的文档、或者对用户的指令理解偏了。第一反应是"模型能力不够"，但很多时候你换了一个更强的模型，问题依然存在。原因很简单：你看到的错误只是症状，病因可能出在模型的 Harness 上。
Scale AI 最近发了一篇论文，标题很直白——"Model or Harness?"。核心思路是：不要再把 Agent 当一个黑盒子来评估了，而是把它拆成多个组件，把组件之间的交互作为失败分析的基本单位。这和我们在 GSME（Generalized Systematic Methodology for Evaluation）、Schema 约束评估、以及 MemoHarness 记忆框架中反复强调的理念一脉相承——Harness 才是 Agent 能力的倍增器，也是绝大多数线上失败的根本来源。
六个组件，三种角色
论文把一个 Agent 系统拆成六个组件。模型（Model）是核心；Owner 是系统的拥有者和配置者；Grader 负责打分评估；Third Party 是外部服务和数据源。这三个是"角色"。剩下的三个是"基础设施"——Harness 和 Environment。
Harness 内部又分四层：Context（上下文注入）、Memory（记忆存储）、Tool（工具调用）、Model（模型本身的配置和路由）。Environment 分为 External（外部运行环境，比如真实网站和 API）和 Local（本地沙箱环境）。当你画出来，模型在中心，User、Harness、Environment 构成内环，各组件在外环——每条失败就对应两个组件之间的一条边。
Figure 1: 径向交互图——模型为中心，User/Harness/Environment 构成内环，各组件在外环。每条失败对应两个组件间的一条边。
失败 = 交互边 + 责任方
这篇论文最漂亮的抽象在这里：每个失败模式由两个维度唯一确定。第一维度是"交互边"——哪两个组件之间出了问题；第二维度是"责任方"——这条边上，到底是哪边的组件该背锅。
举个例子：Agent 调用了错误的 API 参数。表面看是"模型不会用工具"，但细分析可能是 Tool Harness 没有把参数 schema 写清楚（Harness 的责任），也可能是模型确实不理解 JSON Schema（Model 的责任），还可能是外部 API 的文档本身就过时了（Third Party 的责任）。同一种可见行为，三种完全不同的修复路径。
论文一共梳理了 41 种失败模式，归入三个家族：User 相关的失败（用户指令不清、目标冲突）、Harness 相关的失败（上下文缺失、记忆污染、工具描述不准）、Environment 相关的失败（外部服务宕机、沙箱环境限制）。这 41 种模式覆盖了当前 Agent 系统几乎所有的线上故障类型。
同一种可见的 Agent 失败行为，可能需要模型后训练、Harness 工程改造、或环境重新设计——三者是完全不同的修复路径。混为一谈，就是目前 Agent 行业最大的效率浪费。
κ = 0.76：模型评委的可靠性
分类法的生命力在于可复现。Scale AI 用四个前沿模型作为"评委"，让它们对真实 Agent 交互中的失败进行标注，然后和人类标注者的结果做 Cohen's κ 一致性检验。
最好的评委（GPT-5.5）在分类标签层级达到了 κ = 0.76——这是一个相当高的数字，说明模型评委已经可以比较可靠地把失败归类到正确的家族和子类别。不过在更细粒度的故障模式层级，一致性会下降，这也是预期之中的：越细的分类越依赖对上下文的深入理解。
Figure 2: 四个前沿模型作为评委的 Cohen's κ 热力图——分类层级（左侧）最高达 0.76，故障模式层级（右侧）一致性下降但仍远高于随机。
这个结果有一个很实际的意义：你可以用模型评委来大规模自动标注 Agent 的失败模式，而不需要昂贵的人工标注。对于大规模 Agent 部署来说，这意味着可以建立一个自动化的失败监控和归因系统。
回到 Harness Engineering
这篇文章本质上是 Harness Engineering 方法论的一个理论支柱。我们之前在 GSME 中提出要把评估从"模型能力评估"扩展到"系统级评估"，在 Schema 中提出用结构化约束来消除 Harness 引入的模糊性，在 MemoHarness 中设计了记忆层的标准化接口——这些工作都是在回答同一个问题：如何让 Agent 的非模型部分变得可工程化、可度量、可优化。
Scale AI 的这篇论文给出了更系统的回答：先把系统拆清楚，再把失败归因到正确的组件交互上，然后才能对症下药。模型后训练解决的是 Model 端的问题，Harness Engineering 解决的是 Harness 端的问题，Environment Design 解决的是环境端的问题。混为一谈，就是目前 Agent 行业最大的效率浪费。