业务 Agent 评估的“闭环证明”怎么做:从试点到上线的三张检查表

一、为什么“演示跑通”不算证明

Anthropic 在评估指南里区分了两个概念：轨迹（transcript）和终态（outcome）。一个航班预订 Agent 在对话里说“已为您预订”，这只是轨迹；终态是数据库里是否真实存在一条预订记录。只有终态对了，闭环才算完成。

演示环境恰恰只验证轨迹：数据是干净的，权限是放开的，没有并发冲突，也没有过期状态。真实业务里 Agent 最容易出问题的地方——字段缺失、权限拒绝、接口超时、重复执行、状态冲突——在演示里一次都不会出现。用演示成绩申请上线，相当于用彩排录像申请正式演出。

二、第一张表：评估就绪检查（开工之前）

LangChain 的上线前检查清单给了一个很具体的起点：在搭建任何评估基建之前，先人工审阅 20 到 50 条真实 Agent 运行轨迹。机器还没开始打分，人要先看过系统真实的样子。

• 成功标准无歧义：如果两个业务专家对同一条轨迹的 pass/fail 达不成一致，这个评估任务就要重写，而不是换个评分器蒙混过去。
• 任务来自真实业务：评估任务从生产或试点中的真实请求里采样，而不是评估团队凭空编写的“看起来很难”的题目。
• 基线已建立：知道当前人工流程的耗时、成本和错误率，否则“提升”无从谈起。
• 责任人已指定：最了解用户的人定义成功标准；专职评估团队维护基建，业务专家贡献评估任务。
• 失败样本已收集：至少有一批已知的难例和失败模式，评估集不是清一色的 happy path。

三、第二张表：分级评估（试点之中）

评估要分三级，每一级回答不同的问题：

• 单步评估：某一步的工具选择对不对、参数填得对不对。这是调试层面的问题。
• 整轮评估：一次完整任务看三个维度——最终答案是否正确、执行路径是否合理、系统状态变更是否符合预期。
• 多轮评估：在多轮对话里，Agent 能否保持上下文、不重复问、不丢失此前的约束条件。

同时要区分两种评估的用途。能力评估通过率低、用来向上爬坡，衡量系统上限；回归评估通过率接近 100%，用来防止倒退。当一个能力评估的通过率长期很高，就让它“毕业”——进入回归套件，并接入 CI/CD 质量门，版本发布前自动重跑。

评分器建议组合使用：代码评分器做客观确定性检查（优先用），模型评分器处理主观开放任务（先用人标样例校准），人工评分器留给高风险和歧义情形（金标准）。

四、第三张表：上线验收与上线后闭环

上线验收看的不是单次好，而是重复好。Anthropic 建议用 pass@k（k 次中至少一次成功）和 pass^k（k 次全成功）量化可靠性：一个单次准确率 90% 的 Agent，连续 8 次全部成功的概率只有约 43%。需要高可靠的动作，就不能拿单次准确率当验收标准。

• 权重与失败后果挂钩：低风险任务重准确性，运营任务重任务完成率和可靠性，高风险任务把安全、授权合规和人工监督排在速度前面。
• 上线前最终六问：是否达成业务结果、行为是否一致、是否在权限内、可否从预期失败中恢复、性能是否值得成本、上线后能否持续监控和改进。
• 上线后形成飞轮：在线评估监控真实流量，定期人工抽查轨迹，生产中的每一次失败都回流进数据集、变成新的评估用例（trace-to-dataset）。评估集不是写完就冻结的文件，而是跟着生产失败一起生长的资产。

三张表走完，企业手里的不再是“演示很顺利”的印象，而是一份可审计的证据：成功标准是什么、在多少分级上测过、可靠性数字是多少、生产失败如何回流。这才是“闭环证明”四个字的含义。