一个电商售后场景。上线当天任务完成率 87%，人工接管率 11%，验收一次通过。第四十五天复盘时，完成率 74%，接管率 19%。客户技术负责人第一句话是："是不是该换个模型了？"
排查用了两天，结论和模型没有关系：市场部在第三十天上了一批"以旧换新"活动，规则写在活动页图片里，知识库没有同步；这类咨询占了新增流量的 23%，智能体只能给兜底话术。把活动规则结构化入库、并把"活动类咨询"从自动回复改为确认后转人工之后，完成率回到 85%。
这是很典型的一次"效果退化"误判。智能体的表现是一个系统的表现，模型只是其中一个变量。要让上线后的效果可控，需要三件事：能提前发现退化的信号、能定位变化来自哪一层、有机制保证排查结论可复现。
五个能提前发现退化的信号
监控项不需要多，我们只保留五个能直接反映"用户的事有没有办成"的业务信号。技术指标（token 消耗、延迟、错误码）用于定位原因，不用于判断好坏。
| 信号 | 看什么 | 告警阈值 | 最先怀疑 |
|---|---|---|---|
| 任务完成率 | 以用户原始目标为判定单位，跨多轮统计 | 周环比下降 5 个百分点 | 业务规则变了 |
| 人工接管率 | 会话转人工、升级工单的比例 | 相对基线上升 20% | 新场景进了流量 |
| 拒答与兜底率 | 命中"无法回答"类话术的会话占比 | 相对基线上升 30% | 知识库没跟上 |
| 工具调用失败率 | 接口报错、参数不合法、超时三类合并统计 | 绝对值超过 2% | 模型换了输出格式 |
| 重复提问率 | 同一用户在十分钟内重复相同意图的比例 | 超过 8% | 回答看着对但没用 |
前四个信号都能在系统里自动算出来。第五个「重复提问率」最容易被忽略，却往往是第一个冒头的——它的含义是"智能体给了答案，用户不信或没看懂，于是又问一遍"。这时候完成率统计可能仍然是绿的，因为规则判定认为这一轮答对了。
监控至少要覆盖的四层数据
只看会话结果不够，因为结果变差时你无法判断问题出在哪一层。四层数据缺一不可：
- 会话层：意图分布、轮次数、结束方式（解决 / 转人工 / 用户流失）。用于发现"流量结构变了"。
- 模型层：模型版本号、提示词模板版本、token 用量、P95 延迟。用于发现"上游悄悄升级了"。
- 工具层：每次接口调用的入参摘要、返回码、字段完整性、耗时。用于发现"接口契约变了"。
- 知识层：检索命中率、命中片段版本、空召回比例。用于发现"知识过期或没入库"。
三层排查法：先排除业务，再排除依赖，最后才怀疑模型
发现退化后，按固定顺序排查，不要从"改提示词"开始。
第一层：输入变了没有。把告警窗口内的意图分布和上线初期做对比，看新增意图占比、高频问题变化、渠道来源变化。我们的经验是：四成以上的"效果退化"发生在这一层，特征是某几个新意图的完成率极低，而老意图完全正常。这类问题不需要动模型，需要的是补知识、划边界或明确转人工。
第二层：依赖变了没有。逐项核对四个可能悄悄变化的东西：知识库版本、接口字段与枚举值、上游模型版本号、提示词模板版本。这一层的典型症状是工具调用失败率与空召回率同时上升，而不是回答内容变差。上一个案例里的接口字段调整就属于这一层。
第三层：才怀疑模型本身。只有在输入结构与依赖都没有变化，且各意图完成率均匀下降时，才考虑模型侧。常见诱因是上游版本变更导致指令遵循方式变化——尤其是结构化输出的格式约束能力。
用一百条哨兵样本把问题复现出来
上面三层排查需要一种手段来验证，否则只是猜测。我们使用的是哨兵样本（sentinel set）。
做法很简单：从验收评测集中挑出一百条覆盖主要意图、标注明确、期望输出固定的样本，每天凌晨自动跑一次，记录通过率。因为这批输入完全固定，所以它的通过率变化可以直接归因到系统侧。
- 哨兵样本同步下降，线上也下降 → 模型或提示词侧发生变化，去核对版本号。
- 哨兵样本平稳，线上下降 → 问题在业务侧，去看意图分布和知识覆盖。
- 哨兵样本平稳、线上也平稳，但用户投诉增加 → 判定标准本身有问题，重做人工抽检。
三种情况分别对应三种处理方式，不需要开会争论。成本方面，一百条样本每天跑一次的 token 花费通常低于一次人工复核，这是最便宜的护栏。
防止退化的四项机制
排查是事后，机制才是事前。我们要求客户在上线评审时一并确认这四项：
- 版本冻结与灰度：生产环境锁定模型版本号，上游新版本先在影子环境跑完整评测集，通过后再灰度 10% 流量，观察三天。
- 影子流量：新提示词、新模型不直接替换线上，而是复制真实请求并行执行，只记录不返回。两周即可拿到同分布对比数据。
- 变更联动：业务侧活动、规则、价格调整，必须触发知识库同步工单，并把对应问答进入哨兵样本。这条最容易漏，也最常引发退化。
- 月度巡检评审：每月用完整评测集复评一次，输出完成率、成本、延迟三条曲线，并记录本月做过的所有变更。半年后能解释清楚效果为什么变化，靠的就是这份记录。
上线后监控检查表
可直接用于上线评审，八项全部为"是"才算具备运维条件：
- 任务完成率按"用户原始目标"统计，而不是按单轮回答是否正确
- 已建立上线首周的各项基线值，并设置了明确的告警阈值
- 每条会话日志记录了模型版本、提示词版本与知识库命中片段
- 已有不少于一百条的哨兵样本，且每日自动执行并有历史曲线
- 模型版本变更走影子环境与灰度，不直接全量替换
- 业务活动上线会触发知识库同步工单，责任人明确到个人
- 工具接口的字段与枚举变动会提前通知到智能体维护方
- 有固定的兜底与转人工策略，且不会因效果下降而被临时放宽
常见问题
问：AI 智能体上线后应该监控哪些指标？
业务侧四项足够：任务完成率、人工接管率、拒答与兜底率、工具调用失败率，再加一个重复提问率用来提前发现问题。其余都是定位用的过程指标。判断一个指标该不该上看板，标准只有一个——它变化时你会不会采取动作。不会触发任何动作的指标，只是在占屏幕。
问：效果下降怎么判断是模型问题还是数据问题？
用固定输入解决归因问题。哨兵样本每天跑一次，输入和期望都不变，它的通过率变化只可能来自系统侧。哨兵样本同步下降是模型或提示词问题；哨兵样本平稳而线上下降，是业务与知识问题。没有这批固定样本时，这类争论只能靠经验猜，往往以盲目更换模型收场。
问：多久做一次全量效果回归？
哨兵样本每天一次，完整评测集每月一次，另外加上四类变更触发：换模型版本、改提示词模板、知识库结构调整、接口字段变动。经验是变更触发比日历触发更重要——绝大多数效果退化都紧跟在某一次变更之后，只是没人记录，所以看不出来。
最后一条经验：效果退化很少是断崖，多数是连续两周每天掉半个百分点。能拦住它的不是某一次模型升级，而是那批看起来毫无产出、每天都要跑一遍的固定样本。
本文数据来自天辰平台智能体运维与效果保障项目，已做脱敏与归一化处理。