9 月 23 日，一篇题为 Learning from Failures 的论文（arXiv 2609.28003）提出 FRESH，瞄准一个很接地气的问题：中小模型便宜、适合本地与大规模部署，却常常在长程、有状态的环境里犯结构性错误——漏掉必填观测、过早写入、重复调用已经失败的动作、违反动作前置条件。这些错会直接带偏状态、触发策略违规，甚至造成不可逆的后果，因此「让小模型可靠地用工具」成了落地门槛。
作者点出的旧办法有两个软肋。其一，微调需要大量数据与算力，对小模型并不友好；其二，平面记忆（flat memory）会把失败动作直接召回，却丢掉了它发生的因果上下文与前置条件——你记下了「这个动作失败过」，却没记下「在什么状态下、因为什么、后来怎么修好的」。于是模型下次仍可能踩同一个坑。
把经验建成「异构图」，而不是一条条记录
FRESH 的做法是把历史成功与失败，转成结构化的外部经验，存进一张异构图（heterogeneous graph）。图里显式建模任务、动作、错误、修复与执行条件之间的依赖：哪个动作在哪种状态下失败、失败后靠什么修复、修复又依赖哪些前提。这样，一个被冻结的模型在面临新状态时，能顺着图检索到「可靠的做法」与「要避免的复发失败」，从而做出更安全的工具调用决策。
在 τ-Bench 与 AppWorld 两个基准、配合多个开源模型的实验里，FRESH 相对「无记忆」与代表性记忆基线，稳定提升了任务成功率与工具使用可靠性。它的价值不在于把模型变大，而在于给小模型配了一套「失败档案」：模型不用重训，也能从过去踩过的坑里长记性。对预算敏感、又想上 agent 的团队，这比一味堆大模型更有性价比。
它和「记忆蒸馏」是两条路，别混为一谈
同期的 LEGOMem 等方向走的是「把成功轨迹蒸馏成可复用记忆单元」，FRESH 则把镜头对准失败与因果。两者并不冲突，反倒互补：一个负责让模型「学会怎么做对」，一个负责让模型「别再犯同样的错」。对工程而言，真正有用的记忆系统，恐怕要同时装下这两类经验——成功的可复用路径，与失败的因果边界。当然，FRESH 的成效仍依赖被记录轨迹的质量，面对没见过的新型错误，图的泛化能力还有待更多场景检验。
一个能落地的画面是：客服或运维智能体每次工具调用出错，系统自动把「状态—动作—报错—修复」写进图；下次在相似状态下，模型先查图再动手，把排障从人盯着日志变成模型自助。它不要求改模型权重，冻结模型即可，和那些要重训的方案相比，迭代成本更低、回滚更干净。代价是图的维护与版本管理，以及业务规则变更时及时清理过期边——这部分仍要人兜着。对预算敏感又想上 agent 的团队，这比一味堆大模型更务实：不强求更强模型，只让便宜模型少犯已知错。
还有一点值得强调：FRESH 的长处是「记已知错」，而不是「凭空纠错」。它把模型从反复踩同一个坑里拽出来，却不会让小模型突然具备它本不具备的推理能力。因此在生产里它更适合做「防呆层」——在调用工具前先过一遍失败档案，把明显会踩雷的动作拦在门外；真正的难题攻坚，仍然要靠更大的模型或更精细的 harness。把两者分工清楚，比指望一个组件包打天下更现实。
落到实践，FRESH 给小模型 agent 的启发很直接：与其在每次出错后手动微调，不如先把「错误—修复—条件」的因果链沉淀成可检索的结构化记忆，让模型在推理时自助避开已知坑。这把「从失败中学习」从一句口号，变成了可工程化的组件。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。