AI 客服从问答走向办事：企业要补的三类系统接口

先给结论：AI 客服这两年真正的变化，不是回答变得更像人，而是它开始被允许动手。查订单、改收货地址、补开发票、开一张工单，这些动作一旦落到企业系统里，决定成败的就不再是模型的表达质量，而是接口层有没有准备好。三类接口缺一类，AI 就只能停在问答；三类都通，它才从一个答疑工具变成服务入口。

AI 客服这两年最大的变化是什么？

结论：从答得上变成办得成，衡量标准也随之从答准率换成了办结率。

2023 年前后企业上 AI 客服，主流做法是把产品手册、常见问答、售后政策切成片段存进向量库，用户提问时检索相似段落交给模型组织语言。这套做法解决的是知识检索问题，验收指标是答准率和拦截率，也就是有多少问题不用转人工就结束了。

转折点出现在模型支持工具调用之后。企业发现自己可以把业务接口挂给模型，让它按需去查一条真实数据，而不是从文档里找一段可能过期的描述。于是同一个问题的处理路径变了：以前是告诉用户退货政策是几天，现在是查这笔订单当前在哪个环节、还能不能退、点了退货之后系统里发生了什么。

这个变化对采购标准的影响很直接。前两年比的是知识库覆盖率、意图识别准确率、话术丰富度，现在比的是能对接几个业务系统、能不能代客操作、出了问题能不能举证。一批只会做问答的供应商开始被压价，而能把客服对话和订单、工单、库存打通的方案，议价能力明显更强。

为什么卡点往往不在模型，而在接口层？

结论：模型能理解意图，但企业系统只认身份、权限和幂等，这三样它自己给不了。

把 AI 接入真实业务，第一道墙是系统本身没有对外接口。不少企业的核心系统上线时间早，只提供数据库账号，连一个像样的查询服务都没有。要让它支持代客查询，先得在它前面补一层接口，这层接口还要处理只读账号、字段裁剪、调用限速，工作量往往比接模型大得多。

第二道墙是身份。坐席帮客户改地址，系统里留下的是坐席的账号；AI 帮客户改地址，系统里该记谁？如果没有一套可识别的服务身份，所有操作都会落在同一个技术账号上，事后完全无法追溯是哪一次会话触发的。这已经不是技术细节，而是权限模型的设计问题。

第三道墙是幂等。网络抖动、模型重试、用户连点，同一次操作被提交两遍是常态。业务接口如果没有业务主键去重，第二遍就会多开一张工单、多发一次货。人工操作时坐席会看着屏幕判断，模型不会，它只会按约定再调一次。

第四道墙是审计颗粒度。多数系统的日志记的是接口路径和返回码，记不下会话上下文。等到要复盘一次错误操作，才发现只有一行调用记录，既不知道用户当时说了什么，也不知道模型为什么选了那个动作。

三类核心接口分别解决什么问题？

结论：知识库同步解决答案时效，业务落库解决能不能办，会话转人工解决办不了时怎么接住。

表格里第一行最容易被低估。知识库同步不是把文档一次性灌进去就完事，它要跟着商品上下架、活动开始结束、政策版本替换一起动。同步接口如果只处理新增和修改，删除和失效就永远传不过去，结果是新政策上了线，AI 还在按去年的规则回答。正确做法是让接口以状态字段为准，每次同步都带上当前是否有效，由接收侧按状态覆盖。

第二行的幂等键是最值钱的一个字段。约定很简单：同一个请求编号在有效期内重复到达，直接返回首次的处理结果，不新建单据。有效期按业务定，订单类一般一天，工单类可以更长。有了这条约定，模型的重试、网关的重发、用户的连点都不会造成重复。

业务落库接口的最小字段约定可以写成这样，重点在请求编号和操作人身份两处，缺了任何一个都没法上线。

POST /openapi/v1/ticket/create
Headers: X-App-Key, X-Trace-Id, X-Operator
必填字段: request_id / session_id / customer_id / category / summary
幂等约定: 同一 request_id 在 24 小时内重复提交，返回首次结果，不新建工单
响应字段: ticket_no / status / assignee / created_at

会话转人工这一行常被做成一个跳转链接，实际要传的是上下文摘要。用户已经说了三遍订单号，转过去还要再说第四遍，体验断点就在这里。合理的做法是把最近若干轮对话压成一段结构化摘要，连同客户标识、已尝试过的动作、当前卡在哪一步一起交给坐席端，坐席打开就能接着办。

数据脱敏和审计该放在哪一层？

结论：脱敏放在出口，也就是送进模型之前；审计放在入口，也就是每次调用发生时。

