智能客服 Agent 怎么落地？从回答问题到处理工单

客服自动化应该开放到哪一层

先做一条可闭环的售后路径

一个可作为首版的示例是：用户描述问题，系统补问必要信息，查询本人订单，检索适用政策，生成工单摘要，确认后提交，再返回真实工单编号与后续入口。

这个流程不要求 AI 决定全部售后规则。是否过保、是否允许退款、是否具备操作权限，应由确定的业务规则或授权人员判断。模型主要帮助理解表达、组织信息和选择允许的查询步骤。

从一种产品或一类工单开始，能更快暴露资料、接口和交接上的问题。记录原流程的处理时间和返工情况，才能在试点后比较是否有实际改善。

• 先支持常见咨询和一类明确工单。
• 将规则例外和投诉升级交给人工。
• 让用户能查看处理状态，并随时要求人工帮助。

对接 CRM、ERP 时，工具只开放必要能力

工具可以是“查询当前用户的订单”“查看维修进度”“创建售后工单”。避免直接开放通用数据库执行或不受限制的数据导出。每个工具应有明确参数、数据范围和返回字段。

身份信息由应用传入，不能让模型随意指定用户或租户。ERP 中的内部备注、采购成本和他人联系方式，也不应随着查询结果全部返回。前端只展示与当前任务相关的信息。

• 在测试环境验证接口，再接正式数据。
• 用业务服务层校验参数、身份与操作条件。
• 规定接口超时、限流和无结果时的用户提示。

创建工单与发送消息，要能确认并防重复

写入之前，应把将要提交的内容、对象和影响展示清楚。后端收到确认后再次校验权限与业务状态。对会改变状态的请求设置防重复策略，不能让模型在超时后无限重试。

例如创建工单接口响应超时，可能是提交失败，也可能是提交成功但响应丢失。系统应先根据业务请求标识查询结果，确认未成功后再按规则重试，并把最终状态反馈给用户。

退款、赔偿、变更收货信息等操作需要单独的审批和身份校验。即便客服 Agent 能调用这些接口，也不应默认拥有批准权限。

• 记录用户确认内容与实际提交参数。
• 用请求标识避免重复创建和重复通知。
• 只有收到业务系统成功结果，才告知操作完成。

人工接管需要携带上下文

有效交接至少应包含用户诉求、已核验身份范围、已查询状态、引用依据、已尝试操作和失败原因。客服人员接手后应能继续处理，避免让用户把所有内容再说一遍。

上线先控制试用入口与任务范围，记录完成率、重复提交、转人工原因、处理时长和用户反馈。数字应来自实际运行，且要说明统计口径；减少转人工不应以错误回答或拖延用户为代价。

验收中加入用户中途改需求、连续点击、接口超时、身份过期和人工接管等情况。数据与模型调整后，重跑这些关键流程，确认没有破坏已经稳定的操作。

• 用户主动要求人工时，提供明确入口。
• 工具异常与证据不足时及时停止自动处理。
• 给每个会话保留可追踪的工单或服务记录。

ERP 没有开放接口时，先明确能读到什么

先让系统供应商确认是否有受支持的导出、只读视图或扩展接口。批量导出的文件只能回答截至导出时间的数据，不应展示为实时库存或即时订单状态。若采用受授权的界面自动化，还要验证账号权限、页面变化、重复操作和故障恢复，不能因为能点击演示页面就承诺稳定集成。

• 记录每个数据源的同步时间、延迟上限和字段口径，超出有效期时提示人工核对。
• 没有可靠的写入与结果查询机制时，首版只生成待处理草稿，由人员在原系统确认执行。
• 不绕过供应商授权或直接修改业务数据库；原系统改造、许可费用和技术支持另列范围。

人工交接单应区分事实、推测和待确认状态

建议交接字段包括会话或工单标识、用户诉求摘要、核验方式与授权范围、已确认业务事实及查询时间、引用资料版本、已调用工具及结果标识、状态不明的请求、待补信息、升级原因、接手队列和接收状态。模型推测需单独标注，不能作为已经完成的操作交给客服。

• 敏感身份材料只保留受控记录的引用，交接摘要中不复制证件、密码或完整账户信息。
• 接口超时但可能写入成功时，将请求标识和“需先查结果”交给人工，避免再次执行。
• 以接手人能确认收到并继续处理作为交接通过条件；无人接单时保留任务并给用户可用的后续入口。