核心 GUIDE
Retry Amplification（重试放大）
Retry 原本是为了提高可靠性，但当多个层级面对同一个模糊失败都独立重试时，负载和 Side Effect 会被成倍放大；没有共享 Budget 与 Idempotency 的重试反而会制造事故。
核心心智模型
Retry Amplification 发生在 Client、Queue、Service 或 Agent Loop 各自对不确定性重复 Work 时。多层 Retry Policy 组合后往往是乘法关系，而不是简单相加。
为什么重要
AI Production System 里可能同时存在 Model SDK Retry、Agent Loop Retry、HTTP Client Retry、Worker Queue Redelivery 和 Workflow Retry。依赖最脆弱时，这些层反而会制造更多请求；如果 Operation 有 Side Effect，原请求最终成功后，后续重复尝试还可能再次产生动作。
01
让 Retry 有唯一 Owner 和统一 Budget
先画出关键 Operation 的全部 Retry Layer，决定哪一层拥有策略，限制 Attempt Count 与 Elapsed Time，并对瞬时过载使用带 Jitter 的 Backoff。跨层传播同一个 Operation Identity，让 Downstream 能 Deduplicate。对于状态模糊的 Side Effect，Retry 前先验证 Remote State，而不是把 Timeout 当成失败。
02
示例：一次退款 Timeout 被放大成多次结算
Agent 因 Payment API Timeout 重试 Refund，HTTP Library 同时自动重试，Queue 又因为 Visibility Timeout 重新投递 Job。一次用户动作于是产生多个 Settlement Attempt。受控设计使用统一 Operation ID、Idempotent Settlement、唯一 Retry Owner，并在再次尝试前验证状态。
常见失败模式
- SDK、Application 与 Queue 都重试，却没有 Shared Budget。
- 依赖过载时立即高频 Retry，进一步放大故障。
- 对模糊 Side Effect 重试，却没有 Idempotency 或 State Verification。
工程启发
- 调整参数前先盘点全部 Retry Layer。
- 跨 Retry 与 Delivery Boundary 使用同一个 Operation Identity。
- Incident 中同时监控 Retry Volume 与 Amplification Ratio。
关键结论
- 01Retry 可能制造负载，而不一定制造韧性。
- 02多个独立 Retry Loop 会互相放大。
- 03Idempotency、Budget 与 Verification 必须和 Retry Policy 一起设计。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。