Agent接入电商微信客服后的质量保障不是写完代码上线就完事。需要一套测试和评估体系持续验证Agent的工具选择准确率、回复质量和用户体验。一、测试用例——从真实对话构建Agent的测试不能靠开发拍几个case验证要从真实对话数据里构建测试集。方法从客服对话历史里选200条有代表性的消息覆盖售前/订单/售后/闲聊四类人工标注每条消息的正确意图和正确工具选择。这200条就是回归测试集。每次Agent逻辑变更改提示词、加工具、调参数后跑一遍测试集对比变更前后的准确率。准确率下降说明改动有问题需要回退。二、准确率指标——三个维度工具选择准确率AI选对了工具的比例用户问物流→选了query_logistics而非query_order。目标85%。参数提取准确率AI从消息中提取的参数正确的比例订单号提对了地址提对了。目标90%。回复质量评分用户是否继续追问追问说明没答好、是否转人工转人工说明Agent没解决、是否用户确认操作确认率反映用户信任度。目标追问率15%转人工率10%。三、A/B测试——新旧版本对比Agent升级时不要直接替换旧版本。新旧版本同时跑50%消息走旧版Agent50%走新版。对比两个版本的准确率、响应时间、用户满意度。新版全面优于旧版才全量切换。A/B测试的分组要按用户随机分配同一用户始终走同一版本避免同一用户体验不一致。三个维度对照指标目标低于目标的动作工具选择85%优化提示词参数提取90%加正则辅助回复质量追问率15%扩充知识库质量保障实现# 测试集管理 TEST_CASES load_test_set() # 200条标注数据 def run_regression(): 回归测试 results {tool_acc: 0, param_acc: 0} correct_tool 0 correct_param 0 for case in TEST_CASES: # Agent处理 plan llm_plan(case[input], TOOLS) # 对比标注 if plan[tool_name] case[expected_tool]: correct_tool 1 if plan[params] case[expected_params]: correct_param 1 results[tool_acc] correct_tool / len(TEST_CASES) results[param_acc] correct_param / len(TEST_CASES) return results # A/B测试 def ab_route(wxid): 按用户分组 group hash(wxid) % 2 # 0或1 return new if group 0 else old def handle_with_ab(d): wxid d[fromUser] version ab_route(wxid) if version new: reply new_agent_handle(d) else: reply old_agent_handle(d) # 记录版本结果 db.save(ab_log, { wxid: wxid, version: version, input: d[content], reply: reply, time: now() }) return reply # 质量监控 def quality_report(): 日报三个维度 today today_str() total db.count(ab_log, datetoday) followup db.count_sql( SELECT COUNT(DISTINCT a.wxid) FROM ab_log a JOIN messages m ON a.wxid m.fromUser WHERE a.date ? AND m.createTime a.time, [today]) escalated db.count(ab_log, datetoday, reply_like%转接%) return { total: total, followup_rate: followup / max(total, 1), escalation_rate: escalated / max(total, 1) }落地建议质量保障体系的投入顺序先建测试集200条标注数据是一次性投入长期复用再做回归测试每次变更跑一遍最后上A/B测试需要流量支撑。准确率低于目标时先优化提示词成本最低再考虑加规则辅助。接口和Agent对接参考 Eyun 开发文档。