HyperAIHyperAI

Command Palette

Search for a command to run...

16 小时前
Agent
基准

模型还是框架?一种以交互为中心的智能体故障定位分类法

Harsh Raj Vipul Gupta Anas Mahmoud Razvan-Gabriel Dumitru Darvin Yi Aakash Sabharwal Yunzhong He

摘要

现有评估通常将智能体故障简化为系统层面的结果,掩盖了故障的起源位置以及哪种干预措施能真正改进智能体系统的下一次迭代。这带来了一个修复指派问题:同一个可见故障,根据其起源的不同,可能需要模型后训练、框架工程、环境重新设计或基准修复。由于智能体的行为源于其模型、框架、用户、工具、记忆和环境之间的交互,仅凭结果层面的标签往往不足以提升智能体性能。大多数故障分类法对此问题帮助有限,因为它们通常与特定基准绑定,虽能捕捉有用的细粒度故障模式,却缺乏共享的结构。我们提出了一种以交互为中心的分类法,将智能体故障定位到其起源的交互中,并识别出负责的组件。我们将组件之间的交互作为分析单元。该分类法通过将每个故障分配给两个组件之间的一条边以及指示修复归属的故障侧,系统化地组织了 41 种故障模式。这使得分类法可直接指导行动:模型侧故障指明后训练的目标,框架侧故障指向脚手架和工具集成修复,而环境或评估器故障则揭示出在用于评判智能体能力之前必须重新设计的评估条件。该架构适用于各类智能体架构,从编码助手到长周期个人助理和多智能体系统。我们通过来自公开基准、模型系统卡、已发表报告和记录的智能体轨迹的工作实例来夯实该分类法,并使用独立的推理智能体作为评判者来评估其操作可复现性。在四个前沿模型中,评判者恢复人类标签的效果远高于随机水平,其中最强的评判者在与人类类别标签对比时达到 Cohen's κ=0.76\kappa = 0.76κ=0.76,表明这些类别捕捉到的是共享结构,而非标注者特定的标注偏好。

一句话总结

Scale AI 的研究者提出一种以交互为核心的分类法,将 agent 故障定位到具体的组件交互上,为组件边和故障侧分配 41 种故障模式以直接指导修复,并在跨架构评估时,独立裁判能恢复人类标签,Cohen’s κ=0.76\kappa = 0.76κ=0.76

核心贡献

  • 以交互为核心的分类法将 agent 故障定位到其产生的组件交互上,并指定故障侧(模型、harness、环境或评分器),使修复目标能直接操作。
  • 该分类法从公开基准、系统卡片和 agent 日志中整理出 41 种故障模式,适用于编码、工具使用和多 agent 架构。
  • 使用四个前沿模型进行的 agent-as-a-judge 实验表明,独立裁判以远高于随机水平的准确度恢复人类故障标签,最强的模型达到 Cohen’s κ = 0.76,表明该分类法捕捉的是共享结构,而非标注者个人偏好。

引言

随着 LLM 部署于长期自主运行的环境中,agent 与用户、工具、记忆和环境交互,形成广泛的故障面,其中相同的症状可能源自不同组件。以往的分类法按结果或内部模块对故障进行分类,但无法确定是哪个组件出问题,将不同原因混为一谈,并将修复引导至系统的错误部分。作者提出一种以交互为核心的 41 种 agent 故障模式分类法,将每种故障定位在两个组件之间的边界上,并将责任归于故障侧,从而支持模型后训练或 harness 工程等有针对性的干预。通过展示独立的推理 agent 能一致地恢复人类分配的标签,他们验证了该分类法,表明这一结构捕捉了一个可复现的故障格局。

方法

作者利用基于组件的框架来建模 agent 系统并对故障进行分类。他们将每个故障表示为一个交互边与一个故障侧配对。交互边标识参与交互的两个组件,故障侧则标识对该故障负责的具体组件。

组件被分为三个族:用户、Harness 和环境。用户族包括所有者、评分器和第三方。Harness 族管理模型上下文、记忆、工具访问,以及与其他模型作为 peer 或 subagent 的交互。环境族包含本地执行环境和外部服务。

为了定位故障,作者使用一种特定记号,将两个组件之间的边与故障侧结合。其写法如下:

COMP1COMP2edgefault: SIDEcomponent at fault\underbrace{\mathrm{COMP}_{1} - \mathrm{COMP}_{2}}_{\text{edge}} \cdot \underbrace{\text{fault: SIDE}}_{\text{component at fault}}edgeCOMP1COMP2component at faultfault: SIDE

例如,在工具与模型的交互中,若模型出故障,则表示为边 TOOL-MODEL,故障侧归于 MODEL。

当多个错误共同导致最终结果时,作者应用根因原则:从观测到的系统级故障开始,反向追溯因果链,找出执行无法恢复的最早故障。后续错误被视为后果,分类标签被赋予这个最早且未恢复的故障所在的交互。

