← writing

用转移失败矩阵诊断 agent workflow：Hamel 的方法，和它在复杂系统里怎么扩展

2026-10-09

一条失败的 trace 只进一个格子。行 = 最后做对的一步，列 = 第一处做错的一步。

agent 出了问题，读了二十条 trace，手里一堆笔记，却说不出该先修哪里。Hamel Husain 和 Shreya Shankar 在 AI Evals FAQ 里给的汇总工具叫转移失败矩阵（transition failure matrix）。前半篇是原方法，后半篇是我在自己项目里套用时想清楚的扩展，原文没讲的部分会标出来。

原方法：先判成败，再看步骤

方法两步

Hamel 原文的转移失败矩阵

GenSQL → ExecSQL 有 12 条，先查这里。

它其实是状态机的邻接矩阵

行列是状态，一个格子是一条转移。想明白这一点，循环就不是特例了。

我的项目 Meridian 是一个新闻简报系统，里面有一个写作–核查循环，也就是 Anthropic 说的 evaluator-optimizer：一个 LLM 生成，另一个评估并反馈，循环往复。

写作–核查循环的状态

三条失败的 trace 各落一格

③ 落在对角线下方，这就是循环那条回头的边。原文的例子只有对角线上方有数，是因为那个流程恰好是直线。

矩阵只回答断在哪条转移上。同一步的不同错法（核查漏掉真错、核查误拦好句）记在同一列，进了格子再分。

每一步对不对，不能看日志

核查把一句好话判成了「有问题」：

系统日志与人对照原文的两种看法

没有报错，链路照常往下走。按日志填矩阵，会得出「核查从不失败」。每一步的成败只能由读 trace 的人判。

让 LLM 替你判也还不行。Who&When（ICML 2025）专门测自动定位失败，最好的方法读数如下：

要找的东西准确率
哪个 agent 负责53.5%
错在哪一步（decisive error step）14.2%

论文里的 decisive error step，就是这里说的第一处上游失败。

从 workflow 到 agent，做法一样

Anthropic 的定义：workflow 是 LLM 和工具走预先写好的代码路径；agent 是 LLM 自己动态决定流程和工具使用。上面的写作–核查循环是 workflow，下面这个是 agent。

Meridian 的核查曾经是一个小 agent，四个工具，先用哪个、用几次都由模型定：

模型自己选工具

选路是运行时的事。跑完之后，一条 trace 仍然是一串排好顺序的步骤：

一条 agent trace 的步骤

这条 agent trace 落进的格子

和 workflow 比，只有三处不同：

workflowagent
状态清单从代码抄工具名，加一行「开始」
对角线空有数（同一工具连用）
数的分布集中在几格散开，要读更多条

工具很多、agent 嵌在 workflow 里：粗粒化与分块

这一节是我自己的推演。原文只说了一句：矩阵怎么组织取决于你的应用。

工具很多时，先合并。

工具按用途合并成阶段

小 agent 嵌在 workflow 里时，看成分块矩阵。

外层矩阵与展开的对角块

先粗后细的展开顺序

注意：数学里分块只是换个写法，随时能还原。这里不行：标注时只记了粗状态，细的信息就没留下。读 trace 时笔记里顺手写下具体断在哪个工具，汇总时再决定用粗的还是细的。

矩阵不表达什么

留下丢掉
最后做对的是哪步前面走了什么路
第一处做错的是哪步这是第几次调用

这是有意的取舍，它只回答先去哪里查。顺序重要时两个补法：

小结

延伸阅读

工作做了什么补上本文哪一块
MAST（UC Berkeley，NeurIPS 2025）多 agent 失败分类法：14 种失败模式，3 大类（系统设计、agent 间不对齐、任务验证），标注一致性 κ = 0.88格子里的第二层分类，可以从它起步
Who&When（ICML 2025）自动定位「哪个 agent、哪一步」出错的基准，127 个多 agent 系统的失败日志定位出错步骤目前只能靠人
TRAIL（Patronus AI，2025）148 条人工标注的 agent trace，测 LLM 调试 trace 的能力，最好的模型得分 11%同上
Automata from Agent Traces（ICML 2026）把一批 agent trace 合并成一个有限状态机：12 个数据集上只有 7–43 个状态；按状态特征预测失败，AUROC 最高 0.94agent 事后看也是个不大的状态机；矩阵可以从事后诊断走向运行时预警

参考