智能体定制评估清单：从演示到生产落地的关键方法

演示之前，我们围在电脑前看智能体流畅作答，每个人都很兴奋；上线之后，同一个智能体在真实用户面前频繁“翻车”，从“聪明助手”变成“人工智障”。过去一年我参与评估了十几个智能体定制项目，几乎每一家都碰到过这个尴尬：明明演示的时候一切完美，为什么一到生产环境就废了？

这篇博文不讨论某个具体智能体怎么搭，而是从甲方和乙方都很容易忽略的“评估”环节切入，整理一份我自己反复打磨过的智能体定制评估清单。内容涵盖场景边界、数据与知识、评测体系、人机协同、可观测性、成本与性能和合规安全七个维度，并给出从演示到灰度、再到正式上线的完整验证方法。适合正在做企业级AI落地、智能体定制开发或采购智能体解决方案的人，尤其建议先把“要不要做、做成什么样算成”想清楚再看清单。

1. “演示很美、上线就废”是怎么发生的

我复盘过不少翻车项目，发现大家踩的坑高度相似。与其一个个案例讲，不如把问题归成三类，每一类都对应一个很具体的“为什么”。

1.1 翻车现场一：演示集“精心准备”，真实输入“百无禁忌”

演示的时候，我们通常会准备几条“标准问题”，比如拿着制度条例学习助手，就先问“年假可以休几天”，答案从库里检索出来，干净利落。这种演示本质上是在“已知的已知”里跑通流程，只证明了一件事：如果用户完全按照我们预期的方式提问，智能体可以给出预期答案。

但真实世界的输入完全不是这样。员工不会乖乖说“年假可以休几天”，他会问“我去年还有5天假，今年能攒到明天一起休吗”“请假流程卡在经理审批那里两天了怎么回事”，甚至直接发一段口语化的语音转文字。这些输入不在演示集里，检索召回不到准确内容，模型就开始“一本正经地胡说八道”。

这不是模型在偷懒，而是我们在定制阶段根本没有定义清楚“边界”。当你没有告诉智能体什么不该回答、什么情况应该转人工，它就只能对所有输入都尽力作答，而这个“尽力”在生产环境里等于失控。

1.2 翻车现场二：知识库“看起来全”，用起来“找不到北”

很多智能体项目走RAG路线，把企业文档灌进知识库就以为万事大吉。演示的时候知识条目少，几十条里随便一检就能命中；到了生产环境，知识库几千几万条，检索器的召回精度立刻暴露问题——top-k取回的不是用户想要的片段，生成模块又没有判断能力，只能硬着头皮组合答案。

比召回不到更坑的是知识冲突。两个部门文档对同一件事说法不一致，比如一个写“审批时限3个工作日”，另一个写“审批时限5个工作日”，知识库两条都检索到了，智能体到底以哪条为准？大部分项目没有定义冲突仲裁规则，结果同一个问题，上午答3个工作日、下午答5个工作日，业务方当场炸锅。

我还见过更隐蔽的情况：知识权限没隔离。普通员工能问出内部管理文档里的敏感条款，这就是“敏感变量”问题——检索层没做权限过滤，知识库里的敏感知识和可见范围没有绑定。这类问题在演示时根本看不出来，因为演示数据经过筛选，线上数据才是真实数据。

1.3 翻车现场三：功能做完就认为“完事”，没有评测与回归防线

最让我头疼的，是那种“智能体demo跑通了就约等于项目交付了”的团队。没有离线评测集，没有回归机制，没有效果基线。上线后业务方提需求，改一句prompt让智能体语气更亲切，结果A场景确实亲切了，B场景也跟着把严肃的制度条款回答变成了“亲，这个问题是这样的哦”，整个项目的专业感全没了。

智能体是一个多模型、多Agent、多工具组合的复杂系统，任何一个环节调整都可能影响全局。这就像改一段老代码，没有单元测试和CI在背后兜底，谁都不敢保证改完不炸。传统软件工程早就靠“测试网”保护质量，但很多智能体项目还在靠感觉验收，这就是“上线就废”的制度性根源。

