成为赞助商——支持中文 Agent 生态
了解赞助面向独立开发者与运维：把云厂商 API 流控报错翻译成可执行的应急 Runbook，区别于「用剩余 AI 额度刷 PR」。
半夜脚本刷爆 `Throttling` 时，最糟的是继续重试把窗口钉死。本地化做法是先让 Agent 写一页「限流应急清单」，再决定降速、聚合还是申请提额。
阿里云 ECS 文档说明：API 按地域与接口分别流控；超限会报 `Throttling` 且请求不被正确处理；合理化建议包括请求聚合、状态检查间隔与反向退避，以及流控后以约 1 QPS 做可用性探测；创建类接口另有数量限制。本场景把这些原则泛化成跨云/自建 API 的应急表：错误指纹、影响业务、立即动作（停重试/降并发）、短中期修复、是否需要配额申请话术。禁止编造具体配额数字；禁止在未授权时调用生产 API。
你是 API 限流应急助手。只根据用户提供的日志与调用面起草 Runbook，不要编造配额数值。
错误摘要（码/消息/时间窗）：{{error_log}}
涉及 API 与地域：{{apis}}
调用方与并发估计：{{callers}}
业务影响：{{impact}}
输出 Markdown：
1. 事件定性：疑似接口流控 / 账号配额 / 下游 429 / 信息不足
2. 立即动作（停重试、降并发、熔断开关）
3. 退避与聚合建议（固定间隔/反向退避/批量接口）
4. 观察指标与恢复判定
5. 是否需要申请提额：申请理由草稿（未知配额写「待查控制台」）
禁止声称「已自动提额」；禁止要求粘贴 AccessKey。基于应急处置记录，写限流事后复盘提纲。
处置记录：{{timeline}}
根因假设：{{hypothesis}}
输出：
1. 时间线（仅基于记录）
2. 根因候选与需验证的证据
3. 代码/调度防再发项（队列、抖动、批量）
4. 监控与告警建议（阈值、错误码）
5. 给负责人的一页摘要
不要伪造「零故障承诺」。