很多团队在做 AI 监控时，第一反应是先搭一个大盘：看错误率、延迟、token 成本、调用成功率，再加几条报警线。问题在于，如果你还没先定义“到底什么算失败”，这些图往往只会越做越热闹，越看越难行动。一次检索偏移、一次错误路由、一次审批漏拦截、一次答案虽然流畅却业务上失败，它们在面板上都可能表现为“调用成功”，但对用户和团队的影响完全不同。
所以，真正成熟的可观测性工作，起点不该是图表，而是失败类型。Braintrust、Arize Phoenix 和 Datadog 的相关资料虽然视角不同，但都在指向同一个现实：没有统一失败分类，trace 很难解释，eval 很难覆盖，dashboard 也很难真正服务排障与发布治理。对 TaskPilots 这样的生产编排系统来说，链路追踪、运营审查和持续评估必须共享一套失败语言，团队才能知道哪类问题在增长、哪类问题已经被修住、哪类问题必须拦在上线前。
为什么这个问题重要
真实运行代价
如果先做 dashboard、后补失败分类，团队通常会先得到一堆“知道有问题、但不知道是什么问题”的指标。比如调用成功率很高，但升级率也在升；平均响应时间稳定，但用户转化下降；线上没有显式报错，却出现更多人工接管。问题不是没有数据，而是数据没有围绕失败类型组织，所以根本没法支持决策。
- 同样的红色指标里，混着模型理解错误、检索失配、工具异常和策略边界失效。
- 排障时需要先人工重新解释案例，才能知道该找模型、工作流、数据还是策略团队。
- 复盘时无法回答“哪类失败在增长”，只能笼统地说“质量不稳定”。
如果不处理会怎样
最先暴露的通常不是监控缺失，而是监控失焦。起初只是某些报警总在响，却没人知道值不值得处理；之后变成版本上线后看板看起来正常，业务侧却明显觉得变差；再往后，团队会发现自己根本没有办法把线上事故、离线评估和版本回滚串起来。因为每个环节都在用不同的语言描述失败，最终什么都记录了，什么也无法归因。
一旦继续这样演进，常见后果有四类：第一，失败簇被平均指标掩盖；第二，回归评估没有真实线上对应物；第三，回滚决策依赖拍脑袋；第四，业务指标和技术指标长期脱节。dashboard 越多，这个问题只会越明显。
适用场景
谁最需要这套方法
这套方法最适合已经进入生产阶段、系统不再只是单轮问答，而是涉及路由、检索、工具调用、人工审批、回传与发布治理的团队。尤其适合三类场景：第一，团队已经有 trace 和监控，但解释不了为什么变差；第二，已经做了一些 eval，却不知道该如何覆盖最关键的真实失败；第三，线上问题越来越多，但各团队对“失败”的定义并不一致。
- 多步骤工作流中，不同环节可能失败，但现有面板只显示整体成功或失败。
- 高价值业务链路中，运营团队需要知道哪些失败真的影响转化、留存或升级率。
- 平台团队需要给发布建立统一门槛，而不是让每次上线都临时讨论例外。
什么时候先不要这么做
如果当前系统仍然是短链路原型、调用规模很小、版本变化也不频繁，那么没必要一开始就构建很重的失败分类树。此时更重要的是先把基础日志、输入输出和关键异常采集完整。另一类不适用边界，是任务定义本身还在快速变化的探索阶段，过早固化太细的分类，反而会让团队陷入标签维护而不是问题发现。
推荐系统结构
核心角色与状态
更稳的结构，是先定义一套能跨 tracing、eval 和 dashboard 共用的失败分类，再决定 run、span 和事件上该挂哪些标签。一个实用的起点通常包含五层：输入理解失败、决策与路由失败、上下文与检索失败、工具与集成失败、输出与业务结果失败。必要时再补政策与审批类失败。这样做的关键不是分类多，而是每一类都能映射到明确的治理动作。
- run 层要带最终失败类型与业务影响，回答“整条任务为什么失败”。
- span 层要带局部失败标签，回答“具体哪一步出了什么类型的问题”。
- 评估层要围绕失败簇建数据集与门槛，回答“新版是否修住了这类问题”。
与 TaskPilots 的映射
映射到 TaskPilots，可以把链路追踪理解为失败分类的原始证据层，把运营审查理解为对真实案例进行统一标注和归因，把持续评估理解为把这些失败簇沉淀成回归样本和上线门槛。比如一条失败案例可能最终被标成“决策与路由失败”，而不是“工具超时”，因为真正的问题是控制器本不该进入这个分支。只有先定义好这种分类，后面的面板才知道该按什么维度聚合，团队也才知道该派给谁处理。
站内像 别只追工具日志，要追决策链 讨论的是“要追到决策层”，而这里更进一步讨论“追到决策层之后，应该如何统一命名失败”。像 为交接做审计链：谁委派、为什么委派、怎么回收 这样的结构化交接事件，也应该直接进入失败分类体系，而不是落成一堆无法聚合的备注。
风险与失效点
常见失控方式
第一种常见失控，是把失败分类定义得过于技术化，只覆盖错误码和异常类型，却覆盖不到真正的业务失败。第二种，是分类过细，团队根本记不住也用不一致，最后又退化成“其他”。第三种，是标签体系和 tracing、eval 脱节，导致分类虽然写在文档里，却没有进入日常运行链路。第四种，则是 dashboard 仍然按方便采集的字段来画，而不是按失败类型来聚合，最后面板和 taxonomy 彼此平行。
- 一个事故能被不同团队贴上不同标签，导致趋势图失真。
- 分类没有明确 owner，复盘会上每个人都能解释，却没人真正修复。
- 上线门槛没有绑定失败簇，回归集再丰富也拦不住关键退化。
需要人工兜底的地方
失败分类必须保留人工校准，尤其是在高影响发布、策略边界调整、客户承诺、审批放行和业务结果显著波动的节点。人工兜底的价值，不是手工替代系统打标签，而是定期校验这套 taxonomy 是否仍然解释真实问题。比较稳的做法，是让人工复核代表性案例、检查标签一致性，并决定是否需要合并、拆分或重命名失败类目。没有这层人工校准，taxonomy 很快就会变成另一个没人信的字段。
验证指标
上线前怎么验证
上线前最重要的，不是先画面板，而是先验证失败分类能不能稳定使用。建议至少做三类检查：第一，回溯最近一批真实事故，看团队能否用同一套 taxonomy 完成归类；第二，针对高频失败簇建立小型回归集，验证新版是否真的改善；第三，用一组代表性案例检查 dashboard 草图，确认每一张图都能回答明确问题，而不是仅仅“信息很多”。
- 做标签一致性检查，确认不同角色对同一案例的归类不会严重分叉。
- 用失败簇而不是随机样本建立回归集，避免评估覆盖不到真实痛点。
- 检查每条发布门槛是否都对应某类失败，而不是对应一个孤立指标。
上线后怎么持续判断
生产阶段建议长期追踪四类核心指标：故障定位时间、评估通过率、线上回滚率和业务转化指标。除此之外，还应补两项更贴近 taxonomy 本身的指标：标签覆盖率和标签一致性。前者衡量多少真实问题能被归入明确失败类，后者衡量不同复盘者是否会给出相近结论。如果这两项长期偏低，再漂亮的 dashboard 也很难真正服务治理。
下一步 / FAQ
下一步建议
最实用的第一步，不是先重做整套监控，而是先找最近二十到三十个真实失败案例，强制团队只用一页 taxonomy 去归类。归类结束后，再问三个问题：哪些类目最常见、哪些类目最伤业务、哪些类目目前根本没有 eval 和发布门槛。把这三个答案补齐后，再去设计 dashboard，面板就会天然更聚焦，也更容易转化成行动。
FAQ
失败分类是不是越细越好？ 不是。好的 taxonomy 追求可解释、可复盘、可行动，而不是理论上无限精细。
已经有很多指标，还要先做 taxonomy 吗？ 通常仍然值得。没有统一失败语言，指标再多也很难形成稳定治理闭环。
这会不会拖慢搭 dashboard 的速度？ 短期会慢一点，但通常会大幅减少后续反复改图、改标签和改报警的返工。
最常见的组织阻力是什么？ 往往不是技术，而是不同团队对失败归因的口径不一致。所以 taxonomy 需要跨工程、运营和业务一起确认，而不是只由平台团队单独定义。