AI客服跑了100万次，并不自动意味着客户的100万个问题都解决了。截至2026年10月14日核验，Anthropic发布的Zendesk官方案例披露，其Custom Agents在早期开放的前七周达到100万次执行。这个案例更值得借鉴的，是把客服对话背后的具体工作拆出来，再分别验收。
AI接手的是哪些后台工作？
退款、保修和故障处理往往需要跨系统查资料。客户只说一句“商品坏了”，工作人员可能还要核对订单、保修条件及处理政策，聊天回复只是其中一环。
Anthropic官方案例介绍，Zendesk通过Amazon Bedrock运行Claude，并让客户决定代理可以使用哪些工具和动作。案例中的故障分流流程会识别相似工单、建立Jira问题、通知工程团队，再在修复后处理关联工单。这是该案例描述的流程，不能据此认定每个企业都适合自动关闭工单。
三个数字，需要配三种解释
- 七周100万次执行：计量对象是代理执行次数。同一张工单可能经历多个步骤，执行量不能直接替代最终解决量。
- 人工处理时长最高降低80%：官方给出的是使用这些代理的客户所报告的上限效果，不是全体客户平均值，更不是裁员比例。
- 重复工单合并准确率99%：这是一个客户试点中的特定任务结果，不代表整个客服系统的回答准确率。
公开材料没有提供足以复算这些效果的完整样本、统一测试口径和对照数据。因此，它适合作为试点方向的参考，不能直接填进另一家公司的投资回报预测。
小团队可以先试“找重复”，但先别自动合并
下面是蓝图编辑部据此提出的试点建议，并非Zendesk已披露的实施步骤。先让AI在批准使用、去标识化的历史工单副本中找候选重复项，输出工单编号、相似依据和不确定原因，由工作人员逐条复核。
样本里要特意加入容易混淆的情况：同一个客户的两次独立故障、多人反馈同一故障、标题相同但订单不同的请求。尤其要查“误合并”，因为把不同问题合在一起，可能让某位客户的诉求被遗漏。
验收时同时记录四项：找出的候选有多少、真正重复的有多少、遗漏了多少，以及人工确认后到底省了多少时间。只看准确率会忽略漏检，只看处理速度又可能掩盖错误。
从建议走到执行，还差一道业务确认
Zendesk的产品说明将输入、指令和输出拆开，并强调工具权限和业务边界。迁移到自己的团队时，可以据此追问：AI缺少订单号怎么办，政策冲突交给谁，误操作怎样恢复，哪些动作必须由人确认？
把这些问题写进测试和验收，比追求更大的执行次数更有用。先让一个窄任务稳定减少返工，再考虑扩大权限；最终衡量的仍应是客户问题有没有被正确解决。
