证据与置信度足以支持结论吗？
系统检查证据完整性、标签覆盖和不同判断之间是否冲突。
项目记录 · 2025–26
Agent 失败诊断系统
TB2 Diagnostics
把冗长的 Agent 失败轨迹，转成带证据的错误类型和修复优先级，降低人工复盘成本。
为什么会做这件事
团队只看到“任务失败”，就无法判断下一轮该改规划、工具调用、环境理解还是执行策略。人工逐条看日志平均需要 770 秒，而且不同人可能给出不同结论，评测结果很难稳定地指导迭代。
真正的问题
怎样在不让模型自由猜原因的前提下，把轨迹转成可复核、可统计、可指导修复的诊断结果？
我做的关键选择
每个动作，都应该能解释为什么。
先人工分析 46 条失败轨迹，再建立 L1/L2 分类。
分类必须来自真实失败模式；如果直接让模型生成标签，口径会漂移，也难以比较不同批次。
强制每个判断绑定日志、命令、报错或耗时证据。
证据链让结论可以被复核，减少“解释听起来合理，但轨迹并不支持”的空诊断。
把低置信度与冲突样本交回人工仲裁。
自动化最适合先筛选和统一格式；保留人工兜底能控制误判风险，并继续补全分类边界。
系统怎样运转
一次 Agent 失败如何变成可执行的修复优先级
开始 / 输入处理判断结果
- 运行环境
采集失败轨迹
汇总命令、日志、报错、耗时与模型决策。
- 诊断管线
抽取证据与转折点
区分最终报错、上游异常和真正根因。
- LLM Judge
按固定分类归因
输出 L1/L2 标签、引用证据、解释和置信度。
进入结构化诊断库
直接用于批次统计、问题聚类和修复排序。
提交人工仲裁
复核原始轨迹，确认标签或纠正根因。
扩充分类边界
把无法覆盖的案例加入 taxonomy 迭代样本。
研发闭环
诊断结果转成修复与回归测试
按影响与频率确定优先级；修复后重新运行任务，新的轨迹再次进入诊断。
业务含义诊断的业务价值，是让研发不再从整段日志里猜原因：高置信样本快速归档，争议样本交给人，所有结果最终指向下一轮修复。
亲手做的部分
从判断到可运行的东西。
归因
从轨迹中定位关键转折，将表象错误与根因分开。
判断
让 Judge 依据固定分类和证据格式输出原因、证据与置信度。
仲裁
抽检高置信度结果，人工复核冲突与覆盖不到的样本。
留下的证据
- 与人工判断一致率 92%
- 标签覆盖率 91.7%
- 平均置信度 0.89
- 单轮诊断由 770 秒降至 354 秒
结果来自特定 Agent 与任务集合；分类体系需要在新模型、新工具链和分布外失败上继续检验。
把诊断结果连接到可验证的修复建议，并追踪“诊断正确”是否真的带来任务成功率提升。