长时任务看哪些监控指标？内部门道在这

把长时任务交给智能体之后，最怕的不是慢，而是不知道它此刻在什么状态：是在正常推进，还是已经卡死半小时。监控指标就是解决这个信息差的仪表盘，让运行状况从黑箱变成可读的数字。

类比汽车仪表盘：时速、转速、油量各自回答一个问题。失效之处在于，任务没有统一的「油量」，要用队列长度、心跳时间这类代理指标拼出一幅全貌，指标选不对就会误判。

一条长时任务会经过哪些状态

典型状态链是排队、运行、等待外部返回、重试、成功或失败。每个状态切换都值得记一笔时间戳，有了这些点，才能算出每个阶段花了多久、卡在哪一段。Kimi、腾讯元宝等产品的任务记录页展示的执行明细，本质上就是这条状态链的可视化。

卡住和慢是两回事

慢是每个环节都在动，只是总耗时长；卡是某个环节长时间没有新事件。区分办法是看「最近一次状态变更距现在多久」：若远超该环节的历史常见耗时，就按卡住处理。对卡住的常见原因是等待外部接口返回却没设超时，兜底设计见超时的兜底动作有哪些？从原理到落地。

重试次数里藏着什么信号

偶发重试一两次多半是网络抖动，重试次数持续偏高则是系统性问题：接口限流、参数不被接受、页面结构变化都可能让同一环节反复失败。把重试按环节分组统计，哪个环节的重试曲线抬头，问题就大概率出在哪里。与其反复失败，不如及早熔断转人工。

告警该盯着哪几个数

建议盯四类：任务在队列里的滞留时长，反映吞吐是否吃紧；失败率，反映质量；单任务耗时分布，反映效率；人工接管次数，反映自动化程度的真实水位。阈值别拍脑袋，用历史数据的分位数定，比如超过过去七天百分之九十五分位就告警。

告警要盯的四类数，各反映一件事。

监控指标速查表

• 记录每次状态切换的时间戳
• 用「距上次变更的时间」区分卡与慢
• 重试按环节分组看曲线
• 阈值取历史分位数而非拍脑袋

一句话记住：数据不会说谎，前提是看对指标。

指标还承担追因的功能：失败率升高时，结合分支流转量能判断是哪条路径出的问题，分支机制见工作流的分支条件是怎么定的？机制细节全梳理；分数与指标的口径要对齐，避免各说各话，见Agent 评测是怎么打分的？完成率。开销异常上涨同样能从指标里看出苗头，关联分析见多 Agent 的成本怎么核算？拆开细算。来源可疑的输入引发的行为异常，也要靠调用记录识别，见提示注入在 Agent 上为什么更危险？。指标是运行情况的投影，选对指标，问题才藏不住。

指标的解读要结合任务形态：交互型任务看首响时间，批处理任务看吞吐和积压，长流程任务看阶段耗时占比。同一套指标套所有形态，得出的结论往往南辕北辙。另外，指标要给看的人留出下钻路径——报表上看到失败率升高，能顺着点进具体环节和具体任务，才叫可观测，只有一张汇总表不叫监控。还有个实用技巧：给关键指标配一条正常波动范围的参考线，比单独的当前值直观得多，偏离参考线才是需要行动的信号。指标体系不是一次搭成的，先跑起来再逐步补，比追求一步到位更现实。

聊聊监控指标的常见疑问

• 指标越多越好吗？：不是，盯不过来的指标等于没有，先保住滞留、失败率、耗时、人工接管四个核心数。
• 多久刷新一次合适？：长时任务按分钟级即可，关键环节可以秒级，刷新太密只会增加噪音。
• 要不要给每个任务单独建面板？：先看聚合视图定位异常群体，再下钻单任务轨迹，顺序别反。