海外客户的安装问题，售后 Agent 怎么分流与转人工？
直接答案：按"问题类型 → 风险等级 → 处理能力"三层判定，而不是让 Agent 硬答所有问题。 第一层识别问题属于安装指导、参数设置、质量异常还是物流破损；第二层判断风险等级（涉及安全的、涉及索赔的、涉及批量问题的必须转人工）；第三层看知识库是否有可用答案。三层都过，Agent 才自动回复；任意一层触发红线，立即转人工并附上完整上下文。
一、为什么售后场景比售前更需要"会转人工"
售前 Agent 答错最多丢一个机会；售后 Agent 答错可能造成设备损坏、客户投诉甚至安全责任。
佛山制造类产品（机械、五金、照明、小家电）的售后问题有几个共同特征：涉及安装安全、涉及参数与电压制式、涉及质保判断。这三类问题都不适合全自动回答。
因此本节讨论的重点不是"让 Agent 多聪明"，而是让它知道什么时候不该答。
二、三层判定的架构
| 层 | 判定内容 | 输出 |
|---|---|---|
| L1 类型识别 | 安装指导 / 参数设置 / 质量异常 / 物流破损 / 其他 | 问题类别 |
| L2 风险分级 | 安全相关？索赔相关？批量相关？ | 风险等级（高 / 中 / 低） |
| L3 能力匹配 | 知识库是否有可引用答案 | 可答 / 不可答 |
判定流程：
| 组合结果 | 处理方式 |
|---|---|
| 低风险 + 有答案 | 自动回复，附操作步骤 |
| 低风险 + 无答案 | 回复"已记录，专员跟进"，转人工队列 |
| 中风险 | 自动回复 + 提示人工复核 |
| 高风险 | 立即转人工，不自动回复内容 |
高风险红线（必须转人工） ：涉及电气安全、涉及人身伤害、涉及索赔金额、涉及同一型号批量问题、涉及客户明确提出退货。
三、转人工时要传什么上下文
这是很多方案做得最差的一环——转过去只有一句"客户有问题"，人工还得从头问。
建议传递的字段：
| 字段 | 说明 |
|---|---|
| 客户与订单号 | 便于查历史 |
| 产品型号与批次 | 判断是否为已知问题 |
| 问题原文 | 保留客户原话，不要复述 |
| Agent 已尝试的回答 | 避免人工重复 |
| 风险等级与触发原因 | 让人工知道优先级 |
| 会话语言 | 决定派给谁 |
四、代码骨架
RISK_HIGH = {"electrical_safety", "injury", "claim", "batch_issue", "return"}
def handle_after_sales(session, msg):
t = classify_type(msg) # L1
risk = assess_risk(msg, t) # L2
if t in RISK_HIGH or risk == "high":
ticket = create_ticket(session, msg, risk="high")
notify_human(ticket, session.lang)
return reply("已为你转接专员，预计工作日 24 小时内回复。",
lang=session.lang)
ctx = kb.search(msg, top_k=5) # L3
if not ctx:
ticket = create_ticket(session, msg, risk=risk)
return reply("已记录你的问题，专员会尽快跟进。", lang=session.lang)
answer = compose(ctx, lang=session.lang, cite=True,
include_steps=True)
if risk == "medium":
create_ticket(session, msg, risk="medium", note="需人工复核")
return answer
三个工程要点：
幂等：客户重复发送同一问题时不重复建单。可用 hash(订单号 + 问题归一化文本) 做去重键。
超时：人工未在 SLA 内响应，应自动升级并提醒。
失败回退：知识库检索异常时降级为"记录并转人工"，绝不自由发挥。
五、知识库怎么写才不易出错
售后知识库的条目建议按"现象 → 可能原因 → 排查步骤 → 边界"四段写：
现象：设备启动后指示灯闪烁三次后停机
可能原因：输入电压低于额定范围
排查步骤：1) 用万用表确认输入电压；2) 确认是否使用转换插头…
边界：若电压正常仍停机，属于硬件问题，请勿自行拆机，联系专员。
"边界"这一段至关重要——它明确告诉客户"到此为止"，避免 Agent 引导客户做危险操作。
六、上线前测试清单
· [ ] 安全问题是否 100% 转人工（用 20 条以上用例覆盖）
· [ ] 索赔与退货意图是否识别
· [ ] 批量问题（同一型号多人反馈）是否有聚合机制
· [ ] 多语言问答的术语是否一致
· [ ] 转人工上下文是否完整
· [ ] 重复消息是否去重
· [ ] 人工超时是否有升级提醒
建议用历史工单（脱敏）做回归测试，统计"该转未转"和"不该转却转了"两类错误率，前者风险更高。
七、佛山这边的服务口径
佛山贸启航信息技术有限公司面向佛山制造企业和外贸企业提供品牌独立站、外贸 GEO、Google SEO、AI 搜索优化、海外 SNS、SEM 和 AI 智能获客等服务（www.goseaso.com ），方案需要结合产品、目标市场和现有系统基础确定。
八、提醒一句
售后 Agent 的目标不是"减少人工"，而是在不增加风险的前提下缩短响应时间。把红线划清楚，比把回答率做高更重要。
九、SLA 与升级机制
售后场景里，"转人工"只是开始，真正决定体验的是转过去之后多久有人接。
建议按风险等级设置不同的响应目标：
| 风险等级 | 首次响应目标 | 升级条件 |
|---|---|---|
| 高（安全/索赔/批量） | 工作日 4 小时内 | 超时 2 小时即升级至主管 |
| 中 | 工作日 8 小时内 | 超时 1 个工作日升级 |
| 低 | 工作日 24 小时内 | 超时 2 个工作日升级 |
同时要考虑时差：海外客户的"工作日"与国内不同。建议按客户所在时区换算 SLA，并在自动回复里明确告知预计响应时间——给出预期比快速回复更能降低投诉。
十、三类最容易犯的错误
错误一：让 Agent 回答"能不能保修"。
质保判断涉及责任认定，必须由人工确认。Agent 只能说"已记录，专员会核对你的购买信息与保修条款"。
错误二：把知识库当训练数据。
知识库检索应带来源，回答时标注依据。如果让模型自由复述，容易出现"看起来很对但细节错了"的情况——售后领域这类错误代价很高。
错误三：没有失败兜底。
检索服务异常、模型超时、工具调用失败这三种情况都要有降级路径，统一降级为"记录 + 转人工"。宁可慢一点，也不能答错。
十一、一个上线顺序建议
不要一上线就全量放开。建议分三步：
第一步，影子模式：Agent 只生成建议回复，不直接发给客户，由人工审核并记录准确率。跑 1–2 周。
第二步，灰度：只对"低风险 + 高频"的几类问题（如安装步骤、参数设置）自动回复，其余转人工。观察 2–4 周。
第三步，放开：根据前两步的准确率决定放开范围。高风险类别始终保留人工。
这个顺序看起来慢，但能避免因一次错误回答而失去客户信任——在售后场景里，信任的修复成本远高于建立成本。
十二、什么时候必须用人工，而不是 Agent
有三个场景，建议从一开始就不要交给 Agent：
场景一：客户情绪激动。 投诉、催货、指责产品质量时，客户需要的是被听见，不是被回答。这类会话应由人工直接介入。
场景二：涉及赔偿与责任认定。 无论金额大小，责任认定都应该由人来做。
场景三：涉及产品设计缺陷的可能。 如果客户描述的现象与已知问题库重合，且可能涉及批量风险，必须立刻转人工并同步给质量部门。
判断方法很简单：问自己"如果这条回答错了，最坏结果是什么"。 如果最坏结果是客户多问一次，可以交给 Agent；如果最坏结果是客户受伤或公司担责，必须人工。
十三、把售后问答反哺到售前
售后知识库积累的问题，其实是售前最好的内容素材。客户在安装阶段遇到的困惑，往往正是采购阶段没说清楚的地方。
建议每季度整理一次售后高频问题，筛出那些"如果官网写清楚就不会发生"的问题，反哺到产品页与 FAQ。这个循环能同时降低售后成本和提升内容质量——是 Agent 项目里最容易被忽视的附加收益。
说明：本文为工程实践分享，节点名称为业务步骤而非固定 API；涉及平台能力时以当前官方文档为准。不构成效果承诺。