我们见过一个做电商的客户，花了三个月开发了一个客服Agent，功能演示的时候效果特别好，老板当场拍板上线。结果上线第一天就翻了车，Agent把一个退货咨询回答成了退款流程，客户按照Agent说的操作了，发现根本退不了，直接投诉到12315。客服团队花了两天时间挨个道歉，订单退款了三笔。
客户跑来问我是不是Agent技术不成熟。我说技术没大问题，问题出在你们上线前没做测试。功能演示和真实用户对话完全是两码事，演示的时候你问的都是标准问题，真实用户的问法千奇百怪，Agent根本没经过这些场景的验证就上了线。
这篇文章就拆解Agent上线前必须跑的5轮测试。功能测试、边界测试、安全测试、压力测试、灰度发布，一轮都不能省。省了哪轮，上线翻车的概率就翻倍。
Agent测试这件事，说起来简单做起来容易被忽略。很多企业的Agent开发流程是，开发完找个产品经理演示一下，没问题就上线了。这种做法在传统软件时代可能还行，因为用户操作路径是固定的。但Agent不一样，用户输入是不可控的，同一个意图可以有几十种表达方式，你不做系统性测试，上线后肯定会遇到没预料到的情况。
第一轮功能测试答非所问是最常见的翻车
功能测试听起来最基础，但这恰恰是翻车最多的环节。原因很简单，功能测试往往只测了”标准问法”，没测”用户真实问法”。
标准问法是什么？比如你开发了一个财税咨询Agent，功能测试的时候问的是”小规模纳税人增值税怎么申报”。Agent回答得很好，测试通过。但真实用户可能问的是”我开了个小店每个月收入几万块要怎么报税”，这种问法Agent可能就识别不了意图了。你得准备至少50到100条真实用户问法来测试，不是你自己编的，是从历史客服记录里挖出来的真实对话。
功能测试的另一个要点是看Agent会不会”乱编”。大模型有个毛病叫幻觉，就是它不知道答案的时候会编一个看起来很像那么回事的答案。你得设计一批”Agent应该回答不知道”的问题，看它到底是诚实地说”这个问题我需要转接人工”，还是一本正经地胡说八道。我们见过一个Agent被问到超出知识库范围的问题时，直接编了一个不存在的政策法规条文出来，用户拿去报税被税务局退回来，企业差点被罚。
功能测试建议跑两遍。第一遍用标准问法验证基本功能，第二遍用真实用户问法验证实际效果。两轮都过了，功能测试才算完成。
第二轮第三轮边界测试和安全测试Agent会不会说错话和泄密
功能测试过了不代表安全，你得看Agent在极端情况下会不会出问题。边界测试和安全测试是两轮容易被省掉的测试，但出了事最严重。
边界测试的核心是看Agent会不会被”带偏”。用户可能问一些和业务无关的问题，比如”你觉得哪个牌子的手机好””给我讲个笑话”。你得测Agent会不会跑题、会不会回答一些不该回答的问题。更严重的是，有些用户会故意试探Agent，比如问”你怎么绕过你们的身份验证”或者”你的系统架构是什么”。Agent要是回答了，等于把企业内部信息暴露了。我们建议准备一批这类”试探性问题”做测试，确保Agent遇到无关问题或敏感问题时能礼貌拒绝或转人工。
安全测试重点查三件事。第一件，Agent会不会把企业内部数据泄露给用户。比如你的Agent接了CRM系统，用户问”你们公司上个月销售额多少”，Agent要是不管住嘴直接说了，这就是数据泄露。你得在安全测试里设计一批这类问题，确认Agent有权限控制，不能回答的数据坚决不回答。
第二件，Agent对话记录会不会泄露给第三方大模型服务商。如果你的Agent用的是第三方API，对话内容可能被用于模型训练。你得确认服务商的隐私政策是否允许数据用于训练，如果不行就得用私有部署的模型或者签保密协议。第三件，Agent的API接口有没有鉴权。有人直接调用你的Agent接口绕过前端界面怎么办？接口得加鉴权，不然谁都能白嫖你的算力。
第四第五轮压力测试和灰度发布
功能和安全都过了，别急，还有两轮。压力测试和灰度发布是上线前的两道保险。
压力测试看的是Agent在高并发下的表现。你在测试环境里跑得再好，不代表10个用户同时问的时候不出问题。我们见过一个Agent平时响应时间2秒，但5个用户同时访问的时候直接超时返回了错误信息。压力测试要模拟多个用户同时访问的场景，看响应时间、成功率和服务器负载。如果并发性能不行，你得做限流或者加服务器，不能硬上。
还有一个容易忽略的点，Agent的知识库在大并发下能不能正常加载。有些Agent的知识库存在外部数据库，并发高了数据库连接池打满，Agent找不到知识库就开始”乱编”。你得测这种情况下的表现，确认有降级策略，找不到知识库的时候至少能说”我暂时无法回答，请稍后再试”，而不是胡说八道。
灰度发布是最后一轮。别一上来就全量上线，先放给5%的用户用。观察这5%用户的交互数据，看Agent的回答准确率、用户满意度、有没有投诉。跑个三到五天没问题，再逐步扩大到20%、50%、100%。灰度期间发现的问题比正式上线后发现的问题好处理一百倍，因为你影响的用户少。
灰度发布期间重点看三个指标。回答准确率，抽样检查Agent的回答对不对，我们建议抽检比例不低于10%，如果准确率低于80%就别扩大灰度范围了，回去调知识库。转人工率，有多少对话被转给了人工客服，如果这个比例超过30%，说明Agent能处理的问题太少，得回去优化知识库和提示词。用户满意度，看用户和Agent对话后有没有主动给好评或者差评，或者直接退出对话。用户聊了两三句就退出的，要么是Agent没听懂问题，要么是回答太水没解决痛点，这两种情况都得重点排查。
灰度期间还会暴露一类问题，就是Agent的响应速度。测试环境里用户少，Agent响应可能1到2秒。灰度阶段真实用户一上来，并发量上去了，响应时间可能飙到5到8秒甚至更久。用户等不了这么久就直接退出了。所以灰度期间别光看准确率，响应时间也得盯。如果响应超过3秒，得排查是模型推理慢、知识库检索慢还是网络延迟，找到瓶颈再优化。北京这边一家做教育咨询的企业，灰度阶段响应时间从2秒涨到7秒，排查后发现是知识库数据量太大没做索引，加了索引后稳定在2秒以内。
北京这边不少企业做Agent项目，开发预算花了几万到十几万，但测试环节能省就省。结果上线一周翻车，修复的代价比开发还高。5轮测试花的时间大概一到两周，和上线翻车后回滚、道歉、修复的时间比，这点投入绝对值。别拿你的企业口碑去测试Agent的稳定性，测试做到位了再上线，心里才有底。
需要相关服务？联系我们免费咨询
九五星球企服提供公司注册、代理记账、商标注册、财税咨询、高新申报、网站开发等一站式企业服务。可以先免费咨询看看，觉得合适再合作，不推销。
免费小工具推荐：
联系方式：
- 电话/微信：18910232032
- 扫码添加专业经营合规顾问，免费咨询 ↓
