跨境电商客服智能体
把「查物流、答政策、判断该不该转人工」交给一个可核验的客服智能体：事实性回答只能来自工具返回或知识库原文，没有出处的答案不允许发给访客。
这是我们自建的演示项目，不是真实客户交付，也没有真实客户授权数据。公开它的目的有两个：一是验证我们自己的交付方法是否成立，二是让你在签约前就能看到我们怎么定义验收口径、怎么对待失败。 文中的方案取舍与坑位来自同类项目的共性经验，不是某个客户的实测记录； 评测尚未进行，因此页面只给口径与方法，不给结果数字——没有样本量的数字比留空更容易误导人，我们不做这种表述。
背景与场景
演示项目，非真实客户交付。场景取自跨境电商独立站的售前咨询与售后物流查询，问题集中在物流时效、退换货政策、尺码与库存、支付失败四类。
客户以欧美市场为主，时区跨度大。夜间与周末的咨询无人应答，等到次日回复时，客户往往已经流失。
选这个场景做样板的原因：它的数据可得性最好（历史会话、帮助中心文档、订单与物流 API 都能拿到），而且成功指标可以被明确定义，适合验证我们整套交付方法。
痛点拆解
用客户视角的原话
- 客服的时间大量消耗在重复问题与查物流单号上，这类问题本身几乎不产生价值
- 夜间和周末无人值班，响应延迟直接转化成订单流失
- 多语言靠翻译软件应付，专业术语与政策表述容易出错
- 知识散落在帮助中心、FAQ 文档、客服聊天记录三处，没有统一来源
技术方案
以及为什么这样取舍
核心技术路线用检索增强（RAG），不做模型微调
物流时效和退换货政策变动频繁，微调意味着每次政策更新都要重训，知识更新的成本不可接受。RAG 只需更新知识库文档即可生效。
订单与物流状态一律走 API 实时查询，不依赖模型记忆
让模型「记住」物流状态必然产生编造。所有涉及具体单号的事实性问题，都必须来自工具返回的真实数据。
退款金额、投诉、法务、账户安全四类话题强制转人工，不允许 Agent 自主决策
这四类话题一旦出错，代价远超节省的人力成本。人机分工的设计顺序是：先定义「什么情况必须转人工」，再定义能力边界。
一套知识库 + 提示词层做语言适配，不维护四套知识库
多语言场景下，分别维护英/德/法/西四套知识库必然出现政策不一致。统一知识源、只在输出层做语言适配，可以保证政策口径唯一。
这类项目最容易踩的坑
同类项目的共性经验，非本项目实测记录
坑 1
物流 API 在高峰期超时，Agent 拿不到数据时会顺着上下文「编」一个预计到达时间——这是最危险的一类失败，因为回答读起来完全合理。
怎么解决的
工具调用设超时阈值，失败时强制降级为固定话术并转人工，禁止模型在缺少工具返回值时自行推测事实。同时在评测集中专门加入「API 故障」用例做回归测试。
坑 2
帮助中心文档与实际客服话术不一致——退货窗口政策已经更新，但文档没改，Agent 照旧文档回答，导致答得「有据可查」却是错的。
怎么解决的
知识库引入版本号与生效日期字段，检索时按日期过滤过期条目，并增加冲突检测：同一问题检索到多个互相矛盾的政策段落时，直接转人工并告警。
坑 3
评测样本量不足、又不做分层时，一次解决率会被高频简单问题拉高：样本里查物流这类问题占比过高，就很容易得出「效果很好」的错觉。
怎么解决的
评测集按问题类型分层抽样，并分层报告各类指标，不只看总体均值。样本量与抽样方式必须写进评测报告——这也是我们把它直接写进验收口径的原因。
验收指标与评测方法
尚未实测，只给口径不给数字
这个项目我们还没有跑成体系的评测，所以这里只写「准备怎么量」，不写「量出来是多少」。没有样本量的数字比留空更容易误导人——那正是我们不提供估算值的原因。评测完成后，样本量与判定方式会一并补在这里。
| 指标与口径 | 怎么测 |
|---|---|
| 一次解决率口径：单轮会话内未转人工，且访客未就同一问题继续追问，即计为一次解决；只要发生转人工或同题追问即判为未解决。 | 从历史会话中按问题类型（物流、退换货政策、尺码库存、支付失败）分层抽样，每类不少于 50 条、合计不少于 300 条；由业务方与我们一起人工判定，判定标准在开测前书面确认。 |
| 平均首次响应时间口径：访客发出消息至收到首次有效回复的时间差，不含自动欢迎语。 | 对同一批评测会话读取时间戳直接计算，不需要额外标注。 |
| 转人工率口径：触发强制转人工规则、或 Agent 主动判定无法处理而转出的会话占比。 | 同一批会话中统计转出条数占比，并按触发原因（规则命中 / 主动判定）分开报告——两者的含义完全不同，混在一起看会得出错误结论。 |
| 政策类回答准确率口径：判定回答内容与当时生效的最新政策是否一致；表述方式不同但政策正确，计为准确。 | 从政策类问答中抽 100 条，双人独立标注、分歧由第三人裁定。这是我们预期会低于人工的指标，验收线单独约定，不与其它指标混在一起算总分。 |
| 平均对话轮次口径：解决单个问题所需的往返轮次，含最终确认轮。 | 从同一批会话统计。轮次异常偏高的会话要单独挑出来看，那通常是知识库缺条目的信号，而不是对话设计的问题。 |
一次解决率
口径：单轮会话内未转人工，且访客未就同一问题继续追问，即计为一次解决；只要发生转人工或同题追问即判为未解决。
怎么测：从历史会话中按问题类型（物流、退换货政策、尺码库存、支付失败）分层抽样，每类不少于 50 条、合计不少于 300 条；由业务方与我们一起人工判定，判定标准在开测前书面确认。
平均首次响应时间
口径：访客发出消息至收到首次有效回复的时间差，不含自动欢迎语。
怎么测：对同一批评测会话读取时间戳直接计算，不需要额外标注。
转人工率
口径：触发强制转人工规则、或 Agent 主动判定无法处理而转出的会话占比。
怎么测：同一批会话中统计转出条数占比，并按触发原因（规则命中 / 主动判定）分开报告——两者的含义完全不同，混在一起看会得出错误结论。
政策类回答准确率
口径：判定回答内容与当时生效的最新政策是否一致；表述方式不同但政策正确，计为准确。
怎么测：从政策类问答中抽 100 条，双人独立标注、分歧由第三人裁定。这是我们预期会低于人工的指标，验收线单独约定，不与其它指标混在一起算总分。
平均对话轮次
口径：解决单个问题所需的往返轮次，含最终确认轮。
怎么测：从同一批会话统计。轮次异常偏高的会话要单独挑出来看，那通常是知识库缺条目的信号，而不是对话设计的问题。
说明
这个项目还没有跑成体系的评测，所以上面只有口径、没有结果数字。先把口径公开，是因为它本身就是方案的一部分：签约前你就该知道我们打算怎么量、样本怎么抽、由谁判定，而不是等交付时再看一份无法核对的报告。等评测跑完，样本量与判定方式会一并补在这里；在那之前我们不提供任何结果数字——没有样本量的百分比比留空更容易误导人。
已知局限
什么情况下这个方案不适用
- 不适用于高客单价定制类咨询——这类咨询需要销售做判断和议价，Agent 只能做信息收集
- 不适用于强监管品类：医疗声称、金融产品介绍等合规敏感回复必须经法务审核，不应交由模型生成
- 知识库质量就是效果天花板：源文档本身混乱时，必须先做知识治理，Agent 的表现不会超过知识本身的质量
- 多语言场景下，非英语语种的政策类准确率通常低于英语。具体低多少必须按目标语种单独评测，不能拿英语的结果外推
- 离线评测不能代表上线效果：真实流量会随季节、促销、物流异常而变化。要确认线上表现必须做灰度对照，而这需要真实流量，演示项目阶段做不到
可复现性与下一步
评测集与标注规则：真实项目里评测集由我们与客户共同确定、留在客户侧；我们交付的是抽样与标注规则本身，不带走你的会话数据
评测脚本与分层抽样方法可在诊断阶段一并交付，便于客户用自己的数据复现同一套口径
如果你有相似的客服场景，建议先做一次 30 分钟初诊——我们会先判断这件事值不值得做，再谈交付
这个项目的评测集对我们意味着什么
评测集是我们交付物的一部分。项目结束时它归你所有——包括判定口径和失败案例。 这样即使将来不再合作，你也有能力自己判断效果是否衰减。