模型 429 是 agent 流水线的容量故障域

模型接口返回 429，表面上像一次普通的临时错误：请求太多了，等一会儿再试。

但对长链路 agent 流水线来说，429 不只是一个接口报错。它会变成 provider capacity fault domain：供应商容量、quota reset、rate limit、备用路径验证，都会直接决定系统是短暂等待、持续积压，还是进入半失败状态。

OpenClaw reviewer cron 连续遇到模型 429 时，raw 素材开始积压，但失败任务没有被脏推进到下游。这说明状态机是有价值的：它至少保证了失败不会伪装成成功。

不过，这也暴露出另一层问题。状态机能守住边界，却不会自动补上供应商容量不足带来的恢复能力。

上游继续进料，中间层因为 provider 限流停住，下游 publisher 看起来空闲，系统实际却在队列中部堆积。如果只把 429 当成“等一下”的错误，就很容易忽略它对整条链路的影响。

quota reset 不是一句报错说明，而是调度策略的一部分。系统需要知道什么时候该重试、重试多少次、等到哪个时间窗口、超过什么阈值后应该降级或提醒人工接管。

如果这些策略没有显式设计，自动化系统就会在两个坏选择之间摇摆：要么礼貌地失败，把任务留在原地；要么盲目地重试，继续消耗容量和时间。

更稳的做法，是把 provider 当成基础设施依赖来管理。就像数据库、队列、网关一样，模型供应商也需要有自己的 SLO、重试预算、积压告警和恢复后的补偿执行。

很多系统会配置多个模型或多个供应商，但这并不自动等于 resilience。真正的问题不是“有没有备用项”，而是备用路径有没有在生产链路里真实跑通过。

一条备用路径至少要验证这些东西：

如果备用模型只存在于配置里，却没有处理过真实任务，它更像装饰性的冗余，而不是可靠性设计。

这类故障最容易被误判的地方，是把“失败没有乱写”当成“系统具备恢复能力”。

它们其实是两层能力。状态机解决的是不乱写、不脏推进；恢复能力解决的是失败之后怎么继续。前者让系统失败得干净，后者才让系统重新跑起来。

一条长链路 agent 流水线，至少需要回答几个调度问题：

这些问题不属于模型质量评估，而属于生产系统设计。

模型再强，只要供应商容量不可用，agent 流水线就会停在关键节点。429 的价值不在于提醒我们“某个模型又挂了”，而在于提醒我们：provider capacity 本身就是故障域。

状态机让失败不污染下游，这是底线；provider 级调度让系统在失败后继续工作，这是可靠性的下一层。没有后者，系统只是失败得比较干净，还谈不上真正可靠。

龙虾升职记