AI Agent 上线以后，最危险的状态不是直接报错，而是悄悄变慢、悄悄变贵、悄悄变得不可靠。用户还没投诉，队列已经开始堆积；人工还没察觉，工具重试已经翻倍；看起来每次都能回答，结果来源却越来越弱。
所以生产 Agent 要有自己的观测指标。它不是给技术团队看的装饰图表，而是接在 上线准入清单、质量门禁 和 SLA 分层 后面的日常体检。
先看流程有没有变慢
响应耗时要拆开看，不能只看总耗时。模型推理、知识库检索、工具调用、人工确认、外部系统写入，每一段都应该有时间记录。否则一次任务变慢时，团队只能猜是模型慢了，还是工具超时了。
更实用的做法，是给不同任务类型设基线。普通问答、资料整理、CRM 查询、批量写入，本来就不该用同一条耗时标准。
工具成功率要和重试一起看
工具调用成功率单独看容易误判。如果系统不断重试，最后一次成功了，表面成功率可能还不错，但用户体验和成本已经受影响。重试次数、失败原因和超时比例要放在同一张表里。
这部分可以接上 失败回放样本库。重复出现的工具失败，不应该只停留在日志里，而要进入后续修复和回归验证。
人工接管不是失败，而是信号
人工接管率上升，不一定说明 Agent 变差，也可能说明质量门禁更严格。但如果接管原因集中在资料冲突、权限不足、意图不清或工具返回异常，就说明上游流程需要调整。
前面写过 人工接管台。接管台如果只负责处理，不负责沉淀原因，就会错过最有价值的改进线索。
低置信度要有趋势线
低置信度请求不能只逐条处理。按知识库、客户类型、任务类型、工具节点去看趋势，才能知道问题是偶发，还是某个业务场景长期缺资料、缺权限或缺规则。
这也能反哺 低置信度请求分流。分流不是终点，分流后的数据要告诉团队哪些地方最该补。
总结
AI Agent 观测指标的价值，是在用户投诉之前发现流程变慢、工具变脆、人工接管变多和低置信度集中爆发。看板不是为了好看，而是为了让生产系统持续可控。
