AI Agent 越来越"会做事"了,为啥生产里还是翻车?——arXiv 2602.16666 用 12 个指标把"靠谱"这事儿拆明白

• 关联论文:2602.16666

你有没有这种感觉:Agent 跑 demo 时像天才,一上生产就开始掉链子——同一道题问两次,答案不一样;用户换个说法,Agent 跑偏;偶尔还来个"误删数据库"或者把 prompt 里的密钥吐到日志里。

你以为是模型不够大。arXiv 2602.16666(AI Agent Reliability)说,问题根本不在模型,在你评估 Agent 的方式。

传统评测只用"成功率"一个数。模型能力涨,这一个数跟着涨。但生产里 Agent 翻车的原因,绝大多数不是"做不做得对",而是"行为稳不稳、失败可不可预期、出错代价有不可控"——这些维度根本没人测。

这篇论文的贡献是:把航空、医疗器械这些安全关键工程的四维评估思路搬到 Agent 上,给出一个可以照搬的12 指标 + 4 维度框架,在 15 个模型上证明了一件事——

能力分数高的模型,可靠性不一定高。能力与可靠性是弱相关。

它更戳人的是结论:近期模型迭代主要带来 robustness 的小幅改进;consistency(一致性)、predictability(可预测性)几乎没动。也就是说,排行榜前 10 名的 Agent,在"靠谱"这件事上可能差不多烂。

一句话故事

别再用单一成功率评估 Agent——把可靠性拆成 consistency / robustness / predictability / safety 四维,每个维度 3 个具体指标(共 12 个),在 15 个模型、2 个 benchmark 上证明:能力分数持续走高,可可靠性几乎纹丝不动。

为什么这件事跟你我有关

这不是一篇只有研究员才需要看的论文。只要你和 AI 产品经理、客服/代码 Agent、Agent 平台工程打过交道,这 12 个指标就是接下来内部 SLO(服务等级目标)模板的雏形。

具体说,这事对以下几类人直接相关:

• 🛠️ Agent 平台/编排系统架构师:12 指标直接当内部 SLO,CI 流水线接入即可
• 🛡️ AI 安全/合规工程师:拿到"成本—后果"风险矩阵与失败模式分类法
• 📊 评测/红队负责人:建立内部 Agent 评测流水线时的指标框架
• 💼 AI 产品经理:理解为什么"demo 漂亮 ≠ 生产可用",避免被榜单忽悠

其它涉及：

• 🤖 客服 Agent:同一问题答两次不一样,客户体验崩
• 💻 代码 Agent:删错文件、写错路径,事故代价高
• 📞 企业内部 RPA Agent:权限误用、跨系统调用失控
• 🏥 医疗/法律垂直 Agent:错误代价不可逆,必须可预测失败

这些场景的共同点是:生产里 Agent 翻车的真正原因,90% 都不是"做不做得对",而是"行为稳不稳、出错有多可预期、后果有不可控"——单一成功率指标把这些关键维度全盖住了。

核心方法:四维框架 + 12 指标

传统评测只看一个成功率:这道题答对了吗?但生产里 Agent 翻车是"长尾风险"——一年 99 次做对,1 次翻车就可能删库。单一指标无法捕捉这种尾部事件。

论文向航空、医疗器械这些安全关键工程(IEC 61508、DO-178C)取经,提出四个维度:

第一维:Consistency(一致性)

问的是:相同输入是否产生相同输出?

举个最实际的例子:你的客服 Agent 今天回答"退款要 3 个工作日",明天同一问题回答"5 个工作日"——这种不一致会让支持体系彻底失信。三个具体指标:

• Self-Consistency Rate:同一问题跑 N 次,答案一致率
• Semantic Equivalence:答案语义等价率(LLM-as-judge 标定)
• Cross-Seed Stability:跨随机种子/Temperature 方差

第二维:Robustness(鲁棒性)

问的是:输入扰动下行为是否退化可控?

用户多打个错字、改个语序、加个无关前缀——你的 Agent 应该照样能处理。三个具体指标:

• Input-Perturbation Drop:扰动后成功率下降幅度
• Adversarial-Instruction Rate:对抗 prompt 注入的失效率
• Tool-Argument Stability:工具参数抖动的方差

这一维是论文里"近期模型迭代带来小幅改进"的那一维——但只是小幅,不是质变。

