L4.13.3retry without escalation delays the human设计研究
反复重试而不上报会消耗资源并推迟人的介入
别名: 重试耗尽才上报 · retry storm · 不要默默再试
概念解释
工具失败或对象不对时，代理常自己再试：换一种说法、隔几秒再调、换一个相近对象。试的时候人被蒙在成功的表象里，介入被推到额度用尽或超时之后。重试而不上报会推迟人（retry without escalation delays the human）：重试是内部策略，上报是把人拉回来；只做前者，后者的时钟根本不启动。
三次内部重试看起来像稳健。对人来说是三倍的沉默，加上一份更晚、更长的历史。
机制
瞬时故障值得有限重试；权限拒绝、对象不存在、业务规则冲突重试不会变对。代理分不清这两类时，默认重试。产品若把「仍在运行」显示成健康，人不会在重试窗口里进来。资源被无效调用吃掉，外部系统可能被打出限流，人接到的是一份已经二次伤害过的现场。推迟还会拉长需要回溯的历史——晚和长是叠在一起的。
重试次数对用户不可见，等于把失败处理的时限单方面延长。
怎么研究
在不可靠的失败（权限拒绝）上，比较：立即上报、有限次重试再上报、无限重试直到超时。因变量：从首次失败到人看见的时间、无效调用次数、外部是否被打出副作用、人介入时现场是否更糟。自变量：重试是否可见、是否区分瞬时与持久失败、上限。
主终点是人看见的时间，不是最终成功率。成功率被无限重试抬高时，代价是现场。
边界
已知瞬时的网络抖动，有限次退避重试合理，但次数和当前正在重试必须可见，超时仍要上报。近似掩盖是交假成品；这里是交延迟。部分完成的清理不因重试而消失，每一次重试都可能多改一次世界，清理清单要跟着长。
怎么落地
- 把失败分成瞬时与持久。持久（权限、缺失、规则）第一次就上报，禁止重试。瞬时有上限，上限内过程视图写「正在重试 n / N」，到 N 上报。
- 重试不得对外部再产生不可逆副作用；做不到这一点的调用，第一次失败即上报。
- 验证：在权限拒绝上数从失败到人看见的时间。若中间有多次无效调用，策略就还是默默再试。把持久失败改成首次上报，人看见的时间应落到第一次失败附近，外部副作用次数应下降。