长程任务中的智能体，往往不是因为某一次重大错误而失败，而是多个局部问题在持续交互中逐步累积。提示词、工具配置和控制逻辑组成的外部 harness 可以提升鲁棒性，但传统设计主要依赖人工搜索和调试，成本高，覆盖空间也很大。AutoSaddler提出了一条自动化路径：从智能体执行记录中的失败信号出发，持续改进任务执行框架。
把框架改进转成离线学习
AutoSaddler将 harness 优化表述为一个离线学习问题。系统不需要在每次任务执行时即时试错，而是从执行轨迹中收集失败信息，再以小批次方式迭代更新框架。这个思路的关键，不是单纯让模型重新思考答案，而是把失败记录转化为对框架本身的修改依据。
具体流程包括三个环节。首先，系统对失败轨迹进行诊断，定位导致任务中断或结果不佳的原因。其次，系统生成结构化补丁，并把 harness 当作代码来处理，使修改能够针对提示词、工具配置或控制逻辑等组成部分展开。最后，候选更新需要经过验证，再决定是否写回框架。这样做把“发现问题”和“采纳修改”分开，减少了未经检验的调整直接影响后续任务。
实验结果与关键条件
论文在 GAIA2、SWE-Bench Pro 和 Terminal-Bench 2.0 上进行了实验。相较于对应的基础 harness，AutoSaddler 的表现分别提升 9.0、9.6 和 10.0 个百分点。材料没有说明这些提升是否在所有任务类型或不同模型配置下都成立，因此更稳妥的理解是：在论文所报告的实验设置中，自动化框架优化显示出明确收益。
消融实验进一步指出，有效的 harness 优化依赖三个条件：深入调试，而不是停留在浅层反思；针对性修改，而不是不受约束地编辑；考虑泛化的更新选择，而不是只修复某一条具体轨迹。三者共同指向一个工程判断：好的修复不应只让已知失败样例通过，还要尽量避免对其他任务造成负面影响。
我的判断
AutoSaddler的价值，在于把智能体可靠性问题从一次性的提示词设计，推进到可持续迭代的系统工程流程。对于已经拥有执行日志、基础 harness 和验证任务集的团队，这种方法有较强的实践启发：失败轨迹可以成为框架维护的输入，而不是只用于事后分析。
但它的适用边界也很清楚。自动补丁的质量依赖失败诊断和验证机制，离线更新也不能消除评测集与真实任务之间的差异。论文材料只支持其在三个基准上的实验结论，尚不足以说明该方法对所有长程任务都同样有效。更合理的定位，是把它看作智能体框架优化的一种候选范式，而不是可靠性问题的通用解决方案。