先把这个判断撂这：RAG 排障这活，通用 agent 干不动了。于是工具方向开始往回退，从"让 agent 自己找 bug"退到"用专门小工具找 bug"。这种退回本身就是一个信号——不是 agent 不行，是账算不过来了。
RAG 这东西链路长。一个环节挂了不是当场炸，是往下游慢慢渗。最后答案看着挺对，中间某一步早就跑偏了，被下游吞掉了。这种故障拿什么查？人肉查，链路一多就抓瞎。拿 agent 查，Claude Code、Codex 这些全能选手上去，慢、贵、还不准。准到什么程度？有篇论文刚放出来，工具叫 RAGLog，配 Claude Haiku 5.5——最便宜那档——在真实带故障的 run 上把 F1 刷到 0.73。同一批跑例上，Claude Code 0.58，Codex 0.52。注入故障的数据上 RAGLog 0.84，那俩分别是 0.80 和 0.82。贵的大 agent 在这件事上，被几厘钱一次的小工具压着打。这笔账有意思。
为什么 agent 在这事上天然吃亏？因为定位故障要的是范围收敛，不是开放探索。你要的是逐阶段排查、比对规则、看日志偏差，说白了是一套审计逻辑。agent 擅长开放任务，给它一个模糊目标它能自己拆。但你把一个需要严格逐层比对、不能跳步的活交给它，它偏要发散。一发散成本就上去了——几十次推理调用起跳，结果还不一定收敛到你要的阶段粒度。那篇论文里的基线 agent 在阶段级标签上做不好，原因就在这：要么整体给个模糊判断，要么花一堆 token 反复折腾，最后定位还是错的。你以为你在省钱省事，其实你在为一个不适合这活儿的工具交认知税。
这笔账我半年前在另一个场景里见过。当时看测试生成的单子，大家一窝蜂上 agent 做端到端生成，后来发现小团队根本养不起那种 token 消耗，真正能落地的是拆成固定步骤加几个检查点。现在 RAG 排障这波，逻辑如出一辙：不是 agent 不行，是这个场景对 agent 来说太大材小用了——而大材小用的代价，是实打实的 token 账单。
RAGLog 干的事，说穿了不复杂。把不同 API 的日志统一成一个 schema，三层检查：规则先筛，规则盖不住的上 embedding 比对，再盖不住的上 LLM。这个架构本身没有多惊艳，省钱逻辑藏在调度顺序里——多数故障在前两层就已经被揪出来了，根本落不到 LLM 那一步。单次跑一遍只要 5 秒，成本 0.005 美元。你拿着这个数再去对标 agent baselines，几十倍上百倍的成本差就出来了。省的不是某个环节的优化，是把最贵的部分只在最后一公里才调用。这个调度思路，才是它真正能上账本的东西。
还有一点值得单说：RAGLog 不吃参考答案，也不需要改代码插桩。这俩条件在多阶段 pipeline 里其实特别要命——很多团队根本拿不出干净的参考答案来做逐阶段评估，改代码更是碰都不能碰，生产环境里你一插桩，行为就变了。RAGLog 用执行日志本身当原料，等于把排障变成了一件可以事后补做的事。跑完的日志还在，回头想查的时候再查，不用提前埋点。这在账本上值多少钱？值的是"不用为了排障改任何部署"这一项。很多 RAG pipeline 上线的时候压根没想过要排障，等真出事了让他重新插桩，成本大到不如重写。这时候一个只管读日志就能定位的工具，边际成本低到可以忽略不计。
那谁赚谁亏？最尴尬的是那种"通用 agent 排障"的中间产品。它们不会是最后死的那批，但会最先被挤到墙角——因为一旦用户反应过来"排障是专用审计逻辑，不是开放对话"，通用 agent 在这块的价值就会被裁掉大半。工具方赚的是清醒钱：大家都在往 agent 上砸钱的热闹里，回头做个小而省的专用工具，踩中的是真实痛点。用户这边，省下的不是那几毛美元，是排障的时间成本——5 秒一个 run 和 agent 跑几分钟，这中间的账大家都算得过来，但很多人没想过要算。为什么？因为排障这件事在开发流程里一直是隐形成本，没人单独列过账。
我一开始看这篇论文的时候也漏算了一项。它用的模型是 Haiku 5.5，最便宜那档，我第一反应是便宜模型会不会漏检。后来才看明白，漏检这事在规则和前两层里已经兜得差不多了，LLM 那步只是补充。这说明一件事：很多看起来"需要大模型"的任务，其实 90% 早就被传统方法干掉了，大模型只顶最后那 10%。你要是让 agent 从头到尾跑全程，等于把 90% 的便宜活也交给最贵的劳动力去干。这笔账，不细想几遍真看不出来。
那怎么办？维护 RAG pipeline 的话，最该干的不是急着上 RAGLog 这个具体工具，而是先把自己项目的排障逻辑捋一遍：哪些故障是规则就能覆盖的、哪些必须靠语义比对、哪些真需要 LLM 下场。先把这三层分清楚，再决定哪一层用什么工具。RAGLog 给你的是一个现成的三层架构参考，但别指望它开箱即用适配你所有的 pipeline——它的真实价值是提醒你排障应该分层计价，把贵的那部分留到最后。这个判断我目前不敢下死话，因为它自己的评测只覆盖了五个 pipeline，跨场景的泛化还没被充分检验。但方向上，它踩对了点。
排障这个活，拼的是收敛速度，不是开放能力。谁先把"哪一步该花多少成本"算清楚，谁就能在 RAG 这个红利窗口里多活一轮。这笔账，你自己算。