模型给出一段完整、礼貌的回答，容易让演示顺利结束。但一个会操作业务系统的 Agent，还可能查错对象、漏掉关键条件，或者声称完成了实际并未执行的动作。验收需要跟着业务结果走。
分别检查表达、过程和结果
Anthropic 的 Agent 评估文章区分了执行记录与环境中的最终结果：系统说任务完成，并不能证明对应业务记录已经存在。[1] 对企业交付，这提醒我们把不同层面的验收拆开。
表达层面检查答案是否清楚；过程层面检查使用了哪些资料和工具；结果层面核对状态是否符合预期。比如查询客服应使用正确订单，资料不足时应补问，创建工单后应返回确实存在的记录。三者不能互相代替。
先建立一组有代表性的任务
可以从授权、脱敏的历史问题中挑选样例，也可以编写明确标注的模拟场景。样例要覆盖日常任务、信息缺失、对象歧义、规则冲突和服务异常。我们建议第一版宁可小一些，也要让每个任务的预期结果足够明确。
例如，“客户询问配送时间”需要写清订单状态、允许使用的资料和可接受的答复范围。若接口没有预计到达时间，合格答案应承认这一点，不能编出一个日期。一个好的测试样例，通常也是一段清晰的需求说明。
不要把所有质量压成一个分数
正确率、人工接手、响应时间和单次成本反映不同问题。一次改动可能提高答案完整度，却显著增加等待时间；也可能减少人工接手，却让不该自动处理的异常继续执行。把它们合成一个总分，会掩盖重要取舍。
可以为每类任务规定必须满足的条件，再观察体验指标。权限越界、对象错误和未经确认的写入，应作为独立的失败项。至于回复是否简洁、格式是否易读，可以采用明确量表，并定期让业务人员校准评分标准。
把评估放进每一次变更
修改模型、提示词、检索规则或接口之后，使用同一组任务进行对照。对于有随机性的输出，重复运行关键任务，并保存版本和设置，避免把一次偶然成功当作稳定提升。自动评分适合扩大覆盖，但有争议的业务判断仍要人工复核。
上线后的失败应进入待分析队列。经过脱敏和确认后，将有代表性的失败补进测试集，避免同类问题反复出现。同时保留一部分未用于日常调优的任务，减少系统只对熟悉样例表现良好的风险。评估由此成为需求、开发和运营之间共同使用的语言。
下一次验收，选一个系统声称“已经完成”的动作，直接到目标系统里核对结果是否存在且属于正确对象。
参考资料
本文结合公开资料与 Terriva 的方法建议整理。文中的假设场景用于说明设计思路，不代表客户实绩。