客服 Agent 不是自动回复器：把 CRM、订单、物流和退款编排成解决闭环
Google 2026 年 10 月公布的企业案例中，Airwallex 将客户问题解决速度提升到 10 倍、争议处理时间降低 40%；Home Depot 的语音和数字助手将需求识别压缩到 10 秒以内。它们说明客服 Agent 的价值不只是生成更顺滑的话术，而是读懂意图后连接订单、库存、物流、支付和政策系统，完成一次解决。
传统客服最浪费的环节通常是重复询问、切换系统、等待授权和转接后丢失上下文。Agent 应把这些步骤编排成有边界的工单状态机。
自动化率不是首要目标；错误退款、错误承诺或没有上下文的转人工，会把节省的成本重新变成投诉。
以工单状态而不是聊天记录驱动流程
type CaseState = {
caseId: string
customerId: string
intent: "DELIVERY" | "RETURN" | "BILLING" | "PRODUCT"
orderIds: string[]
facts: Record<string, unknown>
missingFacts: string[]
proposedAction?: { kind: string; amount?: number }
risk: "low" | "medium" | "high"
status: "collecting" | "investigating" | "awaiting_approval" | "resolved" | "handoff"
}
每次模型调用只产生状态 patch。订单号、退款金额、物流状态等事实来自工具响应，不能让模型从对话中猜。对话文本用于解释，状态对象用于执行和恢复。
工具应该表达业务动作
不要给 Agent 一个万能 HTTP 客户端。为常见动作提供小而明确的工具，并在服务端执行授权：
@tool
def offer_resolution(case_id: str, option: Literal[
"REDELIVER", "REFUND_TO_ORIGINAL", "STORE_CREDIT", "ESCALATE"
]) -> ResolutionResult:
case = crm.get_case(case_id)
policy = policy_engine.evaluate(case, option)
if not policy.allowed:
return ResolutionResult(blocked=True, reason=policy.reason)
return resolution_service.execute(case, option, idempotency_key=case_id)
退款上限、退货窗口、黑名单和监管要求在策略服务中决定。模型看见的是允许选项，不是完整规则和数据库权限。
转人工必须是无损操作
当身份无法确认、客户情绪激烈、政策冲突或工具连续失败时，Agent 应立即生成交接包：客户诉求、已确认事实、已执行动作、失败原因、引用政策和下一建议。人工无需重问一遍。
{
"reason": "POLICY_CONFLICT",
"confirmed": ["order_delivered", "damage_photo_received"],
"actions": ["replacement_inventory_checked"],
"pending": "manager_override_for_refund",
"evidence": ["crm://case/8842", "policy://returns/v17"]
}
用一次解决率约束降本冲动
应同时监控首次联系解决率、平均处理时长、转人工率、重复来电率、错误执行率、退款损失、客户满意度和每单推理成本。只追求“机器人拦截率”会诱导 Agent 拖延升级，最终增加客户流失。
上线顺序应从员工辅助开始：自动汇总资料和推荐下一步；随后开放查询与低风险动作；最后仅对高置信、可逆场景自动闭环。客服 Agent 的目标是让人工专注同理心、协商和例外判断，而不是把所有客户挡在机器人之外。