从“能回复”到“能上线”：企业智能客服 Agent 的安全闭环

在抖店客服场景里，真正困难的从来不是让模型生成一句看起来通顺的话，而是让它在真实订单、商品知识、客服规则和人工运营之间做出可解释、可追溯、可控的决定。

这个项目将 AI 助手嵌入飞鸽客服工作流：飞鸽仍是客服人员的主界面，AI 以本地侧栏提供建议、解释和处理状态。它不是一套脱离业务的聊天机器人，而是一条围绕真实会话构建的决策闭环。

本文只介绍可公开的工程设计，不包含客户会话、订单号、商品数据、账号凭据或内部策略原文。

先定义问题：模型不能拥有业务权限

客服场景中，“回答得像人”并不等于“可以发送给用户”。错误关联订单、引用过期商品信息，或者在退款、改地址等问题上越权承诺，都会直接造成业务风险。

因此，这个系统的核心原则是：LLM 负责理解和生成，规则系统负责权限和事实边界。

权限优先级固定如下：

Safety Gate > Reply Policy > Skill > LLM

• Reply Policy 决定当前意图是否允许 AI 处理、是否需要人工、可以使用什么能力。
• Skill 只执行被策略绑定的能力，并校验工具权限和上下文。
• Safety Gate 对生成结果做最终否决；它只能拦截，不能反过来授予权限。
• LLM 不能自行决定自动发送、调用业务工具或跳过人工接管。

这条边界让系统从“聊天能力”变成了“受控执行能力”。

一条客服消息如何流转

系统把飞鸽中的文本、商品卡和订单卡规范化为统一会话事件，再进入后续处理链：

飞鸽真实消息 / 商品卡 / 订单卡
        ↓
会话上下文构建 + 相关订单选择
        ↓
知识检索 + 可回答性判断
        ↓
Reply Policy → Skill → Safety Gate
        ↓
AI_DRAFT / AUTO_SEND / HANDOFF
        ↓
发送队列、人工接管、审计与知识回流

这条链路的重点是每个阶段都有明确输入、输出和失败策略，而不是把整段聊天记录与全部订单直接塞给模型。

多订单场景：先确定事实，再生成答案

客服会话经常同时关联多笔订单。一个常见但危险的做法是把订单列表完整交给模型，让它自行挑选“最像”的一笔；这会让选择过程不可复现，也容易把最近付款时间误当成充分证据。

项目中，相关订单由确定性选择器完成。订单号、商品名、SKU 等强证据可以选中唯一订单；如果多个同优先级候选都没有足够证据，系统返回“需要澄清”，而不是猜测。

强证据唯一命中 → 选定订单
多笔候选且证据不足 → 请求澄清
没有可信当前订单 → 不把历史订单当作实时事实回答

付款时间只用于同级候选的展示排序，不能单独成为自动选中依据。这样做牺牲了一部分“立即回答率”，换来的是订单事实的稳定性和可审计性。

RAG 不等于“检索到了就能回答”

知识链路不仅做全文检索，还要回答一个更关键的问题：这些候选证据是否足以支持当前回复？

系统将知识拆分为文档、商品知识、店铺规则和高频问答等不同类型，并通过优先级、生命周期、冲突检查和证据筛选控制输出。最终进入模型的不是全部候选，而是通过可信门槛的证据片段。

如果没有可靠知识：

• 第一次低风险缺失，生成安全的 AI_DRAFT，交由客服确认；
• 连续缺失或出现高风险情况，进入 HANDOFF；
• 发现同类知识存在冲突时，不让模型“自由选择”，而是阻断并等待人工处理。

这种设计将“模型不知道时容易编造”的问题，转换成可运营的知识缺口、人工纠正和审核发布流程。

三种回复结果，而不是单一的“AI 回复”

每次处理都会落到三种明确结果之一：

结果	含义	适用场景
AI_DRAFT	AI 生成草稿，等待人工确认	常规咨询、证据尚需人工确认、订单需澄清
AUTO_SEND	创建自动发送任务	策略、知识、订单、工具和安全检查全部通过
HANDOFF	停止 AI 自动处理，交给人工	用户明确要求人工、高风险、策略禁止或连续知识缺失

自动发送不是一个单独开关。它要求会话处于自动模式、没有人工接管、订单不需要澄清、知识证据可信、策略允许、Skill 执行成功、Outbound 在线，并最终通过 Safety Gate。

默认情况下，系统优先输出草稿而不是自动发送；自动化应建立在可验证的条件之上，而不是建立在“模型看起来很自信”之上。

工具调用的边界：查询可以自动，交易必须人工

系统将工具分为低风险查询和高风险交易两类：

• 订单查询、物流查询等能力以只读方式返回标准化结果；
• 退款、退货、取消订单、改价、改地址等高风险动作不由 AI 直接执行，只生成待人工处理请求；
• 尚未经过业务验收的写操作会明确返回不可用，而不是伪造“执行成功”。

这是一条很朴素但很重要的工程原则：工具能力应当随验收范围增长，而不是随模型能力膨胀。

把人工接管做成状态，而不是一句提示

人工接管不是在界面上显示“请联系人工”就结束了。项目将会话状态建模为 AI 建议、自动发送待处理、待澄清、人工接管、人工处理中等阶段，并记录状态迁移原因。

人工处理者能够看到当前问题、关联订单、已执行的策略与能力、AI 建议和最终发送内容；处理完成后，也可以恢复到之前的 AI 协助或自动模式。

发送链路同时保持本地幂等：同一发送任务不会因为重试或客户端重连而重复发给买家。AI 建议、人工修改和最终发送结果以同一条审计链关联，方便后续复盘。

工程实现与验证

后端以 FastAPI 和 SQLite 提供会话、知识、策略、审计与发送队列能力；前端使用 React/Vite 构建 AI 侧栏和后台运营页面；客户端通过 Electron 与飞鸽工作台协作。

项目覆盖了订单选择、Policy 匹配、知识生命周期、可回答性 Gate、回复决策、消息流、人工接管、真实工具执行和前端运营展示等回归场景。评测侧维护了 330 条初始黄金样本，并使用 Promptfoo 约束 Prompt、模型、Retriever 和 Guardrail 变更后的回归检查。

测试与评测使用隔离数据库，不读取或写入正式会话数据。任何真实设备联调也只用于验证闭环，不作为公开客户案例展示。

这次实践带来的结论

企业客服 Agent 的价值不在于“替代所有客服”，而在于把重复、低风险、事实明确的处理流程标准化，同时把不确定性、风险和知识缺口清晰地暴露给人。

如果只追求一次模型调用的回答质量，系统很容易停留在 Demo；如果把订单事实、知识证据、策略权限、工具边界、人工接管和审计追踪连成闭环，AI 才有机会进入真实业务流程。