Agent 轨迹留存：优先保住新故障

Agent 运行记录越存越多，真正需要排查的新故障却可能先被轮转清掉。dev.to 的这篇文章提出：写入时就把轨迹分成完整保留、摘要和丢弃三层，优先留下首次出现的故障指纹，再用字节预算限制完整记录的占用。它讨论的是如何把存储留给更有调试价值的运行。

目前能确认什么

轨迹中的 span 通常记录一次操作，例如工具调用。大量重复操作会挤占存储，而不同运行的排障价值并不相同。

作者用错误类别、span 数量，以及按调用顺序排列的工具名称、状态和退出码生成指纹。run id 标识一次运行，指纹则尝试归并同一类问题。重复失败压成摘要，重复成功直接丢弃。

代码里的「首次保留」有例外，也不只覆盖失败。

RateLimit、Timeout、UpstreamUnavailable 被排除在首次完整保留之外；首次出现的成功轨迹也可能进入完整层。因此，摘要里的规则不能直接当作代码的精确行为。

所有运行还会先进入一个按数量限制的临时缓冲区。摘要对应的原始记录尚在时，才有机会将其提升为完整保留。完整层另设字节预算，两者控制的是不同范围。

我的判断

对正在做 Agent 可观测性的程序员，这套方案最有价值的是把采样目标从「保留多少次运行」改成「覆盖多少类问题」。

但指纹质量决定了它能否保住关键证据。节选明确忽略工具参数，参数不同引发的故障可能被归为一类；反过来，span 数量稍有变化，又可能把同一问题拆成多个指纹。上线前应拿已知故障检查这两种误判。

存储预算也不能只看完整层。节选没有展示摘要清理策略，临时区按条数限制也不等于按字节限制；单条完整轨迹超过预算时，展示的代码仍会写入。原文提到的四项检查尚未完整提供，当前材料足以借鉴分层思路，还不足以确认它具备严格的容量保障。