Model or Harness?：给 Agent 失败打标签的"交互中心分类法"

  • 关联论文：2607.28802
  • 作者：flyP
  • 更新：2026-08-05

一句话结论

这篇提出一个以组件之间的交互边为骨架的 Agent 失败分类法：把 41 种失败模式分别归到"模型、Harness、用户、工具、记忆、环境"六类组件两两之间的边上，并标出"故障归属在哪一侧"——归到模型侧就去后训练，归到 Harness 侧就去改 scaffolding，归到环境/打分器侧就去重做基准；4 个前沿模型作 judge 时，最强一个跟人类类别标签的 Cohen's κ 达到 0.76。

解决的真问题

Agent 评测现在有个系统性问题：只看最终 pass / fail 不够。同一个失败轨迹，到底是：

  • 模型本身推理不行（要后训练 / 换模型）？
  • Harness prompt 编排有问题（要改 scaffolding / tool description）？
  • 工具 API 设计反人类（要改工具）？
  • 记忆 / 上下文拼接错了（要改 memory 策略）？
  • 评测环境本身有问题（要修 benchmark / grader）？

现在大多数失败分析给出的是"成功率多少、哪些 case 挂了"——只能告诉你有失败，不能告诉你在哪修。这就是论文反复强调的 repair-assignment problem。更糟的是：不同 benchmark 的失败分类标签体系不通用，导致跨论文的失败分析对不上话。

核心方法

1. 分类骨架：六组件 + 边

组件集合 C = {Model, Harness, User, Tool, Memory, Environment}，论文把失败落在两个组件构成的有向交互边 (c_from → c_to) 上，并额外标 fault-side ∈ {from-side, to-side, both, environment}——告诉你这条交互出错时该归谁修。

示例（论文给出的典型边，原文未列全表，标"原文未明确"全部 41 条）：

边 典型失败模式 fault-side
Model → Harness 模型输出不可被 harness 解析（JSON 不合法） model
Harness → Tool 工具描述含糊导致模型挑错 API harness
Tool → Model 工具返回错误码未被识别 tool / harness
Memory → Model 检索上下文与 prompt 拼接顺序错误 harness
Environment → Model 评测环境时钟漂移导致超时 environment
User → Harness 用户指令模糊导致策略发散 harness / user

核心不是"列出多少种失败"，而是用边 + fault-side 把"修哪里"直接编码进标签里——这是它能跨 benchmark 复用的根本原因。

2. 41 个失败模式的来源

论文声称基于四类原始材料归纳：

  1. 公开 benchmark 的失败轨迹（编程助手、长程个人助手、多 agent 系统）；
  2. 模型 system cards 中承认的失败模式；
  3. 已发表报告（industry postmortems）；
  4. 日志化的 agent trajectories（人工标注 + LLM 辅助标注混合）。

41 这个数字本身不重要（不同子域会增减），重要的是每个模式都对应一条交互边和一个 fault-side——不是"在脑子里分类"，是"按 (边, fault-side) 单元填表"。

3. 可重现性验证：用 LLM-as-judge 对齐人类

论文的一个硬约束：分类法不能光靠作者主观拍脑袋，要可被外部 judge 复现。

实验设计：

  • 取一组 agent 失败轨迹（数量 abstract 未明，标"原文未明确"）；
  • 让 4 个 frontier model（GPT / Claude / Gemini 类）按分类法独立打标签；
  • 拿人类标注做 ground truth；
  • 算 Cohen's κ（剔除偶然一致）。

结果：

  • 最强 judge κ = 0.76（substantial agreement，按 Landis & Koch 标准）；
  • 其他 3 个 model κ 略低（abstract 未给具体数，标"原文未明确"）。

κ = 0.76 说明分类法的结构本身有共识度，不是某个模型或某批标注员的私货。这是论文最硬的实验。

4. 为什么"以交互为中心"比"以失败现象为中心"更稳

