AI 草稿、自动发送与人工接管：客服 Agent 的状态机实践

企业客服 Agent 最危险的设计，通常是一个名为“自动回复”的布尔开关。它把建议、生成、发送、失败、重试和人工接管压缩成两个状态：开或关。

真实客服流程远比这复杂：有些问题适合生成草稿，有些可以自动发送，有些必须转人工；发送失败后应保留什么状态？人工修改了 AI 建议后，下一轮还能否恢复协助？这些都需要被建模，而不是靠页面提示或临时分支处理。

三种会话模式与三种处理结果

项目先区分“会话由谁负责”和“本次回复如何处理”这两个概念。

会话模式有三种：

会话模式	含义
AI_ASSIST	AI 可以生成建议，但必须由客服确认发送
AI_AUTO	满足全部安全条件时，允许进入自动发送链路
HUMAN_ONLY	停止 AI 自动处理，由人工全程接管

每次回复决策也只有三种正式结果：

决策结果	含义
AI_DRAFT	生成一份可编辑的 AI 草稿，不自动发送
AUTO_SEND	满足全部条件后创建发送任务
HANDOFF	停止当前 AI 处理，进入人工接管

会话模式决定系统的可用范围，回复决策决定当前消息的处理结果。两者分离后，系统才能表达“会话允许自动化，但这一条消息不能自动发”。

把回复过程建成状态迁移

一次处理不应该只有“已回复”或“未回复”。系统围绕生成和发送过程建立状态迁移：

AI_ACTIVE
    ↓
AI_GENERATING
    ├─→ AI_SUGGESTED          生成草稿，等待人工确认
    ├─→ AUTO_SEND_PENDING     已创建自动发送任务
    ├─→ NEEDS_CLARIFICATION   订单或事实不足，需要澄清
    └─→ HANDOFF_PENDING       必须交给人工

AUTO_SEND_PENDING → AI_SENT / HANDOFF_PENDING
HANDOFF_PENDING   → HUMAN_ACTIVE
AI_SENT           → AI_ACTIVE

状态迁移会记录触发来源、原因和必要上下文。这样运营人员可以知道一次回复是因为订单不明确而停在草稿，还是因高风险直接转人工，而不是只看到一个模糊的“失败”。

自动发送是一组条件，不是一次模型判断

在 AI_AUTO 模式下，系统也不会因为模型生成成功就直接发送。自动发送要求策略、订单、知识、能力和发送通道同时通过：

策略明确允许
    + 会话处于 AI_AUTO
    + 未人工接管
    + 订单无需澄清
    + 知识证据可信且可回答
    + 没有知识冲突
    + Skill 执行成功
    + Safety Gate 放行
    + Outbound 通道在线
        ↓
      AUTO_SEND

任意一项不满足，都不应自动发送。多数情况下系统会退回 AI_DRAFT，让客服继续利用 AI 的表达能力；明确高风险、策略禁止或连续知识缺失时，才会进入 HANDOFF。

为什么第一次缺知识是草稿，第二次才转人工

缺少知识并不总是高风险。对于低风险问题，第一次没有可信命中时，系统允许生成一份安全的 AI 草稿，帮助客服组织语言，但禁止自动发送。

如果同一会话连续出现知识缺失，说明当前问题已经超出已知业务范围，继续让模型反复生成价值不大，风险却会累积。此时系统会以 KNOWLEDGE_MISSING 为原因转人工。

这个策略在“完全放开”和“只要缺知识就立即转人工”之间保留了一个可运营的中间层：既不浪费客服的辅助能力，也不会无限制地让模型猜测。

人工接管需要可恢复、可追溯

当买家明确要求人工、出现投诉或赔付等高风险问题、策略禁止 AI 处理，系统进入人工接管。接管中心需要保留：

• 当前问题和关联上下文；
• 已执行的策略、能力与工具；
• AI 建议与最终发送内容；
• 接管原因和处理状态。

人工处理完成后，可以恢复到此前的 AI 协助或自动模式，而不是粗暴地重置整个会话。AI 草稿被人工修改并发送时，系统同时保留建议和最终结果，用于后续审计与知识优化。

发送链路也必须有状态和幂等性

模型生成正确，不代表消息一定发送成功。网络重连、客户端刷新或重复轮询都可能造成重复领取任务。

因此，发送任务使用服务端幂等标识、领取租约和客户端已发送记录来控制重复执行。发送失败的内容保留在消息流中，可以重试；客服发送回显只入库，不再触发新的 AI 生成，避免系统把自己发出的回复当作买家新问题。

这条链路让“AI 已建议”“人工已发送”“自动发送成功”“发送失败待重试”成为可区分的真实状态。

高风险动作不进入自动执行链

退款、取消订单、改地址、赔付等操作即使被模型正确理解，也不会由客服 Agent 直接执行。系统最多创建待人工处理请求，并将相关上下文带给运营人员。

这种限制不是能力不足，而是把工具权限限制在已验证的边界内。对于业务系统来说，知道什么时候不执行，往往比能执行更多动作更重要。

如何验证状态机没有失控

项目为状态机和回复决策维护了独立回归场景，包括：

• 自动模式下，条件全部通过时才创建发送任务；
• 置信度不足、Gate 不确定或订单需澄清时保持草稿；
• 首次低风险知识缺失生成草稿，连续缺失后转人工；
• 高风险、用户要求人工、策略禁止时跳过 LLM 并直接接管；
• 自动发送成功、失败重试、人工发送与回显不会重复或形成消息回环；
• 人工接管后可以按规则恢复原有 AI 模式。

结语

客服 Agent 不是“模型 + 发送按钮”。它需要把建议、确认、发送、失败、澄清和人工接管变成正式状态，并让每次状态变化都可解释、可恢复、可审计。

当自动化被建模为状态机和安全条件的组合，AI 才能既帮助客服提升效率，又不会悄悄越过业务边界。