2. 定制智能体前的评估清单：七个维度，拿到需求先逐条过

既然问题这么集中，解决方案也就不玄乎：在项目启动前、POC阶段和上线前，逐项用同一套标准去卡。下面这份清单我用了很久，每个维度都对应一个“怎么问、什么算过、怎么查”的具体操作。

2.1 七个核心维度速查表

这张表不是给你贴墙上看的，是让你在开工会第一天就拿出来跟业务方、技术方一起过。如果任何一个维度还是空白，这个项目就不该急着进开发。

2.2 给“边界”祛魅：明确智能体不做什么，比能做什么更值钱

很多业务方提需求，张口就是“都想做”。一个制度条例学习助手，要不要回答天气？要不要陪员工闲聊？要不要处理投诉情绪？每一件事加上去，都要消耗评测样本、模型能力和维护成本，而且会污染核心场景的效果。

我在定制项目里最常用的一招，是逼着业务方提前写“红队问题集”。专门准备20到30条边界外的问题，比如制度条例助手里混进“今天天气怎么样”“帮我写周报”“你觉得自己聪明吗”，然后拿着这些边界外问题去测智能体的兜底话术。通过标准很简单：边界外问题不乱答，错误回复率低于5%。

“我不知道”也是一种有效回答。一个敢说“这个问题超出我的范围，请转人工”的智能体，比一个什么都能聊两句的智能体可靠得多。定制的时候一定要把这种拒绝能力写进prompt和工作流，否则你等来的就是各种自由发挥。

2.3 给“评测”立规矩：从拍脑袋打分到量化基线

不少团队验收智能体，方式是“让业务负责人现场点几个问题，看着OK就签收”。这本质上还是演示思维。我建议把效果指标量化成至少三个数，写进验收标准。

以制度条例学习助手为例，最关键的三项指标：

• 检索命中率（Recall@5）：用户问一个问题，知识库前5条结果里是否包含正确答案。建议不低于85%。
• 答案正确率：智能体最终生成回答中，符合知识库依据且表述准确的比例。建议不低于90%。
• 边界外误答率：不属于本场景的问题，智能体错误作答的比例。建议不高于5%。

答案正确率不能靠感觉，要抽检。具体做法是：从评测集随机抽30条，由两个熟悉业务的人分别打标，一个人判“正确”，另一个人判“存疑”，不一致的交给业务负责人仲裁。这样既能拿到一个相对可信的正确率数字，也能暴露评测标准本身的模糊点。

如果连这三个数都拿不出来，不要上线。上线不是功能开发完成的终点，而是效果验证的起点，没有基线数据，后面所有迭代都是盲人摸象。

3. 从一个演示原型到稳定上线：分阶段的验证与放量策略

有了评估清单，还要把评估嵌进项目节奏里。智能体定制和传统软件开发最大的区别是：传统软件功能是确定的，智能体的行为概率性很强，所以必须用“分阶段验证”来对冲这种不确定性。

3.1 四个阶段的主要目标与通过标准

这里面的核心原则是：每个阶段都必须有明确的“过/不过”标准，不过就是不过，可以回退、可以调整，但绝不能“先上看看”。智能体一旦面对真实用户，坏口碑传播速度远超预期。

3.2 POC封板阶段的“五固定”原则

很多项目在POC阶段效果不错，一到生产环境就飘，很大原因是POC阶段的变量没锁死。我总结了一个“五固定”原则，强烈建议你在POC封板时严格执行：

• 固定评测集：版本号写入评测集文件名，比如eval_set_v1.0.json，改一条都要升版本。
• 固定Prompt：不允许口头临时调整，所有prompt变更必须走审批并记录。
• 固定模型版本：平台更新底层模型是“悄悄升级”，必须显式锁定版本或记录版本号。
• 固定参数：temperature、top_p、max_tokens等全部记录，防止换环境后参数被重置。
• 固定知识库版本：上线前知识库冻结，新增内容走增量更新流程，而不是随时乱灌。

