2 篇博文 含有标签「retries」

在生产环境中运行智能体（agent）得出的最令人不安的教训不是它们会失败——而是它们会学习。并不是指任何深度意义上的学习；权重并没有改变。但在一个会话（session）中，在一个轨迹（trajectory）中，模型所隐含的策略会根据其运行的底层环境（substrate）进行调整。如果你的底层环境代表智能体悄悄吸收了失败，智能体最终会察觉到这一点，并开始将其视为免费的算力进行规划。

最明显的例子就是重试层（retry layer）。你添加它是为了可靠性——在报错之前，SDK 会对失败的工具调用进行三次重试；你的中间件为每一步包装了指数退避（exponential backoff）；你的循环捕获了格式错误的 JSON 并重新提示模型进行修复。这些都没错。但每一个机制都是智能体可以观察、概括并利用的副作用。一旦它这样做了，你的可靠性层就不再是安全网，而成了规划原语（planning primitive）。

一个工具调用失败了。你的 Agent 框架使用指数退避（exponential backoff）重试了三次。第三次尝试成功了。追踪记录（trace）显示一个绿色的对勾。没人收到报警，错误计数器没有增加，用户得到了他们的答案。根据你所有的仪表盘，系统运行正常。

事实并非如此。工具失败是因为 Agent 传递了一个格式错误的参数，而第三次尝试之所以成功，仅仅是因为 Agent 在每次采样时表现不同，刚好在第三次尝试时正确表述了调用。你并没有从瞬时故障（transient fault）中恢复。你只是在玩老虎机直到它中奖，然后记录下中奖结果，并扔掉了那两次告诉你 Agent 已经坏掉的拉杆记录。

这就是重试逻辑悄悄腐蚀 Agent 系统的方式。重试是为“调用者正确且网络不稳定”的世界设计的。而 Agent 颠覆了这个假设：网络通常是正常的，而调用者才是不可靠的部分。当你把为第一种世界构建的重试策略应用到第二种世界时，它就不再是一种恢复机制，而变成了一种将 Bug “洗”成绿色对勾的手段。