如果你在做 agent，尤其是会跑很长、还要多个 agent 互相调用的那种，这条值得看一眼。它解决的是一个越来越扎手的运维问题：agent 干了一大堆步骤之后出错了，到底是哪一步、哪个 agent 把事情搞砸的？这个问题学术上叫「故障归因」（fault attribution），落到工程上就是 agent 系统的根因排查。 痛点在于轨迹太长。一个复杂任务的完整执行轨迹（每一步的思考、工具调用、返回结果、agent 间的消息）很容易膨胀到几十万甚至上百万 token，超出任何模型的上下文窗口。现有的诊断方法是把整条轨迹塞进一个 LLM 的上下文里，让它通读后指出哪步出错。问题有两个：一是「注意力稀释」——内容越长，模型越难在海量上下文里精准盯住那个真正出问题的片段；二是只要轨迹超过上下文上限，这套方法就直接没法用了。而长程 agent 的轨迹超限几乎是必然。 SAFARI（Scaling long-horizon Agentic Fault AttRibution via active Investigation）的做法是把「被动读全文」换成「主动调查」。它不再一次性把轨迹灌进上下文，而是给 LLM 配一套专门的工具箱，让模型能像查资料一样去读取、检索轨迹的局部片段——需要看哪段就调工具去拿哪段，而不是被迫先把所有东西都装进脑子。配合工具箱的是一块持久的短期记忆（Short-Term Memory，STM），用来在多轮调查之间保留中间结论、做跨轮推理。两者合起来，效果是把「诊断能力」和「模型架构的上下文上限」解耦：轨迹再长，模型也只在每一步按需取用相关片段，不再受窗口大小硬约束。 这套思路本质上是把 RAG / agentic 检索的范式搬到了「读自己的执行日志」这件事上——与其扩上下文，不如让模型学会主动去翻日志。 结果方面，论文给了三个锚点：在 1M token 预算下，于 Who&When 数据集上超过当前 SOTA 20%；在 25K token 预算下，于 TRAIL GAIA 子集上超过 19%（这两个都是 agent 故障归因方向常用的评测集）。最有说服力的是极端长程场景：当目标故障点位于模型原生上下文窗口 5 倍之外时，SAFARI 仍能保持 0.58 的 precision，而论文指出传统的整轨迹评估器在这种情形下基本完全失效。换句话说，它真正的价值不在「常规长度上多几个点」，而在「超长轨迹下还能不能用」这条线上把可用区间往外推了一大截。 对谁有用：做 agent 平台、多 agent 编排、或者要给 agent 系统搭可观测性 / 自动 debug 的团队，这是一个可以参考的工程范式——故障归因不必靠堆上下文长度，而可以靠给诊断模型配检索工具加记忆。它也呼应了一个更普遍的判断：处理超长信息，未来更可能是「让模型主动检索」而非「无限扩窗口」。 诚实的保留：原文（及摘要、arXiv 页面）只给出了上述三个数字，没有公布更细的逐数据集对比表、消融结果或 baseline 具体取值，0.58 precision 对应的召回 / 整体表现原文未给出，也无法据此判断它在「常规长度」下相对成本的开销。论文目前是 ICML 2026 的 AIWILD（Agents in the Wild）workshop 论文，属于工作坊一级而非主会正刊，方法的稳健性与可复现性仍待第三方验证。