自由观察，自由推理：简单 LLM 测试框架胜过手工设计的根因分析智能体

1. 问题与价值

本文解决的是微服务故障根因分析（RCA）中一个被长期忽视的评测问题：手工设计的 LLM 智能体流程，到底有没有比“让一个能力足够的模型自己查”更好？

在此之前，大量已发表的 LLM RCA 智能体都在程序里写死了调查流程——标准操作程序（SOP）、固定阶段、角色子智能体、投票机制等。每个方法都在自己的数据上、和少数几个基线比较，所以没人知道这些手工设计是否真的有效，还是仅仅因为评测口径不统一而显得有效。

论文在 RCAtlas 上做了这个比较：8 个公开数据集筛出 90 个经验证的案例、23 个场景，六个模型 × 三档推理强度。结果是简单 harness 的 PR@1 到 65–77%（三个中档模型），已发表的 RCA 智能体 16–53%，非 LLM 方法 6–39%；而且在准确率超过最强非 LLM 方法（NSigma，PR@1 38.9%）的那些运行里，成本或时间上帕累托最优的每一次，用的都是简单 harness —— 这个门槛不能省：DecomRCA 其实是所有运行里最便宜最快的，只是准确率不够。

这个结果的价值在于：如果手工设计的流程并不比简单 harness 更好，那么整个“为 RCA 专门设计多智能体架构”的研究方向就需要重新审视其投入产出比。受益者是微服务运维团队和 RCA 研究者——前者可以直接用更简单、更便宜、更快的方案达到更高准确率，后者可以把精力从堆叠智能体架构转向模型能力、数据质量和评测基准的建设。

2. 已有工作的不足

在本文之前，最好的做法分为两类：

一类是已发表的 LLM RCA 智能体，例如 FoA（Flow-of-Action，SOP 驱动的多智能体）、RCAgent（带专家子智能体的自主智能体）、RCA-Agent（控制器-执行器分离的 OpenRCA 智能体）、DecompRCA（程序端检索加一次 LLM 重排）、mABC（角色智能体投票）。这些方法的共同问题是：程序决定了模型读什么、什么时候读、怎么推理。当程序选中的 SOP 不包含日志步骤时，模型永远看不到日志；当程序从告警出发沿调用链向下走时，一个“停止接收请求”的故障服务永远不会被检查到。要分清层次：这两条机制是本文读代码和做案例研究得出的结论（用来解释它们为什么只拿到 16–53%），不是立项前学界已有的共识；把它当背景写，等于把实验结果前置成了前提。

另一类是非 LLM 方法，包括统计方法（NSigma、BARO）、因果发现与推断（CIRCA、RCD、DyCause、FaultInsight）、依赖图传播（MicroRCA、MicroRank）、多源融合（TORAI）。这些方法的问题在于：它们只能利用数值型指标的统计偏差或依赖图结构，无法读取日志文本和事件中的决定性证据。例如 NSigma 和 BARO 只给“上升”的指标打高分，一个请求量骤降的故障服务反而排到倒数。

但上面两类说的都不是本文要补的缺口。非 LLM 方法只能吃数值与图结构、分数低到 6–39%，这是能力边界，不是「缺少统一评测」；已发表智能体分数低，是本文的发现，而不是它立项的理由。

真正的缺口只有一句：每个已发表智能体都在自己的数据上评测、基线选择随意，没有一个统一且经过有效性筛选的基准，把“手工设计流程”和“模型自由调查”放在同一批案例上正面比较。所以这两类工作在本文里更准确的角色是「被比较的两条路线」，而不是「两个各自有缺陷的对手」。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，我的思考路径大概是这样的：

第一步：先怀疑“手工设计”本身。 已发表的 RCA 智能体都在程序里写死了调查步骤。我会想：这些步骤是不是真的在帮模型，还是在限制模型？一个直接的检验方法是，拿一个什么都不规定的 harness——比如把数据打包一次扔给模型——和这些智能体在同样的案例上比。如果简单 harness 赢了，那说明手工设计的边际贡献是负的。

但这里会撞上第一个矛盾：一次性把全部数据扔给模型，上下文窗口可能装不下。微服务案例的遥测数据动辄几十万行，指标、追踪、日志、事件四类数据加起来可能超过模型上下文限制。所以“一次调用”这个最简方案本身就有技术障碍。