第三维:Predictability(可预测性)

问的是:Agent 在已知失败模式上是否真的会以可预期方式失败?

最反常识的维度。模型最危险的不是它做错了,而是它在已知模式下还做出你意料之外的事。三个具体指标:

• Refusal Calibration:该拒绝时是否拒绝、不该拒不拒
• Escalation Appropriateness:出错时升级到人工/降级路径的恰当率
• Failure-Mode Entropy:失败模式的熵——低熵意味着失败模式可控

论文明确说:predictability 几乎没动。也就是说,大部分 Agent 失败的时候,你是真的"想不到会这样失败"。

第四维:Safety(安全性)

问的是:错误代价是否有上限?会不会出"删除整个数据库""泄漏密钥"这种不可逆高危动作?

这是企业最关心的维度。三个具体指标:

• High-Severity Action Rate:不可逆高危动作的频率
• Sensitive-Leakage Rate:隐私/凭证泄漏率
• Rollback Recoverability:出错后能否通过回滚/补偿恢复

论文点出一个反直觉的事实:Safety 高分 ≠ "使用安全"。模型可能在敏感泄漏率上 0.01%——但只要这一发命中了不可逆高危动作,整个系统就翻车。

评测协议

每个指标都给出数学定义 + 测量协议,避免"凭感觉打分"。配套协议:

1. 多轮采样 + 统计聚合:每个 query 至少跑 N 次(论文未公开 N),用置信区间报告
2. 配对扰动集:对每个原 query 生成 k 类扰动(字符级、词级、句式级),测鲁棒性
3. 失败模式分类法:用 taxonomy 把错误分类(拒绝错位/工具错位/推理错位/行为越权)
4. "成本—后果"二维 safety 矩阵:横轴错误频率、纵轴严重程度,把安全问题落到可排序的风险清单

关键实验与数据

论文主实验在 15 个模型上跑、覆盖闭源(SOTA 商用 LLM)与开源代表;跑 2 个互补 benchmark(具体名称未在 abstract 公开,论文未明确;从社区信息看是 AgentBench 类 + 自建工具调用基准)。

三个关键发现:

1. 能力 ≠ 可靠性:能力与可靠性是弱相关。同一榜单前 10 名,可可靠性可以差出 3-5 倍
2. 近期能力提升主要带来 robustness 的小幅改进:consistency、predictability 几乎没动
3. Safety 高分 ≠ 使用安全:0.01% 敏感泄漏率命中一次不可逆高危动作,就是 100% 事故

配套交互式 dashboard:hal.cs.princeton.edu/reliability(论文评论信息)。ICML 2026 接收,对工程团队是强信号。

⚠️ 存疑与待核: - 评测 benchmark 的具体名称与覆盖任务未在 abstract 公开,工程团队无法判断覆盖任务类型,建议直接访问 dashboard 核实 - 15 个模型的具体名单与版本未公开,选型参考性受限 - GitHub repo/开源代码状态未明确,需去 dashboard 页面核实 - 采样次数 N 未公开,导致不同团队评测结果不可比 - v3(2026-06-02)实验数据是否与 v1 相同需查正文

这事儿对你有什么用——三条立刻能抄的启发

别只看排行榜。1 个成功率数字 ≠ Agent 靠谱。三件现在就能做的事:

1️⃣ 把 reliability 指标写进 CI:上线前每个 Agent 任务跑 12 指标,阈值与 SLO 挂钩

# .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]

2️⃣ 看 dashboard 而不是看 accuracy:能力分数上涨不再值得庆祝,先看 consistency / predictability 涨没涨

3️⃣ 安全设计按 cost-severity 矩阵分级:把动作分 4 级(读/写/删/改权限),给每级配最大频率阈值

# 工具权限等级标签示例
TOOL_SEVERITY = {
    "file:read":    0,  # 无限制
    "file:write":   2,  # ≤5%
    "file:delete":  3,  # =0% 且必报警
    "exec:sudo":    3,  # =0% 且必报警
    "send_email_external": 3,
}

工程边界(必须看清)

⚠️ 不神化,但要重视——落地前必须知道的 3 个边界:

1. LLM-as-judge 偏差会被引入 Semantic Equivalence:Semantic Equivalence 用 LLM 做裁判,但 judge 本身有偏(偏好长答案、偏好 JSON 格式),导致语义等价率虚高。建议仅作参考,不作为 pass/fail gate

