当上下文已给齐答案：11 个大模型做根因推理，谁过关？

把遥测数据塞进大模型，让它告诉你哪里坏了——每隔几周就有人宣称「根因分析已经被 LLM 解决了」。Coroot 团队在实践中指出，这种说法混淆了两件本质上完全不同的事情：模型能否基于已有信息进行推理，以及模型拿到的是不是合适的数据。这两件事的失败方式完全不同，必须分开看待。

把问题拆成两半

「AI 能不能做 RCA」本身是个错误的问题。用 LLM 做根因分析实际上包含两个独立工作：

• 推理：模型能否把面前的数据串成一个因果故事。例如服务变慢，同时出现 CPU 饥饿、节点 CPU 打满、邻居进程抢占资源三件事，能推理的模型会把它们归并为「吵闹邻居」这一根因；较弱的模型只会列出三个无关「问题」，或者抓住最显眼的症状当成原因。
• 编排（harness）：把什么数据、以什么形态喂给模型。通常涉及工具调用，让模型决定何时取数、何时停止。这部分出问题与模型推理能力无关，纯粹是数据没到位。

当模型给出错误结论时，人们往往归咎于「LLM 做不了 RCA」，但多数情况下真正的原因是数据没备齐。在两者被分开之前，无法判断问题究竟出在哪一层。

消除编排变量的实验设计

Coroot 在自家 AI RCA 产品中采用了一个思路：不让模型拿着工具去自由探索，而是由确定性流水线先完成信号关联、提炼成 findings，再把这些 findings 一次性放入模型的上下文。模型无需调用工具、无需进入 agent 循环，所有需要的信息都已经摆在 prompt 里。

这样一来，问题被压缩为纯粹的推理：若模型在完整上下文下仍然找不到根因，那就只可能是推理能力不够，而不是数据编排不到位——这让能力比较变得可量化。

作者据此设计了一个测试：选一个真实故障场景，把已经包含答案的同一份上下文分别丢给多个模型，看谁能把根因讲清楚。不允许抓取，不允许决定看什么，只考推理。

题目：藏在 K8s 事件里的混沌实验

测试场景是一段典型的网络延迟故障：catalog 服务与 Postgres 数据库 db-main 之间的查询变慢，超时蔓延，前端开始返回 502。数据库与服务本身并无异常，真正的元凶是集群内一个 Chaos Mesh 的 NetworkChaos 实验，它在 catalog 与 db-main 之间注入了网络延迟，并在 Kubernetes 事件中留下了痕迹。修复方式也很直接：删除该实验，以及会再次拉起它的 schedule。

这道题的难点在于「陷阱」：

• 前端报错、延迟升高是表象；
• 真正的信号藏在 catalog 一侧，是到 db-main 的 TCP 网络延迟与连接耗时；
• Kafka 上的延迟、catalog 与 db-main 的 CPU、数据库存储指标也会波动，但都不是根因；
• 更隐蔽的是 db-main：Postgres 的查询计时从收到首字节算到回传末字节，网络往返时间被算进了查询耗时，因此 pg_stat_statements 看起来像「同样的查询突然变慢了」——实际上慢在链路上，不在数据库里。

如果模型顺着这条错误的线索读下去，就会把锅扣在数据库上。判断真实原因与下游效应之间的差别，正是对推理能力的考验。

评判标准

每道题问模型三件事：根因是什么，因果链路是什么，立即的修复动作是什么。打分只有「过」或「不过」两个档位。作者明确表示无法把「半对」折算成分数，因此门槛很简单：是否同时点出混沌实验、解释从前端回溯到 catalog 再到 db-main 的传导链，并指出既要删除实验也要删除 schedule。

输入上下文约 9,800 tokens，输出约 1,000 tokens 级别，一次性完成，不做多轮。

结果概览

11 个模型参加测试，Claude Opus 4.8 是文中被点名「过关」的案例。它的回答按正确顺序串起链路：前端报错 → 回溯到 catalog 的 Postgres 查询变慢 → 指向 NetworkChaos 注入延迟 → 以相关 RTT 与 TCP 峰值作为佐证；证据层面包括 RTT 与连接耗时随慢查询同步爬升、相关 gorm.Query span 变慢、K8s 事件标记实验起止时间，以及 db-main 的 CPU profile 干净、说明并非数据库问题；修复动作也足够实用——先删实验恢复连通性，再删 schedule 防止它再次触发。最后一步在凌晨三点的事故现场尤其关键，也最容易遗漏。

（原文结果表部分截断，11 个模型各自的完整通过情况未在摘录中给出。）