随着客服自动化的成熟,越来越多的团队正从单一的通用型智能体转向多个专业化智能体——一个专注于账单,一个专注于技术故障排查,一个专注于订单物流——每个智能体在其狭窄领域内的表现,都优于一个需要横跨所有领域的通用型智能体。这种架构带来的挑战在于协调:让智能体之间的交接对客户来说不着痕迹,客户体验到的应该是一场连续的对话,即便底层系统并非如此。
专业化为何有效,又在何处失灵
一个对支付和订阅系统拥有深度访问权限的账单专用智能体,解决账单问题的速度和准确性,都优于依靠政策摘要工作的通用型智能体。但一场以账单问题(“为什么我被重复扣费了”)开始的对话,常常会在对话中途转变为技术问题(“因为一个 bug 导致我的订单被重复提交”)——如果此时的交接处理不当,就会出现智能体重新自我介绍、要求客户重复背景信息,甚至更糟——彻底丢失原始问题的线索。
一次良好交接应有的样子
- 将完整的对话背景传递给接手的专业智能体,而不只是最新的一条消息
- 传递已提取的所有事实信息——订单号、账户状态、情绪倾向
- 接手的智能体应简要确认交接(“关于这个问题的技术部分我可以帮您处理——我看到您提到的订单是…”),而不是从零开始
- 绝不要求客户重复上一个智能体已经掌握的信息
编排层才是真正的工程难题
判断某条消息应由哪个专业智能体处理——尤其是同时涉及两个领域的消息——是一个路由问题,它应当拥有独立于任何单个智能体准确率之外的自身评估体系。实际操作中,这意味着编排器需要一套专门的测试集,涵盖模糊的、跨领域的对话——而不能仅仅假设当前活跃的专业智能体总能正确识别出需要交接的时刻。
何时应保留通用型智能体
并非每一种部署都能从彻底的专业化中受益。对于支持量较低的客服业务而言,多个专业化智能体带来的协调开销,可能会抵消每个专业智能体各自带来的准确率提升,此时配备强大检索能力的单一、调优良好的通用型智能体,仍是更实际的选择。专业化开始产生正回报的临界点,往往同时取决于支持量和领域复杂度——像账单这样支持量大、范围狭窄的领域,远比支持量低、范围宽泛的领域更适合拥有自己的专业智能体。
多个专业智能体胜过一个通用智能体——但有一个前提条件
多个专业化智能体可以胜过一个通用型智能体,但前提是它们之间的衔接部分,要被投入与专业智能体本身同等精细的工程设计。那些在专业智能体质量上重金投入、却把交接层当作"管道"随意对待的团队,其表现往往持续落后于对两者投入大致相当工程关注的团队,因为客户对服务质量的真实感受,在很大程度上恰恰是由对话跨越领域边界的那些瞬间所决定的。
一套专门针对衔接环节设计的测试集
在实践中,建立对编排层的信心,意味着构建那些故意横跨两个领域的测试对话——一起最终发现是技术 bug 的账单投诉、一个演变成退款请求的物流问题——并且不仅要检查最终是否由正确的专业智能体处理了它,还要检查从客户的角度看,这次过渡是否感觉天衣无缝。无论多么全面的"仅专业智能体"测试集,都永远无法揭示这一类失败,因为按其设计方式,它从不会要求单个专业智能体去处理一场本该被交接出去的对话。