怎么改：做一个证据包（evidence package），用规则筛选出“有变化的指标序列、日志模板、事件”，把数据量压到模型能接受的范围。但这就引入了一个新的问题——规则筛选本身也是一种手工设计。如果证据包的筛选规则漏掉了决定性证据，那 one-shot 也会失败。这个矛盾在论文里确实存在：one-shot 的 PR@1 低于 SQL agent 和 Codex，说明规则筛选确实有代价。

第二步：如果一次调用不够，就让模型自己查。 证据包方案的问题在于“程序决定模型读什么”。那能不能让模型自己决定读什么？两个现成的方案：一个是 SQL agent，给模型一个 DuckDB 数据库和几个工具（列文件、读 schema、跑 SQL、提交答案），让模型自己写查询；另一个是 Codex CLI，给模型一个文件夹和任务说明，让它自己写 Python 和 shell 命令分析数据。这两个方案里，模型既决定读什么，也决定怎么算。

这里会撞上第二个矛盾：SQL agent 和 Codex 的调用次数远多于 one-shot（SQL agent 平均 26.8 次调用，Codex 平均 8.5 次），成本和时间都更高。如果准确率提升很小，那多轮调查就不划算。所以必须做成本-时间-准确率的 Pareto 分析，看看多轮调查的增量到底值不值。

第三步：如果简单 harness 赢了，那为什么已发表智能体输了？ 我会去看轨迹。一个自然的假设是：手工设计的流程在“程序决定读什么”这一步就错了。比如 FoA 的 SOP 匹配机制，如果匹配到一个不读日志的通用 SOP，模型就永远看不到日志里的“Connection refused”这种决定性证据。mABC 从告警出发沿调用链向下走，一个停止接收请求的服务永远不会被检查。这个假设可以量化：统计每个方法里“程序固定发出的模型调用”占全部调用的比例（prescribed-call ratio），看它和准确率的关系。

但这里会撞上第三个矛盾：光看调用比例可能解释不了全部差异。RCA-Agent 的 prescribed-call ratio 是 0.29，比 FoA 的 0.51 低，但准确率反而更差。所以“程序规定了多少调用”不是唯一因素，程序规定的调用在调查的哪个阶段、是否切断了模型获取关键证据的路径，可能更重要。论文里的案例研究（rca100-main-0104）就是在补这个解释。

第四步：模型能力和推理预算的贡献要分开。 简单 harness 的准确率随模型变强而上升，但推理预算（reasoning effort）的作用不清楚。我会设计一个对比：同一个模型，把推理预算从 medium 拉到 xhigh 或 max，看准确率变化多少；再和“换一个更强的模型”对比。如果换模型带来的提升远大于加预算，那说明方向感比探索量更重要。

与论文实际路径的差异：我猜的路径是先怀疑手工设计、再逐步放开模型自由度，这和论文的实际结构基本一致。但论文比我多走了一步：它把“aptitude”和“unreliability”分开度量（用三次重复运行的最好和最差 pass），这是我在重建路径时没有提前想到的。这个区分很重要，因为它揭示了“多轮调查的收益主要在 aptitude（至少一次能解出来），而强模型的收益主要在 reliability（每次都能解出来）”。另外，论文把非 LLM 方法也纳入同一基准，这是我一开始没放在优先位置的——我可能会先只比较 LLM 方法，但论文的对比让“简单 harness 超过非 LLM 方法”这个结论更有冲击力。

4. 核心 intuition

用一个日常类比：一个有经验的医生，你给他完整的病历、检查报告和化验单，让他自己决定看什么、做什么检查，通常比一个被医院 SOP 流程卡死的实习医生更准。

这个类比对应的机制是：RCA 的关键证据往往不在预设的检查路径上。案例 rca100-main-0104 里，故障根因是 inventory 服务停止接收请求，它自己的错误率没有上升，请求量反而骤降。任何“从告警出发沿调用链向下走”的流程（mABC）都会在 cart 停下来，因为 cart 是唯一还在接收请求并报错的服务；任何“只看得分最高的异常指标”的方法（NSigma、BARO）都会把 inventory 的请求量骤降排到倒数，因为这些方法只给上升的指标打高分。只有让模型自由地看到 cart 的日志里“Connection refused (inventory:9090)”从 43 条涨到 609 条，再自己去查 inventory 的请求量变化，才能找到根因。

