Model or Harness? An Interaction-Centric Taxonomy for Localizing Agent Failures
Harsh Raj, Vipul Gupta, Anas Mahmoud, Razvan-Gabriel Dumitru, Darvin Yi, Aakash Sabharwal, Yunzhong He
cs.AI
2026-07-31
Scale 提出 Agent 失败的交互归因分类,41 种失败模式按组件间的边和责任侧归类,四模型当裁判,与人工最高一致 κ=0.76。
Agent 跑挂了,日志里看到的是一个系统级结果:任务没完成、邮件发错了、代码没跑通。但同一个表象背后,该改的东西可能完全不同:是模型该再训练,是脚手架(工具集成、记忆、上下文管理)该改,是评测环境本身有 bug,还是 benchmark 设计错了。作者把这叫「修复归属问题」:同样的可见失败,根因不同,修法就不同。
既有的失败分类大多是针对单个 benchmark 的细粒度清单,换个系统就对不上。这篇想要一套跨架构共用的结构,而且要可操作,分完类直接告诉你该动哪一块。
作者把 agent 系统拆成一个焦点模型和围绕它的组件,组件归成三个族:
每种失败定位到两个组件之间的一条「边」,再标一个「责任侧」,即这条边上谁的错、就该谁修。模型侧的失败指向后训练目标,脚手架侧的指向工具集成或上下文管理修复,环境或打分器侧的说明评测条件本身要重做。
归因规则是关键:从系统级失败往回追,找到「执行没能恢复的最早那个失败」当根因,后续错误算它的后果。41 种失败模式里,36 种归到模型,5 种归到周围组件。
分类本身基于 40 个真实案例(SWE-bench、ClawsBench、Harbor-Mix、Anthropic 系统卡、GitHub issue、agent 轨迹日志)。一个挺典型的例子:某 agent 误删了 200 多封邮件,根因不在模型「想删」,在上下文压缩丢掉了「别动收件箱」这个约束,属于典型的上下文侧脚手架故障。
可复现性用「agent 当裁判」测:裁判拿到失败源的引用(Docent 或 Face),自己重建证据再分类。四个前沿模型当独立裁判:
| 裁判 | 与人工类别一致 κ |
| GPT-5.5 | 0.76 |
| Claude Opus 4.6 | 0.71 |
| Claude Opus 4.7 | 0.71 |
| Claude Opus 4.8 | 0.70 |
裁判两两之间最高 κ=0.84(Opus 4.6 与 4.8)。要求四票一致时,类别精度升到 0.96,但覆盖率掉到 68%。
对做 agent 的人,这套东西回答的是「挂了之后往哪儿看」,而不是「挂没挂」。责任侧的划分直接映射到该动哪个工具、哪个团队。而且它跨架构:编程助手(Claude Code、Codex)、长期个人助理(读邮件、浏览)、多智能体系统都套得进去。裁判一致性能到 κ=0.76,说明这些类别抓到的是真共享结构,不是某个标注者的私人偏好。
41 种里 36 种归到模型,严重偏模型侧。作者承认这点,但这意味着脚手架和环境侧的失败被低估,而现实中很多 agent 问题恰恰出在工具和环境。40 个案例是精心挑选的,不是失败随机抽样,存在向「清晰、有意思」案例的选择偏差。κ=0.76 是「显著一致」但远不完美,类别级一致性好于细粒度失败模式级。这套东西是定位器不是修复器:它告诉你错在哪条边,不告诉你具体怎么改。最后,「最早未恢复失败」的规则在长轨迹里多个错误交织时会有歧义。