2. High-Severity 动作清单需要按业务定制:原文的"不可逆高危动作"是通用定义,每个业务系统需要自定义危险动作词汇表。建议读取 agent 工具注册表,按权限等级分级

3. 跨平台 benchmark 与生产环境的行为差异:AgentBench / WebArena 的任务与实际业务场景差异大,benchmark 上 consistency 高不等于生产一致性好。建议用影子评测(shadow mode):真实流量并行跑 agent,在生产前用真实 query 跑离线评测

与同方向工作的关系

• 与 AgentBench / SWE-Bench / τ-bench:能力基准;本文不替代,补一层"可靠性"视角
• 与 Anthropic / OpenAI 的 Responsible Scaling Policy(RSP):把 RSP 思路下放到 Agent 评测层级
• 与 Safety-critical engineering(IEC 61508、DO-178C):明确借鉴四维分解思路
• 与 LLM-as-judge 系列研究:用 judge 但承认 judge 偏差
• 与 OpenComputer(arXiv:2605.19769):用"硬编码 verifier"替代 LLM-as-judge,可作为 Safety 维度的互补方案

接入 12 指标的最小可行路径(6 步)

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

一句话总结

别再用单一成功率评估 Agent——把可靠性拆成 consistency / robustness / predictability / safety 四维共 12 指标。能力分数高的不一定靠得住,这是 2026 年下半年所有 Agent 团队必须重写的评估手册。

🎯 适合谁读: - Agent 平台/编排系统架构师(SLO 模板) - AI 安全/合规工程师(风险矩阵与失败分类法) - 评测/红队负责人(评测流水线指标框架) - AI 产品经理(理解 demo 漂亮 ≠ 生产可用)

📌 一句话:Agent 能力分数涨得再高,如果 consistency / predictability 没动,生产里照样翻车——12 指标不是更复杂的评估,是终于看得见全貌的评估。

---

三个标题变体

1. 反直觉版:AI Agent 越来越"会做事"了,为啥生产里还是翻车?——arXiv 2602.16666 用 12 个指标把"靠谱"这事儿拆明白
2. 数字钩子版:15 个模型 × 12 个指标——arXiv 2602.16666 证明 Agent 能力涨 ≠ 可靠,4 维框架直接当 SLO 模板
3. 类比版:相当于给 AI Agent 做"航空级体检"——arXiv 2602.16666 用安全关键工程的思路把"翻车"拆成 4 维 12 指标

📱 小红书风格卡片文案(直接可用)

📱 你有没有这种感觉:Agent 跑 demo 时像天才,一上生产就开始掉链子——同一道题问两次答案不一样,用户换个说法 Agent 跑偏,偶尔还来个"误删数据库"或者把 prompt 里的密钥吐到日志里。

你以为是模型不够大。arXiv 2602.16666(AI Agent Reliability)说,问题根本不在模型,在你评估 Agent 的方式。

传统评测只用"成功率"一个数。模型能力涨,这一个数跟着涨。但生产里 Agent 翻车的原因,绝大多数不是"做不做得对",而是"行为稳不稳、失败可不可预期、出错代价有不可控"——这些维度根本没人测。

这篇论文把航空、医疗器械这些安全关键工程的四维评估思路搬到 Agent 上,给出12 指标 + 4 维度框架,在 15 个模型上证明:

能力分数高的模型,可靠性不一定高。能力与可靠性是弱相关。

更戳人的结论:近期模型迭代主要带来 robustness 的小幅改进;consistency(一致性)、predictability(可预测性)几乎没动。

🧠 为什么"成功率"一个数不够用?

举个客服 Agent 的例子:同一个问题"退款要几天",今天回答 3 个工作日,明天回答 5 个工作日——单一成功率指标里这俩都算"答对了",但客户体验彻底崩。

生产里 Agent 翻车是"长尾风险"——一年 99 次做对,1 次翻车就可能删库。单一指标根本捕捉不到这种尾部事件。

⚙️ 12 指标 + 4 维度框架(直接照搬):

🔹 Consistency(一致性)——相同输入是否产生相同输出? - Self-Consistency Rate(同问题跑 N 次答案一致率) - Semantic Equivalence(答案语义等价率) - Cross-Seed Stability(跨种子/Temperature 方差)

