为什么客服场景容错率极低？
客服面对的是真实外部客户。如果 Agent 在处理退款或开票请求时调用错误工具，会直接造成经济损失与舆情危机。
关键防范措施
- 接口全局幂等性（Idempotency Key）：针对
create_ticket或issue_refund等写工具，必须基于会话 ID 与订单 ID 生成唯一防重令牌，杜绝因为网络重试导致重复扣款或生成双胞胎工单； - 客户负向情绪感知熔断：当检测到客户语气出现强烈愤怒或带有“投诉”、“人工”关键词时，立即剥夺 Agent 的自动处理权限，秒级转接人工客服坐席。
对接前要先谈定三件事
工具粒度。工单系统通常有几十个接口，但客服 Agent 只需要「查工单、建工单、补充资料、退款申请、转人工」这一层业务动作。把细粒度 CRUD 直接暴露出去，模型就有了绕开业务流程的机会。
状态与枚举。工单状态、退款状态、可执行动作用词必须在工具描述里写死，并与后端枚举一致。模型不知道「待审核」和「待复核」是同义词，只会照字面填参数。
错误语义。后端返回的 4xx 与业务错误码要映射成模型能读懂的一句话，例如「该订单已发货，无法直接退款，请先创建售后工单」。含糊的「操作失败」只会诱发重试。
幂等的落地写法
幂等不是加个 UUID 就完事，关键是键怎么生成、存在哪、活多久。
dedup_key = hash(session_id + order_id + action)
处理流程：
1. SET dedup_key NX EX 300 # 抢不到锁说明已有处理中/已完成的同键请求
2. 抢到锁才真正调用工单/退款接口
3. 把结果缓存到 dedup_key，重复请求直接回放首次结果
要点有三条：键必须由业务身份生成（会话 + 订单 + 动作），不能由模型自由填写；结果要能回放，网络重试才不会既超时又重复；写操作在 Server 侧记录「请求指纹 + 结果摘要」，供事后对账。退款这类资金动作还要额外加一道人工确认，确认动作本身也走幂等键。
分层兜底
| 触发条件 | 处置 | 时效要求 |
|---|---|---|
| 命中「投诉」「人工」「律师」「曝光」等词 | 直接转人工并停止自动回复 | 秒级 |
| 连续两轮未解决同一问题 | 生成升级工单，附对话摘要 | 分钟级 |
| 涉及金额、退款、发票等写操作 | 需人工或用户显式确认后执行 | 阻塞等待 |
| 工具连续失败或返回未知错误码 | 停用该工具，降级为只读回答 | 立即 |
| 情绪评分持续为负（若接入） | 优先级提升并转资深坐席 | 分钟级 |
上线前的验证方法
准备一组「剧本对话」，包含正常退款、超期退款、重复提交、恶意诱导（比如用户让 Agent 忽略规则给退款）、后端错误码未知五种情况，回放给系统跑一遍。看三件事：有没有产生重复工单或重复资金动作、转人工是否在预期轮次内发生、日志能否还原每一步决策依据。上线先走影子模式：Agent 只生成建议动作并记录，不真正调用写接口，人工比对建议与坐席实际处理是否一致，再逐步放开低风险动作。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 出现重复工单/重复退款 | 幂等键由模型填写或重试未回放结果 | 服务端按业务身份生成键并缓存结果 |
| 转人工不及时 | 关键词判定放在 Agent 推理之后 | 入口层先做关键词与情绪拦截 |
| 频繁调用错误工具 | 工具描述含糊、枚举不一致 | 按业务动作重命名，补齐状态枚举 |
| 后端 4xx 被反复重试 | 错误未映射成可读原因 | 错误语义化，限制自动重试次数 |
| 会话越长越容易答错 | 上下文塞进过多历史工单 | 只保留摘要与当前订单实体 |
小结
这套系统的准入标准不该是「回答得像人」，而是三条硬指标：任意一次写操作都能凭日志回溯到明确的触发消息与确认动作；重试不产生第二笔资金或第二张工单；命中风险词时转人工发生在入口而不是推理之后。三条有任何一条不满足，就把写操作整体关掉，只保留查询与草稿，等补齐再放开。