智能体定制上线前必做的评估清单：从Demo到生产的实战指南

这两年“智能体定制”这个词出镜率越来越高企业内部做办公助手业务部门做销售客服几乎每个团队都想搭一个属于自己的智能体。工具层面也热闹得很Dify、Coze、RAGFlow、MaxKB这些平台把搭建门槛压到了低代码看起来已经进入“开发同学花一两天就能出个Demo”的时代。但真正进入交付阶段后我听到最多的抱怨是演示的时候什么都能答上线之后就各种“失忆”“胡说”“卡死”。要么是知识库召回了一堆不相关内容要么是工具调用在真实环境里超时重试把接口打爆要么是几个固定话术之外的开放问题直接把智能体问崩。我把这类现象总结成一句话“演示很美、上线就废”。这篇文章不谈怎么搭Demo那是平台教程干的事。我想分享的是从“能演示”到“能上线”这段路到底要过哪些评估关卡。这份评估清单是我带多个智能体项目沉淀下来的适合准备把智能体从POC推向生产的团队也适合正在选框架、做方案的技术负责人。看完你至少能回答一个问题在把智能体交付给真实用户之前我应该检查哪些东西。1. 先别急着选框架把“演示需求”翻译成“生产需求”1.1 演示与生产之间的三道鸿沟我见过不少团队第一个演示版本跑通后直接进入开发排期连“演示版本到底解决了谁的什么问题”都没想清楚。演示版本的本质是“在受控条件下证明可能性”生产版本的本质是“在不可控条件下持续交付价值”。这两者之间至少隔着三道鸿沟。第一道是输入鸿沟。演示时你问的是精心准备的几十个问题输入基本全是已知模式上线后你面对的是真实用户他们会用各种口语化表达、错别字、行业黑话甚至故意刁难的问法。任何没有做过边界测试的智能体在这种输入面前都会迅速暴露短板。我见过最典型的案例一个演示时对答如流的制度问答助手上线后被用户用一句带着方言口音的模糊提问直接问懵因为训练集的表达习惯太规整了。第二道是环境鸿沟。演示时知识库是干净的工具是直连的依赖的服务都在线生产时知识库要持续更新工具背后有鉴权、限流、超时底层模型还可能在不同时段发生性能波动。很多Demo没考虑过上游服务的故障一旦某个API接口返回非预期结果整个智能体就会像多米诺骨牌一样倒下。这类问题靠演示阶段根本发现不了只能靠上线前的故障注入测试来暴露。第三道是价值鸿沟。演示追求“答得对”生产追求“用得上”。答得对只是基础用得上意味着稳定可用、成本可控、出了问题有人处理。这一道鸿沟最容易在验收环节被忽略等月度账单出来才追悔莫及。我在好几个项目里都见过类似的情况智能体答得挺准但每轮都在调用最贵的模型、处理一个简单问题时绕了五个节点成本曲线上涨速度远超预期。1.2 需求确认阶段的三次灵魂拷问在我参与过的智能体项目里凡是后期返工严重的十有八九是需求阶段没把话问透。建议在动手搭建之前团队内部先过三个问题。第一问谁是这个智能体的最终用户他每天真实的工作场景是什么注意最终用户不等于拍板买单的人。有一次我们做一个内部制度问答助手签合同的领导觉得“能回答社保政策就行”但真正每天在用的人力专员需要的是制度文档按版本同步更新、能回答“新旧制度冲突时以哪版为准”。这两者差的不是功能而是对使用语境的理解直接体现在工作流设计和知识库结构上。第二问成功长什么样用什么数字衡量是“咨询解决率提升了20%”还是“客服平均响应时长下降了30%”或者是“每天有500个真实用户在用它”把成功标准量化成指标后面的评测集设计、上线后的数据运营才有抓手。没有指标的智能体项目验收环节必然变成扯皮现场。第三问智能体答错的时候代价有多大这个问题的答案直接决定你要不要加安全兜底、要不要人工接管、要不要在关键节点做人在环路。比如内部知识问答答错最多重查一次文档但一个辅助合同审查、辅助医疗问诊的智能体答错了后果完全不同必须设计强校验流程和拒答机制。我在实操中会用一张表把“答错概率”“答错后果”“容忍级别”列出来容忍级别高的靠提示词约束容忍级别低的必须上规则校验或人工审批这条判断贯穿整个开发周期。2. 框架、模型与架构先看底子再谈定制2.1 框架选型自研、开源平台、商业平台怎么权衡“智能体定制”这四个字里定制是重心但底子决定定制能走多远。框架选型是第一个分岔口我不建议一上来就迷信某个框架而是先把需求摆出来做匹配。自研基于LangChain、LlamaIndex这类库或者干脆自己写编排逻辑适合的场景是流程高度非标、需要深度控制每一步、团队有较强的工程能力。自研最大的坑是维护成本——模型升级、接口变更、并发抖动都要自己扛如果团队只有一两个人兼职维护很容易陷入“写的时候爽、后面没人管”的境地。我自己早期做过一个自研方案半年后回来维护光看当年的代码注释就要花掉一天。开源平台Dify、RAGFlow、MaxKB等适合的场景是想快速搭建可控的Agent应用流程标准化程度高团队希望保留二次开发能力又不想从零造轮子。这类平台通常把工作流编排、知识库管理、工具接入做了封装你会明显感觉开发速度上来了。但注意开源平台不等于免维护版本迭代快、插件质量参差、底层数据库迁移都可能成为隐性成本。选开源平台前建议先看一眼社区的Issue列表和最近版本的发布频率判断你是否有能力跟上节奏。商业平台Coze这类SaaS服务适合的场景是追求上线速度、不想投入太多运维精力、对数据驻留要求不敏感。风险在于平台策略变化和迁移成本一旦你的工作流深度依赖某个平台的开箱能力将来想迁回自建会很痛苦。我在选型时一般会画一个“需求-能力”匹配表横轴是流程非标程度纵轴是数据敏感程度和团队维护能力的综合值。高非标加高维护能力走自研中等非标走开源平台做二次开发低非标加低维护能力走商业平台。这个判断因人而异但核心原则是一致的——选型是为了让后面六个月的迭代更轻松而不是为了让Demo演示更炫。2.2 模型选型的成本与延迟账模型选择是定制智能体的另一个关键变量很多人只看“聪明程度”忽略成本和延迟。做生产评估时我会至少看四个数字单次调用的token成本、P95延迟、上下文窗口利用率、以及模型在特定任务上的稳定性。成本账比很多人想象的要复杂。假设你的智能体一天被调用1万次每次平均消耗输入4000 token、输出600 token用主流旗舰模型算一个月的API费用可能轻松过万甚至更多。更隐蔽的是如果没有做缓存而是每次都让模型从头推理成本会线性增长。我们在生产环境里给高频问题加了语义缓存相似问题直接命中历史答案费用直接降了大概60%。这件事值得在任何正式上线前做一次测算把预估调用量、平均token数、缓存命中率、混合模型路由简单问题用便宜小模型复杂问题才调旗舰模型一起算进月度账单。延迟账同样不能忽略。演示时单轮问答5秒大家都觉得无所谓生产上用在客服场景里超过3秒用户就想退出用在工作流里还会连锁拖慢整个链路的响应。建议在选型阶段就定一个延迟预算比如“单轮交互P95不超过4秒”然后针对性选模型、设置流式输出、调整重试策略。模型能力再强如果每次都等到全部token生成完才吐出答案用户的体感也是“卡死了”。2.3 单智能体还是多智能体别为了架构而架构这两年“多智能体”的概念被炒得很热好像不搞几个角色协同就不好意思说自己做智能体开发。但我在实际项目里的经验是多智能体是手段不是目的越复杂的架构越难调试、越费钱、越容易翻车。单智能体适合大部分场景一个主Agent加上工具调用和知识库逻辑简单日志清晰成本可控。遇到一个请求先判断意图再决定走哪条处理路径这条路径上挂RAG还是挂API用提示词和规则就能覆盖大多数业务。对我们做过的大多数智能体定制项目来说单智能体都是更稳妥的起点。什么时候才需要多智能体当任务确实可以拆成多个有明确边界、不同模型擅长的子任务并且子任务之间的衔接可以通过结构化消息完成时多智能体才值得考虑。比如一个销售智能体线索识别、话术生成、客户资料校验这三个环节用不同模型和不同提示词策略各自跑再统一汇总效率和效果都会更好。但如果子任务之间互相依赖、上下文纠缠不清多智能体会把一个小问题放大成几个模型的“踢皮球现场”——每个Agent都觉得自己做得对最后结果却是一团乱麻。我在评估架构时有一条铁律能单智能体搞定的绝不上多智能体上多智能体之前先写清楚每个智能体的输入输出协议和失败兜底方案写不出来就不上。架构的复杂度应该匹配业务的复杂度而不是匹配技术的炫技需求。3. 核心环节拆解工作流、工具调用与知识库的坑位排查3.1 工作流设计从“流程图思维”切换到“状态机思维”很多人设计智能体工作流第一版就是画一个漂亮的流程图用户提问、判断意图、查知识库、生成答案。这个流程图在演示里跑得飞起一上线就报错为什么因为流程图只画了“正常路径”而生产环境里相当比例的流量走的是“异常路径”。我的建议是把工作流当成一个状态机来设计。每个节点都要定义清楚什么情况下进入这个节点、在这个节点做什么、做完之后往哪个状态转移、如果中间失败了怎么办、超时怎么办、返回的数据结构不符合预期怎么办。举一个真实例子我们做一个工单分类智能体第一版只写了“按关键词分类分不出来就默认其他”。上线后大量工单被误分到“其他”用户抱怨明显。后来我们在分类节点后面加了一个置信度阈值——模型对分类结果的置信度低于0.6时自动转人工预分类而不是硬着头皮继续往下走。就这么一个小改动工单准确率从78%提到了92%。另外工作流里的每一步都要有明确的超时和重试策略。模型调用设置超时工具调用设置超时整体链路设置总超时重试要有退避比如第1次等1秒第2次等3秒第3次直接失败走兜底。不然并发一高重试风暴会把下游接口打挂。设计工作流时我会刻意问自己一个问题如果把工作流里的每个节点都想象成一台机器哪台机器最容易卡住、卡住了我该怎么办把这个问题答完工作流的健壮性就基本到位了。3.2 工具调用边界、超时与幂等智能体定制最吸引人的能力就是“让它调用工具”比如查库存、下订单、创建工单。但工具调用也是上线后事故率最高的环节。我总结出三个高频翻车点工具边界不清、超时控制缺失、非幂等操作被重复执行。先说工具边界。给智能体暴露什么权限、允许它调用哪些工具必须白名单化。不要一股脑把所有内部API都挂上去而是按场景最小化授权。比如一个客服智能体只需要查询订单状态、创建售后工单就不应该给它开放修改价格和删除订单的接口。边界不清的智能体一旦被恶意输入或者无意间的上下文偏移诱导可能做出危险动作。我在每个工具接口上都加了参数校验和权限标记宁可多写几行配置也不给智能体留下越权的口子。再说超时。真实环境里的API不是Demo环境里的Mock服务慢接口、限流、503都真实存在。我在接入每个工具时都会先做一次三件套测试正常响应测一次、延迟5秒测一次、直接返回500测一次看智能体怎么处理。一个合格的工具封装在调用失败时必须向模型返回结构化的错误信息告诉它“这次调用失败原因是A可以尝试B”而不是返回一段让人看不懂的报错堆栈。模型看不到工程细节只有给它可理解的信息它才有可能正确地自我纠错。最后说幂等。凡是会对外产生实际影响的工具调用——创建订单、发消息、扣库存——必须支持幂等。也就是说同一个请求重复执行效果应该和只执行一次相同否则当模型因为下游超时而自动重试时用户会收到两条一样的短信或者库里出现两条重复的订单。实操中我们会在工具参数里要求调用方传入一个全局唯一的requestId服务端用它做去重这是防止“重试事故”最有效的办法。这条经验是从一次真实的双订单事故里换来的疼过一次之后就再也没省过这一步。3.3 RAG知识库召回率不等于准确率知识库问答是智能体定制里用得最多的场景也是最典型的“演示很美、上线就废”重灾区。演示时知识库里只有几十篇精心写的文档怎么检索都对生产时文档上千篇格式五花八门有PDF、有Excel、有扫描件、有老旧系统导出的乱码文本召回结果立刻变得不可控。RAG链路的核心指标不只是召回率而是答案准确率。召回率再高如果把一堆无关内容混进上下文模型照样会被带偏。我见过一个制度问答智能体被检索系统同时召回了两份互相矛盾的老旧制度文档模型直接答出了错误结论。所以评估RAG时我会重点看三件事切分策略、混合检索、重排。切分策略上固定按字数切比如512字一块是最省事但最容易割裂语义的做法。制度条款、技术方案这类文档我建议优先按结构切分按标题和章节来同一章节的内容尽量放回同一块必要时加上重叠窗口避免语境断裂。切分后还要做一轮人工抽查专找那些“一句话含义被拦腰截断”的样本这类样本是影响回答质量的关键。混合检索上纯向量检索对同义改写友好但对专有名词和精确编码往往不敏感。生产环境我更推荐“BM25关键词加向量召回”双路召回再融合尤其在企业内部文档场景很多精确数字、合同编号、产品型号就是靠关键词精准命中的。RAGFlow这类平台已经内置了混合检索能力自研的话需要自己实现一个简单的分数融合逻辑难度不大但收益明显。重排是另一个容易被忽视的环节。向量召回给出一堆相似文档后直接用top几拼上下文很容易把正确答案挤出窗口。加一个rerank环节让专门的重排模型对召回结果按与问题的相关性重新打分再取前几块进上下文。这一步对答案质量的提升非常明显我自己的经验是加上rerank之后测评集上的准确率普遍能提升8到15个百分点成本增加却很有限。还有一块容易被忽略的是知识库的时效性。生产环境的知识库不是静态的制度会改、产品会更新、旧文档该标记失效。我会在知识管理流程里加一个“版本状态”字段过期文档不参与检索但留档备查并且设置定期巡检任务让维护人能及时发现哪些文档内容和新制度冲突。知识库不是搭好就完事的它需要持续喂养和维护。4. 上线前评估清单一张表照着打勾4.1 评测集要做成“制度”不是“一次考试”智能体开发最典型的做法是开发人员自己写几道题测一测感觉不错就上。这种“感觉主义”评测基本等于没有评测。我在项目里推的是把评测制度化至少包含三套评测集。第一套是标准场景集覆盖业务方定义的核心场景每个场景5到10个问题答案有明确的标准或人工标注。这套集子用来做回归测试每次改提示词、换模型、调工作流之后都要全量跑一遍防止“修好一个问题打死一片功能”。第二套是边界对抗集专门收集那些容易让智能体翻车的问题模糊提问、多轮反问、恶意指令、措辞带错别字的、以及明显超出业务范围的问题。对抗集不用多但必须真实我建议从历史线上对话里挖哪里答错了就录进哪套集子。第三套是拒答集用来测智能体会不会老老实实说不知道。一个生产级智能体必须学会拒绝不应该对着超出能力范围的问题一本正经地编答案。我们给拒答集定了一个指标叫“非幻觉率”低于90%不允许上线。评测集建好之后还要配上评分方式。能自动判分的尽量自动判分比如标准答案比对、关键词覆盖、是否命中拒答规则需要人工判分的设定明确的打分标准避免不同人的评分差异太大。另外每次上线前必须跑一遍“新旧版本对比评测”同一批问题旧版本和新版本各跑一遍重点看新版本有没有引入新的退步项。在智能体项目里回归测试不是可选项是每次改动的必选项因为大模型的输出天然有随机性你根本没法靠“感觉没变”来确认它没变坏。4.2 可观测性没有日志就没有迭代权这是我认为整个智能体定制里最容易被忽略、却又最致命的一环。很多团队上线智能体后用户反馈“不好用”但团队连“哪里不好用”都说不清楚因为没有日志。大模型应用的可观测性和传统应用不一样除了系统日志你还得记录每一次对话的完整轨迹用户输入、命中意图、走了哪个节点、调了哪个工具、工具返回了什么、模型生成了什么、每一步耗时多少、最终答案是什么、用户有没有后续追问或点击“不满意”。我搭建智能体监控时会做四个维度质量维答案是否被采纳、用户是否追问、有无投诉、性能维每轮对话的P50和P95延迟、模型首字延迟、成本维每轮对话消耗token数、按用户和场景的成本分布、稳定性维工具调用失败率、超时率、异常拒答率。这四维数据汇总成一张日常看板每天扫一眼哪里出了问题基本一目了然。一次真实的排查经历有个企业助手智能体上线后某个部门的提问成功率突然掉到60%。如果只有应用日志你最多看到“部分问题失败”但因为我们记录了每个对话的完整轨迹很快定位到是那个部门提问中的“项目代号”出现频率激增而项目代号对应的最新数据还没同步进知识库导致检索召回为空。补上数据后成功率立刻恢复。没有可观测性这种问题可能要折腾一周才能定位而且用户早跑光了。4.3 成本、延迟与并发上线前的性能摸底说到上线就不得不提容量评估。智能体和传统接口不一样它的消耗是动态的同样的QPS下问题复杂度不同token消耗可能差出好几倍。所以上线前的性能摸底不是压测一个固定QPS就完事还要考虑最坏情况。我建议做三类准备。第一类是压测用评测集里的问题作为压测脚本按预估峰值的1.5倍到2倍QPS去打一轮看模型API的响应时间、下游工具服务的承载、以及整个工作流的P95延迟是否还符合预算。第二类是预算水位算清楚“如果某个用户疯狂刷接口成本会被打爆到什么程度”然后设置用户级和总体的并发限制、配额限制。第三类是降级方案主模型不可用时切到备选模型主知识库不可用时切到备份索引工具服务不可用时直接把对应能力从工具列表中摘除。给智能体开一个“残疾模式”保证核心能答比追求所有能力都健在更现实。性能摸底还要关注两点冷启动和上下文膨胀。如果智能体需要上传大量文档作为上下文首轮调用会非常慢且贵如果多轮对话把历史都塞进上下文每轮成本都会上涨。上线前一定要设一个上下文管理策略比如超过多少轮就做摘要、摘要后只保留关键信息、对话超过N轮自动提醒人工接管。这些策略看着琐碎但都是真实账单上会体现的数字。4.4 灰度发布先把新智能体放到“观众席”智能体上线最忌讳“一键全量”。因为大模型的输出有随机性同样的代码和参数今天测和明天测结果都可能不一样。全量上线一旦翻车影响面立刻扩大回滚成本极高。我推荐至少做两步影子模式和灰度放量。影子模式是指新版本的智能体在后台跑但它的输出不直接展示给用户只记录结果拿去对比线上老版本的答案——这样你能拿到大量真实流量的评测数据而用户完全不受影响。灰度放量则是把新版本先开放给5%的用户观察质量、延迟、成本指标稳定后再逐步放大到20%、50%、100%。灰度过程中要盯哪些信号我一般看五个平均答案采纳率用户有没有追问或点“踩”、负面反馈数、工具调用失败率、每轮平均成本、P95延迟。任一指标超过老版本1.2倍马上暂停灰度要么回滚要么定位问题后再继续。很多事故其实都是“状态推进得太快”造成的。灰度发布的核心不是流程繁琐而是给你留出发现意外的时间这个时间省不得。5. 我在实际项目中踩过的坑以及对应的排查方法5.1 典型问题速查表把这一年多来在智能体定制项目里高频遇到的问题整理成一张表方便遇到类似情况时直接照方抓药。现象根因方向排查方法解决方案演示正常上线后经常答非所问输入分布差异大没做过对抗测试拉取真实用户日志人工标注一段失败样本扩充边界对抗集增加意图识别兜底规则知识库问答给出一堆互相矛盾的内容切分破坏语义、过期文档参与检索抽查召回结果看top文档来源结构切分加版本字段、过期文档下线、加rerank工具调用频繁失败用户反复投诉超时控制缺失、错误返回不可读查看工具调用日志复现超时场景工具封装统一返回结构化错误、退避重试、幂等requestId换一版提示词旧功能反而退步没有回归评测集全量跑标准场景集对比新旧版本建立评测集制度版本上线前必须回归流量稍大就响应变慢模型调用并发受限、上下文膨胀压测看P95延迟和token消耗趋势流式输出、语义缓存、模型路由、上下文管理用户问“为什么答错”时团队说不清可观测性缺失检查是否记录了完整对话轨迹补全四维监控质量、性能、成本、稳定性5.2 三件很多人忽略的小事除了上面这些大环节还有几件小事在实操中影响很大拿出来单独说说。第一件给智能体加“身份和边界”声明。很多翻车其实不是技术问题而是提示词里没有说清楚“你是谁、你能做什么、不能做什么”。我在每个定制智能体的系统提示词里都会固定写一段边界描述明确列出拒绝回答的范畴并且配一个礼貌的拒答话术。这不仅仅是合规考虑也是防止模型被诱导越权的重要因素成本几乎为零但收益很高。第二件提示词版本管理。智能体定制项目迭代快提示词可能一周改三版。如果提示词没有纳入版本管理出了问题根本不知道线上是哪一版。我们用代码仓库管理提示词和知识库配置每条变更都走评审和记录标注变更原因和对应评测结果。这听起来像小题大做但等到你需要回滚一版有问题的行为时就会感谢当初这个决定。第三件上线不是终点。我见过太多项目把智能体发布当成了结束发布后一个月没人看数据、没人管知识库更新三个月后智能体已经变成一个“答非所问的空壳”。我的建议是上线后至少留一名负责人做数据周报和知识库巡检并把“智能体问答质量”纳入和传统客服质检类似的常态化管理里。有个很形象的比喻智能体就像一个刚入职的员工Demo阶段是它的“试用期展示”只有把培训、考核、复盘、纠偏都做起来它才能从“能说会道”变成“真的能干活”。最后回到开头那句话。智能体定制的难点从来不在“把模型接进来”而在于把它当成一个长期运营的系统来对待。我自己踩过的坑足够写一本小册子但最值钱的教训就两条一是永远别拿Demo的评测结果代替生产的评测结果二是把智能体当员工管理除了让它干得漂亮更要让它出问题时有人管、有日志查、有预案退。做到这两条你的智能体至少不会成为那个“演示很美、上线就废”的反面教材。