企业 Agent 的可观测性至少要回答四句话：它正在处理哪项工作；执行到了哪一步；结果是否已经在业务系统确认；为了这个结果用了多少模型、工具和人工。只看 Token、延迟和报错，得到的是接口监控，不是 Agent 运营。
六层指标放在一起才有意义
| 层级 | 典型指标 | 防止什么误判 |
|---|---|---|
| 业务结果 | 终态达成率、漏错项、提前发现时间 | 把“生成内容”当完成工作 |
| 任务执行 | 开始、等待、人审、写回、回读、结束 | 会话还活着却不知道卡在哪里 |
| 人工协作 | 确认率、驳回率、接管原因、接管时长 | 把人工兜底藏在漂亮成功率后面 |
| 知识与连接 | 命中来源、数据时效、连接失败、权限拒绝 | 把事实问题误判成模型问题 |
| 模型与成本 | 完整任务 Token、模型切换、单位成功成本 | 用单次调用均价估算整项交付 |
| 风险与审计 | 越权拦截、敏感动作、重复写入、变更影响 | 只在事故后翻原始日志 |
这些指标必须能落回同一个业务对象。例如一次“催回款”任务，要能关联客户、订单、应收明细、当前责任人和复查日期；否则无法判断一次模型调用是否真的对应一笔应收的推进。
先定义终态，再定义成功率
“已生成报告”“已发送提醒”“接口返回 success”都不是可靠终态。终态应能从权威系统独立回读，例如工单变为已关闭且客户确认、应收完成到账认领、审批进入生效状态、项目缺口被责任人处理。
因此成功率的分母也要说清：是全部触发、有效任务、进入自动执行的任务，还是排除资料缺失后的任务。没有分母定义，两个团队的 90% 成功率可能完全不是一回事。
写回与回读的详细方法见Agent 写后为什么必须回读；异常如何分流见Agent 遇到异常怎么办。
失败要按业务原因分层
同样是任务失败，处理人可能完全不同：模型理解错误由 Agent 运营人员处理；知识过期由内容 Owner 更新；连接器失效由 IT 修复；权限拒绝可能是正确门禁；客户尚未回复则属于外部等待。把它们全部记成 error，只会得到一张无法行动的红色图表。
每类异常至少带上对象、阶段、证据、责任人、截止时间和恢复方式。运营看板的价值不是告诉你“有 37 个错误”，而是让 37 个错误进入正确队列。
成本按成功任务计算
企业购买的不是一次 API 调用，而是一项工作结果。应把主会话、工具调用、重试、子任务、人工复核和失败浪费计入同一任务账本，再计算单位成功任务成本。模型价格下降不代表业务成本一定下降，少一次返工往往比少几千 Token 更重要。
建立可观测平台时，先挑一条真实闭环，从触发到终态逐步串起证据，不要先造一张“全公司 AI 大屏”。需要把指标与真实系统连接起来，可从企业知识中枢和开沿 Agent继续评估。
看板要支持逐层下钻
管理层先看业务结果和异常趋势，业务 Owner 再按工作类型、部门和责任人下钻，运营人员进入具体任务查看步骤，IT 最后定位到连接器和原始错误。若所有角色只能打开同一张模型调用表，数据虽多，决策路径却断了。
一条指标必须能回到样本。例如“本周终态达成率 82%”应能展开分母、排除项、失败分类和具体任务；“单位任务成本上升”应能区分模型变贵、任务变长、重试增多还是人工接管增加。不能下钻的总数很容易掩盖口径变化。
告警按业务影响分级
单次模型超时可以自动重试，不必立刻通知所有人；批量任务停止获取、写后无法确认结果、权限范围异常扩大，则应立即升级。告警规则同时考虑影响对象数量、动作可逆性、持续时间和是否存在人工替代路径。
每条告警还要有抑制和恢复条件。同一根因影响多个任务时合并事件；依赖恢复后先跑真实探测，再逐步恢复任务，避免“服务绿了”但业务仍未继续。
每月淘汰没有行动价值的指标
运营一段时间后，检查每个指标是否真的触发过决策。长期无人查看、无法改变行动或与其他指标重复的项目应下线；新出现的高频异常则补充口径。可观测体系不是一次交付的大屏，而是随真实工作持续收敛的经营工具。