脱敏的方向经常被搞反。有些方案在模型返回之后才做替换，这等于敏感信息已经出过一次企业边界。正确的位置是调用前的网关：手机号保留后四位、身份证只留首末位、详细地址收敛到区县、银行卡号整段替换。规则要按字段配置，而不是按整段文本做正则替换，否则同一段话里混着订单号和手机号时会误伤。

不过脱敏不能一刀切。售后核身需要比对手机号后四位，物流改址需要完整地址，把字段全抹掉，AI 就办不成事。可行的做法是按动作分级：只读类查询给脱敏后的数据，写操作类在核身通过后临时放开必要字段，并且这次放开要单独记一条审计。

审计则要能回答四个问题：谁在什么时间、以什么身份、对哪条数据、做了什么动作。这四个要素里，身份和动作最容易缺。日志只记接口路径的话，事后只能看到调用发生过，看不到业务含义。审计表建议直接与会话标识绑定，一条会话对应多条动作记录，出问题时按会话串起来看，比按时间翻日志快得多。

还有一条常被忽略：模型给出的建议动作和实际执行的动作要分开记。前者是模型的判断，后者是系统的结果，两者不一致时，问题可能出在权限拦截，也可能出在参数映射，混在一起记就分不清责任。

自建还是采购，判断依据是什么？

结论：先看身份体系，再看接口存量，最后看审计要求，三项都过关才适合自建。

身份体系是第一道判断题。企业如果有统一账号和单点登录，能给 AI 分配一个可识别的服务身份，并把它纳入现有权限体系，自建的技术前提就成立了。反过来，如果各系统账号各自为政，连人都没统一，先补身份比先上 AI 更划算。这一步做不好，后面所有代客操作都会卡在授权上。

接口存量是第二道。核心系统已经有稳定的对外接口和版本策略，接入是组装工作；只有数据库权限的话，先补接口层，工期和风险都要重新评估。这里有个常见的误判：把数据库直连当成捷径，短期能跑通，长期会在字段变更、性能争抢和审计缺失上反复付账。

审计要求是第三道。金融、医疗、教育这类受监管行业，对会话留存和操作留痕有明确年限要求，自建意味着要自己承担存储、归档和调阅的合规责任。采购则要把这部分写进合同，明确数据存放在哪、保留多久、谁能调阅。这一条谈不清楚，后面很难补。

三项都过关的企业，自建的优势在于能把客服对话和内部流程深度绑定，动作可以更细。三项有一项不过关，采购成熟方案更快，代价是可定制空间有限，遇到特殊业务流只能等对方排期。中间路线是把问答和对话管理交给外部，把业务落库和审计留在自己这边，接口由自己控，这也是目前比较多企业采用的组合。

常见问题：接入前最该先想清楚的几件事

AI 客服一定要能改数据吗？

不一定。先区分查询类动作和写入类动作。查询类风险低、收益直接，适合先上；写入类涉及资金、库存、地址这类会改变业务状态的字段，要等幂等、身份、审计三件事都落实再放开。很多企业第一阶段只开放查询，把办结率提升最明显的部分先拿到，第二期再接写入。

知识库多久同步一次合适？

按内容变化的速度定。商品资料、价格、活动规则这类一天内会变的，用增量接口按小时同步；政策制度、流程说明这类季度级变化的，每天一次足够。关键不是频率，而是失效能不能及时传达，删除和下架必须和新增走同一条链路。

转人工的触发条件怎么设？

至少三类要转：连续两轮没有识别出有效意图、涉及敏感操作且核身未通过、用户明确要求人工。另外建议加一条兜底规则，模型对某个动作的置信度低于阈值时不执行，直接转人工，这比让它猜一个结果更安全。

接口是让供应商做还是自己做？

业务系统的接口建议自己做或者由原厂商做，因为字段含义、权限边界、异常码只有他们清楚。对话侧、知识库侧、模型编排可以交给供应商。分界线放在业务系统边界上，后续换供应商时业务侧不用重做，这是最省事的一种切法。

上线后怎么判断这套东西有没有用？

看三个数：一次解决率、转人工率、代客动作成功率。前两个反映对话能力，第三个反映接口质量。第三个数字低，问题基本不在模型，去查接口超时、权限拦截和幂等冲突，比调提示词有效得多。

厦门经纬度软件科技做接口开发与系统互联，近 20 年软件开发经验、服务 5000+ 中小企业，这类把 AI 对话接到业务系统上的活，通常从梳理接口清单和身份体系开始。需要评估现有系统能不能支撑，可以联系 0592-8061158 或 32518962@qq.com，地址 厦门市软件园三期集美北大道1140号。