AI智能体验收标准怎么定？四层指标与十条可测红线

AI 智能体最容易踩的坑：演示成功不算交付

过去两年接触过的 AI 项目里，翻车的项目几乎都有一个共同点：演示当天一切正常，上线三个月后被叫停。演示环境里只有二十条标准问题，答对了就算成功；生产环境里是每天两千条真实提问，其中一半是长尾，一成是脏数据，还有一成会让模型产生完全没见过的输出。

问题不在技术，在于双方从来没约定过「什么叫做好了」。合同上写「交付可用的 AI 智能体」，这句话和写「交付一个能用的软件」一样，验收时必然吵架。

本文按四层指标把验收标准拆开，每层都给可以直接写进合同的可测数字。这些数字主要来自国外公开的智能体基准测试、工业界 2026 年的生产数据，以及云厂商官方公布的智能体监控指标口径。

第一层：能力基线——先知道天花板在哪

验收 AI 项目最容易被误导的一件事，是把「公开基准分数高」当成「在你的业务里能用」。这两件事的相关性比想象中低。先看目前公开基准的实际水平：

这组数据来自斯坦福 2026 年人工智能指数报告所引用的各基准排行榜，以及 2026 年 6 月的第三方榜单快照。有两个结论必须读出来：

第一，能力提升是真的，但分布极不均匀。浏览器操作类任务已经超过人类（85% 对 72%），但涉及多个系统串联的企业流程，公开评测里最好的配置也只有约 26% 的通过率。最难的开放式长程任务上，最强配置得分低于 10%——而同一套配置在别的基准上通过率能超过 80%。

第二，「85%」这个数字在生产里意味着每 100 个任务失败 15 个。做一次演示，20 个问题答对 17 个，观感很好；做一个月业务，几千个任务里失败几百个，就是事故。基准分数和业务可用性之间不是线性关系，中间还隔着任务长度、数据脏度和异常处理三道放大器。

所以第一层验收的做法是：不要问模型能力有多强，要问它在你这条具体链路上能过多少。要求用你自己业务的 50 到 100 个真实历史案例做测试集，跑一遍看准确率，这个数字才是可用的基线。

第二层：链路成功率——乘法效应是最贵的坑

这一层是验收里最容易被忽略、也最致命的一层。智能体和传统软件最大的区别在于，它的每一个步骤都会出错，而整个流程的成功率是所有步骤成功率的乘积。

公开数据里有两个很直观的例子：单步任务成功率从 2025 年的 68% 提升到 2026 年的 89%，看着是重大进步。但四步串联的整体成功率是 0.89 的四次方，约 63%——单步提升了 21 个百分点，四步之后整体只提升了约 26 个百分点，还剩下三分之一的失败率。另一个例子更直接：单个智能体成功率 70% 时，三个串联之后的整体成功率只剩 34%。

这张表可以直接写进合同当验收依据。含义很直接：如果你的业务流程是五步串联，就不能用单步的标准来验收，必须要求「完整跑通五步」的成功率达标。而如果要求整体成功率达到 90%，那么单步成功率必须做到 99% 以上——这通常意味着业务里绝大多数环节不能用生成式模型，只能用确定性代码。

实际项目的正确做法是把链路切开，逐段设标准。哪几段可以让模型做、哪几段必须用规则锁死、哪几段必须人工确认，这三个决策在设计阶段就要定，不能留到验收时再吵。很多团队在这里犯的错是整条流程都用模型驱动，然后期望一个数字兜住全部风险。

第三层：运营指标——用官方口径，别自己发明

前两层管的是「能不能做对」，第三层管的是「能不能一直做对」。这一层有一件事做得非常聪明：主流云厂商的呼叫中心智能体产品已经定义了公开的官方监控指标口径，直接借用比自己造轮子可靠得多，因为这些指标是被大规模生产验证过的。

这五个指标里，「转人工率」是最需要提前定的一个。它是唯一一个「高了好、低了也可能是问题」的指标：太高说明智能体没干活，是高级表单；太低说明它在硬答，该转的不转，风险反而更高。行业里成熟场景的常见区间是 15% 到 40%，具体取决于业务复杂度。

「回答有用率」必须在合同里定义清楚怎么采集。让用户随手点赞很便宜，但绝大多数人不会点。要拿到真实信号，通常的做法是在智能体给出的每个回答下方固定放两个按钮，并把「有用率」定义为有用数除以有用数与无用数之和——而不是除以总请求数。这两个算法算出来的数能差三倍，不写清楚就会在验收时各执一词。

第四层：生产环境的安全与稳定性红线

这一层不是智能体独有，但智能体把它放大了。因为模型会生成内容，会调用外部接口，会接触业务数据，任何一个环节出问题都可能直接变成对外事故。

