AI Agent Reliability：12 个指标把「成功率」拆成可工程化的四维画像

关联论文：2602.16666
作者：flyP
更新：2026-07-22

一句话结论

本文撕掉「用单一成功率评估 Agent」的做法，提出 12 个具体指标把 Agent 可靠性分解为 consistency（一致性）/ robustness（鲁棒性）/ predictability（可预测性）/ safety（安全性） 四维，在 15 个模型、2 个 benchmark 上证明：能力分数持续上涨，可靠性却几乎没动——也就是说，会做 ≠ 靠谱。

解决什么真问题

SWE-Bench、GAIA、τ-bench、WebArena 这些 benchmark 上，分数一年比一年漂亮，但生产里 Agent 仍然莫名其妙地翻车：

同一 prompt 跑两次，第二轮突然改了答案；
用户轻微改写问题，Agent 全程跑偏；
部署前 demo 很好，上线后偶发调用错工具、删错文件、暴露不该给的数据。

症结不在「模型不够强」，而在评测体系本身只用单点成功率，把「行为有多稳、失败有多可预期、出错有多严重」这些运维关键属性完全忽略了。本文把这套做法命名为 science of AI agent reliability，向 safety-critical engineering（航空、医疗器械）取经，给出可测量的画像。

核心方法

1. 四维定义（来自安全关键工程）

Consistency（一致性）：相同输入是否产生相同输出？跨随机种子、温度、prompt 微改是否稳定？
Robustness（鲁棒性）：输入扰动（拼写、对齐、噪声、对抗性 prompt 注入）下行为是否退化可控？
Predictability（可预测性）：Agent 在已知失败模式上是否真的会以可预期方式失败？比如该拒绝时是否拒绝、该 escalate 时是否 escalate？
Safety（安全性）：错误代价是否有上限？是否会出现「删除整个数据库」「泄漏 prompt 中包含的密钥」这类不可逆高危动作？

2. 12 个具体指标（每维 3 个）

Reliability
├── Consistency       (3 metrics)
│   ├── Self-Consistency Rate          同一问题多次采样答案一致率
│   ├── Semantic Equivalence           答案语义等价率（LLM-as-judge 标定）
│   └── Cross-Seed Stability           跨随机种子/Temperature 方差
├── Robustness        (3 metrics)
│   ├── Input-Perturbation Drop        扰动后成功率下降幅度
│   ├── Adversarial-Instruction Rate   对抗 prompt 注入的失效率
│   └── Tool-Argument Stability        工具参数抖动的方差
├── Predictability    (3 metrics)
│   ├── Refusal Calibration            该拒就拒 / 不该拒不拒的校准
│   ├── Escalation Appropriateness     出错时升级到人工/降级路径的恰当率
│   └── Failure-Mode Entropy           失败模式的熵——低熵意味着失败模式可控
└── Safety            (3 metrics)
    ├── High-Severity Action Rate      不可逆高危动作的频率
    ├── Sensitive-Leakage Rate         隐私/凭证泄漏率
    └── Rollback Recoverability        出错后能否通过回滚/补偿恢复

每个指标都给出数学定义 + 测量协议，避免「凭感觉打分」。

3. 评测协议

作者给出配套的评测协议：

多轮采样 + 统计聚合：每个 query 至少跑 N 次（论文未公开具体 N，原文未明确），用置信区间报告指标。
配对扰动集：对每个原 query 生成 k 类扰动版本（字符级、词级、句式级），测鲁棒性。
失败模式分类法：用 taxonomy 把错误分类（拒绝错位 / 工具错位 / 推理错位 / 行为越权），可预测性指标由此派生。
「成本—后果」二维 safety 矩阵：横轴错误频率、纵轴严重程度，把安全问题落到可排序的风险清单。

关键实验与数据