🔹 Robustness(鲁棒性)——输入扰动下行为是否退化可控? - Input-Perturbation Drop(扰动后成功率下降幅度) - Adversarial-Instruction Rate(对抗 prompt 注入失效率) - Tool-Argument Stability(工具参数抖动方差)

🔹 Predictability(可预测性)——失败模式是否可控? - Refusal Calibration(该拒就拒/不该拒不拒的校准) - Escalation Appropriateness(出错时升级路径恰当率) - Failure-Mode Entropy(失败模式熵——低熵意味着失败模式可控)

🔹 Safety(安全性)——错误代价是否有上限? - High-Severity Action Rate(不可逆高危动作频率) - Sensitive-Leakage Rate(隐私/凭证泄漏率) - Rollback Recoverability(出错后能否回滚恢复)

📊 关键实验数据:

发现	含义
能力 ≠ 可靠性	同一榜单前 10 名,可可靠性可差 3-5 倍
近期能力提升主要改 robustness	consistency / predictability 几乎没动
Safety 高分 ≠ 使用安全	0.01% 敏感泄漏命中一次不可逆高危动作 = 100% 事故

15 个模型、2 个 benchmark 验证,ICML 2026 接收。配套 dashboard:hal.cs.princeton.edu/reliability

🎯 为什么这事儿跟你有关?

• 🛠️ Agent 平台架构师:12 指标直接当内部 SLO 模板
• 🛡️ AI 安全/合规工程师:拿到风险矩阵与失败模式分类法
• 📊 评测/红队负责人:评测流水线指标框架
• 💼 AI 产品经理:理解 demo 漂亮 ≠ 生产可用,不被榜单忽悠

其它涉及:

• 🤖 客服 Agent:同一问题答两次不一样,客户体验崩
• 💻 代码 Agent:删错文件、写错路径,事故代价高
• 📞 企业内部 RPA:权限误用、跨系统调用失控
• 🏥 医疗/法律垂直 Agent:错误代价不可逆,必须可预测失败

🛠️ 三件现在就能做的事:

1️⃣ 把 reliability 指标写进 CI——上线前每个 Agent 任务跑 12 指标,阈值与 SLO 挂钩:

agent-reliability:
  - run: python -m agent_eval --metrics 12 \
      --threshold consistency=0.9 \
      --threshold safety_high_severity=0.01
    on: [push, pull_request]

2️⃣ 看 dashboard 而不是看 accuracy——能力分数上涨不再值得庆祝,先看 consistency / predictability 涨没涨

3️⃣ 安全设计按 cost-severity 矩阵分级——把动作分 4 级(读/写/删/改权限),给每级配最大频率阈值:

TOOL_SEVERITY = {
    "file:read":    0,  # 无限制
    "file:write":   2,  # ≤5%
    "file:delete":  3,  # =0% 且必报警
    "exec:sudo":    3,  # =0% 且必报警
    "send_email_external": 3,
}

⚠️ 但落地前必须看清的 3 个边界:

1. LLM-as-judge 偏差会被引入 Semantic Equivalence——judge 本身有偏(偏好长答案、偏好 JSON 格式),导致语义等价率虚高。建议仅作参考,不作为 pass/fail gate

2. High-Severity 动作清单需要按业务定制——原文是通用定义,建议读取 agent 工具注册表,按权限等级分级,Level-3 动作必须 = 0% 且必报警

3. 跨平台 benchmark 与生产环境的行为差异——AgentBench / WebArena 的任务与实际业务场景差异大,benchmark 上 consistency 高不等于生产一致性好。建议用影子评测(shadow mode):真实流量并行跑 agent,在生产前用真实 query 跑离线评测

🎯 最小可行接入路径(6 步):

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 指标,定位具体弱维定点优化

📌 一句话:别再用单一成功率评估 Agent——把可靠性拆成 consistency / robustness / predictability / safety 四维共 12 指标。能力分数高的不一定靠得住,这是 2026 年下半年所有 Agent 团队必须重写的评估手册。

🔔 评论区聊聊:你团队现在用几个指标评估 Agent?一致性、可预测性、安全性,哪一维最让你头疼?

AIAgent #Agent可靠性 #Agent评测 #大模型 #LLM #ICML2026 #SRE #AIOps #智能体 #评测框架 #安全工程 #生产可用 #arXiv260216666