• 权限边界。智能体只能读它职责范围内的数据。合同里要写明它能访问哪些表、哪些接口，越权访问必须被拒绝并且留下日志。
• 输出可追溯。每一条结论必须能追溯到来源或输入依据，不能出现无法解释的答案。这是后续排查问题的基础，也是监管场景的硬要求。
• 敏感信息处理。客户身份证号、合同金额、内部价格策略这类内容是否进入模型上下文，要明确写清。国际主流的智能体安全风险清单把「敏感信息泄露」和「过度授权」列在最高危的两类里。
• 高危操作二次确认。涉及付款、删除、发外部邮件、修改生产配置的动作，必须有确认环节。这一条不能靠模型自觉，要靠工程实现。
• 服务可用性。智能体依赖的模型接口和向量库都有可用性波动。合同里要约定服务可用性下限（通常 99.5% 到 99.9%），以及降级方案——上游挂了的时候是转人工还是返回预设答案。

为什么 Demo 成功和生产失败之间差那么远

上面的验收标准之所以必须这么严，是因为有一道鸿沟。2026 年的工业界数据把这个鸿沟量化得很清楚：

这组数字的共同指向是：演示环境和工作环境是两个系统，而不是同一系统的两个阶段。演示是一次性的、有预设的、被观察的；生产是连续的、随机的、没人盯着的。88% 的智能体在受控演示里工作正常，进了真实工作流就失败——这个转化率差，几乎和「试点到生产失败率 89%」互相印证。

值得注意的是失败率的定义：70% 到 95% 的时间失败，指的是「任务层面的失败」而不是「系统宕机」。系统一直是活的、页面一直能打开，但产出的结果有七成到九成不能直接用——这就是智能体项目最真实的形态。所以验收如果只测「系统能不能用」，会得到一个乐观到失真的结论。

十条可以写进合同的验收红线

把上面四层收敛成十条具体的、可以直接写进合同条款的验收项：

这十条里，第 10 条的灰度期最容易被省略，也最不该省。它是唯一一条能让上面九条在真实数据上被验证的机制。双轨运行的意思是：智能体的每一个决策都同时给出结果，但不自动生效，由人确认；跑两周之后统计指标，达标再切自动模式。这两周的投入换来的是「上线后翻车」的概率大幅下降——按 89% 的试点失败率来看，这个投入几乎是必须的成本，不是可选项。

三个必须提前定的机制

除了指标本身，验收阶段还有三件事需要在合同里先写清楚，否则到了执行时没有依据：

一是指标采集方式。指标从哪来、谁来统计、多久统计一次，必须在合同里写明。是用云厂商的现成监控台，还是开发方自建面板，还是指定第三方工具。这一条不写，验收时的数据就没有公信力。

二是未达标怎么处理。不达标是整改还是延期，是扣款还是重做，比例怎么算。多数项目在这一条上是空白，结果就是「不达标」变成了「再等等看」，一直拖到合同快结束才爆发。

三是退出机制。如果灰度期结束后指标持续不达标，怎么终止、已付款项怎么处理、源码和已积累的业务数据怎么交接。这一条本来是保护甲方的，但因为写起来像是在预设不信任，很多合同干脆不提。实际效果是：真出问题的时候，只能走法律途径，而走法律途径需要的时间成本，远超当时就把这句话写进去。

换算到枣庄：三种项目的验收重心

不同类型的智能体项目，验收重心完全不同，指标不能一套模板套到底：

这张表里最值得留意的是最后一列。「单步成功率」「平均准确率」这类数字是智能体项目里最好看也最没用的指标——用精心挑选的简单样本测，单步准确率能做到 95%，但业务价值是零。合同里如果只写「准确率不低于 90%」而不定义测试集怎么抽样，这份合同基本等于没约束。

关于预算和周期的部分可以另看：同类项目的投入区间在公开市场上有明确的价格带，从一万五千美元的概念验证到两百万美元级的多智能体平台都有；而从试点到生产的转化率，公开数据显示只有 38% 左右，所以首期预算里必须留出重做的余量。

结语：验收标准不是技术文件，是商业文件

看完上面四层，可能会有一个感觉：要求好像太严了。这其实是智能体项目最实际的一课——它现在确实还做不到 100% 可靠，任何假装它能做到的验收设计都是自欺。

公开数据摆在那儿：浏览器操作能超过人类，复杂企业流程只有 26%，最难的开放任务不到 10%，生产环境里失败时间是 70% 到 95%。接受这个现实，然后把不确定性用工程手段管住——可测的指标、明确的采集方式、有宽限的灰度期、写得清楚的退出条款——这才是当下把智能体真正用起来的方式。

所以在签合同前，值得问对方三个问题：这十项指标你们打算怎么测？测试集由谁出？灰度期跑多久？三个问题答得具体，说明交付方想过生产落地；答不上来，说明他做的是演示，不是系统。