首次失败通常并非代价高昂的那一次。
代价高昂的部分在于首次失败之后发生的情况：系统持续尝试、持续消耗资源，并持续产生相同的结果，因为情境未发生任何变化。
我们反复遇到一个简单的模式：智能体遗漏一个步骤，运行时环境进行重试，下一次尝试看到相同的状态，循环重复，直到成本在账单或操作员日志中显现。此时，问题不再是大模型质量问题，而转变为控制系统问题。
为何循环比错误本身危害更大
单次错误步骤是可以恢复的。无边界的重试循环会加剧错误。
这对于令牌消耗、应用程序接口调用以及操作员关注度而言都是如此。对于信任而言也是如此。一旦系统因行为不可控而声名狼藉，人们便不再允许其处理实际工作。
这种故障模式平淡无奇，因此容易被忽视。没有人会在观看顺利路径演示时思考第三次出现相同错误后会发生什么。但真正的成本正蕴藏于此。
我们最初的尝试
显而易见的举措通常是错误的：
- 延长提示词
- 添加通用重试机制
- 增加超时时间
- 让大模型“进行更多推理”
- 使用略微不同的措辞重新运行相同命令
这些更改可能使演示效果更佳，但无法修复卡死的循环。
如果环境未发生变化，重试往往只是同一错误的第二次复制。
真正有效的方案
解决方案并非更聪明的语言，而是更严格的边界。
我们必须让运行时环境在继续执行前回答四个问题：
- 预算是多少？
- 什么算作成功？
- 验证器是什么？
- 当相同失败重复发生时该如何处理？
一个小型策略块通常足以使这一过程具体化：
{
"预算上限": 250,
"最大尝试次数": 3,
"遇到相同错误时停止": true,
"需要验证器": true,
"生成回执": true
}
这听起来并不宏大。但这正是关键所在。
最大的可靠性提升源于拒绝将重复失败视为进展。一旦运行时环境能够连续两次或三次检测到相同的阻碍因素，它便有权停止，而不是假装下一次重新运行会有所不同。
为何回执至关重要
回执将一次运行从模糊的故事转化为可核查的事实。
回执应显示：
- 智能体尝试了什么
- 发生了什么变化
- 什么失败了
- 运行为何停止
若无回执，循环可能隐藏在生成自信感的摘要之中。有了回执，你可以看到确切的停止点，并决定下一步行动应是人工干预、更换工具，还是完全不采取行动。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