自由地看意味着模型可以跨数据源（指标、追踪、日志、事件）交叉验证；自由地推理意味着模型可以自己决定“先看症状、再追谁不能连谁”，而不是被 SOP 的固定步骤绑死。手工设计的流程之所以输，不是领域知识没用，而是把领域知识固化成控制流之后，一旦案例不匹配预设流程，模型就被剥夺了看到决定性证据的机会。

5. 方法 pipeline 举例

以论文案例研究中的 rca100-main-0104 为例，走一遍三种简单 harness 的完整流程。

案例背景：RCA-100 数据集里的一个案例。inventory 服务的 Service 选择器选不到任何 pod，所以 cart 调用 inventory 时连接被拒绝。根因是 inventory（服务级别）。故障期间 inventory 的请求量从约 1,450 次/分钟骤降到 109 次/30 秒，然后归零；cart 的错误率从 1.7% 升到 32.5%；cart 的日志里“Connection refused (inventory:9090)”从故障前 43 条涨到故障期间 609 条。

One-shot 流程：

1. 程序按规则筛选证据，生成证据包。证据包包含 136 个条目，约 75k tokens。其中条目 E27.2 是 cart pod 的日志模板，显示“inventory call failed: Connection refused (inventory:9090)”从 43 条涨到 609 条。
2. 模型一次调用收到整个证据包，输出答案：“cart requests to inventory:9090 were refused; cart then returned an Internal error, which surfaced as frontend cart errors.” 排名第一的候选是 inventory。
3. 评分：inventory 是根因，PR@1 命中。

SQL agent 流程（Luna，pass 1）：

1. 步骤 1-7：模型列出六个表的 schema。
2. 步骤 12：模型写 SQL 查询失败的 span，按服务和操作分组，发现 frontend AddItem 有 637 次失败，cart GetInventory 有 562 次失败。
3. 步骤 14：模型查日志，用 LIKE '%fail%' 匹配，发现 cart 的“Connection refused (inventory:9090)”有 1,291 条。
4. 步骤 17：模型写了一个有语法错误的 SQL，自己修正后在步骤 18 重写。
5. 步骤 18-30：模型按 30 秒时间桶分组查 inventory 的 span，确认请求量从 1,450/分钟降到 109/30 秒再到 0；检查 inventory 的 pod 日志和拓扑位置。
6. 步骤 31：提交答案，第一名是 deploy:inventory。
7. 总计 31 次查询、22 次模型调用、107 秒。

Codex 流程（Luna，pass 1）：

1. 命令 1-2：列出并加载所有文件。
2. 命令 3：模型自己写 Python 代码，对每个实体和指标计算故障前后中位数差的绝对值，同时检查事件、按服务分组的 span 和错误日志。输出显示 cart 的 error_rate 从 0.017 升到 0.325，排名第一，且日志里已有“Connection refused (inventory:9090) 01:59:23”。
3. 命令 4-6：并排查看 inventory、cart、frontend 的指标和日志。
4. 命令 7：放大到 01:58:30–02:00:30 的时间窗口，发现 inventory 服务到 01:59:22 还在正常服务，cart 从 01:59:23 开始被拒绝。
5. 写报告，第一名是 deploy:inventory。
6. 总计 7 条命令、8 次模型调用、57 秒。

对比：FoA 在同一案例上的失败路径：

1. FoA 自己把故障描述填成“microservice incident”，匹配到通用 SOP“Microservice Issue”，匹配分数 0.915。
2. 这个 SOP 的固定步骤是：异常指标（81/448 个）→ 入口请求 → 这些服务的追踪。没有日志步骤。
3. 四个会读日志的 SOP（Memory、Network Loss、Code/Config、DB/Cache）都没被匹配到。
4. judge 在第一轮就宣布根因是 cart，报告 cart 为根因。
5. 评分：cart 不是根因，PR@1 未命中。

6. 核心数学推导

