会话层决定能不能用
先确认现有客服系统是否开放接口或支持坐席辅助模式。有的系统只能导出会话、无法实时接管，这种情况要先换通道或加一层中间件。会话层不通，后面所有能力都无从谈起，这也是很多项目卡在第一周的真实原因，与模型能力其实没有关系。
业务层决定答得对不对
订单、物流、售后单与客户档案决定答案是否具体。做法是只读取必要字段，按订单号与手机号后四位做校验后查询，返回结构化状态而非整段文本。字段越多不等于越好，读取范围要按场景最小化，避免把整张客户表暴露给模型上下文。
写操作要单独授权
改工单状态、发起退款、补发配件属于写操作，风险远高于查询。建议先只读运行数周，确认判断准确后再逐个开放写接口，并加审批与幂等控制。为什么必须这样：重复提交与误改状态在售后系统里极难回滚，客户看到的往往是错误进度。
身份与权限别省
接入前要确定谁在什么身份下查询什么数据：客户自助、坐席辅助、内部网点三种场景的数据范围完全不同。常见做法是按角色做字段级权限，敏感字段脱敏后再进入模型上下文。权限设计缺失的系统，往往在上线后被迫整体回退重做，代价远高于前期规划。
日志要能还原对话
集成完成后，排查问题靠的是日志：哪次请求、命中哪条知识、调用了哪个接口、返回什么、坐席何时接管。日志不全，出错只能靠回忆与猜测。建议把会话标识、知识条目版本与接口响应码一并记录，并约定保留周期与访问审批，便于复盘与责任界定。
适用与不适用
适合谁
- 已有在线客服或呼叫中心、希望加一层 AI 的企业
- 订单与工单系统有开放接口的电商与制造业
- 需要对内对外两套入口、权限要求不同的集团客服
不适合谁
- 客服系统完全封闭、无法导出也无法接入的团队
- 订单数据分散在个人表格、没有系统可对接的业务
典型场景
某建材企业的客服系统只能导出会话，无法实时接管。项目组先在中间加了一层消息网关，把在线咨询与电话转写统一成会话流，再接订单与物流查询接口，只读运行三周。确认无误后才开放改工单状态与补发申请两个写接口，并加审批与重复提交校验，避免误操作。
可执行步骤
- 确认现有客服系统是否开放实时接口与坐席辅助能力，缺什么先补什么
- 逐场景列出必需的最小字段，逐项申请只读权限，并注明用途与期限
- 按订单号与身份校验设计查询流程，返回结构化状态而不是整段文本
- 先只读运行数周，确认判断准确后再逐个开放写操作，并加审批与幂等校验
- 记录会话标识、知识版本与接口响应，约定日志保留周期与查看权限
常见坑
- 一开始就要求全字段读取，安全评审卡住数月，项目被迫延期，最后只能缩小范围重来，前期投入白费。
- 写接口没有幂等控制，模型重试导致重复补发，损失要人工逐单核对，客户还会收到两份货。
- 订单与工单用不同标识，同一客户查两次结果不一致，回答自相矛盾，坐席自己也不敢采信。
- 日志只记录模型输出，不记录知识与接口调用，出错无法定位到具体环节，复盘只能靠猜测。
自检与验收清单
- 会话层是否支持实时接管或坐席辅助，接口是否稳定
- 每个场景的最小字段是否列清、是否获得明确授权
- 写操作是否有审批环节与幂等控制，能否回滚
- 身份与字段级权限是否按客户、坐席、内部三类角色区分
- 日志是否记录知识版本、接口响应与接管时点
常见问题
必须换掉现有客服系统吗？
多数不必。如果系统支持开放接口或坐席辅助，可以在其上叠加一层；只有完全封闭、连会话导出都受限的系统才需要考虑替换。替换成本高，建议先做接口可行性验证再决定，不要为了 AI 重建整套客服体系。
接口不稳定怎么办？
要做降级设计：查询超时或失败时，明确回退到人工并提示稍后重试，不要让模型编造一个状态。同时设定超时阈值与重试次数，把失败率纳入监控，接口问题在客服场景里会直接变成客户投诉。
客户数据能给模型看吗？
按最小必要原则处理：只传当前问题需要的字段，敏感信息脱敏，能本地部署的优先本地。数据用途、保留期限与访问权限要写进合同与内部制度，涉及个人信息时按相关法律要求做评估与告知。