让 AI 写一段重试逻辑并不难难的是让它判断哪些请求不该重试。一个简单的 HTTP 状态码背后可能藏着完全不同的业务状态请求到底有没有到达服务器服务器有没有已经处理过重复发送会不会造成重复扣款有人做了个小实验准备了 14 个 API 失败场景包含请求方法、响应状态码、幂等键、限流头等额外信息要求每个模型对每个场景返回一个决定立即重试、延迟后重试或者不重试同时给出一句话解释。评分只看决定是否正确解释不计分但会被收集用来观察模型是否真的理解了场景。测试的模型有 8 个包括常用的几个编码和文本模型。每个场景都有预期答案最终成绩就是正确决定的百分比。先说最扎眼的结果。一个支付请求返回了 429并附带 Retry-After 头看起来像是典型的限流应该等一等再试。但这个请求没有幂等键重复发送可能导致重复扣款。24 次尝试中只有 6 次做出了正确判断正确率 25%。而且六次失败在三个轮次里完全一致不是随机波动更像是模型系统性地掉进了同一个坑看到 429 和 Retry-After就条件反射地选择重试忽略了支付场景缺少幂等保护这个关键上下文。反过来另一个支付场景附带了幂等键重复请求不会造成重复扣款模型们基本都能正确处理。这说明它们不是完全不懂幂等而是在信号冲突时容易被更显眼的 HTTP 状态码带偏。除了这个支付陷阱其他场景的表现分布也值得看。14 个场景里有 7 个在全部 24 次尝试中都答对了。这些主要是直截了当的重试情况比如服务不可用、限流且明确告知等待时间等。真正的差异出现在需要判断重试时机、多步状态流转或者上下文有矛盾的地方。有意思的是同一个模型三次运行的得分可能一样但错的具体场景会变。比如有个场景叫过期过滤器工作流四个模型在不同轮次给出了不同答案。有的模型从立即重试改成了延迟后重试它仍然认为可以重试只是对时机的判断变了。这让人开始怀疑只按立即重试和延迟后重试严格区分对错是否合理也许某些场景本来就允许多个合理答案。再看稳定性。8 个模型乘以 14 个场景一共 112 个组合跑了三轮。其中 102 个组合在三轮里对错结果一致稳定性大约 91%。也就是说大部分情况下模型表现是稳定的但同一得分背后模型可能在不同场景上犯错只是错误数量恰好相同。效率方面有的模型明显更省。有个模型在文本生成和样式任务上用得挺多这次也保持了较低的成本但它的成绩最差。另一个模型花费排在第二高原因不完全是 token 定价而是它没有遵守输出格式本该只返回一个决定和一句话解释却输出了几千个字符把成本拉高了。这个实验最直接的启示是AI 辅助编码时让模型生成重试策略容易让它正确判断哪些请求该重试、什么时候重试仍需要人把关。尤其是在支付、订单、库存这类涉及状态变更的场景HTTP 状态码只是线索之一方法是否幂等、有没有幂等键、请求是否可能已被处理这些上下文同样关键。盲目照着模型的决定去重试风险可能比不重试更大。从方法上看这个基准测试还能改进。比如允许某些场景有多个可接受的答案而不是只认一种。或者把解释也纳入评分观察模型是不是蒙对的。但即便在目前这种简单评分下最强模型也没有全对说明这个看似基础的问题对 AI 来说远没有到轻松解决的程度。对于日常开发一个实用建议是可以让 AI 帮你列出重试策略的候选方案但最终判断哪些请求可以安全重试应该由了解业务幂等性和状态流转的人来确认。如果模型给出的理由和你的业务上下文冲突不要因为它的决定看起来符合 HTTP 惯例就忽略矛盾。