完整分类法采用层次化结构。模型位于根部,向下分为组件族,再细分到具体组件,最后是每个交互边关联的故障模式。

分类法详细列出了每个族的故障模式。对于用户族,故障包括模型侧的指令遵循失败或谄媚,以及所有者侧的指令-评分器不匹配。对于 Harness 族,故障涉及上下文管理(如目标漂移)、记忆操作(如遗漏写入或污染)以及工具使用(如工具幻觉或格式错误参数)。多 agent 交互根据其他模型的角色分类,区分 peer 和 subagent 故障,如委派失败或通信失败。对于环境族,故障包括环境侧的服务失败或过期状态交付,以及模型侧的恢复失败。

作者通过反复审查公开基准和 agent 轨迹中的故障,迭代开发了该分类法。定义稳定后,他们冻结分类法以确保标注一致。他们应用根因原则分配标签,根据现有证据确保每个故障归因到正确的交互边和故障侧。

实验

agent-as-a-judge 实验评估四个前沿模型能否通过重构来自不同来源的证据并分类最早未恢复的故障,来一致地应用该故障分类法。裁判在交互类别上与人类标签的一致性较高,但由于证据异质性和根因归因挑战,完整的故障模式标签一致性有所下降。选择性投票以牺牲覆盖率为代价提高精度,结果表明分类法捕捉了共享结构,使得故障定位可用于区分模型侧、harness 侧和环境侧的故障。

该分类法将 agent 系统建模为一组相互作用的组件,每个组件都有清晰的定义,通过指定两个组件之间的边和故障侧来实现故障定位。这种分解将源自模型、harness、环境或评估设置的故障区分开,使干预能针对正确的组件。所有者指定任务和成功标准,评分器独立评估结果,从而将评估失败与遵循指令的失败分开。上下文是模型在当前交互中可用的信息,而记忆是跨会话持久化的存储,工具组件提供模型动作与观察的双向接口。在多 agent 设置中,peer 角色描述的是两个模型互不支配的交互,而 subagent 角色表示主模型充当编排者。

所有被测裁判在交互类别上与人类标签的一致性均达到较高水平,精确匹配准确率在 0.75 到 0.80 之间。对于更细粒度的故障模式任务,性能下降,准确率在 0.62 到 0.72 之间,因为标签集更大且首先需要正确识别类别。GPT-5.5 在两个任务上均领先,Claude-Opus 模型的类别得分相近,但故障模式准确率变化更大。GPT-5.5 在裁判中达到最高的类别准确率(0.80)和故障模式准确率(0.72)。三个 Claude-Opus 裁判的类别准确率相同(0.75),但故障模式准确率从 0.62(Opus-4.7)到 0.70(Opus-4.6)不等。

Agent 裁判从源材料中预测故障模式标签,可提供或不提供人类分配的交互类别。当提供黄金类别时,Claude Opus 模型的准确率和 F1 明显提高,表明许多故障模式错误源于类别分类错误。GPT-5.5 并未从黄金类别中受益,两种设置下表现相同。对 Claude Opus 模型而言,提供正确的交互类别可使故障模式准确率和 F1 相比从头预测类别和模式有显著提升。GPT-5.5 无论是否提供黄金类别,准确率一致,说明其故障模式错误并非集中在类别阶段。在 Opus 变体中,从黄金类别获得最大准确率提升的是 4.6 和 4.8 版本,而 4.7 提升较小。

在四个裁判中进行选择性投票,显示出覆盖率与精度之间的权衡。要求交互类别一致性更强,将使类别精度从全覆盖时的 0.78 提升到 68% 覆盖率时的 0.96,故障模式精度从 0.70 升至 0.89。然而,召回率下降,且集成在更多样本上弃权,使 F1 分数保持相对稳定。从两名一致裁判增加到三名,将类别精度从 0.78 提升至 0.83,同时保持 90% 覆盖率。全体一致时达到最高的类别精度(0.96)和故障模式精度(0.89),但仅覆盖 68% 的样本。

该评估使用基于组件的分类法,将 agent 系统故障分为交互类别和更细粒度的故障模式。LLM 裁判在交互类别任务上与人类一致性较高,但更细粒度的故障模式任务准确率下降,类别分类错误常常导致下游错误。提供黄金交互类别可提高 Claude 模型的故障模式准确率,但对 GPT-5.5 无效,表明 GPT-5.5 的错误较少集中在类别阶段。裁判间的集成投票揭示了覆盖率与精度的权衡,更严格的一致性要求以牺牲覆盖率为代价获得更高精度。


用 AI 构建 AI

从创意到上线——通过免费 AI 协同编码、开箱即用的环境和最优惠的 GPU 价格,加速您的 AI 开发。

AI 协同编码
开箱即用的 GPU
最优定价

HyperAI Newsletters

订阅我们的最新资讯
我们会在北京时间 每周一的上午九点 向您的邮箱投递本周内的最新更新
邮件发送服务由 MailChimp 提供