7000多条真实故障记录，18套生产级检测器，两套公开基准测试。结果让团队内部吵了三天——专门训练的启发式检测器，在大多数故障类型上干掉了顶级大模型评委。
这事反直觉。行业里默认的解法是用AI评AI：把执行轨迹丢给GPT-4o或Claude，问"哪出错了？"灵活、通用，就是贵。但Pisama的测试数据显示，这套"金标准"在结构性故障面前集体翻车。
两套基准，一个残酷现实
Patronus AI发布的TRAIL数据集，148条真实智能体执行轨迹，841处人工标注错误，横跨21种故障类型。难点在于：系统必须找出所有问题，不是挑一个最明显的，是全部。
顶级大模型在这栽了。Gemini 2.5 Pro的联合准确率11.0%，Claude 3.7 Sonnet 4.7%，OpenAI o3 9.2%。这些模型能写代码、能推理、能通过律师考试，却在"系统性检查清单"这种任务上露怯——它们被优化的是开放式推理，不是结构化的逐项排查。
另一套Who&When更刁钻。ICML 2025的spotlight论文，任务是给定多智能体对话故障，判定哪个智能体、在哪一步出的问题。检测+归因+定位，三重难度叠加。
Pisama的启发式检测器在这套基准上的 headline 数字：比最强LLM高5.5倍，成本为零。
100%精准率的代价
但准确率不是团队最看重的。真正让产品经理拍桌子的是精准率：当Pisama报故障时，它永远是对的——TRAIL数据集上100%精准率。
代价是召回率。40%的故障会被漏掉，这些是启发式规则没覆盖到的模式盲区。换句话说，这套系统的哲学是：宁可沉默，也不误报。
漏掉的40%去哪了？LLM escalation（大模型升级机制）接手。分层架构由此成型：规则能搞定的，零成本秒级响应；规则搞不定的，再喊贵的大模型来救火。
LLM零分的领域，规则拿满分
分类数据揭示了一个尴尬事实。Context handling（上下文处理）——大模型评委在此零分——启发式检测器接近满分。循环故障、规范合规性、工具调用错误，同属此列。
这些故障的共同特征：有强烈的结构性信号。循环有明确的重复模式，工具错误有固定的返回码格式，规范合规可以拆解为可验证的约束条件。模式匹配器提取这些信号，比语义推理更可靠。
Who&When的细分数据更有意思。启发式检测器在步骤定位上击败o1：16.8% vs 14.2%。找到"故障发生在哪一步"，比单纯判断"有没有故障"更难，但规则系统依然领先。
LLM还没被淘汰的战场
但故事有另一面。语义理解类故障——意图误判、隐含需求冲突、创造性任务中的质量滑坡——这些没有固定模式，启发式检测器束手无策。
团队内部曾有争论：要不要把LLM评委彻底降级为"兜底方案"？最终结论是保留混合架构。规则层负责速度和确定性，LLM层负责覆盖长尾和语义灰色地带。
校准数据集来自13个外部源：MAST-Data（NeurIPS 2025）、AgentErrorBench、SWE-bench轨迹、GAIA轨迹、真实n8n工作流故障。7,212条标注条目按难度分层交叉验证，确保规则不会过拟合到特定场景。
一个细节：n8n工作流故障的纳入是去年Q4的决定。当时团队发现，生产环境的真实故障分布与学术基准差异显著——太多"第7步应该调用API A但调成了API B"这种低级错误，在干净的研究数据里罕见。
Pisama的18个检测器类别中，有3个完全依赖LLM escalation，其余15个以启发式为主、LLM为辅。这个比例会随数据积累动态调整。上个月刚把"响应格式异常"从LLM层迁移到规则层，因为攒够了模式样本。
下一步测试方向已经确定：多模态轨迹（带截图的网页操作）、长程依赖故障（第3步的错误第50步才暴露）、以及动态工具调用场景。规则系统在这些领域的表现，将决定混合架构的边界往哪移动。
读者里有多少人在用LLM-as-judge做生产监控？你们的规则层和模型层比例是多少？
热门跟贴