Data Agent 的评测准入卡口80% 通过线与运行期七个指标一个 Data Agent 跑通 Demo 不难难的是三件事多少人在用、用得多频繁、用出了什么结果。2026 年 9 月 19 日快手技术沙龙给出的一组数字把这三件事量化到了罕见的程度Data Agent 平台 WAU 突破 10600周人均对话 55 次数据分析师与产品运营渗透率超 80%NPS 73.5单次任务提效中位数 13 倍父子 Agent 路由准确率 95%核心资产知识覆盖率 80%知识服务准确率 83%。但比运行数据更值得抄的是它上线前的那道闸门设置 80% 评测准入卡口上线前累计评测了 60 万条数据、1 万个任务。这个细节回答了一个当前最普遍的问题——为什么大多数企业的智能问数产品停在 Demo 阶段因为没有一个量化的准入标准决定它能不能见真实用户。本文拆解 Data Agent 评测准入卡口怎么建、运行期指标怎么盯。一、为什么必须有评测准入Agent 的错误是乘法衰减传统数据系统的错误是加法的一个脚本算错一张表影响范围可枚举。Agent 的错误是乘法的一个口径理解错了它会把错误贯穿到取数、加工、分析的整条链路还会用流畅的自然语言把错误结果讲得头头是道——错误不仅被放大还被包装得更容易被信任。所以 Agent 从 Demo 到生产的分水岭不是能不能跑而是在足够大的任务集合上准确率是否稳定越过阈值。快手选 80% 作为准入线、用 60 万条评测数据喂出这个数字传递的方法论是准确率不是测一次的分数而是用大规模评测集压出来的统计结论。10 个任务跑对 8 个和 800 个任务跑对 640 个是完全不同的置信度。二、评测集建设三类覆盖别只测简单题评测准入的第一资产是评测集。参考快手的实践评测集要按三个维度建设按任务类型分层。Data Agent 的任务不是均质的至少分五类简单取数单表条件查询、复杂取数多表关联、窗口计算、报告生成取数 归因 组织成文、数据开发运维跑批、修数、告警处理、实验分析A/B 解读。每类单独统计通过率——整体 85% 可能掩盖报告生成只有 60%的结构性短板。按难度分层。每类任务再分三档常见模式历史高频问法、变化问法同义改写、口语化、长尾任务低频但真实存在。Agent 在常见模式上 95%、在长尾上 50% 是正常分布卡口要按常见模式必须达标、长尾允许灰度来设计而不是一刀切。黄金答案。每个评测任务要有标准答案且答案要业务方确认。这里最大的工程量不是写任务而是维护黄金答案——口径变了答案要跟着变。建议黄金答案挂上对应的数据字典条目口径变更时自动触发关联评测题的重审。一份可参考的起步配置每类任务 200~500 题、难度按 5:3:2 分布、全部带黄金答案与评分脚本。总量先到 2000 题随运行期发现的真实失败案例持续回填——评测集是活的资产不是一次性考卷。三、准入卡口设计一个阈值不够要一组闸门单看总通过率 ≥80%会漏掉关键风险建议按场景设一组闸门闸门建议阈值说明整体任务通过率≥80%快手同款准入线按加权任务类型计算高频场景通过率≥90%前 20% 高频问法是用户的基本盘涉敏数据任务的权限准确率100%权限错误零容忍一票否决幻觉率答非所问/编造数据≤2%错数据比不回答危害大数字准确率结果正确的前提≥85%单独统计防止格式对内容错闸门之外还有两条准入纪律回归评测——Agent 每次升级换模型、改 Prompt、调工具必须重跑全量评测集禁止只测新增功能灰度放量——通过卡口后先进 5%~10% 用户灰度观察两周真实指标再全量。评测集测的是已知题型灰度测的是未知题型两道闸缺一不可。四、运行期七个指标上线不是终点是评测的延续上线后盯什么快手披露的指标体系可以直接借用按价值 → 深度 → 质量三层组织价值层有没有人真正受益WAU 与渗透率10600 / 80%目标用户里有多少人每周真的在用。渗透率比绝对数诚实——强制推广拉起来的登录数骗不了渗透率。NPS73.5用户愿不愿意推荐是能用和好用的分界线。深度层用得有多重3.周人均对话次数55 次高频使用说明 Agent 进入了日常工作流而不是猎奇工具。4.单任务提效中位数13 倍注意用中位数不用平均值——平均值会被少数长尾任务拉爆中位数反映典型任务的真实收益。质量层结果可信吗5.父子 Agent 路由准确率95%多 Agent 架构下任务有没有被派给正确的子 Agent。路由错了后面全错。6.核心资产知识覆盖率80%企业的核心数据资产有多少被 Agent 的知识体系覆盖。覆盖率低意味着 Agent 只能答它知道的用户不知道边界在哪。7.知识服务准确率83%知识被调用后答对的比例。覆盖率与准确率要一起看——只追覆盖率会引入大量低质知识只保准确率会让 Agent 知识面过窄。这套指标的意义在于把Agent 做得好不好从感受变成周报数字。建议数据团队按周出一份 Agent 运行指标卡和质量报表同等级别地进管理层评审。五、评测的四个常见失真分数高不等于能上线评测体系本身也可能骗人。四个最常见的失真点建卡口时要专门防评测集泄漏。评测题目混进了 Agent 的训练语料或知识库原文——它背过答案通过率虚高。防线评测任务用真实业务问法的变体改写定期补充新题老题轮换退役。过拟合评测集。团队针对评测题反复调 Prompt 和路由评测分数上去了真实分布的问法却答不好。防线固定一部分封存题永不参与调优只在版本发布前跑封存题分数与公开题分数差超过 10 个百分点就是过拟合警报。答案漂移。业务口径变了黄金答案没跟着改Agent 按新口径答反而被判错。防线黄金答案挂数据字典条目口径变更触发关联题目重审——评测集的维护责任要写进数据标准运营流程。只测正例。评测集全是标准问法 标准数据状态没有脏数据、没有权限受限场景、没有并发冲突。防线故意构造 10%~20% 的对抗题——脏表、改名口径、无权限表考察 Agent 是硬答还是如实说做不到。对 Agent 来说正确地说这个我没权限/数据不存在也是通过。六、小团队 30 天起步方案不必照搬 60 万条评测数据的规模小团队可以这样起步周动作产出第 1 周从历史取数工单/BI 查询日志抽真实问法500 题初始评测集五类分层第 2 周业务方确认黄金答案写自动评分脚本评分基线 首轮通过率报告第 3 周设准入闸门跑第一次正式评测达标/未达标结论与短板清单第 4 周上线 Trace 采集与失败案例回灌机制评测集进入持续运营状态判断标准30 天后团队应该能回答三个问题——我们每个场景的通过率是多少、离准入线差多少、差的题集中在哪类。答不上来说明评测还停在跑分没有变成工程体系。七、运行期闭环让失败案例反哺评测集快手披露的闭环值得完整借鉴Trace 全链路追踪 智能诊断 Agent形成发现—复现—诊断—修复—沉淀的循环。落到操作层是四个机制失败采集用户点不满意或结果被人工修正的任务自动进入失败案例池带完整 Trace。复现与归因失败案例先重放复现归因到四类——知识缺失评测集没覆盖、口径错误知识库内容错、工具故障SQL 超时/接口异常、模型能力不足当前模型天花板。归因不同修法不同。修复回灌知识缺失的补知识、口径错的改知识、工具故障的修链路修完后该案例进评测集——保证同一个坑不踩第二次。定期重评月度用回灌后的评测集重跑全量观察通过率曲线。通过率不涨或下降说明修复没有沉淀成能力。结尾Data Agent 的竞赛正在从比 Demo切换到比兑现切换的标志就是评测准入与运行指标这套工程化体系。快手的数字给了一个可对标的参照系80% 准入线、60 万条评测数据、七个运行指标、发现到沉淀的闭环。对多数团队不必照搬规模但必须照搬结构——先建 2000 题的分层评测集和一组准入闸门再按周跑七指标运行卡让每个失败案例回到评测集里去。Demo 可以靠灵感规模化只能靠这套笨功夫。