每次重试都会重置的预算算不上预算——它的生命周期必须比单次运行更长

同一种故障的三个版本反复出现：换个说法重新查询就能重置的检索上限、启动一次新的根运行就能重置的 API 预算，以及错误工作流可以再次触发的工作流重试循环。系统不同，漏洞却相同——限制的作用域是单次运行，而故障并不受这个作用域约束。大多数限制按单次运行设置，自有其道理：运行次数很容易统计。单次运行的 token 预算、每条调用链的 max_calls、在 10 秒内出现 10 次相同调用时触发的循环检测器——这些都能应对短时间内的密集重复，却都抓不住缓慢发生的重复。失败的调用每隔几分钟重复一次、换个说法的查询返回相同证据、通过一次新执行发起的重试：在限流器看来，每一个都像是全新的任务，于是预算重新开始计算。我会把限制的作用域设为任务，而不是单次运行。这意味着三件事。第一，需要一个能跨根运行、重试和重新触发而保持不变的任务标识符——如果创建运行的系统无法传递这个标识符，预算也就无法延续，这正是首先要弥补的缺口。第二，需要一个以任务、操作及其输入共同作为键的重复计数器，其衰减窗口要足够长，能捕捉间隔数分钟的重复，而不只是短时间内的密集重复。第三，错误处理路径应继承剩余预算，而不是创建新预算：重新运行作业的错误工作流，应从同一份额度中扣除用量，而不是另开一个新账。难以判断的是，重试从何时起不再算重复，而应算作真正的新工作——输入变了、证据变了，或状态发生了变化。永远累计所有操作，会扼杀合理的重试。因此，计数器需要过期机制，以及与实际变化挂钩的重置条件，而不是随新的运行 ID 重置。在你的系统中，最棘手的是哪一部分——在不共享任务标识符的系统之间持续保留同一个任务标识符，还是判断一次重试何时才算真正的新工作？