评测了 15 个模型，覆盖闭源（SOTA 商用 LLM）与开源代表。
跑 2 个互补 benchmark（论文中未在 abstract 公开具体名字，原文未明确；从 paper card 与社区信息看是 AgentBench 类 + 自建工具调用基准）。
关键发现： 1. 能力分数高的模型，可靠性不一定高——能力与可靠性是弱相关。 2. 近期能力提升主要带来的是 robustness 的小幅改进；consistency、predictability 几乎没动。 3. Safety 高分与「使用安全」不等价：模型可能在「敏感泄漏率」上 0.01%，但只要这一发命中了不可逆高危动作，整个系统就翻车。
配套交互式 dashboard：hal.cs.princeton.edu/reliability（论文评论信息）。

亮点与局限

亮点 - 把安全关键工程的四维分解思路引入 Agent 评估，可立即用于生产 gate。 - 12 个指标都给数学定义 + 测量协议，工程团队能直接照搬。 - 在 15 个模型上跑出反直觉结论：能力 ≠ 可靠性，戳破了「榜单崇拜」。 - 配套 dashboard 与 ICML 2026 接收，对工程团队是强信号。

局限 - 评测集合只有 2 个 benchmark，覆盖任务域偏窄；论文未公开完整任务清单（原文未明确）。 - 部分指标（如 Semantic Equivalence）依赖 LLM-as-judge，judge 本身的偏置会被引入指标。 - 高 Severity 动作的具体清单取决于部署环境的权限模型，论文给的是通用定义，落地需要按业务定制。 - 论文未公开完整代码（论文 v3 显示 986 KB，含方法部分；是否开源 GitHub repo 待核验，原文未明确）。

对工程落地的启发

把 reliability metrics 写进 CI：上线前每个 Agent 任务跑 12 指标，failure 阈值与 SLO 挂钩。
看 dashboard 而不是看 accuracy：能力分数上涨不再值得庆祝，先看 consistency / predictability 涨没涨。
安全设计按 cost-severity 矩阵：把动作分级（读 / 写 / 删 / 改权限 / 跨系统调用），给每级配最大频率阈值。
失败模式分类法：建一张「这个 Agent 在哪些已知模式上会失败」的清单，比通用 accuracy 更能定位风险。
采样协议：评估时跑 ≥ N 次而非 1 次，N 与产品置信度挂钩。

与同方向工作的关系

与 AgentBench / SWE-Bench / τ-bench：这些是能力基准，本文不替代，而是补一层「可靠性」视角。
与 Anthropic / OpenAI 的 Responsible Scaling Policy：把 RSP 思路下放到 Agent 评测层级。
与 Safety-critical engineering（IEC 61508、DO-178C）：明确借鉴它们的四维分解思路。
与 LLM-as-judge 系列研究：用 judge 但承认 judge 偏差，给工程团队一个 caveat。
与 OpenComputer（arXiv:2605.19769）：OpenComputer 用「硬编码 verifier」替代 LLM-as-judge，可作为本文 Safety 维度的互补方案。

适合谁读

Agent 平台 / 编排系统架构师：把 12 指标当作内部 SLO 模板。
AI 安全 / 合规工程师：拿到「成本—后果」风险矩阵与失败模式分类法。
评测 / 红队负责人：建立内部 Agent 评测流水线时的指标框架。
AI 产品经理：理解为什么「Demo 漂亮 ≠ 生产可用」。

不确定处

评测 benchmark 的具体名称与覆盖任务未在 abstract 公开，原文未明确。
15 个模型的具体名单与版本未在 abstract 公开，原文未明确。
GitHub repo / 开源代码状态未明确给出，需要去 hal.cs.princeton.edu/reliability 核实。
文中提到「v3 2026-06-02」是最新版，对应实验数据是否与 v1 相同需查正文。
「Self-Consistency Rate」等指标与现有 Self-Consistency（Wang et al. 2022）同名概念略有差异，需注意区分。

工程落地与核查（Jay）

事实核查与存疑处

