生产 Agent 为何陷入脚本修复循环
文章称对 23 个模型开展了 736 次测试，分析 Agent 临时编写脚本处理生产数据时的失败模式。摘录重点包括 MIME 与字节解析错误、报错堆积污染上下文，以及重复运行结果不稳定。
原文暂未完整获取，基于公开信息的快读
一篇 dev.to 文章把生产 Agent 的失败问题指向了执行方式：让模型临时写脚本，报错后再把错误塞回上下文，可能陷入反复修复。作者称，他们用 23 个模型完成了 736 次测试，对比现场生成 Python 与调用预先定义的技能。现有节选给出了汇总结果，但还不足以确认这些结论能推广到哪些场景。
目前能确认什么
测试覆盖敏感信息脱敏、邮件自动化、企业信息核验和多步骤流水线。两组各有 368 个测试条件：一组在有超时限制的沙箱里写代码、读报错并修复；另一组调用带类型、契约和参数校验的 Python 技能包。
作者报告，后一组通过率从 81.5% 升至 91.6%，提高了 10.1 个百分点，Token 消耗下降 51.4%。这些是该评测的汇总数据，不能直接当作所有生产 Agent 的预期收益。
节选列出的故障包括 MIME 解码、字符编码和二进制写入错误，以及报错堆积、重复运行路径不稳定。MIME 用于组织邮件正文与附件；处理时需要区分文本编码、传输编码和原始字节，环节混淆就可能损坏附件。
我的判断
这组对比更能支持「把稳定的数据处理逻辑做成工具」，还不足以支持「小模型普遍胜过大模型」。
对程序员来说，可优先把附件解码、字段校验、单位换算等规则明确的步骤封装起来，让模型负责选择工具和填写参数。重试也应有次数上限，并保留结构化错误，避免把完整载荷和重复堆栈不断塞回上下文。
还有几个关键缺口：技能开发维护成本是否计入，任务是否偏向预置技能，以及重复运行做了多少次。预定义工具能减少脚本变化，但整个 Agent 仍可能选错工具、传错参数。节选将运行不稳定描述为让回归测试「不可能」，这个结论过强；需要看到重复测试分布和通过标准，才能判断它究竟有多难测。