额度已经耗尽，AI 为什么还在重试？
AI 助手停了，服务明明告诉它：“本轮额度已用完，今晚恢复。”
过一会儿，它却又试了一次。重试次数增加，工作没有前进。程序究竟没有读懂哪句话？
一种可能是：服务说出了失败原因，程序只记下“这一步失败了”。就像快递员告诉你“今天仓库关门”，系统却只登记“本次配送失败”，于是照常安排下一趟。
原因是在什么地方丢掉的？
这个问题来自 electrumnz 提交的 Paperclip #13549。Paperclip 管理持续运行的 AI 工作，其中包含失败后的恢复安排。
作者报告，一次生产检查发现 320 条额度相关的终止运行，其中 186 条带有重试关联，额度原因却没有被正确登记。这是上游的调查，我们没有访问那套生产数据。它让我们感兴趣，是因为“失败再来一次”对网络波动或许有用，对尚未恢复的额度却可能只是在重复碰壁。
程序要决定下一步，先得判断失败原因。这次修改补上了一个原先漏掉的入口：当消息以“这一轮执行失败”的错误码到达时，也去检查其中有没有额度信息。
所以，关键不只在于服务有没有说清楚，还在于这句话有没有到达负责决定等待时间的那段代码。
让同一句话，再走一遍
我们取出修改前后的原始分类代码及解析辅助函数，提供相同的九组输入。其中一条消息说额度已经耗尽，并给出了恢复时间。
| 输入 | 修改前 | 候选版本 |
|---|---|---|
| 带恢复时间的额度消息，经“本轮失败”入口到达 | 没有给出分类 | 识别为额度限制，算出服务消息对应的恢复时间 |
| 额度消息，没有恢复时间 | 没有给出分类 | 识别为额度限制，给出默认一小时等待 |
| 普通网络错误 | 没有给出分类 | 仍没有给出分类 |
| 缺少密钥，经原有适配器失败入口到达 | 配置不完整 | 仍是配置不完整 |
前两行都得到了一个等待时间，但依据不同：一条是从服务消息里读出来的，另一条是程序在信息不足时采用的默认值。
这一区别会影响人的判断。看到“请等到某个时间”，人很容易以为服务已经保证届时恢复；默认等待一小时，只说明程序打算隔一小时再试，并不包含这种保证。
图 1：来源：作者依据两版原函数的分类输出绘制。准确时间与时区换算保留在文末实验补充。
这里验证的是“分类代码给出了什么”。真正负责安排下一次执行的程序是否照此等待，还需要再接着测。单凭这张表，不能宣布整个重试问题已经解决。
有“额度”这个词，也可能是在否认额度问题
我们又故意给它一句话，中文意思是：“没有超出额度，网络连接失败。”实际输入的英文原文是：
No quota exceeded. Socket failed.
候选函数仍把它归为额度问题，并给出默认一小时等待。
这句话是我们人为构造的反例，没有证据表明真实服务会这样报错。它说明了关键词匹配的一条边界：看见某个词，还不一定读懂了整句话。
另一组输入提供了无法识别的时区，程序也退回默认等待。由此看，同样精确的时间显示，背后可能是有效解析，也可能只是备用规则。记录下这个区别，才能解释程序为什么这样等。
一个时间，还需要一句解释
进一步值得探索的是，让服务连接程序直接传递明确的失败原因和恢复时间，减少靠文字猜测；确实需要猜测或使用默认值时，也保留依据。这是后续方向，本轮仍只完成了分类函数对照。
普通使用者也能帮忙验证后半段：保留当时的提示语和时间，再记录重试次数是否继续增长、提示时间到了以后任务有没有恢复。这能帮助开发者把“原因已经识别”与“后续确实等待”连起来。
工具告诉你“请等到这个时间”时，它能不能同时说明，这个时间是服务告知的，还是程序估出来的？
固定版本与实验边界
保留的完整数值对照
实验时钟固定为 2026-09-16 04:50 UTC。额度消息指定 21:20 Pacific/Auckland，解析得到 09:20 UTC；无恢复时间时默认加一小时，得到 05:50 UTC。本轮读取时 PR 仍 open，固定来源状态不代表之后没有变化。
受测新增入口标识为 acpx_turn_failed（本轮执行失败）；输出的 parsedResetTime 用来区分是否解析到了恢复时间。“没有给出分类”是本函数返回 null，不表示后续所有处理都一定直接重试。
| 输入 | 修改前 | 候选版本 |
|---|---|---|
| 上述额度消息，经“本轮失败”入口到达 | 没有给出分类 | 额度限制；09:20 UTC 重试 |
| 额度消息，没有恢复时间 | 没有给出分类 | 额度限制；05:50 UTC 重试 |
| 普通网络错误 | 没有给出分类 | 仍没有给出分类 |
| 缺少密钥，经原有适配器失败入口到达 | 配置不完整 | 仍是配置不完整 |
基线 d0b67bfe71277f5a5ad21c7a7b6cb7af09e2ccca；候选 688c994a95d6c447816c50b14e30745d8ea9e855。使用受检锚点提取原分类函数块及原始解析辅助函数，9 输入 × 2 版本，共 18 条观察，不是 18 次真实服务调用。
补充场景覆盖结构化 retryNotBefore（得到 12:00 UTC）、未知错误码、无效时区，以及缺少密钥通过不同入口时的表现。否定句仅为人为边界输入。没有运行真实调度器、数据库恢复扫描、生产账户或模型调用。
全部结果与复跑脚本。没有据此认定 CodeFlowMu 具有同一错误入口或额度重试缺陷。