业务说没省事，技术说正常：智能体到底怎么验收？

周三下午的验收会开到第三轮。业务部门说，智能体用了一个季度，没觉得省事；技术团队把监控调出来，响应时间、调用成功率都正常。两边都觉得自己没错，会就卡在那里。

这类会我们没少参加。多数时候，真正卡住的不是谁在推卸责任，而是一开始没人把"什么算验收通过"写下来。等到项目到期，只能靠感觉投票。

下面这 4 个指标，建议项目第一天就定，配一张表，拿走就能改。它不考核模型有多聪明，只回答一件事：这事你原来花多少时间，现在还花不花。

一、模型跑分好，不等于项目能验收

技术侧盯的是模型本身：响应快不快、回答像不像。业务侧要的是另一件事：这件事我原来花多少时间，现在还要不要花。

中间隔着一整段流程——数据从哪来、结果给谁用、出错了谁来接。这段流程没有指标，项目就只能靠"感觉好不好用"收尾。

指标要定在流程上，不要定在模型上。这是验收能不能谈拢的分界线。

图1 验收会上的两套尺子：两边各拿"正常"的证据，却没一份是同一把尺子

二、指标一：任务能不能从头跑到尾

先看端到端完成率：一个完整任务，从输入需求到交付结果，机器能独立走完多少，需要人接手的环节有几个。

统计方法很朴素。挑 10 到 20 个真实任务，逐条走一遍，记下在哪一步停下、为什么停。停下来的地方往往集中在一两处：资料格式不统一、权限没打通，或者结果要人工再核一遍。

试点期不必追求高完成率，但要写清楚卡在哪一步。写清楚的卡点，就是下一期优先要投入的地方。

三、别用"准确率"卡业务：看可用率

第二个是可用率：机器给出的结果，业务人员拿来能直接用的比例。

为什么不用准确率？准确率需要一个标准答案，可很多业务场景本来就没有。合同条款的说法、经营分析的措辞，同一个意思几种写法都对。按"像不像标准答案"打分，会把能用的结果判成错的——团队被冤枉几次，就不愿意参与了。

做法是这样：从产出里抽样，让真正用它的人判断"能不能直接用、要改几处"，按"直接用、小改、重做"三档记数。小改算可用，重做不算。

四、人还要不要一直盯着：人工介入频次

第三个是人工介入频次：跑同样的任务量，人平均要介入几次，每次花多久。

这个指标常被漏掉，却离真实收益最近。一个工具结果都对，只要每一步都要人确认，省下的时间就接近零。反过来，结果偶尔不完美，但人只在关键节点看一眼，业务侧的体感会完全不同。

记录时把介入点分三类：纠错、补数据、走审批。三类各占多少，直接告诉你下一步该补哪块能力。

五、连续跑得住吗：异常兜底

第四个是连续运行和异常兜底：多天、正常业务节奏下稳不稳，真出异常时有没有明确的降级方式。

试点期常见的翻车是中途停了没人知道。所以清单里要留两项：连续运行的观察周期和记录方式；异常时的处理路径——是回退到人工、切到备用流程，还是先暂停再通知。

六、把四个指标放进一张表

这张表不是用来打分的，是把"好不好用"拆成可以逐条讨论的事实。会上争起来的时候，指出具体哪一格不达标，比互相说服省时间。

图2 四个验收指标各自衡量的对象

七、搬进内网，完成率可能先掉一截

有一点常被漏掉：部署环境不同，这四个指标的分量不一样。

在公有云上跑顺的方案，搬进内网以后，完成率往往先掉。不是模型变差了，是内网的权限、数据源、更新方式和外面不同。所以内网、本地化部署的场景，验收前要先确认一件事：这些指标是在什么环境里测的。

以本地化部署为交付形态的产品，比如领铄智能的 Blade Agentic OS 企业智能体平台和 Blade Agent Box 企业级边缘 AI 一体机，部署形态本身就是验收条件的一部分。测试环境和交付环境差多少，验收表里要单独占一行写清楚：是同一套配置，还是需要重新测一轮。具体配置与性能参数，以合同与实际交付配置为准。

图3 测试环境与内网交付环境的差异

最后

四个指标不多，也不复杂。难的是在项目开始时就愿意把它们写下来。写下来意味着要接受"可能不达标"这个结果，很多人卡在这一步。

如果你们单位正在推试点，可以先拿上面这张表改一版，指标换成自己的业务语言，再跟业务部门对一遍口径。对不上的地方，通常就是项目后面会出问题的地方。