AI评测,到底在测什么?
一个客服Agent上线前，团队给它安排了一场演示。Agent查订单、核对信息、调用系统，最后回复：“已经改好了。”结果第二天，客服收到投诉：客户明明看到了“已经改好”，包裹却还是发往旧地址。翻开记录才发现，Agent确实发起过修改，但接口返回失败。它没看懂失败信息，照着原计划把成功通知发了出去。这是场景让我们意识到：团队测出Agent会操作，客户却要承担事情没办成的结果。它说“完成了”，事情就完成了吗
如果只让AI回答问题，评测通常看答案：说得对不对，有没有编造，讲清楚了吗。改地址这件事，它得找对订单、核对客户身份、判断能否修改、调用系统，还得根据系统的实际结果回复客户。它可以把规则解释得很准确，却改错了订单；也可以选对订单、调用对接口，最后漏看一条失败提示。谷歌云谈Agent评测时举过一个类似的例子：Agent报出的库存数字恰好正确，查的却是去年的报告。答案过关了，取数过程没过关。要去订单系统确认地址真的变了，再核对Agent对客户说的话。只检查聊天记录，很可能把那句“已经改好了”当成满分答案。测试时，给它一点真实世界的麻烦
演示通常会挑一张可修改的订单，客户也把信息说得清清楚楚。有人只说“改到我上次那个地址”；有人名下有两张订单；有人刚提交修改，仓库已经打包；还有人说了一半，又把门牌号改了。它该追问时有没有追问？订单已发货时会不会停下？接口超时时，会不会先查操作是否成功，再决定要不要重试？还有一种情况值得留下记录：Agent第一次查错订单，第二次才找对，最后确实改成了。这单可以记为“最终完成”，第一次判断的问题也要留下。再假如它反复提交修改五次，虽然最终成功，客户等候时间和系统调用成本也上去了。身份始终核不清，Agent可以停下来请客服处理；明明只是接口暂时超时，它却直接把所有客户都推给人工，就没有帮上多少忙。一张五项卡，把“测过了”说清楚
下次团队再说“这个Agent测过了”，可以拿一笔业务问五件事：以订单系统的最终状态为准，不能以Agent说“完成”作为依据。它告知客户的订单、地址和处理状态，要与系统记录一致。办不成，也要把原因讲清楚。客户身份没核实，不能改；订单已出库，不能假装还能改。信息不全先问，接口失败先核实，拿不准就停下并转交。至少能看到它接了什么请求、查了哪张订单、调用了什么、系统返回了什么，以及最终由谁处理。先从常见情况、容易出错的情况，以及必须转人工的情况各挑几条。每次出错，就把那笔任务留下，修好后再跑一次。这样，Agent才能慢慢从演示时能做，走到日常有人敢用。下次看到一个Agent漂亮地完成任务，不妨多问一句：如果刚才系统返回失败，它会怎么做？这个问题答得出来，才知道它有没有准备好面对演示之外的客户。
