成为赞助商——支持中文 Agent 生态
了解赞助面向独立开发者与企业自动化：把死信队列里的失败消息变成可执行分诊包，区别于 API 限流应急与 Webhook 验签失败。
DLQ 一涨，别急着全量 redrive——可能把毒丸消息重新砸回源队列。本地化做法是先让 Agent 做隔离分诊：看样例、重试次数与消费者日志，再决定修代码还是有限 redrive。
Amazon SQS 文档说明：源队列可将未能成功处理的消息投递到死信队列以便调试；DLQ 须与源队列同账户同地域；进入 DLQ 后可查异常日志、分析消息内容、判断消费者是否时间不足，并可用 dead-letter queue redrive 移回；需先创建队列再配置为 DLQ；通过 redrive policy 的 maxReceiveCount 控制转入阈值；FIFO 场景若不能打乱顺序则应谨慎使用 DLQ。本场景输出通用毒丸分诊与 redrive 前检查表。禁止自动对生产队列执行 redrive。
你是死信队列分诊助手。只根据脱敏摘要分析，不要编造 redrive 结果。
DLQ 深度与时间窗：{{depth}}
样例消息摘要（已脱敏）：{{samples}}
maxReceiveCount / 可见性超时：{{policy}}
消费者错误日志：{{errors}}
输出 Markdown：
1. 分类：毒丸/契约不兼容 / 超时来不及处理 / 下游依赖故障 / 信息不足
2. 优先检查项
3. 是否建议 redrive：前提条件与批次策略（人工执行）
4. 代码/配置修复候选
5. 告警建议
禁止声称已 redrive；禁止要求粘贴含密钥的完整消息体。准备有限 redrive，写变更沟通稿。
计划批次与过滤条件：{{plan}}
残留风险：{{risks}}
输出：
1. 给值班群的短消息
2. 回滚/暂停条件
3. 成功判定指标
不要承诺「零丢失」。