论文的核心公式有三个：PR@1、RR、prescribed-call ratio。这里推导 prescribed-call ratio（公式 3），因为它最直接支撑“手工设计流程限制模型自由”这一核心论点。

符号解释：

• M：模型集合，本文中是三个中端模型 Luna、Flash、Haiku。
• ∣M∣：模型集合的大小，等于 3。
• C_m：模型 m 有运行轨迹的案例集合。
• ∣C_m∣：模型 m 有轨迹的案例数量。
• c_i：案例 i 的模型调用总数。
• f_i：案例 i 中被程序固定发出的调用数（prescribed calls）。
• ρ：prescribed-call ratio，即程序固定调用占全部调用的比例。

推导步骤：

第一步，对单个模型 m，先算每个案例的 prescribed 比例 f_i / c_i。这个比例在 0 到 1 之间。0 表示该案例的所有模型调用都是模型自己决定发出的；1 表示所有调用都是程序固定发出的。

第二步，对模型 m 的所有案例取平均，得到该模型的平均 prescribed 比例：

(1 / ∣C_m∣) · Σ_{i∈C_m} (f_i / c_i)

这里用 Σ_{i∈C_m} 表示对集合 C_m 中的所有案例求和。

第三步，对三个模型再取平均，得到最终的 prescribed-call ratio：

ρ = (1 / ∣M∣) · Σ_{m∈M} [ (1 / ∣C_m∣) · Σ_{i∈C_m} (f_i / c_i) ]

这个公式在算什么：它在量化“一个方法的调查过程中，有多大比例的模型调用是程序在固定位置发出的，而不是模型自己选择发出的”。ρ 越高，说明程序对调查的控制越强，模型的自由度越低。

代入实际数值（以 FoA 为例）：FoA 的 ρ = 0.51，per-case range 是 0.46–0.55。这意味着 FoA 平均每 100 次模型调用里有 51 次是程序固定发出的，且这个比例在不同案例间波动很小（0.46 到 0.55）。对比之下，Codex 的 ρ 是 0.00（逐案例也是 0.00–0.00），SQL agent 平均同样是 0.00 但逐案例可到 0.08（它有一个固定阶段的调用，个别案例会触发），one-shot 只有一次调用、无固定阶段。所以严格说：简单 harness 的固定调用接近但不必然为零。DecompRCA 的 ρ = 1.00，因为它只有一次模型调用，而这次调用是程序在筛选完 15 个候选之后才发出的重排调用。

一句话总结：这个公式把“手工设计流程限制模型自由”从定性描述变成了定量度量，揭示出简单 harness 和已发表智能体之间的清晰分界——前者 ρ = 0，后者 ρ ≥ 0.10。

7. 实验设计

数据集：RCAtlas-Core，90 个经过有效性筛选的案例，来自 8 个公开 RCA 数据集的 10 个套件（RCAEval RE1–3 分开算），覆盖 23 个场景、10 个故障类别。根因级别分布：59 个服务、20 个 pod、11 个节点。数据规模从 37k 到 5.6M 遥测行。随机猜测命中率中位数 3.45%，对应有效候选数中位数 29。

基线：三层对比。第一层是三个简单 harness（one-shot、SQL agent、Codex）；第二层是五个已发表 LLM 智能体（FoA、RCAgent、RCA-Agent、DecompRCA、mABC）；第三层是七个非 LLM 方法（NSigma、BARO、CIRCA、RCD、TORAI、FaultInsight、SimpleRCA），外加随机排序作为地板。

模型：六个模型。Setting 1 在三个中端模型上跑所有 LLM 方法：GPT-6 Luna、DeepSeek V4.1 Flash、Claude Haiku 5.5。Setting 2 在六个模型上跑简单 harness，增加 GPT-6.1 Sol、GPT-6 Astra（xhigh）、MiMo-V2.6-Pro。Setting 3 把 Luna 和 Sol 的推理预算提高到 xhigh 和 max。

指标：PR@1（第一名命中根因的案例比例）和 RR（倒数排名，前 t_i 个位置都得满分，t_i 是根因数量）。不报告 PR@k（k>1），因为不同方法返回的答案数量不同。另外定义了 aptitude（A，三次运行中至少一次命中的案例比例）和 unreliability（U，三次运行中有时命中有时不命中的案例比例）。

