做智能体定制这行，我见过太多项目死在最后一公里。演示的时候业务方拍手叫好，上线跑不到一个月就蔫了，用户不买账、准确性拉胯、兜底全靠人工。前阵子和几个同行聊天，大家最头疼的都是同一件事：智能体定制怎么避免“演示很美、上线就废”。今天不聊模型选型那套虚的，直接给一份我自己项目里沉淀下来的评估清单，照着走查，能筛掉大部分上线即翻车的隐患。这篇东西适合正在做智能体交付的项目组、准备引入智能体定制的业务负责人，也适合那些被乙方Demo忽悠得心痒痒、但还没想清楚怎么验收的甲方。
1. 先搞明白：演示很美的智能体，为什么一上线就露馅
1.1 演示环境是“无菌实验室”，生产环境是“真实路面”
任何一个智能体定制项目，演示时都在一个高度理想化的环境里跑：数据是挑过的、用户问题是预埋的、系统是稳定的、网络是通畅的。可生产环境完全是另一回事。真实业务里，用户提问的表达千奇百怪，“帮我查一下那个订单”这种指代不明的输入每天能收到几百条；业务系统偶尔超时，接口偶尔返回乱格式；知识库里的文档更新不及时，甚至存在新旧两版矛盾的条款。
我举个例子。我们之前给一家物流公司做智能客服，演示时用的是标准的运单查询流程，用户输单号、查状态、反馈异常，非常顺滑。上线后第三天就出问题：用户说“我的快递怎么还没到”，系统没有单号，应该追问，结果模型直接默认了一个错误逻辑，回复“您的包裹已签收”。用户当场炸了。这就是典型的演示环境不会暴露的问题——现实业务里，用户不会按系统设计者的思路提问。
1.2 干净样例掩盖了“数据质量”这个真短板
演示时用的测试数据，基本是人工整理过的理想样本。字段完整、格式规范、语义清晰，喂给模型当然漂亮。但真实业务数据有多脏，我这边举三个最常见的例子：
- 用户输入夹杂口语、错别字和方言，“这个退了不要了，再下一单”；
- 图片类输入经常是歪的、反光的、模糊的，OCR解析直接降级；
- 数据库里的历史工单充斥着空值、错录、重复订单。
所以做智能体定制，首先要有一个清醒认知：模型再强，喂进去的数据不行，效果一定拉胯。这不是调参能解决的问题，需要从数据治理层面做功课，而不是指望换个更贵的模型就万事大吉。
1.3 演示者熟悉系统，真实用户有“一万种奇怪操作”
演示走查时，操作者大概率是项目的开发或产品，他们对系统的边界、问答逻辑、后台配置都了然于心。但真实用户不会看操作手册，也不会按照预设路径走。他们可能：
- 第一句不说单号，先说一长段抱怨；
- 对话进行到一半突然换话题；
- 要求智能体做超出权限范围的操作；
- 把客服机器人当成人工客服，输入“转人工”得不到响应就开骂。
说白了，真实用户的行为是不可预测的。评估一套智能体定制方案能不能上线，不能只看“设计好的问题能不能答好”，更要看“没设计过的问题会不会把系统带崩”。
2. 智能体定制评估第一关：模型能力别只看演示时的那几个问题
2.1 指令遵循与工具调用：连续跑50次看成功率
很多智能体定制项目号称“能调用工具”，演示时只是调一个接口查个订单。真实业务里，一个任务往往需要连续调用多个工具：查订单、查物流、查库存、计算退款金额、再写一条售后工单。中间任何一步工具的入参解析错了、调用顺序乱了，整个流程就断了。
评估方法很直接：准备一份覆盖核心流程的测试集，端到端连续跑50次，统计整体成功率。我见过的合格项目，50次里至少要有48次全流程跑通，换算下来95%。低于这个数，上线后用户体感会非常糟糕，因为哪怕10次里失败1次，对用户来说就是“这个客服不行”。
2.2 多轮记忆与主动澄清：真实对话不会一轮结束
演示时大多是一问一答，但真实用户经常连续说好几句话、会在对话中途追加条件。我建议在评估时专门设计几组“高难度多轮场景”，核心考察三件事：
- 对话超过10轮之后，模型还能不能记得最开始用户报的关键信息；
- 用户引入一个新的指代对象时，模型能不能正确关联上下文；
- 信息不足时，模型是主动追问澄清，还是硬着头皮瞎猜乱答。
我之前测过一个项目，用户报了个订单号要求改地址，客服小二改完地址后，用户又补了一句“顺便把那个赠品也换个颜色”，模型直接把上一个订单的赠品给改了，完全没确认是哪个订单。这种错误，演示时根本不会发生，因为演示脚本里不会有这种模糊指代。
2.3 幻觉与拒答的平衡：宁可说不知道，也不要硬编
做智能体定制，最怕的不是模型能力不足，而是模型“太自信”——明明知识库里没有，它也能给你编一个答案出来，而且语气还很笃定。这种幻觉，在演示时往往被忽略了，因为演示问题都在知识库覆盖范围内。真实上线后，用户会问各种奇奇怪怪的问题，模型遇到没见过的内容能不能明确说“不知道”并引导转人工，这比什么都重要。
评估时建议做一组“知识库外问题”专项测试，数量不少于50条，逐条看模型的拒答率和编造率。合格线是：编造率不能超过2%，拒答时必须有引导话术，推荐人工客服或标准求助路径。说实话，一个敢于承认“我不知道”的智能体，比一个硬撑着胡说的智能体可靠得多。
3. 智能体定制评估第二关：知识库和数据，才是RAG效果的真短板
3.1 用三个月的历史真实语料，做一次“脏数据走查”
所谓“RAG效果好不好”，多数人以为是检索算法或模型能力的问题，实际上80%的瓶颈在数据本身。做智能体定制的验收，我强烈建议拉出近三个月的历史真实对话记录或工单数据，抽样200条左右作为走查样本。抽样时不要挑好的，要尽量覆盖那些当初被判定为“难处理”“需人工介入”的记录。
把这两百条样本逐一喂给智能体，人工标注三类结果：完全解决、部分解决、没解决。最后算一个“真实解决率”。这个数字往往比演示时PPT里写的准确率低20到30个百分点，也正是这个差值，决定了上线后的用户口碑。
3.2 文档解析与检索粒度：PDF里的表格是重灾区
现在很多知识库还是以PDF、Word、扫描件为主，解析的时候问题特别多。尤其是PDF里的表格，转成文本后经常排版错乱，检索的时候根本匹配不到正确内容。更麻烦的是扫描件，OCR识别出来一堆乱码，再强的embedding模型也救不回来。
所以数据评估有一个笨办法：拿知识库里的原始文档，随机抽20份做解析测试，统计“解析后可检索质量”的比例。我自己的标准是，至少90%的文档解析后能保持语义完整，低于这个数，先别急着调检索，先把解析流程修好。
3.3 知识冲突、时效性与更新机制
业务文档经常存在新旧版本并存的情况，比如产品下市了，但旧说明文档还挂在知识库里。智能体检索时可能调出新版规则，也可能调到旧版规则，回复就无法保持一致。更头疼的是时效性问题：知识库里没有更新时间戳，模型永远拿旧信息回答用户，用户一看就是答非所问。
我之前评估过一个企业内部的HR智能体，员工问年假天数，知识库里同时存在旧员工手册和新年假制度，智能体有时答旧政策5天，有时答新政策10天。这种知识冲突，靠调模型参数根本解决不了，必须在知识入库环节建立版本管理与时效标记。评估时务必问清楚：知识库有没有负责人，有没有更新SOP，有没有冲突裁决机制。
3.4 权限与安全：智能体不能知道的，坚决隔离
智能体定制接入企业系统之后，往往会面临权限边界问题。用户直接问“帮我查一下某个同事的薪资”，或者试图让它执行未授权操作，智能体必须守得住红线。这个话题经常被忽略，但一旦上线，它就是合规和数据安全的重大风险点。
评估方法不复杂：列出敏感信息清单和越权操作场景，逐条测试智能体是否能够正确拒绝。更重要是的，接入企业内部系统时，接口层面要做权限管控，而不是单纯依赖模型的“自觉”。智能体意味着企业多了一个数据交互入口，这个入口该有的权限管控、操作审计、访问日志，一个都不能少。
4. 直接可抄的智能体定制评估清单：七个维度一次走查
4.1 七个维度的权重与设计逻辑
这份清单的核心思路很简单：把智能体当成一个“新入职员工”来验收。面试成绩好不能说明能力行，真正要看的是试用期表现、异常处理、对业务规则的熟悉程度，以及离开了老员工（人工客服）能不能独立干活。
我这边一般按七个维度来打分，每个维度满分5分，按权重加权计算总分。总评分4.5分以上才建议上线，3.5到4.5分建议整改后再上线，低于3.5分基本要回炉重做。
| 评估维度 | 权重 | 核心关注点 |
|---|---|---|
| 场景覆盖度 | 15% | 真实业务输入是否全面覆盖，长尾场景占比 |
| 模型基础能力 | 10% | 指令遵循、工具调用、多轮记忆、拒答能力 |
| 知识库与数据质量 | 25% | 文档解析、检索命中、知识冲突、更新机制 |
| 任务完成质量 | 20% | 端到端解决率、转人工率、平均交互轮数 |
| 异常处理与兜底 | 10% | 无法回答时的兜底话术、转人工路径、纠错机制 |
| 可观测性与运维 | 10% | 链路追踪、指标监控、对话回放、版本回滚 |
| 成本与维护模型 | 10% | 单次交互成本、内容维护人时、业务量增长模型 |
4.2 每个维度的具体评估问法
这七个维度如果只是“看报告”，基本等于没评估。我习惯把它转成一张“问问题清单”，走查时逐条过，每个问题都要有证据支撑：
- 场景覆盖度：有没有抽样跑过三个月真实数据？Top10高频场景是否都有对应测试用例？超出设计范围的输入占比是多少？
- 模型基础能力：连续调用工具50次的成功率是多少？10轮以上多轮对话的关键信息定位准确率是多少？模糊输入下主动追问的行为占比是多少？
- 知识库与数据质量：随机抽20份文档的解析通过率是多少？检索Top10命中率是多少？新旧知识冲突共有多少条？是否有明确的更新责任人与更新周期？
- 任务完成质量：端到端完全解决率是多少？转人工率是多少？平均解决一个问题需要几轮对话？
- 异常处理与兜底：知识库外问题测试50条的拒答率是多少？编造率是多少？转人工入口是否在任何界面都可达？
- 可观测性与运维：有没有对话链路追踪？有没有token消耗监控？有没有失败对话回放功能？模型和知识库的版本是否可回滚？
- 成本与维护模型：单次交互成本是否算清楚？知识库每次更新需要投入多少人力？业务量翻倍时成本是否线性增长？
这套问题，每一个都对应着上线后真实会遇到的情况，而不是验收PPT上的漂亮指标。
4.3 一次完整的清单走查，最少需要五天
走查这七个维度，不是半天能完事的。我的经验是，最少留出五整天：
- 第一天：准备数据。拉历史语料、抽真实样本、整理测试集、配对预期答案；
- 第二天：基础能力测试。跑指令遵循、工具调用、多轮对话、拒答测试，记录数据；
- 第三天：知识库走查。做解析测试、检索测试、知识冲突排查；
- 第四天：端到端任务测试。把完整业务场景从头到尾跑一遍，观察转人工率和解决率；
- 第五天：汇总打分、组织评审会、输出整改清单。
另外一个建议：走查时一定要让“没参与过项目的人”当验收员，最好是了解业务但不了解技术细节的真实用户代表。原因很简单，项目组自己测自己的东西，会下意识地绕过那些容易失败的场景，陌生人提的问题才是用户真实会问的问题。
5. 上线不是终点：把评估清单变成持续运营的一环
5.1 别直接全量上线，灰度跑两周再说
智能体定制的上线方式，我极其不推荐“一次性全量切换”。不管前期评估做得多充分，真实环境总有想不到的边角情况。稳妥的做法是灰度发布：先切5%左右的真实流量跑一到两周，密切观察三个关键指标的变化——转人工率、平均交互轮数、用户满意度评分。
如果灰度期间转人工率没有明显上升、平均交互轮数没有明显变长、满意度没有下滑，再逐步扩大到30%、50%，最后全量。这个过程听起来保守，但能避免“一上线用户就骂，运营团队连夜救火”的尴尬。
5.2 用户反馈闭环：把“不满意的答案”变成优化弹药
很多智能体定制项目有个通病：上线之后没有反馈收集机制，用户遇到错误答案只能默默关掉页面或者转人工，开发团队完全不知道自己做的东西在真实环境里表现如何。这等于盲人开车。
我强烈建议在界面上保留“有帮助/没帮助”按钮，在后台记录所有负面反馈对应的对话链路，每周安排专人抽看，把高频失败场景录入优化池，形成“反馈—标注—优化—回归”的闭环。智能体不是上线就完事的项目，它会随着用户使用慢慢进化。
5.3 回归测试集：防止修一个 bug 再造一个新问题
智能体定制上线后，知识库会更新、提示词会调整、模型版本也会升级。每次改动都有可能引入新的回归问题——之前答对的开始答错了，之前不幻觉的开始幻觉了。所以搭建一套固定的回归测试集非常关键。
这套回归集建议包含四类样本：核心业务场景100条、高频用户问答100条、知识库外问题50条、多轮复杂对话30条。每次改动后先跑一遍回归集，只要发现通过率下降，立刻定位原因，必要时回滚版本。这也是为什么在评估维度里强调“版本可回滚”，没有版本管理，出了问题是没法追溯的。
5.4 别忘了评估清单本身的版本迭代
我自己的习惯是，每做完一个智能体定制项目，都会把评估清单更新一版，把这次项目中新踩到的坑补进去。比如之前有一次做工业设备故障诊断，发现用户经常上传模糊的照片，后来就在“知识库数据质量”维度里增加了“图片类输入质量”的专项评估项。再比如做金融领域定制时，发现用户对智能体的用词严谨性极其敏感，一种说法稍有问题就投诉，于是“回答合规性”也单独成了评估维度。
这份清单不是死的，它应该跟着行业的实践一起长。这也是做智能体定制这件事最有意思的地方——没有一套标准答案能适配所有业务，但有问题清单和评估方法，能保证你前进的方向不会偏。
最后说一点我的真实体会：我做过这么多智能体定制项目，最容易被跳过、但损失最大的评估项其实是“多轮追问测试”。演示的时候大家都习惯把用户问题写得清清楚楚，可真实用户说话从来都是缺胳膊少腿的。你在评估清单里加一条“信息不足时智能体是否主动追问”，能帮你避免上线后至少三成以上的答非所问。这份清单，建议每个智能体定制项目从立项第一天就挂在墙上，别等演示完、上线前才想起来用。
性能评价指标体系与综合赋权方法)