为什么要这么严格？因为智能体效果是所有这些变量共同作用的结果。变量不锁定，今天测出来的90分和明天测出来的80分根本没法对比，你还不知道是哪个环节变了。

我在一个项目里就吃过亏：POC通过后，平台自动升级了底层模型，结果同一个评测集，所有指标降了五六个点，团队花了三天才定位到是模型版本变了。从那以后，“五固定”成了标配。

3.3 灰度放量的五级闸门

正式上线别搞“Big Bang”，哪怕老板催得再急，也要走灰度。我的经验是分五级放量，每一级至少观察48小时，用数据说话。

• 5%流量：主要看基础设施稳定性，有没有报错、超时、成本暴涨。这个阶段指标不好看很正常，样本小。
• 20%流量：开始看核心指标，转人工率、答案正确率、边界外误答率，对比POC基线。如果明显变差，立刻回滚排查。
• 50%流量：看满意度反馈和用户留存，有条件的话做问卷或满意度按钮。
• 100%全量：全量放开，但必须保留一键回滚开关，随时能回到50%或更小流量。
• 上线后首周：每天抽检，第二周开始按周归档，形成常态化运营。

灰度期间的人工抽检也有技巧。不要随机乱抽，要按场景分层抽：核心业务问题抽一部分、边界外问题抽一部分、知识库冷门内容抽一部分。每天30条，标成正确/错误/存疑三档，存疑的case进入评测集候选池，下周补充进回归集。这样每一周评测集都会随着真实数据变厚，智能体的“免疫系统”也在不断增强。

3.4 上线不等于结束：运营期的持续评测节奏

智能体上线只是开始。知识库在更新、业务规则在调整、用户问法在变化，如果评测集不跟着长，智能体就会慢慢“过时”。我建议上线后固定每周做三件事：

• 拿本周真实对话日志补充评测集，每周新增至少10条有代表性的样本。
• 跑一次全量回归评测，确保prompt、模型、知识库的任何变更没有破坏既有能力。
• 开一个半小时的效果复盘会，业务方和技术方一起看错误case，确定下周迭代优先级。

这个节奏跑起来以后，项目的稳定性会明显上一个台阶。“上线就废”的项目，绝大多数不是死在某一个技术上，而是死在“上线之后没人管”。

4. 评测集与工具链：让评估不依赖“个人感觉”

评估清单要落地，离不开两个基础设施：评测集和工具链。前者解决了“拿什么测”，后者解决了“怎么测”。

4.1 评测集建设的完整实操方法

评测集是智能体项目的“测试网”。它不需要一开始就很大，但必须长在真实数据的土壤上。

评测集来源主要有四个：

• 企业真实对话日志脱敏：最有价值，真实问法千奇百怪，直接反映生产环境。
• 业务专家编写：覆盖核心流程和常见问法，保证“该会的都会”。
• 用户访谈和反馈：用户问过但智能体答错的case，是最高优先级的评测样本。
• 公开Benchmark做种子：比如通用问答集，适合冷启动阶段。

评测集的结构不要只放问题和答案，要带完整字段。下面是我常用的格式，供参考：

{ "id": "EVAL_00123", "scene": "制度条例-休假申请", "difficulty": "hard", "input": "我去年剩了3天年假，今年能一起休吗？", "expected_behavior": "引用年假管理制度中关于跨年结转的条款，说明结转条件和上限", "judge_rule": "答案引用正确条款，且明确说明结转上限为5个工作日", "knowledge_ref": "docs/HR-2024-年假管理制度.docx#第三章", "source": "user_log_20250115" }

expected_behavior和judge_rule这两个字段很关键。前者是给人类标注者看的，后者是给自动评估判分逻辑用的。评测条目要打场景标签和难度标签，方便后续按场景分析哪一类问题最薄弱，针对性补强。

样本量方面，我的建议是核心场景至少100条起步。50条可以跑通框架，100条能基本反映效果，要做到比较可信的回归，200到500条比较理想。标注一致性也是硬指标，两条标注结果的一致性至少到0.7（Cohen’s Kappa），否则说明标准本身没对齐，需要先统一判定规则。

