本地栈是 platform 模式 真实 DashScope key——每次上传简历会真调 embedding一次 discovery run 会对每个职位 fan-out LLM 分析历史事故143 职位 ≈ 300 次调用清空预算。触发任何流程前先追查 MQ 消费者的下游 fan-out。验证 LLM 逻辑用 mock活体验证最多单条 smoke。fan-out 是什么文章目录Fan-out 解释用你这段上下文来理解为什么它是事故元凶这段笔记的核心警告Fan-out 解释Fan-out扇出是一个分布式系统 / 消息队列中的常见模式指的是一条消息触发后自动派生出多条并行的下游调用。用你这段上下文来理解MQ 收到一条消息请对这批职位做 discovery 分析 │ ▼ Consumer 消费这条消息 │ ├──▶ 职位 1 → 调 1 次 LLM ├──▶ 职位 2 → 调 1 次 LLM ├──▶ 职位 3 → 调 1 次 LLM │ ... └──▶ 职位 143 → 调 1 次 LLM一条消息进来143 条 LLM 调用散出去—— 这就是 fan-out。为什么它是事故元凶因素说明放大倍数不可控职位数量决定调用次数开发者很容易低估用的是真 key每次 fan-out 都在烧真金白银看起来只是跑了一下你以为触发了一次流程实际触发了 300 次 API 调用这段笔记的核心警告在执行任何流程之前先搞清楚 MQ 消费者下游会 fan-out 出多少次真实 API 调用。换句话说一条消息 ≠ 一次调用一条消息可能 N 次调用N 职位数。这就是预算被清空的根本原因。