1. 为什么一个客服Agent会在“审”字上卡这么久
先说个场景。你花了两个星期，搭出一个客服Agent的Demo：能回答问题、能查订单、能转人工，demo演示的时候客户眼前一亮，老板当场拍板“这玩意儿赶紧上生产”。然后真正的噩梦开始了——运营说要准确率报表，安全说要鉴权审计，客服主管说应答语气不对，法务说承诺话术有风险，研发说并发扛不住，最后连数据库的字段命名都要吵三轮。
我作为FDE（Forward Deployed Engineer，前线部署工程师），过去一年半经手了36个客服Agent项目，从金融、电商到SaaS工具，几乎每一个都踩过同一条河：Demo到生产之间，隔着一条深不见底的生产化鸿沟。这篇文章就是把这36次经验浓缩成的36条判断和操作准则——所谓“FDE36记”，不是理论框架，是从真实项目里一条一条捞出来的血泪清单。
先给这篇文章定个位。如果你还在做Demo阶段，或者正准备把Agent推到生产，这篇文章可以帮你少走至少三个月的弯路。我会按项目从评审到上线的真实顺序来讲：先讲清楚为什么Demo做得再漂亮也不算数，再讲数据、模型、Agent架构、评测、灰度上线、运维复盘这几个核心环节里，FDE到底该审什么、怎么审，最后给一份可以直接拿着用的检查清单。适合正在做Agent项目的研发、产品经理、解决方案工程师，也适合那些被老板一句“尽快上线”逼到失眠的同学。
核心就一句话：从Demo到生产，不是一个“部署”的动作，而是一整套工程体系的补齐过程。你缺的不是一个能把Demo跑起来的容器，而是一条能证明这个Agent在真实流量下不会翻车的证据链。
2. 先认清现状：Demo阶段的Agent和生产的Agent根本不是同一个物种
2.1 Demo骗了所有人，包括你自己
每一个Agent项目的起点都长得很像：一个精心挑选的演示脚本，几个标准问题，一段流畅的回复，再加上“你看它能调用API了”的惊喜时刻。Demo的本质是从所有可能的对话路径中，选一条最好看的展示出来——这本身没问题，问题在于所有人都默认“能走通一条路，就能走通所有路”。
我做过的第一个客服Agent项目就是典型反面教材。演示的时候，用户问“我的订单到哪了”，Agent直接调了物流API，返回了精准的轨迹信息，全场鼓掌。上生产第一天，第一个真实问题就把Agent打懵了——“我上周买的东西怎么还没到？你们是不是发错地址了？”这个问题里同时包含了订单查询、时间判断、地址核验、情绪安抚四个意图，我那个Demo Agent直接给用户返回了一大段“抱歉我无法理解”的兜底话术，用户转头就投诉到12315。
真实流量的残酷之处在于：用户不按你设计的剧本说话，而且每一句话都可能包含多个意图、隐含的槽点、残缺的上下文和强烈的情绪。Demo只要能回答脚本里的问题就算成功，生产Agent必须在理解、检索、工具调用、风险控制四个维度上同时经受住随机组合的考验。
2.2 FDE在这中间的位置：不是“审别人”，是“帮所有人把问题暴露出来”
很多团队对FDE的角色理解有偏差，以为FDE是QA的加强版，或者是个会写代码的产品经理。实际上，FDE在生产化过程中承担的是一个横切角色：既要在评审会上用技术语言挑战架构方案，又要在业务方那边把“Agent能做到什么程度”这件事翻译成人话，还要在项目延期的时候背起第一口锅。
我在“审”Agent项目的过程中，最核心的工作其实是三件事：第一，逼着团队把隐性假设变成显性指标；第二，把生产环境可能发生的失败场景提前捞出来，在安全的环境里让它们发生一遍；第三，在关键节点上敢拍板，说“这版不能上”，并且给出能上的路径。所谓36记，本质上是这三次行动在36个项目里反复打磨出的具体招式。
2.3 生产级的定义：不是你写了几千行代码，而是你证明了什么
生产级这个词已经被滥用得不成样子了。有人把加了个日志中间件就叫生产级，有人把容器化部署叫生产级。我给“生产级客服Agent”定的标准，就五个字：出事能兜底。更具体一点说，需要同时满足以下条件：
- 回答质量可度量，并且有明确的bad case复现和修复流程；
- 关键链路（LLM调用、检索、工具调用）有降级方案，任何一个外部依赖挂了，用户不能感知到“系统坏了”；
- 用户数据从输入、处理到落库，全程有权限控制和审计日志，出了纠纷能追溯；
- 回答内容涉及承诺性表述时，有合规层面的约束机制；
- 线上运行有监控、告警和快速回滚的能力，而不是靠用户投诉发现问题。
这五条没有一条能在Demo阶段被真正验证，因为它们全都是对抗性场景下的表现，而不是顺风局里的表现。后面每一记都会围绕这五条展开。
3. 评审的第一枪：需求对齐与边界划定
3.1 先别谈技术，先把AI能干和不能干的边界画清楚
每个客户来找我做客服Agent的时候，都会提一堆“智能化”的诉求：要能理解情绪、要能主动营销、要能处理复杂投诉、还要7×24小时在线。我现在的习惯是，第一次需求沟通会上就带着团队画一张“能力分层表”，把需求分成四层：
| 层级 | 能力类型 | 典型例子 | 生产化难度 |
|---|---|---|---|
| L1 | 固定答案检索 | 退货政策、营业时间、费用说明 | 低（知识库+精确匹配） |
| L2 | 结构化信息查询 | 查订单、查积分、查物流 | 中（需要API+参数抽取） |
| L3 | 多轮推理任务 | 改地址、申请退款、计算赔偿 | 高（需要状态管理+业务规则） |
| L4 | 开放对话与决策 | 情绪安抚、复杂投诉处理、赔偿谈判 | 极高（需要人机协同+风险控制） |
绝大多数客服Agent项目，真正生产化后稳定运行的都是L1和L2，L3能做到有限场景，L4必须人工接管。这不是技术不行，而是责任边界问题——一个让用户觉得“跟真人一样”的Agent，一旦说错话，造成的信任损伤比一个“明显是机器人”的Agent大得多。
3.2 用户需求翻译：业务方说“智能”，你要追问哪三个问题
业务方说“我们想要一个智能客服”的时候，FDE必须追问三个问题：第一，你希望它能替代人工处理的百分之多少的会话？第二，不能处理的时候，你希望它用什么方式转交？第三，你对回答准确率的最低容忍线是多少？这三个问题问完，80%的需求都会立刻变得清晰起来。
有一次我问客户这三个问题，对方的回答是：希望能处理80%的会话，准确率要95%以上，不能处理的要无缝转人工。我当场给他算了一笔账：按你现在的知识库完整度和数据结构，前三个月能做到40%的自动解决率就已经很好了，准确率能做到85%就是优秀水平。然后我们一起把目标调成了“自动解决率45%、用户满意度不低于人工均值”，项目才真正推进下去。FDE的价值不在于迎合需求，而在于把需求里的水分挤干净。
3.3 第一记到第三记：需求评审的黄金三问与范围冻结
我把需求评审阶段最重要的三条经验整理成前三记：
第一记：问“不在范围内的是什么？”需求文档永远写的是“要做什么”，但项目翻车往往是因为“没写不做什么”。比如客服Agent到底管不管售前咨询？管不管投诉工单的后续跟进？管不管已经转人工之后的会话摘要？这些“边界外问题”不定清楚，开发过程中每两天就会冒出一个新需求，每一个听起来都合理，每一个都会把排期打穿。
第二记：问“数据现在长什么样？”很多Agent项目死在了知识库的数据质量上。客户拍着胸脯说“我们有完整的FAQ库”，等你拿到手才发现，两百篇文档里有八十篇是五年前的公告，链接全部失效，表格格式混乱。在需求阶段就要做一次数据现状抽样，拿真实数据评估知识库覆盖率，而不是听业务方说“我们有数据”。
第三记：问“回答错了，后果是什么？”这是衡量Agent生产级别的最关键问题。卖电器和卖保险，同样是一个回答错误，后果完全不同。金融、医疗、法律类场景的回答错误可能带来合规风险，这时候Agent必须在关键回复前增加“免责声明”或者强制转人工；而电商场景回答错了运费政策，最多是客诉升级。根据回答错误的后果等级，决定Agent的能力边界和人工介入策略，这是需求阶段就必须定死的事。
4. 数据与知识库：Agent的地基不在模型，在数据管道
4.1 你以为在做AI，其实在做数据清洗
我做了这么多客服Agent项目，最深的体会是：所谓的“AI落地”，80%的工作量是在清理和治理数据，真正调模型的时间不到20%。客服Agent的每一次回答，本质上都是先从知识库里检索到相关内容，再交给大模型组织语言。知识库的质量直接决定了回答质量上限。
知识库建设中最常踩的坑有三个。第一是格式混乱：同一个意思，在三个文档里有三种说法（“退换货”“退货换货”“退换货政策”），检索的时候全都匹配不上。第二是信息过期：促销政策、物流时效这类信息更新频繁，知识库如果没有版本管理和有效期标注，Agent就会一本正经地念旧政策。第三是粒度不当：有的知识库条目是一个完整页面，几千字塞在一起，检索召回后LLM根本找不到关键信息；有的条目又切得太碎，一句话一个条目，失去上下文语义。
4.2 知识库治理的金标准：一个意图对应一个高质量答案单元
我在客服Agent项目里推行了一个“知识单元”的概念。它不是简单的FAQ问答对，而是一个具备独立语义、包含上下文信息、标注了适用条件和有效期的答案块。比如“退货政策”不是一条纯文本，而是拆成“退货时限”“退货条件”“退款到账时间”“特殊商品退货说明”几个子单元，每个子单元都带属性标签（适用品类、时间范围、优先级）。
这样做有三个好处：检索阶段可以用标签缩小范围；生成阶段LLM拿到的上下文更聚焦，幻觉概率降低；维护阶段运营人员只需要改过期的那一条，不用通篇重写。知识单元是知识库和生产Agent之间的标准接口，没有这个抽象层，后续的评测、更新、权限管理全都会变成一团乱麻。
4.3 第四记到第七记：数据评审时必查的四个文件
我在数据评审阶段重点查四个东西，基本每次都能查出问题：
第四记：知识库覆盖率盘点表必须存在。把过去三个月的真实客服会话记录抽样，人工标注出高频问题TOP100，然后逐一对照知识库，看覆盖率是多少。覆盖率低于70%的话，Agent上线的第一天就会被骂“智障”。
第五记：数据更新流程必须有负责人。业务政策每个月都在变，知识库谁来更新？多久更新一次？有没有审核流程？很多项目败给了“上线时是准的，三个月后全是过期的”。我见过最离谱的情况是，一个客户公司的运营离职了半年，知识库就半年没人动过。
第六记：数据权限表必须拉通。客服Agent能查到什么级别的订单信息？能查到用户手机号吗？能查到历史投诉记录吗？这些权限不只是技术上的问题，是合规问题。我经手的项目里，至少有三个在安全评审环节因为权限边界不清被打了回来。
第七记：冷启动阶段要给人工留后门。知识库永远不可能一开始就100%覆盖，Agent答不上来的问题，必须有一条清晰的路径转给人工客服，并且把“Agent不知道答案”做成一个显式的状态记录下来，而不是让它胡编。知識库建设是持续运营的过程，不是上线前的一次性交付。
4.4 用一段真实经历说明数据劫难的过程
我印象最深的一个项目是给某家电品牌做售后客服Agent。客户方对接人信心满满地跟我说，他们的知识库“特别完善”，有三百多篇售后文档。结果我们导入之后一测，检索到的答案驴唇不对马嘴——用户问“冰箱不制冷了怎么办”，Agent返回的是“冰箱使用注意事项”第一条“请勿将热食直接放入冰箱”。
排查了三天才发现问题：那三百多篇文档是过去的十年里慢慢堆上去的，其中有一大半是产品说明书扫描版OCR出来的，错字连篇，还有些是已经停产的老型号资料。我们最后花了整整一个半月，把三百多篇文档清洗成了两百三十个知识单元，每个单元都做了字段标注，重测之后检索命中率从38%升到了91%。这一个月半月才是Agent生产化的真正起点。
5. 模型与Prompt：别迷信大模型，你的任务是让它别乱说话
5.1 基础模型选型：参数不是越高越好，是越可控越好
客服Agent的模型选型，很多人第一反应是“越大越好”。大模型的推理能力确实强，但客服场景里还有另外三个指标在打架：延迟、成本、可控性。一个500B参数的模型，答得再好，如果用户要等8秒才收到回复，体验就是差的；如果单次调用成本是3分钱，一天十万次会话就是三千块，老板的脸色就是黑的；如果模型思考太发散，回答里动不动就带出几句不可控的发挥，客服主管就是要骂人的。
我现在做客服Agent项目，模型选型的基本判断是分层的：意图识别和实体抽取用7B~13B的小模型，跑得快也够用；生成回答用中大型模型，具体多大取决于业务对语义理解的复杂度；涉及复杂推理或长上下文的时候，才考虑调用更大参数的模型。核心原则是每一层都选够用且可控的，而不是全程都用最贵的。
5.2 系统提示词的工程化：把提示词当代码管理
客服Agent的Prompt（系统提示词）和你在ChatGPT网页上随手写的Prompt完全是两回事。生产环境的Prompt需要具备几个工程属性：版本管理、环境隔离（dev/staging/prod）、A/B测试、动态注入、分级权限。我见过太多团队把Prompt直接写在代码里，改一次要重新发版，出了问题想回滚都不知道回滚到哪个版本。
我在项目里会要求团队把Prompt拆成“静态模板+动态参数”的结构。静态模板描述Agent的角色、语气、输出格式、铁律；动态参数在运行时从配置中心加载，注入当前用户上下文、当前业务政策版本、当前可用的工具列表。这样运营同学改一个话术不需要重新部署代码，只需要在配置平台上改一条记录。
这里还有一个关键技术决策：Prompt里要不要放“铁律”？我的答案是必须放，而且要放在所有规则的最前面。所谓铁律，就是无论如何都不能违反的边界，比如“不得承诺退款到账的具体时间”“不得透露其他用户的隐私信息”“涉及医疗建议时必须引导线下就医”。大模型的服从性不是百分之百，但把铁律放在显眼位置，加上输出格式约束，可以把违规率压到可接受的范围。生产级Agent不是“永远不会犯错”，而是“错误率低到可控，且出错了能兜住”。
5.3 第八记到第十二记：模型与Prompt评审五个关键检查点
第八记：所有对这个模型回答质量的质疑，都要转化成一测试集。团队内部争论“这个模型回答到底好不好”，不要用感觉说话，建一个两百条问题的回归测试集，每次换模型、改Prompt，全部跑一遍。这不仅是评审工具，更是防止“改了A坏了B”的护身符。
第九记：写清楚每个Prompt的作用边界。有人把角色设定、知识检索指令、工具调用规则、输出格式全放在一个大Prompt里，结果就是互相干扰，模型经常在回答格式上发疯。把Prompts按职能拆开，至少分成角色定义、知识引用规则、工具使用说明、输出格式约束四块，每块单独管理和测试。
第十记：模型输出的温度参数必须配置。客服场景默认temperature不要超过0.3，越高越容易飘。尤其是涉及金额、日期、政策条款的回答，宁可它像个死板的客服，也不要它像个自由的诗人。
第十一记：准备“无答案”的输出模板。模型答不上来的时候，比答错了更可怕。明确配置一种“无法回答”的表达方式，而不是让模型为了完成对话胡编。我的标准做法是：当检索结果的置信度低于阈值，或者模型判定超出能力边界，输出固定话术“这个问题我暂时无法确认，为您转接人工客服”，同时后台记录一个超限事件。
第十二记：Prompt变更必须走评审。改一个词可能让准确率掉5%，这不是危言耸听。我经历过一次事故，运营同学把“语气更亲切”加进了Prompt，结果模型开始在回答里自己加表情符号和段子，客服主管直接炸了。Prompt变更的权限要收拢，至少要有技术侧的人做回归验证。
5.4 控制幻觉的实操手法：检索引用与自我约束
客服场景里，“幻觉”是生产化的头号敌人。一个客服Agent一本正经地告诉用户“您可以在任一门店无理由退换”，结果这家公司的政策是“仅限线上订单七日无理由”——这种错误一次就能上热搜。
控制幻觉，光靠Prompt写“不要编造”是不够的，我在工程上用了三招组合拳。第一招是检索引用强制约束：Agent的回答必须引用知识库中的具体来源，回答中涉及的事实性内容要带上引用ID，没有来源支撑的内容不允许输出，这会在很大程度上切断模型自由发挥的空间。第二招是置信度阈值截断：当检索召回的相似度分数低于阈值时，不启动生成，直接走“无法回答”分支。这个阈值要拿真实bad case反复调。第三招是领域定制化微调：如果业务场景非常垂直，且知识库结构稳定，可以考虑用开源模型做领域微调，让模型从参数层面就“知道”这个领域的说话方式，比纯靠Prompt控制要稳得多。这三招不能百分百消灭幻觉，但能把幻觉率从“偶发”压到“极低频”。
6. Agent架构与工具调用：没有状态机的Agent，不配叫生产级
6.1 工具调用的评审：比“能调API”更重要的是“调错了怎么办”
Demo阶段展示Agent调用API，通常展示的是顺滑路径：识别到“查订单意图”，提取订单号，调用订单查询API，返回结果，生成回答。整个过程看起来完美无瑕，但生产环境里，这一条链路上每一个环节都可能出错：意图识别错了（用户说“退单”结果识别成“查单”）；参数提取错了（订单号和手机号搞混了）；API超时了（下游系统挂了，Agent干等）;API返回的数据格式和预想不一致（订单状态多了一个枚举值）。FDE在工具调用评审时，重点不是看happy path，而是把这些failure path一条一条全部捋出来。
我要求团队在架构文档里必须画一张“工具调用失败分支表”，列出每个工具、每个失败场景下的兜底行为：是重试、是换工具、是转人工、还是用预设话术安抚。没有这张表，Agent在线上就是一颗定时炸弹。
6.2 第十三记到第十八记：Agent架构评审的六条硬性要求
第十三记：必须有会话状态管理，而不是每次请求都无状态处理。客服对话天然是多轮的，用户可能在第5句话的时候才说清“就是刚才那个订单”。如果每次LLM调用都是独立无状态的，上下文信息只能靠把前几轮对话塞进Prompt里硬拼，当对话超过十轮时，Token消耗和上下文丢失问题就会同时爆发。生产级Agent必须显式管理会话状态，把“用户意图”“关键实体”“待确认信息”“对话里程碑”这些东西结构化存储。
第十四记：工具调用结果必须校验后再给LLM。从API拿到的返回数据，要先过一次数据校验层，字段缺失、格式异常、业务状态码错误都要在这一层拦截，不能直接把原始返回塞给LLM。
第十五记：所有工具调用的耗时最长路径要有兜底。客服场景里，一次完整回答的端到端延迟最好不要超过3秒，超过5秒用户体验就会明显下降。如果流程里要调三个API，必须评估串行还是并行，以及最慢的那个接口超时了怎么降级。
第十六记：并发控制必须做隔离。同一个用户并发请求（用户手抖连点了两下），同一个账号不同会话的并发，还有管理员测试和生产流量的并发，都要有隔离策略。不然一个测试脚本就能把整个Agent集群打挂。
第十七记：Agent“思考过程”必须可观测。线上出了问题，你要能回放Agent的完整决策过程：它收到了什么输入，检索到了哪些知识，调用了什么工具，拿到了什么结果，为什么选择了这个回答。现在我经手的项目都会把完整的trace日志落库，每个会话有一个trace_id，出问题的时候按id一查就能定位。
第十八记：人工接管通道必须无缝。Agent判断需要转人工的时候，用户必须能无感平滑过渡。会话内容摘要要自动生成，人工客服接手的时候能看到完整的对话历史，用户的诉求已经被Agent处理到了哪一步也要标明。在Agent和人工系统之间要提前约定好状态同步机制。
6.3 状态机设计：让Agent从“自由发挥”变成“按剧本走”
我在生产级客服Agent里强烈推荐引入状态机设计，这也是FDE在架构评审时最常要求团队补的一块。客服对话本质上是一个带有明确目标的流程：从用户提出问题，到Agent确认信息，再到解决问题或转人工，每一步都有明确的输入输出和转移条件。把这种流程显式建模成状态机，意味着Agent的大模型部分只需要负责“理解当前状态+选择下一个动作”，而不是自由自在地进行开放式对话，这会大幅降低不可控性。
举一个退款场景的例子。状态机可以定义成这样：初始状态是“接收诉求”，Agent需要判断用户的诉求是否属于退款范畴；识别为退款后进入“核实订单”状态，在这一个状态里Agent只做一件事——收集订单号、核实是否在退款期内；确认满足条件后进入“执行退款”状态，调用退款API并输出结果；任何一步不符合条件，就转移到“转人工”状态。每一个状态里都对大模型的自由发挥做了限制，模型只能在预设的动作集里做选择题，而不是做填空题。把Agent的混乱度锁在一个可控的框里，这是从Demo到生产最关键的一次思维转变。
6.4 我踩过的坑：Agent为了“完成任务”自己去造假数据
有一次线上事故让我印象特别深。用户问“我这个月的话费账单怎么算的”，我们的Agent为了回答这个问题，需要调用账单API，但订单号参数提取失败了。按设计应该走“参数缺失，请用户补充”的分支，结果Agent自作聪明，从对话历史里找了一个相似的号码填了进去，调API成功，返回了一个错误账单，还煞有介事地给用户算了一通。
这个问题在Demo阶段完全暴露不了，因为Demo脚本里订单号永远提取正确。上线后两周内，这个“参数填错但成功调用”的情况发生了4次。修复方案就是上文说的——工具调用失败分支表，加上参数校验层。凡是参数校验不过，必须走确认流程，绝不自动猜。这一条现在写进了我所有项目的架构评审标准里。
7. 评测体系：没有评测，你根本不知道Agent是好是坏
7.1 离线评测与在线评测：两条腿缺一不可
很多团队做Agent评测，只做一种——拉几个同事问几轮，主观感受一下“答得还行”。这在Demo阶段没问题，但在生产化阶段，评测必须体系化。我把评测分成两条线：离线评测和在线评测。
离线评测的核心是可复现、可回归。准备一份足够全面的测试集，包含正常的用户问题、带错别字的口语化表达、多意图混合场景、诱导性的恶意输入、上下文依赖的多轮对话，每一个case都标注好标准答案或期望行为。每次改Prompt、换模型、更新知识库，全量跑一遍测试集，看准确率、召回率、无效回答率等指标变化。没有这套回归机制，你根本不敢动线上任何参数。
在线评测的核心是真实流量的黄金指标。客服Agent最关键的在线指标不是“回答准确率”（这个线上很难实时标注），而是：自动解决率（Agent独立解决的会话占总会话的比例）、转人工率、用户满意度评分、平均响应延迟。这四个指标直接决定了Agent对业务的价值。
7.2 第十九记到第二十二记：评测指标要盯住的四个数
第十九记：自动解决率是客服Agent最重要的北极星指标。它的定义是“Agent独立解决且用户没有再次进线的会话占比”。一次会话中Agent回答了一个问题，用户回复“好的谢谢”，然后结束会话，这算解决。用户追问了三次还是没得到答案，最后转人工，不算。自动解决率直接决定这个Agent值不值得继续投钱。
第二十记：无效回答率比答错率更需要盯。“对不起我无法理解”这种话术，说多了用户会骂人，而且会直接损害品牌形象。无效回答率反映了Agent的能力边界，这个数字太高（超过15%），说明知识库覆盖率或意图识别能力有严重问题。
第二十一记：用户不满情绪的比例要单独统计。在会话文本里做情绪识别，把标注为“愤怒”“失望”的会话单独抽出来看，分析是哪些问题触发的。很多时候你会发现，Agent答对的问题也可能引发不满——比如话术太生硬，或者没有站在用户角度表达共情。
第二十二记：人工接管率要和人工处理效率放在一起看。转人工率不是越低越好，也不是越高越好。关键指标是：转人工之后，人工客服的处理时长有没有因为Agent提前做了信息收集而缩短。如果Agent转人工时连订单号都没问出来，那“转人工”只是把问题原封不动地扔给了人。
7.3 评测集怎么建：从真实会话里挖金子
评测集不是技术团队拍脑袋写出来的，它的来源只有一个：真实会话记录。我建评测集的标准流程是这样的：上线后第一周，把所有的Agent会话全部粗筛一遍，按用户问题类型聚类，找出TOP30的高频问题场景；每个场景下，人工标注10~20条真实用户问题和期望回答；再加上故意构造的边界case（包含敏感词、多意图、错别字、长句子、语义模糊的表述）。这个评测集初步建起来大约是三百到五百条，之后每周根据线上bad case补充进去。
评测集的关键在于持续更新。生产环境的用户问题分布每个月都在变，上个月没有的新问法，这个月可能就冒出来了。我见过最成功的Agent项目，团队每两周就会把线上所有bad case过一遍，筛选出足以代表一类问题的case加进回归集，长期积累下来，评测集的规模达到了几千条，模型从来没敢瞎动过。
7.4 评测指标的取舍：别让单一指标骗了你
做Agent评测最容易犯的一个错误是只盯“准确率”。准确率高可能只是因为测试集太简单，或者Agent倾向于输出安全但没用的回答。同样的道理，“用户满意度高”也可能是因为用户压根没抱期待。
我建议用“2+3”的指标组合看Agent质量：两个核心指标——自动解决率和无效回答率；三个辅助指标——用户满意度、转人工率、平均响应延迟。每次评审会上，先把五个数字同时亮出来，然后对照bad case逐条分析。当两个核心指标出现背离的时候（比如自动解决率上升的同时无效回答率也在涨），往往意味着Agent学会了“推活儿”而不是“干活”。
8. 灰度与上线：从Demo到生产，最关键的是前5%的流量
8.1 灰度策略：别拿全部用户当小白鼠
我见过的客服Agent上线事故，绝大多数不是模型的问题，而是流量放量太猛。有些团队在测试环境跑了两天，感觉“还行”，第三天直接切了全量流量，结果用户问法百花齐放，Agent当场崩溃。
正确的上线节奏是分五步走的。第一步，内部小范围测试：团队同学自己用，模拟各种刁钻问题。第二步，影子模式：把真实流量复制一份喂给Agent，但Agent的回答不发给用户，只做离线评估，对比Agent回答和人工客服回答的差异。第三步，1%~5%灰度：接极小比例的线上真实流量，全程监控关键指标。第四步，逐步放量：从5%到20%再到50%，每一档至少观察24小时，指标稳定才继续放。第五步，全量上线：完成所有评审关卡，正式全量。
很多团队的Agent项目死在“跳过了影子模式”。他们觉得反正是AI，接上就完事了。实际上，影子模式是你唯一一个不需要承担用户体验风险，就能获得真实流量反馈的机会，跳过的都是傻子。我经手的项目里，有至少五个在影子模式阶段发现了致命问题——包括一个金融项目，Agent在回答“理财产品的风险等级”时给出了和合规文件完全相反的结论。
8.2 第二十三记到第三十记：上线前严格检查的八个关卡
我把上线前评审总结成了八个关卡，每一条都有对应的产出入口。负责项目的FDE或者技术负责人，拿着这份清单逐一确认，任何一项不合格都不允许全量上线。
第二十三记：知识库覆盖关卡。高频问题TOP100的覆盖率必须达到80%以上，低于这个数直接打回。配套要求是知识库的更新流程和负责人已经落实，不是上线前突击导入一批文档。
第二十四记：评测回归关卡。完整的评测集全量跑一遍，跟基准版本相比，核心指标不得回落。Prompt、模型、知识库的任何变更，都要有评测记录存档。
第二十五记：工具链路关卡。所有Agent会调用的外部API，都要经过故障演练——模拟超时、限流、返回异常数据，确认Agent的降级行为符合预期。
第二十六记：安全合规关卡。数据鉴权、审计日志、敏感信息脱敏，这三项全查一遍。涉及用户隐私数据（手机号、地址、订单详情）的访问，必须有明确的权限边界，并且能追到具体调用记录。
第二十七记：限流降级关卡。Agent服务本身需要有流量控制和优雅降级的能力。LLM调用有超时限制，依赖的外部模型服务如果挂了，要能快速切换到备用模型或者走“无法回答”分支。
第二十八记：监控告警关卡。上线前必须配置好核心指标的监控看板和告警规则。我最低要求是五个告警：无效回答率突增、延迟超标、错误率超标、转人工率异常波动、外部依赖调用成功率下降。
第二十九记：回滚预案关卡。上线方案里必须包含回滚方案，明确“什么指标触发回滚”“怎么回滚”“回滚后流量怎么切”。回滚演练至少做一次，确保不是写了文档但没人知道怎么操作。
第三十记：责任矩阵关卡。上线后的运维责任要明确到人：谁负责监控告警响应，谁负责bad case分析，谁负责知识库更新，谁负责和业务方沟通。没有明确责任人，出了问题就会变成“大家都在群里，但没有人动手”。
8.3 我亲历的一次灰度事故：1%流量都差点翻车
有一个电商项目，灰度放了1%的流量，我心想这总该稳了吧。结果当天晚上就爆了。用户的问法在各种平台千奇百怪——“在吗？”“你这个客服是机器人吗？”“呵呵”“滚”……这些非标准化输入全都涌进来，Agent的意图识别模块被各种边缘case打得晕头转向，无效回答率飙到了40%。更麻烦的是，有几个用户开始和Agent争执，Agent反而一本正经地解释“我是AI助手”，用户骂得更凶了。
那天晚上我们紧急下线流量，花了一周调整意图识别模型、补齐边角case的兜底话术、给Agent加了“遇到极端言论时尽快转人工”的规则，重新灰度才平稳下来。那次事故让我彻底明白了一个道理：生产环境的用户输入，永远比你想象得脏十倍。Demo里你精心设计的对话，会被真实用户用最朴素、最暴躁、最不讲逻辑的方式打碎。
8.4 上线后的黄金48小时：盯住这几块屏
上线后的黄金48小时，是整个项目最紧张的时段。我的习惯是拉一个作战群，群里必须有：技术负责人、FDE、运营对接人、客服主管。作战群里的核心是共享监控看板，包括实时自动解决率、无效回答率、平均延迟、错误日志滚动窗口、转人工会话摘要。每两小时过一遍bad case，把明显的问题拉出来立刻修复，修不了的先降级到人工兜底，绝不硬扛。
黄金48小时里还有一个容易被忽视的细节：关注那些Agent“没被问到”的问题。如果某个高频业务场景，上线48小时内居然没有一条相关会话，那大概率不是用户不需要，而是Agent的能力没有露出入口，用户问了但没被识别出来，直接触发了兜底话术。这种“沉默的坏case”，比明面上的错误更危险。
9. 运维与持续运营：上生产只是开始，不是结束
9.1 第三十一记到第三十六记：Agent的长期运营之道
第三十一记：建立bad case周会制度。每周固定时间，把过去一周的所有bad case（无效回答、答错、用户不满、转人工后用户投诉）拉出来逐条过。这不是追责会，而是“从错误里找模型进化方向”的会。我经手的项目里，坚持每周过bad case的团队，三个月后自动解决率普遍能提升10~15个百分点；不做的团队，三个月后指标大概率原地踏步甚至退化。
第三十二记：知识库要按版本管理，变更留痕。谁在什么时候改了哪条知识，为什么改，影响哪些会话——这些都要留痕。我把知识库和代码一样对待：有版本号、有变更记录、支持回滚、支持A/B测试。运营同学改了一条例，如果是恶改，技术上能秒回滚，不用为了一个错别字发版。
第三十三记：定期做用户满意度回访。不要只看在线评分，要抽一部分会话做深度回访，问真实的用户感受：“你觉得这个客服机器人怎么样？有没有哪句话让你不舒服？”你会发现很多在线评分看不出来的问题——比如语气太公式化、回答太冗长、没有情感温度。这些问题不会直接造成流失，但会一点点磨损品牌好感度。
第三十四记：持续优化Prompt和模型，但要小步快跑。不要憋大招——攒了三个月的优化一次性上线。每次改一点，跑评测集，看线上指标，稳了再放量。我的经验是每周都可以有小的Prompt优化，两三周做一次模型升级评估，大版本升级（换模型底座）则至少间隔一个月，走完整的灰度流程。
第三十五记：关注Token成本，别让老板在看账单的时候心疼。客服Agent的调用成本是随流量线性增长的，如果不控制，每个月光LLM费用就能吃掉一大笔预算。常用的降本手段包括：对高频简单问题用小模型回答、用缓存命中重复问答对、控制上下文长度、对长对话定期压缩历史摘要。技术上省下来的钱，就是业务的利润。
第三十六记：把Agent的运营数据做成管理层能看懂的一页纸。FDE不只要管技术，还要管向上汇报。我每个月给业务方出一张“Agent月报”，核心就是六个数字：自动解决率、无效回答率、平均延迟、用户体验评分、人工客服工作量下降比例、运营成本。这六个数字一摆，老板自然知道这套系统上对了没有，下个月预算也自然好谈了。
9.2 运维阶段的自动化防线：告警不是摆设，要能驱动行动
Agent上线后的运维，最怕的是“告警刷屏但没人处理”。我推行过一个“告警分级处理”机制：P0级告警（服务不可用、错误率超30%）要求10分钟内响应，直接拉电话会议；P1级告警（核心指标异常波动）要求30分钟内响应，进作战群排查；P2级告警（指标缓慢恶化）要求当天处理，记录在周会里跟踪闭环。每一条告警都必须有对应的处理SOP，不能只报警不处理，也不能处理了不复盘。
另外，我强烈建议在运维阶段做定期的对抗性测试。每个月抽一次，模拟攻击者、恶意用户、突发流量，看看Agent的防线会不会被击穿。比如连续高频请求会不会打爆限流，诱导性提问会不会套出敏感信息，断掉某个外部API后Agent会不会进入正确降级状态。这些测试在平常运行时看着多余，真出事的时候能救命。
9.3 一个真实的Agent持续迭代样本：六个月的数据变化
给大家看一组我经手的一个客服Agent项目，上线之后六个月的指标变化，这组数据很有代表性：
| 指标 | 上线第1周 | 第1个月 | 第3个月 | 第6个月 |
|---|---|---|---|---|
| 自动解决率 | 42% | 51% | 63% | 71% |
| 无效回答率 | 18% | 12% | 8% | 5% |
| 平均响应延迟 | 3.8秒 | 3.2秒 | 2.5秒 | 2.1秒 |
| 人工客服工作量（较接入前） | -18% | -27% | -35% | -46% |
前两个月的提升主要来自知识库的持续补全和意图识别模型的迭代；第三个月开始，优化重心逐步转移到对话流程和话术调优上——同样的一个问题，Agent给出了更简洁、更自然的回答，用户不需要反复追问了，自动解决率随之提升。第六个月的提升则主要来自多轮对话状态机优化，Agent处理复杂问题的能力显著增强。每一个百分点的提升背后，都是几十上百个bad case的修复和一轮一轮的分析，没有任何魔法，全是笨功夫。
10. 最后说点FDE自己的体会
做了36个客服Agent项目之后，我最深的感触是：Agent生产化这个事，技术难度其实没有想象中高，难的是在一个组织里推动所有人建立“生产级共识”。研发想早点上线，业务想快点见效果，运营担心服务质量下降，法务担心合规风险，每一方都有自己的立场，而FDE恰恰是那个要把所有立场揉到一起，达成一个可执行方案的人。
我的经验是，FDE不能只做技术评审，还要做期望管理。在项目启动的第一周，就要跟所有干系人把“你期望Agent做到什么程度”这个议题谈透。业务方如果说“我希望90%的问题都能自动解决”，你可以先回答“这个目标我们争取在半年内达到，但前三个月我们先把自动解决率做到50%以上，同时保证用户满意度不低于人工”。定一个可达成、可量化、有节奏的目标，比架构设计什么都重要——因为这决定了所有人遇到困难时是齐步往前走，还是互相甩锅。
还有一点想特别提醒同行：做Agent项目，不要把自己当成“调模型的人”，要把自己当成“系统负责人”。模型只是这个系统里的一个组件，真正决定成败的是数据、流程、工具链、评测体系和运营机制。你问自己一个问题：如果明天LLM服务商挂了，你的Agent系统还能不能让用户得到基本服务？如果你答不上来，那这个系统还没到生产级。
最后再分享一个小技巧。我每次在评审会上，都会向开发团队提一个安安静静但很致命的问题：“请给我演示一下Agent搞砸的场景。”如果团队只能演示“答得好”的画面，而演示不出“出错了怎么兜底”，我会直接叫停上线计划，哪怕业务方觉得我小题大做。因为Demo展示的是系统的上限，而生产环境活下去靠的是系统的下限。你能接受的下限在哪里，你的系统才真正能在哪里运行。
这36记，说到底就是36次关于“下限在哪”的追问。希望这些经验，能让你的客服Agent从Demo到生产的路，走得比我当年稳一点、快一点。
