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