消融：论文没有做传统意义上的消融实验（比如从某个智能体里移除某个组件）。最接近消融的是：第一，prescribed-call ratio 分析（第 6.3 节），量化每个方法的程序控制程度；第二，模型能力和推理预算的对比（第 6.4 节），分别改变模型和 effort 看准确率变化；第三，aptitude 和 unreliability 的分解（第 6.5 节），把准确率拆成“至少一次能解”和“每次都能解”两部分。

实验能否支撑结论：能支撑主要结论。90 个案例、6 个模型、3 个推理预算、3 次重复运行，加上统一的评分规则和有效性筛选，足以支撑“简单 harness 在同样案例上超过已发表智能体和非 LLM 方法”这一核心主张。显著性检验（配对 bootstrap，10,000 次重采样，95% 置信区间）也支持主要差距。

缺什么：论文自己在 Limitations 里承认，Codex 是唯一测试的通用编码 harness，其他如 Claude Code 可能不同；所有模型都是 2026 年的，无法判断结论是否适用于更弱的模型；预算限制导致没有测试当前最强的模型。另外，prescribed-call ratio 只能度量“程序固定了多少调用”，不能直接证明“程序固定调用导致了准确率下降”——论文也承认需要一个消融实验来直接检验这个因果关系。

8. take-aways

1. 简单 harness 全面超过已发表智能体：在三个中端模型上平均，简单 harness 的 PR@1 是 65–77%，已发表智能体是 16–53%，非 LLM 方法是 6–39%。Codex 的 77.2% 比最好的已发表智能体 FoA 的 53.3% 高出 23.9 个百分点。

1. 程序固定调用是已发表智能体的共同特征，但比例与准确率不是单调关系：所有已发表智能体的 prescribed-call ratio 至少是 0.10（mABC），最高到 1.00（DecompRCA），而三个简单 harness 都接近 0.00。两者的关系是「整体上比例越高越差」，不是打分排序——RCA-Agent 的 0.29 低于 FoA 的 0.51，准确率却也更低，说明固定调用比例只是描述性指标，不能当准确率的预测器。

1. 换强模型比加推理预算更划算：从 Luna 换到 Sol，Codex 的 PR@1 从 68.9% 升到 87.0%，提升 18.1 个百分点；而把 Luna 的推理预算从 medium 拉到 max，Codex 的 PR@1 只从 68.9% 升到 72% 左右（第一轮），提升约 3 个百分点，时间却乘以 1.5 到 4 倍。

1. 强模型买可靠性，多轮调查买 aptitude：从 Luna 换到 Sol，unreliability 从 32–36 降到 7–8；在 Luna 上，SQL agent 和 Codex 的 aptitude 比 one-shot 高 10–11 个百分点（86 和 84 对 74），但 unreliability 相似（30–36）。

1. 成本-时间 Pareto 前沿上全是简单 harness：在所有准确率超过最佳非 LLM 方法（NSigma，PR@1 38.9%）的运行中，每一个在成本或时间上 Pareto 最优的运行都用简单 harness。最便宜的选择是 Luna + Codex，每个案例不到 1 美分，PR@1 68.9%；最快的选择是 Sol + SQL agent，45 秒每个案例，PR@1 85.6%。

9. 最脆弱的假设

最脆弱的假设是：“程序固定调用”和“准确率下降”之间的因果关系成立，而不仅仅是相关性。

论文的证据链是：简单 harness 的 prescribed-call ratio 为 0，准确率最高；已发表智能体的 prescribed-call ratio 从 0.10 到 1.00，准确率更低；案例研究显示 FoA 的 SOP 匹配机制跳过了日志步骤，mABC 的调用链遍历跳过了停止接收请求的服务。这些证据支持“程序固定调用导致准确率下降”的解释。

但这个假设有一个明显的替代解释：已发表智能体之所以输，不是因为它们固定了调用，而是因为它们固定调用的方式恰好是错的。如果有一个智能体把“读日志”这一步固定进 SOP，并且 SOP 匹配机制足够好，它可能不会输。论文在 Limitations 里也承认：“prescribed-call ratio 度量的是调查有多少被固定，而不是这种固定导致了更低的准确率；一个消融实验——把某个智能体的固定流程解除——才能直接检验这一点。”

