Agent 客服：先把 FAQ、工单和人工接管串起来，再谈全自动
客服最容易被做成一个会聊天的窗口，但真正决定体验的，是答案是否有依据、事务工具是否可控，以及系统是否知道什么时候该转人工。
01.客服系统最容易误判的目标，是“替代所有人工”
很多人一提到 Agent 客服，第一反应就是做一个会聊天的窗口。但真实客服场景里，聊天能力本身并不是最难的部分。
真正决定体验的，通常是这些事情：
- •回答有没有引用到正确知识
- •查订单、查物流、查工单这些动作能不能稳定执行
- •模型会不会乱承诺退款、补偿或升级处理
- •当问题超出边界时，系统能不能及时转人工
所以客服 Agent 的第一目标，通常不是“把人工客服替掉”，而是先把高频、低风险、规则相对稳定的问题处理好，并且把复杂问题整理成更适合人工接手的状态。
02.先选一个单一链路，而不是“万能客服”
如果第一版目标写成“覆盖所有客服场景”，项目很快就会失控。更现实的切入点通常是某一条清晰链路，例如：
- •订单状态查询
- •退款进度查询
- •售后材料收集
- •常见政策问答
以“售后助手”为例，一个可交付的第一版通常已经足够有价值：
- •回答常见售后政策
- •查询订单和工单状态
- •收集缺失信息
- •必要时转人工，并附带对话摘要
这比做一个“什么都能聊一点”的客服机器人更容易上线，也更容易复盘。
03.一条稳定的客服链路，通常由三层能力组成
1. 知识问答层
用于回答规则明确、知识库可覆盖的问题，例如：
- •发货时间
- •退款时效
- •保修政策
- •发票开具流程
这里的重点不是“回答得像不像真人”，而是答案能不能追溯到知识来源。
2. 事务查询层
用于执行确定性操作，例如：
- •查询订单状态
- •查询物流轨迹
- •查询历史工单
- •创建售后工单
这些动作不应该靠模型自由发挥，而应该由受限工具直接对接业务系统。
3. 人工接管层
用于处理这些情况：
- •低置信度问题
- •需要人工裁量的例外
- •用户情绪明显升级
- •涉及赔付、改价、退款审批等高风险动作
没有这第三层，客服 Agent 很容易在“回答不确定但还在硬答”的状态里越走越偏。
04.模型负责理解与组织，系统负责查证与执行
在客服场景里，一个比较稳的职责拆分是：
更适合模型处理的部分
- •识别用户意图
- •把口语化描述整理成结构化问题
- •判断是否信息缺失
- •生成更适合客服查看的摘要
更适合系统处理的部分
- •查询订单、物流、工单
- •校验用户身份
- •执行退款、补单、改地址等高风险动作
- •命中知识库后返回对应证据
如果让模型同时负责“判断 + 执行 + 编造解释”，最后最容易出问题的就是事务边界。
05.一个更实用的响应骨架
比较推荐的方式，是让模型先输出一个受限的处理计划，再由系统决定走哪条链路。
from typing import Literal
from pydantic import BaseModel, Field
class SupportPlan(BaseModel):
lane: Literal["faq", "order_lookup", "ticket", "handoff"]
intent: str
confidence: float
requires_human: bool
reply_outline: str
needed_fields: list[str] = Field(default_factory=list)
def execute_support_plan(plan: SupportPlan, session_id: str, tools):
if plan.lane == "faq":
return tools.answer_from_kb(session_id=session_id, outline=plan.reply_outline)
if plan.lane == "order_lookup":
return tools.lookup_order_and_reply(session_id=session_id, outline=plan.reply_outline)
if plan.lane == "ticket":
return tools.create_ticket(session_id=session_id, summary=plan.reply_outline)
return tools.handoff_to_human(session_id=session_id, summary=plan.reply_outline)这个模式的核心价值在于：
- •模型输出有 schema 约束
- •是否查单、建单、转人工由系统显式控制
- •后续可以直接对
lane、confidence、requires_human做评估
06.对话状态不要贪大，但必须够用
客服 Agent 不需要把所有聊天内容永久记住，但有几类状态最好明确保存：
- •用户身份与校验结果
- •当前会话的主意图
- •已采集到的订单号、商品名、时间等关键槽位
- •最近一次系统动作
- •是否已经触发过人工接管
这几类状态足够支撑大部分售后对话，也方便人工客服接手时快速理解上下文。
07.人工接管不是失败，而是能力边界
很多团队把“转人工”当成系统失败指标，这很容易把 Agent 推向危险方向，因为它会被激励去硬答更多本不该硬答的问题。
一个更健康的策略是把人工接管视为正常能力边界，并提前定义明确触发条件，例如：
- •连续两轮仍然无法确定意图
- •检索结果互相冲突
- •用户要求例外处理
- •用户情绪明显恶化
- •即将执行高风险外部动作
同时，转人工时不要只丢一段聊天记录。更好的做法是附带一段摘要：
- •用户诉求
- •已完成查询
- •当前证据
- •未解决问题
- •推荐的人工下一步
这会显著减少人工客服重新问一遍的成本。
08.客服 Agent 特别需要 guardrails
客服场景天然会碰到大量敏感信息和合规要求，所以 guardrails 往往比“语气拟人化”更重要。
至少要重点处理这几件事：
知识依据
没有命中知识依据时，宁可保守回答或转人工，也不要编造政策。
PII 保护
日志、trace、训练样本和质检数据里都要考虑手机号、地址、订单号等敏感字段脱敏。
工具审批
任何修改订单、执行赔付、发起退款的动作，都不适合无条件自动执行。
语义安全
恶意提示、辱骂文本、诱导越权操作，都要在用户输入和模型输出两侧做检测。
09.评估时不要只看“回复像不像人”
客服 Agent 的评估更应该围绕业务正确性和处理边界：
- •问题分类是否正确
- •知识回答是否有依据
- •工具调用是否正确命中
- •是否该转人工时及时转了
- •转人工摘要是否完整
如果后面要做更细的在线指标，也可以继续看：
- •一次解决率
- •平均人工接管率
- •高风险误承诺率
- •用户重复描述率
这些指标比“模型语气是否更像客服”更有工程价值。
10.三个常见误区
1. 先做意图分类百科，再做系统集成
客服真正的难点不是多写几个意图标签，而是把知识、交易和人工接管连成一条可运行链路。
2. 让模型直接承诺业务动作
是否能退款、是否能补发、是否可以免审核，这些都应该由规则和系统决定，而不是模型口头承诺。
3. 转人工时不附带结构化上下文
如果人工客服拿到的只是原始对话记录，前面 Agent 积累的价值几乎就浪费了。
11.总结
客服 Agent 真正可交付的形态，不是一个“更会聊天”的机器人，而是一条更完整的客服处理链：
- •能回答有依据的问题
- •能调用受限工具查证事实
- •能在边界外及时转人工
- •能把上下文整理得更利于人工继续处理
只要先把这条链路做稳，再去扩更多场景和更自然的交互，系统就更有机会成为真实业务的一部分，而不是一个展示型 demo。