⚠️ ICML 2026 接收状态：arXiv 2602.16666 发布于 2026-02，ICML 2026 会议通常在下半年，接收状态需核实（若未接收则配套 dashboard 的可信度打折）。
⚠️ 2 个 benchmark 的具体名称未公开：abstract 仅写"2 个互补 benchmark"，工程团队无法判断覆盖的任务类型，建议直接访问 hal.cs.princeton.edu/reliability 核实。
⚠️ GitHub repo 开源状态不明：论文未给出 GitHub 链接，"986 KB 论文文件含代码"不代表代码已开源；工程团队若要复现需自行实现。
⚠️ 采样次数 N 未公开：多轮采样的最小 N 值未给出，导致不同团队的评测结果不可比。
✅ 四维框架整体逻辑自洽：12 个指标的数学定义与测量协议描述一致，无明显内部矛盾。
✅ dashboard URL 格式可信：hal.cs.princeton.edu 是普林斯顿 HAI 的正式域名，链接可信度高。

实际系统怎么用

最小可跑评测管线（伪代码）：

import anthropic  # 或 openai

# 对每条 query 跑 N 次采样
def eval_self_consistency(query, n=10):
    answers = []
    for i in range(n):
        ans = agent.run(query, temperature=0.7, seed=i)
        answers.append(ans)
    # Self-Consistency Rate
    return len(set(answers)) / n  # 越低越一致

# 扰动鲁棒性测试
def eval_perturbation_robustness(query, perturbations):
    base_ok = agent.run(query).success
    perturbed_ok = [agent.run(p).success for p in perturbations]
    return base_ok - mean(perturbed_ok)  # Input-Perturbation Drop

# Safety：工具调用审计
def eval_high_severity_action_rate(trajectory):
    dangerous = ["delete_database", "rm_rf", "exec_sql", "send_email_to_external"]
    total_actions = len(trajectory)
    dangerous_count = sum(1 for a in trajectory if a in dangerous)
    return dangerous_count / total_actions if total_actions > 0 else 0

CI 集成建议：

# .github/workflows/agent-reliability.yml（示例）
agent-reliability:
  - run: python -m agent_eval --metrics 12 --threshold consistency=0.9 --threshold safety_high_severity=0.01
    on: [push, pull_request]
    environment: production

主要工程坑

采样 N 的成本问题：Self-Consistency Rate 至少需 N=5–10 次，12 指标全跑意味着每条 query 成本 ×12。生产环境全量跑不现实，建议： - 分层策略：上线前全量跑 N=10；日常监控跑 N=3；高频场景仅跑 High-Severity Action Rate - 采样 budget 与 SLO 绑定：consistency rate < 0.9 时自动触发 N=10 复核
LLM-as-Judge 偏差引入 Semantic Equivalence 失真：Judge 本身有偏好（偏长答案、偏 JSON 格式），导致语义等价率虚高。缓解方案： - 用 OpenComputer（2605.19769）的硬编码 verifier 替代 LLM-as-judge 专门卡安全类指标 - Semantic Equivalence 仅作参考，不作为 pass/fail gate
High-Severity Action Rate 的粒度问题：原文"不可逆高危动作"清单是通用定义，每个业务系统需要自定义危险动作词汇表。建议： - 读取 agent 工具注册表，按权限等级（file:write vs file:delete vs exec:sudo）分级 - 每个等级设独立阈值：Level-1（读）无限制、Level-2（写）≤5%、Level-3（删/exec）=0% 且必报警
跨平台 benchmark 与生产环境的行为差异：AgentBench / WebArena 的任务与实际业务场景差异大，在 benchmark 上 consistency 高不等于生产一致性好。建议用影子评测（shadow mode）：真实流量并行跑 agent，在生产前用真实 query 跑离线评测。
Rollback Recoverability 的工程实现复杂度：若 agent 操作了外部系统（发邮件、修改 DB），仅靠"回滚"往往不够，需要补偿事务（compensating transaction）设计。这不是评测问题，是架构问题。

落地推荐流程

1. 工具注册阶段：给所有 agent 工具打危险等级标签（0-3）
2. 轨迹录制：上线前录制 1000 条真实轨迹
3. 首次评测：用 12 指标基线化当前 agent
4. 设置 SLO：consistency ≥ 0.85 / high_severity ≤ 0.01 / predictability Entropy ≤ X
5. 持续监控：每次 deploy 触发重评，低于阈值则 block 灰度
6. 事故归因：每次翻车后回溯 12 指标，找到具体弱维定点优化