论文没有给出这个消融实验。所以如果有一个已发表智能体在解除其固定流程后准确率没有提升，或者有一个简单 harness 在加入固定流程后准确率没有下降，那么“自由调查优于手工设计”这一核心主张就会被削弱。论文的结论实际上更准确地表述应该是：“当前这批已发表智能体的手工设计方式不如自由调查”，而不是“任何手工设计都不如自由调查”。

10. 一周最小复现

目标：复现“简单 harness 超过已发表智能体”这一核心结论的最小版本。

资源约束：1 张 24GB 消费级显卡，1 周时间。24GB 显存可以本地运行 7B–14B 级别的开源模型（如 Qwen 系列），但论文里的模型都是 API 模型。所以复现策略是：用 API 调用一个中端模型（如 DeepSeek V4.1 Flash 或类似价位模型），本地显卡只用于数据处理和评分。

具体步骤：

1. 第 1 天：下载 RCAtlas 的案例列表和代码（论文提供了 cases/core90_cases.csv 和 cases/core90_labels.json），从公开源重建 10–15 个案例。优先选 RCA-100 和 OpenRCA 2.0 的案例，因为它们的日志和追踪数据比较完整，且论文的案例研究来自 RCA-100。
2. 第 2 天：实现 one-shot harness。按论文附录 C.2 的规则写证据包生成器：筛选有变化的指标序列（用故障前中位数和 MAD×1.4826 计算变化分数，阈值 4 个 spread）、日志模板（30 个变化最大的实体，每个最多 8 个模板和 12 条原始行）、事件分组。把证据包发给 API 模型，解析前 5 个候选。
3. 第 3 天：实现 SQL agent。用 DuckDB 加载案例的指标、追踪、日志、事件表，给模型 4 个工具（列文件、读 schema、跑 SQL、提交答案），用 ReAct 循环，最多 100 次调用。
4. 第 4 天：实现一个已发表智能体的简化版。建议选 FoA，因为它的 SOP 机制最容易复现：写 3–4 个 SOP（一个通用 SOP 不读日志，一个网络故障 SOP 读日志），让模型自己匹配 SOP 并执行固定步骤。
5. 第 5 天：在 10–15 个案例上跑 one-shot、SQL agent、简化 FoA，每个方法跑 2 次。记录 PR@1 和每个案例的耗时、调用次数、成本。
6. 第 6 天：分析轨迹，统计每个方法的 prescribed-call ratio（FoA 的固定调用数除以总调用数），看是否出现论文里的模式：简单 harness 的 ρ = 0 且准确率更高，FoA 的 ρ > 0 且准确率更低。
7. 第 7 天：写报告，对比你的 PR@1 和论文在相同案例子集上的 PR@1。

预期指标：在 10–15 个案例上，one-shot 和 SQL agent 的 PR@1 应该明显高于简化 FoA。论文在 90 个案例上 one-shot 平均 65.3%、SQL agent 72.8%、FoA 53.3%。小样本上波动会更大，但趋势应该一致。如果 FoA 在你的子集上超过简单 harness，检查 SOP 匹配是否过于简单（比如总是匹配到读日志的 SOP），或者案例选择是否偏向 FoA 擅长的故障类型。

关键简化：不需要复现 Codex（CLI 配置复杂），不需要跑非 LLM 方法，不需要 6 个模型，不需要 3 次重复。核心是证明“自由调查的简单 harness 在一个统一基准上超过一个手工设计流程的智能体”。

11. 反例设计

目标：设计一个实验，如果成功就能推翻“自由调查优于手工设计流程”这一核心主张。

实验设计：构造一个 RCA 案例集，其中决定性证据只能通过一个特定的、非显而易见的查询路径获得，而这条路径恰好是一个手工设计的 SOP 会固定执行的。

具体做法：选 20 个案例，每个案例的根因证据藏在日志的某个特定字段里，这个字段只有在执行一个特定的 SQL 查询（比如按 trace_id 关联日志和 span，再按 parent_span_id 向上追溯三层）才能看到。自由调查的 SQL agent 和 Codex 可能会因为搜索空间太大而错过这个查询，而一个手工设计的 SOP 如果恰好包含“按 trace_id 关联日志和 span 并向上追溯”这一步，就能稳定命中。

