AI 工作流上线后怎么监控？四个指标与告警阈值思路

跑完不等于跑对：静默失败长什么样

我们做过一条「客户表单 → 模型抽字段 → 写 CRM」的工作流。上线后监控面板一片绿，第三周销售说这个月新线索是零。翻日志才发现，上游表单改版把字段名从 company_name 换成了 corp，模型取不到值，返回空 JSON；写入环节对空值做了容错，于是老老实实写进去一条只有 ID 的空记录。整条链路没抛过一个异常。

这就是静默失败。技术上每一步都返回 200，业务上产出为零。只盯「有没有报错」的监控，对这类问题基本失明。下面四个指标，是我们做 AI 工作流自动化 时会默认上的最小集合。

先把常见的静默失败列一列，对照你手上的流程看中了几条：

• 调度没触发。容器重启后定时器没起来，任务根本没跑，日志里连报错都没有。
• 接口返回 200，body 里是错误信息或空数组，客户端按成功处理了。
• 模型输出被 max_tokens 截断，JSON 解析失败后悄悄走了默认分支。
• 重试三次都失败，异常被 catch 住写了一条 warn 日志，主流程继续往下走。
• 知识库检索命中 0 条，Agent 硬着头皮编了一个答案，语气还很笃定。

指标一：执行成功率，拆成技术成功率和业务成功率

技术成功率好算：无异常退出的执行数 ÷ 总执行数。业务成功率得你自己定义「合格产出」——字段是否齐全、答案有没有引用到文档、写库条数是否大于零。

两个数字放一起看，差异会告诉你问题在哪：技术成功率 99%、业务成功率 82%，八成是数据或模型环节在悄悄掉链子；两个一起掉，多半是对端系统或网络。还要防一个陷阱——定时任务没触发时，分母是零，面板上的成功率看起来是满分，实际上什么都没跑。所以并行加一条「应执行次数 vs 实际执行次数」的对账。

指标二：平均耗时看 P95，别看平均值

平均值会被大量快速成功的执行拉平，真正难受的是那 5% 的长尾。我们一般同时记 P50 和 P95：P50 稳着、P95 从 40 秒涨到 3 分钟，基本能定位到模型接口变慢、重试变多，或者知识库变胖导致检索变慢。

耗时还是成本的前哨。同一流程耗时翻倍，往往意味着 token 用量或重试次数也在翻倍，可以直接和 模型 API 与成本管理 放在一张表里看。

指标三：异常类型分布，看结构变化比看数量有用

把错误打上三个维度：模型层（超时、限流、输出格式不符）、集成层（鉴权失效、外部系统 5xx、字段缺失）、业务层（校验不通过、检索无命中）。单看每天 30 条报错没什么信息量，看占比才有——JSON 解析失败从 5% 涨到 40%，通常是换了模型版本或有人改了提示词；鉴权失败突然冒出来，多半是密钥到期。

指标四：人工兜底次数，很难被美化的质量信号

兜底率 = 人工介入的执行数 ÷ 总执行数。这个数字往上走，说明自动化在「假装工作」，把难处理的都推给人了。我们的习惯是兜底率超过 10% 就回头查两件事：提示词里的边界条件写没写清，业务校验节点是不是漏了。反过来也要防兜底被滥用——某条流程天天靠人补，那就不是自动化，是给人多加了一道工序。

指标	计算口径	优先看什么	告警思路
执行成功率	技术成功数 ÷ 应执行数；业务合格数 ÷ 应执行数	两个值之间的差值	连续 3 次技术失败，或业务成功率低于基线 5 个百分点
耗时	P50 / P95	P95 的漂移速度	P95 超过基线 1.5 倍并持续 30 分钟
异常类型分布	按模型层、集成层、业务层打标计数	各类型占比变化	单一类型占比超过基线 2 倍
人工兜底	人工介入数 ÷ 总执行数	周趋势而非日数据	周兜底率超过 10%，或环比翻倍

表里的倍数是起步值，不是标准答案，最终阈值要以你自己跑出来的基线为准。

阈值怎么定：先观察两周，再分层

不要一上线就配告警，会把自己淹了。先只记录不告警，跑一到两周拿基线——注意覆盖工作日和周末，很多企业流程周六的量只有工作日的三成，拿工作日的基线去卡周末必然误报。

阈值取基线的倍数，而不是拍一个固定值，因为不同流程的量级差太多。然后分三层：只记录不打扰的、发企业微信群的、打电话的。真正值得打电话的通常就两类——核心流程连续失败、每日对账出现缺口。

抑制规则也得有：同一错误 30 分钟内合并成一条；连续失败 N 次才升级，别让一次网络抖动把群里刷屏；发布窗口留白。告警内容要带够上下文：流程名、执行 ID、失败节点、输入摘要（脱敏）、上次成功时间，否则值班的人还得自己去翻日志。

埋点埋在哪儿

每个节点进出各写一条结构化日志，字段固定：trace_id、节点名、耗时、状态、错误码、输入输出摘要。摘要要脱敏，手机号、身份证号这类别直接落盘。

业务校验建议做成独立节点，别藏在代码里。校验不过就显式失败并打标，让它在异常分布里占一格，而不是被 try/catch 吞掉。

再加一个每日对账任务：应产出条数 vs 实际产出条数，差值为零才通过。这一条比看板上任何一条曲线都管用，静默失败基本都会被它捞出来。跑智能体类流程时，对账还得覆盖「答案有没有引用到知识库文档」——我们在 企业知识库 的落地里踩过这个坑：检索为空但模型照样输出，看上去毫无破绽。

看板别做太复杂

四个数字加一条趋势线就够了。实时曲线好看，但没人盯；真正起作用的是每天固定扫一眼趋势——兜底率是不是在爬，业务成功率是不是在缓慢下滑。缓慢下滑比突然报错更麻烦，因为它不会触发任何告警。

私有化部署的场景，日志和看板尽量跟业务数据放在同一侧，别为了监控把敏感字段传到外部服务，本地日志加单点看板就够用。

下一步做什么

挑一条跑得久、影响面大的流程，先加两样东西：业务校验节点和每日对账任务。跑两周，把四个指标的基线记下来，再谈告警阈值。做完这一步，你至少知道自己在不在「静默地坏着」。要一起看监控设计或埋点方案，可以走 联系我们，或者直接打 400-873-2750。