TraceBench：让agent找故障根源，写程序的竟比直接回答更差
假设你请来一位故障诊断专家，让他盯着监控面板回答"是哪个参数出了问题"。把条件调到最理想时，他能答对九成以上。可你要是换个考法：请他把诊断思路写成一份能反复使用的 Python 脚本，他的正确率反而掉了近十个点。这已经够反直觉了，更怪的还有两件事：他放着曲线图不看，更信任一长串数字；你把带正确答案的示例样本撤掉，他反而发挥得更好。
这不是某个小团队的内部测试，而是 TraceBench 这篇新论文在四套主流 agent 系统上反复验证出的结果。它没有测试任何新模型，而是建了一个考场：故障是当场制造的，标准答案事先写死，环境里会干扰判断的因素被一件件关掉，然后让四个 LLM agent 系统进去答题。论文想回答的只有一个问题：当智能体在系统里"答对了根因"，我们凭什么相信它真的懂了因果，而不是靠工具链、上下文长度或者运气蒙对的？
能说"出事了"的agent，为什么还不能信它说"为什么"？
这篇要讲的，是 TraceBench 怎样审计"agent 答对根因"这件事可不可信。它审计的是两种容易混为一谈的能力。能说"出事了"，叫异常检测，只需要一个阈值，CPU 飙了、延迟掉了，报警就响了。说清"为什么出事"，叫根因归因（root-cause attribution），要在几十条互相纠缠的时间序列里指出是哪一个变量在什么时候变了，才最终点燃了这一切。报警只需要看到烟，归因必须找到火源。TraceBench 审的不是报警，而是后一种：agent 报出的那个根因，凭什么信它不是蒙的。
审计之所以必要，是因为根因定位正在从规则脚本和人工值班，批量交给 LLM 智能体：云平台的告警工单、微服务的指标诊断，都开始让 agent 在遥测数据上自己找根因，而现有的评测方式说不清这些 agent 答对题目时靠的是什么。TraceBench 的回应是建一个答案事先写死、干扰被一件件关掉的考场，把"受控归因"单独拎出来考，然后在四套主流 agent 系统上反复验证。这场审计得到的预告证据有三件反直觉的事：让 agent 把判断写成脚本去诊断，它反而比直接回答更差；放着曲线图不看，更信一长串数字；撤掉带正确答案的示例样本，它反而发挥得更好。
归因之所以难，在于它面对的是连锁反应。一次配置错误会引发内存升高、延迟抖动、告警刷屏，几十条序列一起变形，真正的根因藏在那条最先变形的曲线里。检测算法只要识别出"今天不对劲"就够了，归因却要在相关性的大海里捞出因果。这层难度不会因为换成 LLM 智能体而消失，只会被转嫁给新环节：agent 得自己决定看哪条通道、算哪个统计量、信哪个工具的输出。
看看真实环境这一侧的标杆。AIOpsLab 是 MLSys 2025 上发布的真实云环境评测：自动部署真实微服务，用故障注入工具制造崩溃，让 agent 在 Prometheus 指标、Jaeger 追踪和日志里走完检测、定位、归因、处置的完整事件生命周期，由 UIUC、UC Berkeley、Microsoft 和 IISc 联合推出，初期包含 48 个 problems。AIOpsLab 另一侧是 OpenRCA，ICLR 2025 上第一个大尺度的真实软件 RCA 基准：335 个真实软件故障、68GB 的多模态遥测，agent 要在日志、指标、调用链里定位根因。OpenRCA
这两类基准解决的问题是"agent 在真实系统里能不能把事情办成"，但它们测不出另一件事：agent 是不是真的在做因果推理。原因在于真实环境里的分数混着太多东西，会不会操作工具链、会不会读懂调用链、上下文能塞多长，全都一起进了总分。一个 agent 答对了根因，可能是它推理出来了，也可能只是整套工具链顺。反常的点就在这里：环境越真实、变量越不可控，"归因能力本身"反而越测不出来。
图注：AIOpsLab 的总体架构：Orchestrator 居中协调，左侧 Workload/Fault Generator 向微服务注入故障与负载，服务经 Prometheus/Jaeger/Filebeat 导出遥测，右侧 agent 经 ACI 与 Orchestrator 交互。AIOpsLab
这正是 TraceBench 想绕开的。它把问题从"真实系统里能不能答对"换成"在答案已知、杂质被滤掉的合成故障里，agent 还能不能指认根因"。答案已知，才谈得上信不信。要做到这一点，得先会制造一场"答案已知"的故障。
制造一场"答案已知"的故障：物理模拟器、干预注入与可解性过滤
TraceBench 用三个可解释的物理动力学模拟器来合成故障。BallDrop 是一个在重力场里上下弹跳的小球，BounceBall 是一个在两条刚性墙之间滚动的阻尼质量块，MassSlide 是一个在斜面上被周期力推动的质量块。每个模拟器都只握有几个参数：重力加速度、恢复系数、斜面倾角、弹性系数之类。选物理模拟器而不是任意合成数据，图的是一层可解释性：每个候选根因都有明确的物理意义，agent 答对"恢复系数变了"，意味着它真读懂了轨迹的形态变化，而不是撞上了统计规律的巧合。
三个模拟器的干预也各有各的物理形态，论文里的例子包括：增大 BallDrop 的恢复系数、增大 BounceBall 的倾角、减小 MassSlide 的斜面倾角。agent 拿到的观测同样不干净：每个模拟器都有专属噪声模型，在异方差高斯噪声之上叠加上相关的漂移，以及干预时刻附近特有的过渡成分。噪声的存在让"直接看图说话"失效，逼 agent 靠统计推断把信号从背景里抠出来。
每道题是这样造出来的。先让模拟器用一组基准参数跑出一条干净轨迹，然后在某个时刻 $t_{\mathrm{int}}$ 对其中一个参数做一次瞬时干预，相当于在物理定律里拧了一个旋钮，之后轨迹继续演化。agent 拿到的是加了噪声的多变量时间序列，任务是回答：有没有变量被动过？如果动了，是哪一个？
这一步是整个基准的命门：被拧的旋钮的名字，就是这道题的标准答案（ground truth）。标准答案不是靠人标注出来的近似，而是出卷老师亲手埋进去的事实。你说出"恢复系数变了"，就等于复述了制造故障时的动作。流水线里还会混入一批完全没有干预的样本，这一手防的是偷懒：如果 agent 预设"题目里一定有人动了参数"，遇到没动过的样本就会强行指认错误根因，这批样本逼它先判断题里到底有没有变化。反过来说，无干预样本也不是随便留的：只有当至少两个干预根因能通过同一道过滤时它才会被保留，否则"什么都没发生"这个答案会变得过分好猜。光有答案还不够，得保证题目真的解得出；把这几步拼起来，整条流水线长这样：
图注：TraceBench 流水线总览，以 BallDrop 为例：左栏黑色是干预前、橙色是干预后的位置轨迹，竖虚线标出 $t_{\mathrm{int}}=4.0$ 的干预时刻，本例干预增大了重力加速度；右栏是"模拟器 → 观测/干预/噪声/探测 → 测试批与支持批 → agent → 预测"的完整数据流。TraceBench
样本在进入 agent 之前，还要过一道质检，论文叫它可解性过滤（solvability filtering）。它的职责是筛掉三类废题：干预效果太小以至于检测不出的、干预后参数能"平凡地"复现整条轨迹的、以及不同参数在观测上互相混淆的。四道关卡层层递进：
第一关是"无干预对照"：用同样的初始状态和基准参数重跑一遍，如果加了干预和没加干预几乎一模一样，这题没人能做对，拒绝。第二关是"静态变化对照"：从干预时刻起全程改用干预后的参数重放，如果后干预参数就能平凡地重现整条轨迹，说明这道题的答案形同虚设，拒绝。第三关是硬阈值：至少有一个观测通道的效应噪声比要达到 2 以上，干预的效果必须压得过噪声。最后一关是模拟器专属规则，处理物理系统特有的混淆，比如小球落地静止后，重力和质量在观测上再也无法区分，这类样本直接丢掉。TraceBench
过滤之后，agent 面对的每道题都是标准答案确定、题目可判别（包括无干预）的干净题。agent 仍须先判断有没有发生干预，再归因到具体参数。在这样的题上答对，才谈得上归因能力。可考场的大门还开着四个可以旋动的旋钮，论文把它们做成了四根可控轴。
把"诊断推理"单独拎出来：四维可控轴与两种提交方式
TraceBench 把每一道题都放在四个独立可控的轴上考核，每根轴各自变化一种环境条件，合起来回答评测设计里最难的问题：agent 的归因能力边界，到底是任务本身给的，还是环境给的？
第一根轴是领域上下文（domain context），决定给不给 agent 一份系统说明，告诉它"这是重力场里的小球"、每个通道的含义、候选根因有哪几类。不给的时候，类名会匿名为 label_0 到 label_n。第二根轴是观测噪声，基准里只用两档：κ_low 和四倍于它的 κ_high。第三根轴是有标签示例，除了一道题标配的 10 个测试样本，还会不会给每个候选类附上 3 个带正确答案的示例样本。第四根轴是提交方式（submission mode）：直接报答案，还是把判断写成一段可复用的 Python 脚本。四根轴画成四张卡片：
图注：TraceBench 的四个可控轴：domain context、observation noise、labeled examples，以及 direct or programmatic submission，四张卡片各自对应一个可独立调节的轴。TraceBench
第四根轴值得停下来多讲两句，它是整套设计里最有洞察的一环。直接回答（论文记作 S_direct）时，agent 可以针对每个样本做独立的判断，"这条轨迹像换了弹性系数，那条像改了重力"。写脚本（记作 S_prog）时，agent 必须把判断压缩进一个通用函数，用同一个程序处理所有样本。这还不算完：脚本提交后，论文会拿一批 agent 在考试过程中从没见过的 held-out 样本去跑它。这一下就把两件事分开了：答对这一题，和掌握一条能迁移到新样本上的根因规则。前者考临场，后者才考理解。如果脚本学到的是干预留下的稳定物理签名，它在没见过的样本上应当同样答对；如果它只是背下了考试集里的几句话，新样本一来就会露馅。TraceBench
被测的是四套完整的 agent 系统，每套都是"语言模型 + 终端脚手架 + 推理设置"三层结构：gpt-5.5 配 Codex，gemini-3.1-pro 配 Gemini CLI，claude-opus-4.6 配 Claude Code，开源的 minimax-m2.7 跑在 OpenCode 上。推理强度一律设成 high，每个 episode（一个完整的答题回合）在隔离容器里运行，只有 Bash 和 Python、没有网络，基础设施挂掉的回合会重启重跑，让分数只反映能力、不反映平台稳定性。主实验是 3 个模拟器 × 4 种条件（低噪/高噪 × 直答/脚本）× 5 个随机种子，每个 agent 跑 60 个 episode。四根轴并不是同时都在变：主实验固定领域上下文和有标签示例都开着，只让噪声和提交方式两两组合；两组消融实验再分别拔掉标签、拔掉上下文补测，都在高噪声档下进行，成本所限只跑了 gpt-5.5 和 gemini-3.1-pro，看分数各自往哪边掉。
顺着这条线看，TraceBench 不是孤例。TemporalBench 是 USC 团队 2026 年初发布的同类基准，同样用受控合成产出带标准答案的任务，但它考的是事件条件下的预测与理解，任务按"历史理解、无上下文预测、上下文推理、事件驱动预测"四族切分，其中上下文推理一族还按六维能力再细拆，整体规模是 2775 个任务、191 条时序实例。两边都靠受控合成制造标准答案，标签的形态却不同：TemporalBench 的答案是统计意义上的相对变化，TraceBench 的答案是物理参数的身份。agent 的行为本身也不是重点。TemporalBench 同方向的 TimeSeriesGym 则考 ML 工程产出物，数据处理、建模、训练，跑的是另一条跑道。TimeSeriesGym 相比之下，TraceBench 的切口更窄：只在受控物理时间序列上考诊断归因，并且把镜头对准 agent 到底干了什么。考完的分数，落到了三件反直觉的事上。
三件反直觉的事：靠数字不靠画图、写脚本反而更差、示例标签没用
先看骨架。随机瞎猜的基线是 0.189。gpt-5.5 在低噪声、直接回答这一最理想条件下拿到 0.933 ± 0.056，是六列准确率里全组最强，claude-opus-4.6 次之。垫底的是 minimax-m2.7，六列平均比 gpt-5.5 低约 46 个百分点。TraceBench
| agent | 低噪·直答 | 低噪·脚本(held-out) | 高噪·直答 |
|---|---|---|---|
| gpt-5.5 | 0.933 ± 0.056 | 0.671 ± 0.096 | 0.833 ± 0.194 |
| claude-opus-4.6 | 0.853 ± 0.115 | 0.614 ± 0.084 | 0.593 ± 0.170 |
| gemini-3.1-pro | 0.760 ± 0.115 | 0.604 ± 0.128 | 0.560 ± 0.221 |
| minimax-m2.7 | 0.293 ± 0.134 | 0.287 ± 0.031 | 0.300 ± 0.165 |
46 个百分点这个数字本身值得警觉。据论文作者引用外部 leaderboard 的解读，同一对模型在 SWE-Bench Pro 上只差约 2 个百分点（gpt-5.5 为 58.6%，minimax-m2.7 为 56.22%）。同样的两个模型，换一个任务就差了二十多倍。这说明差距不是模型代差，而是任务形态的差异：TraceBench 考的是需要持续多轮工具辅助分析的归因，和"生成一段代码"不是一回事。另一个不意外的规律是噪声伤人：从低噪升到高噪，gpt-5.5 平均掉 11 个百分点，claude-opus-4.6 掉 17.7，gemini-3.1-pro 掉 19.3。
不过数字只是骨架，真正值得读的是三件反直觉的事，每一件都需要机制级的解读。
第一件，agent 靠数字不靠画图。从交互日志看，闭源 agent 每个 episode 平均往控制台输出超过 4600 个数值；gpt-5.5 的 console 输出 token 占比高达 77% 到 80%，而它是最爱看图的一个模型，即便如此，它直答时每集检查的图也不到一张，写脚本时是零张。gemini-3.1-pro 每集生成 1.7 到 5.1 张图，但一张都不看，minimax-m2.7 的工具链里干脆没有图像检查这一步。反常之处在于，我们默认"图比数字直观"，但这些 agent 把多变量序列摊成一张 DataFrame 做模式匹配，比如检查弹跳周期有没有变短、速度峰值有没有突变。日志能支持到这一步：gpt-5.5 的高准确率工作流几乎完全由数值打印主导，而不是可视化，数字序列对它们来说是可判定的特征。但"画图只是把同样的数字转成像素，图是高延迟的奢侈品"只能算候选解释，日志判不了：没有一组对照组告诉我们，如果强迫 agent 先画图再判断，成绩会不会变好。日志能证明它们做了什么，不能证明它们为什么不做另一件事。
第二件，写脚本反而更差。闭源三家在写脚本模式下的 episode 准确率普遍低于直接回答，更关键的是，脚本在 held-out 新样本上的准确率系统性低于它在考试集上的准确率。held-out 一列能确定的事实是：脚本没能把考试时答对的依据完好地带到新样本上，泛化出现了裂缝。裂缝为什么出现，日志和分数给不出唯一答案，只有候选解释。论文的读法是：直答时，agent 用得上"这条轨迹像换了弹性系数"这种样本特异的判断；写脚本等于要求医生把对每个病例的判断压缩成一套固定诊断规则，压缩的过程丢掉个例信息，于是脚本记住的是考试集里看得见的模式，而不是干预留下的稳定物理特征。另一种候选解释是：写代码这个动作本身更难，agent 把预算花在了调试程序而不是分析轨迹上。要分辨这两种机制，需要把提交的脚本拆开，看它是把考试集的具体特征写死，还是学到了可迁移的规则；这一步光凭分数和现有日志判不了。
第三件，去掉有标签的示例反而略升。消融实验显示，把领域上下文拿掉，准确率掉 20 到 32 个百分点，token 用量反而在四种情形里三种都上升，agent 在靠更多探索补偿缺失的上下文。但把有标签示例拿掉，多数条件下准确率反而升 4 到 11 个百分点，唯一的例外是 gpt-5.5 写脚本的 held-out 列，掉了 4.1。日志里能对上号的事实是：去掉标签后 token 用量也同步下降，输入确实变短了。至于准确率为什么反而升，目前只有候选解释：当系统描述、候选类名和控制台数字已经足够时，那三个一一对应的"样本-标签"对只是噪声叠噪声，反而把 agent 的判断往示例上锚定。但"去掉之后它更专注"这一点日志记不了，专注与否不是可观测量；分数也分不清改善是来自输入变短、示例误导被移除，还是别的什么。
| 消融（高噪声下） | gpt-5.5 直答(episode) | gpt-5.5 脚本(held-out) | gemini-3.1-pro 直答(episode) |
|---|---|---|---|
| 去掉领域上下文 | 0.513（−32.0） | 0.316（−23.2） | 0.313（−24.7） |
| 去掉标签示例 | 0.887（+5.3） | 0.506（−4.1） | 0.647（+8.7） |
括号内是与未消融主条件的差值，单位是百分点，负值代表掉分。
到这一步，算力这笔账也该算一算。论文把准确率分别对 token 用量、单集成本、时长和工具调用数画成四块面板：gpt-5.5 在每个面板都是最高分，而 claude-opus-4.6 每集要花 5.2 到 8.6 美元，gpt-5.5 只要 1.3 到 1.8 美元。TraceBench
图注：准确率与四类资源开销的对照：四块面板分别以 token 用量、评测成本、单集时长、工具调用数为横轴，纵轴都是准确率，每个 agent 配置一个数据点，误差棒为总体标准差。TraceBench
更多算力并不单调地转化为更高准确率。把三件反直觉的事合起来看，论文真正想说的不是它们注定如此，而是：这些结果提示，单一分数不足以解释能力。minimax-m2.7 的 0.29 是"任务太难"还是"模型不行"，光看数字回答不了。没有日志，"写脚本更差"会被误读成"任务太难"，"去掉标签更好"会被误读成"标签没用"；有了日志，每个反直觉结论才有机会被还原成可继续追问的行为细节。三件事各自的机制尚无定论，但"分数不够用"这一点，已经被它们共同提示得很清楚了。
它证明了什么、又测不到什么：受控评测的边界与价值
论文在 Limitations 里把边界交代得很老实。一是 closed-set 标签，标准答案是从固定候选类里选的，测不了开放式诊断；二是受成本约束重复次数太少，统计功效有限；三是每个模型配的脚手架不一样，Codex、Gemini CLI、Claude Code、OpenCode，所以模型差异和脚手架差异是搅在一起的。代表性子集也说明白了：规则采样、完全可观测、低维机械系统、至多一次瞬时参数干预。换句话说，这套考场的命题范围被物理模拟器的表达能力框死了：真实系统里那些没有平行宇宙对照的故障，它天然测不到。这套考场能证明的是，在已知干预的受控任务上，agent 展现出了归因表现，行为日志为它的策略提供了可检验的线索；它不能证明的，是 agent 拥有内在的因果表征，或是这套方法在真实工业系统里已经可用。
那它和真实环境基准是什么关系？互补，而不是替代。AIOpsLab 和 OpenRCA 回答"把 agent 扔进真实生产环境，它能不能把事情办成"，TraceBench 回答"在受控物理世界里，agent 能不能在已知干预的任务上展现出归因表现，行为日志又能否为它的策略提供可检验的线索，还是说它只是看着相关性猜"。真实环境侧的失败率提供"能不能"的证据，受控侧的机制日志提供"为什么"的证据，两边合起来才是完整的审计面。
把这条线索再拉远一点，四条评测路线其实各占一格：TemporalBench 与 TraceBench 都用受控合成制造标准答案，区别在考点，一个考预测和理解、一个考诊断归因；OpenRCA 与 AIOpsLab 都扎进真实系统，区别在形态，一个读离线遥测、一个跑云端到端。每个位置回答不同的问题，谁也不能替代谁，这才是评测生态该有的样子。
有意思的是，"让 agent 写代码再诊断"并不是 TraceBench 凭空发明的考法，工程界早就这么干了。RCAgent 是发表在 CIKM 2024 上的工具增强 RCA 系统，用 controller agent 调度代码分析、日志分析等工具完成云上根因定位，已经在阿里云 Apache Flink 实时计算平台落地。RCAgent
图注：OpenRCA 的 RCA-agent 工作流：User 与 Controller（含 Reasoning/Action）双向交互，Controller 指挥 Executor 里的 Python Kernel 执行代码，Telemetry（Metric/Trace/Log）单向喂给 Kernel。OpenRCA
这段工程脉络说明 S_prog 模式不是考场里的刁钻考法，而是真实 RCA 工作流的缩影，只是 TraceBench 把它关进了一间只有受控时间序列的屋子做归因考试。
想动手复现或者深挖，官方入口都在。项目页 tracebench.github.io 挂着 leaderboard，论文 Table 1 的数字在截至 2026-07-21 的公开快照里互相印证；数据集在 Hugging Face 的 eth-siplab/tracebench，代码在 GitHub 的 TommasoBendinelli/TraceBench，论文还以 arXiv 附属文件发布了一份 gpt-5.5 在 BallDrop 低噪直答模式下的代表性完整轨迹。TraceBench 项目页 想从行为层面复盘"它到底怎么答对的"，这份轨迹是最好的起点。
TraceBench 真正教给评测者的是这样一件事：分数只能告诉你 agent 答对了多少，行为日志才能为"它到底靠什么答对"提供可检验的线索。这套考场能证明的，是 agent 在已知干预的受控任务上展现出了归因表现；它不能证明的，是 agent 拥有内在的因果表征，或是它在真实工业系统里已经可用。"写脚本反而更差"之所以值得记住，不在于这个结论本身，而在于它是分数和能力之间那道裂缝的最直接证据。想深入可以读原文：TraceBench: Controlled Evaluation of LLM Agents for Time-Series Root-Cause Attribution，arXiv:2608.27182
参考文献
- TraceBench（锚论文）：Bendinelli, Dox, Holz. TraceBench: Controlled Evaluation of LLM Agents for Time-Series Root-Cause Attribution. arXiv:2608.27182. https://arxiv.org/abs/2608.27182
- TraceBench 项目官网：https://tracebench.github.io/
- AIOpsLab：Chen et al. AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds. MLSys 2025. https://arxiv.org/abs/2501.06706
- OpenRCA：Xu et al. OpenRCA: Can Large Language Models Locate the Root Cause of Software Failures?. ICLR 2025. https://openreview.net/forum?id=M4qNIzQYpd （代码：https://github.com/microsoft/OpenRCA）
- TemporalBench：Weng et al. TemporalBench: A Benchmark for Evaluating LLM-Based Agents on Contextual and Event-Informed Time Series Tasks. arXiv:2602.13272. https://arxiv.org/abs/2602.13272
- TimeSeriesGym：Cai et al. TimeSeriesGym: A Scalable Benchmark for (Time Series) Machine Learning Engineering Agents. arXiv:2505.13291. https://arxiv.org/abs/2505.13291
- RCAgent：Wang et al. RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models. CIKM 2024. https://arxiv.org/abs/2310.16340