判据：如果在这个案例集上，手工设计 SOP 的智能体（比如 FoA 加上一个专门针对这类故障的 SOP）的 PR@1 显著超过 SQL agent 和 Codex（比如高出 15 个百分点以上），那么论文的核心主张就被推翻——因为这说明当调查路径足够隐蔽时，程序固定的领域知识可以引导模型走向自由调查发现不了的证据。

为什么这个反例有效：论文的核心论点是“程序固定调用会跳过决定性证据”。这个反例直接攻击这个论点的反面：如果程序固定调用恰好指向决定性证据，而自由调查因为搜索空间太大而错过，那么“自由优于固定”就不再成立。论文的案例研究里，FoA 输是因为它的 SOP 匹配机制选错了 SOP（通用 SOP 不读日志）；如果 SOP 匹配机制足够好，或者案例的故障类型足够单一以至于 SOP 总能选对，手工设计就可能赢。

论文是否已经排除了这个反例：没有完全排除。论文在 Limitations 里承认“一个消融实验——把某个智能体的固定流程解除——才能直接检验因果关系”。论文的 90 个案例来自 8 个数据集的 23 个场景，故障类型多样，这可能是手工设计流程表现差的原因之一。如果在一个故障类型高度单一的生产环境里（比如某个服务总是因为数据库连接池耗尽而故障），一个专门针对这个故障类型的 SOP 可能会稳定超过自由调查。

12. 落地判断

能否用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”：能，但需要调整预期和架构。

怎么用：论文的直接结论是“简单 harness 比手工设计的多智能体流程更好”。对于自托管 27B 模型（比如 Qwen 27B 或类似规模），最合理的落地方式是：

1. 用 SQL agent 模式，而不是多智能体脚手架。27B 模型的能力不足以支撑复杂的多角色协作，但足以在 ReAct 循环里写 SQL 查询。给模型一个 DuckDB 数据库，里面是案例的指标、追踪、日志、事件表，加上 4 个工具（列文件、读 schema、跑 SQL、提交答案），让它自己查。
2. 证据包作为降级方案。如果 27B 模型的 SQL 生成能力不够稳定（在 DuckDB 上频繁出语法错误），退回到 one-shot 模式：用规则筛选出有变化的指标、日志模板、事件，打包成证据包一次发给模型。论文里 one-shot 的 PR@1 是 65.3%，比 SQL agent 的 72.8% 低 7.5 个百分点，但实现简单得多。
3. 不要用多智能体脚手架。论文的核心发现是手工设计的流程会限制模型获取证据的自由。27B 模型的能力本来就有限，再叠加一个固定流程的脚手架只会进一步限制它。

成本量级：自托管 27B 模型的推理成本主要是 GPU 时间。一张 24GB 消费级显卡（如 RTX 4090）跑 27B 模型的 4-bit 量化版本，推理速度大约 20–40 tokens/秒。一个案例的 prompt token 用量按论文 Table 8：one-shot 在 Luna 上是 235,644，而 agent 类合计从 90k（Sol 配 SQL agent）到 200 万以上（Flash 与 MiMo）。取 235,644 这个量级估算，在本地 27B 上大约需要 3–6 小时。如果案例量不大（比如每天 10–20 个），这是可行的。如果案例量大，需要用更小的模型（7B–14B）或者批处理。

最大的坑：27B 模型的 SQL 生成能力和推理能力都远弱于论文里的 API 模型（GPT-6 Luna 的 AA index 是 29.9，27B 开源模型通常更低）。论文里 SQL agent 在 Luna 上的 PR@1 是 68.5%，在更弱的模型上可能会大幅下降。具体来说，27B 模型可能会在以下地方失败：第一，写不出正确的 DuckDB SQL（语法错误、错误的 JOIN 条件）；第二，在 100 次调用限制内找不到根因（论文里 Luna 的 SQL agent 平均 19.7 次调用，但更弱的模型可能需要更多次）；第三，无法从日志文本中提取“Connection refused (inventory:9090)”这类关键信息。建议先用 10–20 个案例做一个小规模验证，如果 27B 模型的 PR@1 低于 40%，就考虑换更大的模型或者退回到 one-shot 模式。