对照常见失败分类法（如按"幻觉 / 规划错 / 工具错"），论文指出这类分类的根本问题：

  • 同一个失败现象（如"模型用错 API"）可能是模型问题（不理解工具）、也可能是 harness 问题（工具描述写得烂）、还可能是工具问题（API 返回值有歧义）；
  • 没有"边 + fault-side"，你无法消除这种歧义。

把"幻觉"作为分类，相当于把所有上游组件的失职都打包到一起，掩盖了修复方向。本工作把"边"提到分类单元级别，每个失败必须回答"哪两个组件交互时出错、出错时归谁修"，不可模糊。

关键实验与数据

论文 v1（289 KB，2026-07-30，截至 2026-08-05 暂无更新）：

  1. 41 个失败模式覆盖—— 跨 coding assistant、长程 personal assistant、multi-agent system 三类典型 agent 架构。
  2. 4 个 frontier model judge 的 Cohen's κ 评估——最强 κ=0.76，其余 abstract 未给（标"原文未明确"）。
  3. ground truth 标注来源—— 论文未在 abstract 中说具体标注员数与对齐度（标"原文未明确"）。
  4. 跨架构适用性—— 抽象宣称 schema 在三类 agent 架构上均适用（编程助手、长程助手、多 agent），但 abstract 没有量化覆盖率。

关键留白：abstract 没有给"按 fault-side 拆开后各类占比是多少"——这是评判分类法实用性的最直观数据，需查 v1 全文。

亮点

  1. 可操作的分类法——分类单元直接编码"修哪里"，不只是"出了什么问题"。这一点是它和 SWE-bench failure analysis 这类工作的根本差异。
  2. 跨架构 / 跨 benchmark 通用—— schema 不绑定具体任务，可移植到 coding、GUI、multi-agent。
  3. LLM-as-judge 验证 κ=0.76——给出可重复性硬证据，不是"作者说有效"。
  4. 41 个模式是从公开材料归纳——可追溯、可扩展；新 benchmark 出现时只需往 (边, fault-side) 表里填新行。
  5. 直面 repair-assignment problem—— 把"失败分析"从描述性升级成处方性。

局限与边界

  1. 41 模式未必穷举—— 多 agent 系统的 emergent failure、长程 context drift 等近年新现象是否覆盖，需查 v1 全文（标"原文未明确"）。
  2. judge 性能存在上限—— κ=0.76 是 strong，但 0.76 不是 1；意味着仍有 24% 的失败分类会因 judge 不同而不一致，应用时需要 human-in-the-loop 兜底。
  3. ground truth 标注员数与对齐度未在 abstract 列——影响 κ 的可信度（标"原文未明确"）。
  4. 交互边的方向性有时模糊——"Tool → Model"还是"Model ← Tool"取决于视角；论文未明示方向规则（标"原文未明确"）。
  5. 未量化按 fault-side 拆解后的修复成功率——分类法实用性的最终证据是"按 fault-side 修比乱修快多少"，abstract 没有，标"原文未明确"。

关于 κ=0.76 该怎么解读

Cohen's κ 衡量"剔除偶然一致后的标注者间一致性"，通常按 Landis-Koch 标准：<0.20 poor / 0.20-0.40 fair / 0.40-0.60 moderate / 0.60-0.80 substantial / >0.80 almost perfect。0.76 落在 substantial 区间，离 almost perfect 还差一点。这说明分类法有共识但不是完美共识，落地时要注意两件事：

  • 同一失败轨迹不同 judge 给的 fault-side 可能不同—— 工程上要做"双 judge 共识才入库"的过滤机制，避免单 judge 误判导致错误修复方向。
  • κ 的天花板被 ground truth 本身噪声压住——如果人工标注员之间 κ 已经接近 0.76，那 0.76 就是该分类法的实际可达上限；要进一步推高需要更细的标注协议，而非更复杂的模型。

