接口自动化里异步任务终态断言，大家是轮询等待还是事件驱动？

背景 做了 3 年接口自动化（pytest + httpx，约 2000 条用例，跑在多人共享的 staging 上）。其中约 15% 的用例涉及异步链路：提交任务 → 后台 worker 处理 → 查询状态接口返回终态（SUCCESS / FAILED）。

现象

• 直接「提交后立即查询」：约 30% 概率拿到 PENDING，断言失败；
• 改成固定 time.sleep(5) 后：本地基本稳，但 CI 上偶发超时（worker 队列积压时 5 秒不够）；
• 改成轮询（最多 30 次 × 1 秒间隔）：稳定性上来了，但单条用例耗时从 2s 涨到 10–30s，整条流水线多花了 12 分钟。

已尝试的排查

1. 轮询 + 指数退避：耗时更不可控，且对慢任务并不友好；
2. 让后端加一个「完成回调」的测试 hook：被研发以「污染生产代码」拒绝；
3. 直接消费 worker 的完成消息（MQ）：可行，但测试代码强耦合了内部消息格式，维护成本高。

期望得到的答案形态

• 大家在「轮询 vs 事件驱动 vs 后端暴露同步接口」之间的取舍依据是什么？
• 轮询的话，超时上限 / 间隔 / 退避策略，有没有一套被验证过的默认参数？
• 如果是事件驱动，测试侧怎么避免耦合内部消息格式？
• 有没有更好的第三种方案（比如 backend 提供 ?wait=true 长轮询参数）？