AI智能体进入生产环境后，最先暴露的问题通常不是能力不足，而是说不清它到底好在哪里。传统软件的验收标准是确定性的，功能按预期返回即可通过；智能体的输出带概率性，同一个请求在不同上下文里可能走向不同路径，单一准确率根本承载不了它的真实表现。在“先识别场景、再验证能力、后扩大部署”的节奏下，量化评估体系应当与试点同步建立，而不是等规模铺开之后再补。
先界定评估对象
评估对象应是任务闭环，而不是模型本身。需要回答的问题包括：任务是否被正确完成、需要几轮交互、失败后能否恢复、证据不足时是否会正确拒答或转人工。把这些拆成可观测的行为项，才谈得上度量。
指标分三层，少一层就会失真
业务层关注效率提升、错误率下降、成本节约，对应智能化技改项目的阶段性验收；系统层关注推理时延、并发能力以及与现有业务系统的集成度；安全合规层则覆盖数据隐私、行业合规与安全审计结果。
三层必须同时看。业务指标好看但时延无法被业务承受，或者准确率上升却过不了合规审查，都是常见的失衡。
基线比指标更难，也更重要
量化评估的前提是可比。小范围试点要形成可控的实验环境，选取业务关键节点或单一业务线，与原有流程或人工处理并行对照。没有基线，“效率提升”只是一个孤立的数字，无法判断是否值得继续投入。
让指标回流，也评估体系本身
监控日志、用户体验调查和业务指标回流构成闭环，评估集应尽量取自真实业务分布。同时，模型版本管理、监控告警和持续合规审查要覆盖评估体系自身：更换一个模型版本，此前的结论就未必成立。
起步阶段不必追求指标齐全。先在一两个关键节点上建立基线和最小指标集，跑通一轮度量与迭代，再考虑向其他场景迁移。评估体系是随业务长出来的，一次设计到位的版本，多半会在第一波真实流量面前失效。