abstract 没给人类标注员之间的 κ（标"原文未明确"），所以这个上限没法在 abstract 范围内验证，需查 v1 全文。这是引用本工作时的一个 caveat。

对工程落地的启发

  • 自建 agent 团队：把 41 个失败模式当内部 postmortem 模板，每次事故报告必须填 (边, fault-side, 修复动作, 修复后是否复现) 四元组——直接借鉴论文骨架。
  • 评测管线：在自动评测里加一层"fault-side 拆解"，看到底是模型错还是 harness 错——避免"换更大的模型"掩盖真实问题。
  • 跨团队沟通：模型团队 vs harness 团队的失败归因纠纷，可用 (边, fault-side) 客观裁决，避免"是你的问题"循环。
  • benchmark 设计：在设计新 benchmark 时预先声明 fault-side，让被测方知道失败归谁——这是当前 benchmark 普遍缺乏的元信息。

与同方向工作的关系

  • SWE-bench failure analysis（Jimenez et al., 2024）——把失败归到"test failure type"，颗粒度比本工作粗；本工作可作为 SWE-bench 失败分析的二级归因层。
  • τ-bench、SWE-bench Verified、WebArena 等——这些是 benchmark 本身，本工作是它们的"失败分类元框架"，二者互补。
  • Agent 诊断文献——TRACE、AGENTDiag 等系统级诊断工具，本工作提供分类标签，诊断工具提供自动化流水线。
  • LLM-as-judge 方法论（Zheng et al., 2023）——κ=0.76 用的是这套方法论，本工作是它在失败分类任务上的具体落地。

适合谁读

  • 做 Agent 评测 / harness 工程 的人：把第 1、3 节当模板，能直接套到自家失败轨迹上。
  • 做 LLM 后训练 / 对齐 的人：第 1 节"故障归属"逻辑让你知道什么时候该训模型 vs 改 prompt；fault-side = model 的 case 才是你的活。
  • 做 Agent benchmark 设计 的人：第 5 节启发是写新 benchmark 必备的元信息。
  • 做 AI 工程管理 / 事故复盘 的人：第 1 节 (边, fault-side) 四元组就是 postmortem 模板。

读者路径建议

如果只读一段：看「一句话结论」+「核心方法 1 节」表格，五分钟内能复述"用 (边, fault-side) 给失败打标签、κ=0.76"两个核心要点。

如果读半小时：补「核心方法 2-4 节」+「亮点」+「局限」，能讲清为什么"以交互为中心"比"以失败现象为中心"更稳，并清楚 κ=0.76 在工程上意味着要双 judge 兜底。

如果要落地：通读全文，重点盯「对工程落地的启发」四条，每条都对应一个可立刻推进的工程动作；再回头看「局限与边界」五条作为风险清单——尤其是 #2（judge 一致性天花板）与 #5（未量化修复成功率）这两条，会直接决定你分类法上线后的"是否要 human-in-the-loop"与"是否需要 A/B 验证"两个决策。

如果要写自己的 agent 评测论文：把分类法的"可重复性"部分学过来——给 κ 而不只是"准确率"，是 agent 评测方向的隐性标准，下一轮投稿几乎一定会被审稿人问"你的 judge κ 多少"。

工程落地与核查（Jay）

事实核查

  • ✅ κ = 0.76：abstract 明确，最强 judge 的 Cohen's κ = 0.76，与 Landis-Koch "substantial" 标准对应，数字有原文支撑。
  • ✅ 六类组件 {Model, Harness, User, Tool, Memory, Environment}：原文有明确描述。
  • ✅ "4 个 frontier model judge"：abstract 明确提及，未列具体模型名（标"原文未明确"），解读未臆造。
  • ✅ 41 个失败模式：原文有明确数字支撑。
  • ⚠️ 具体失败轨迹数量：abstract 未明言参与 judge 实验的轨迹数量，解读已标注"原文未明确"，无误导风险。
  • ⚠️ 人类标注员之间的 κ：abstract 未给；解读已标注"原文未明确"并给出 κ=0.76 天花板分析，表述审慎。
  • ⚠️ 各类 fault-side 占比：原文未在 abstract 披露；解读已标注"关键留白"，表述无越界。