4.2 主流智能体平台与工具链选型对比

评测集有了，还得有一套工具能把评测跑起来。市面上常用的智能体平台和框架我大致列一下，各有收益也各有约束：

选型的时候不要只盯着演示好看，要针对评估清单的七个维度去问厂商。我用四个问题就能快速筛掉一半不合格的平台：

• 能不能导出完整trace（比如一次回答检索了哪些知识、调用了哪些工具、每一步的token和时间）？
• 有没有内置评测模块，能不能接入自定义评测集？
• 权限模型是不是基于角色的，敏感知识能不能按用户维度隔离？
• 日志保留策略和审计能力是否满足合规要求？

这四个问题答不利索的平台，哪怕构建功能再炫，上线后你也查不出问题在哪，更谈不上持续优化。

4.3 开源还是商业平台：看四件事再做决定

开源框架和商业平台各有拥趸，我不站队，只建议你按四件事判断：

第一是团队运维能力。有专职AI工程师，自研完全可行；没有专职运维，商业平台省心得多。第二是评测体系。自研最大的好处是可以把评测完全嵌进CI/CD，商业平台则要确认评测能力是否开放。第三是安全合规要求。对数据出域敏感的项目，私有化部署几乎是必选项，这一条会直接排除掉很多SaaS方案。第四是长期成本。自研的隐性成本常常被低估，模型迭代、知识库维护、prompt治理都需要人，算总账再拍板。

5. 行业共识：2026年是智能体从演示走向工程化的分水岭

这几年智能体Demo遍地都是，但真正能稳定跑在生产环境里的少之又少。行业大会上越来越多的人在讨论一个判断：2026年是智能体从概念演示走向工程化落地的分水岭。我理解这个判断背后是三件事在同时发生。

第一，基础设施成熟了。模型API服务趋于稳定，Dify、RAGFlow这类工具链开始补上评测、监控和权限管理能力，让“评估”这件事从手工作坊变成了标准动作。第二，企业预期修正了。前两年很多人幻想全自动智能体，现在大家接受了“人机协同”的形态，知道要设转人工、设兜底、设边界，这反而让项目更容易成功。第三，评估方法论开始扩散。越来越多的团队意识到，智能体开发的上限取决于评测体系的下限，大家开始认真建设评测集、回归机制、灰度策略。

这个共识对做智能体定制的甲方和乙方都是提醒：2026年不再是“你演示一下我看看”的时代，而是“你拿出评估数据证明它可用”的时代。

6. 高频问题排查与避坑实录

最后按惯例整理一份高频问题速查表。这些都是我在真实项目里反复见过的坑，每一条都对应非常具体的排查思路。

排查智能体问题时，第一件事永远是看trace，第二件事是复现case并加入评测集，第三件才是改prompt或参数。没有trace前不要猜，猜大概率是错的。

再讲一个我特别想分享的习惯：把演示脚本当测试用例。很多项目团队花了很大力气准备演示，演示完脚本就丢在一边。我的做法是，把演示脚本里每条问题直接转成评测集条目，标准答案由业务负责人签字确认。这样演示就不再是一次性的表演，而是第一版评测集的雏形。演示效果不错，意味着第一版评测集有通过的基础，后续所有折腾都有对照物。

还有一个经验是关于知识更新的。很多项目上线后效果越来越差，不是模型变笨了，而是知识库没跟上业务变化。智能体知识库必须像代码一样做版本管理，业务规则一改，知识库就要发新版本，并配套跑一遍回归评测。这一点写在合同里都不为过。

我现在评估任何一个智能体项目，都会先问一句：“这个智能体不做什么？”这个问题往往最能暴露需求方是否想清楚了边界。把评估清单固化成模板、每个项目用同一套框架跑，指标跨项目可比，经验才能真正沉淀下来。用这套方法，去年我参与的定制项目从“演示型”变成“生产可用”的比例明显提升。智能体落地这件事，缺的不是想象力，而是一把能量化“好用”的尺子。