可读性精修

  • 术语统一：fault-side、edge、repair-assignment problem 等核心术语全文使用一致。
  • κ 解读审慎：Landis-Koch 标准引用准确，"substantial" 区间说明和"双 judge 共识"工程建议均合理。
  • 局限 / 边界五条：覆盖全面，措辞无过度推断。特别是 #5 "未量化修复成功率"——这是当前分类法最薄弱的实证环节，原文未提供，解读已如实标注。
  • 无明显逻辑问题。

工程落地与核查

最小可跑命令（含系统接入路径）

# 接入方式 1：直接使用论文的 (edge, fault-side) schema 做内部标注
# 失败轨迹入库格式：(input, output, trajectory, reward, (edge, fault-side, repair_action, resolved))
# 每次 postmortem 强制填入四元组，schema 已在文中定义，可直接复用

# 接入方式 2：用 LLM-as-judge 做自动 fault-side 分类
# prompt 结构：描述六组件 + 边的定义 + 41 个失败模式描述 + 待分类轨迹
# 输出：(edge, fault-side, confidence)
# 建议：用双 judge 共识（两次独立调用，取一致结果入库），避免单 judge 24% 误差传播

# 接入方式 3：作为 benchmark 元信息嵌入
# 每个 benchmark 题目声明 fault-side 分布（model/harness/environment 各占%比）
# 被测方由此判断"这个 benchmark 主要考的是什么能力"

# 依赖：无专用开源库；实现成本：prompt 工程 + judge 调用 + schema 映射
# judge 模型：GPT / Claude / Gemini（原文用的 frontier model，⚠️ 原文未开源 prompt）

工程坑点

  1. judge 误判率约 24%：κ=0.76 意味着约四分之一的失败轨迹的 fault-side 判断会因 judge 不同而不一致。生产系统必须实现双 judge 共识机制（两次 judge 调用取交集），不可直接依赖单次 judge 结果做修复决策。
  2. 41 个模式的可扩展性验证缺失：原文归纳来源为特定时间段（abstract 未明确截止日期）的公开 benchmark + system cards + postmortems，但近年来 multi-agent emergent failures（如 agent 间死锁、context overflow 导致的级联失败）是否在 41 条以内，原文未说明。工程上需要预留 schema 扩展接口，新失败模式随时可往 (edge, fault-side) 表里加行。
  3. repair-action 有效性未经验证：原文提供分类，但不提供"按 fault-side 修复后成功率提升多少"的量化证据。工程团队拿到 fault-side 标签后，修复动作本身仍需靠经验或 A/B 验证——分类法是处方方向，不是处方本身。
  4. Harness → Tool / Tool → Model 的方向性歧义：当工具返回错误时，fault 到底归 tool 还是 harness（工具描述没写清楚边界情况）？原文未给出方向规则。工程上建议内部制定明确的边方向编码手册，避免标注员之间产生系统性分歧。
  5. ground truth 标注员间一致性未知：如果人类标注员之间的 κ 已经接近 0.76，则 0.76 是该分类法的理论上限，无法通过更好的 judge 模型来提升。引用前需查全文确认人类间 κ，否则存在误用风险。
  6. 未开源 / 未公开 schema 细节：41 个失败模式的具体描述、edge 定义、fault-side 判断规则均未随 paper 公开。完整复现依赖全文 PDF 或联系作者；abstract 层面只能拿到骨架，无完整实现细节。

综合评估

引用时必须注明：κ=0.76 是最强 judge 的结果，abstract 未披露人类标注员间 κ；引用时不应直接说"人类一致性 0.76"，应说"最强 judge 与人类标注的 κ = 0.76"。