限流、背压与公平调度

约束并发进入速度，防止需求超过服务配额和资源。

限流约束进入系统的工作速度，背压让上游知道当前容量不足。它们不只是防止服务报错，也决定公平性和尾延迟。模型配额、数据库连接、检索吞吐、sandbox与外部工具各有容量，最慢约束会影响整体完成率。

按租户、用户与任务类型分配并发，交互任务和批量ingest使用不同队列或配额，避免后台吞吐抢占在线资源。热点客户可以有明确预算，但不能无限压住其他工作。队列需要长度、等待时间、取消和过期规则，不能把所有请求无界积压当作可靠接收。

429时遵循服务端提示与带jitter的退避，同时受总deadline约束。多个worker同步重试会形成惊群；简单扩容只会更快撞到供应商配额。应用应控制总并发与请求速率，并区分token速率、请求速率和工具资源，而非只数进程。

调度还需要考虑工作大小。长context和多Agent任务可能占用更多token与连接，不能与短查询完全按请求数等价。可用预计资源作初步分类，实际用量再校准；估计错误要有保护上限，避免一个模型自由发散消耗整个租户额度。

背压应反馈到产品：显示排队、预计范围或可选择的异步执行，而不是一直转圈。到达容量上限时可以拒绝低优先级批任务、降低允许并行或等待，不必静默转到未经批准模型。接受任务也要说明是否已进入可恢复队列。

负载实验同时观察突发、持续高量、单租户热点和供应商降额。报告排队时间、完成时间、公平性、拒绝率、重试放大与有效结果成本。吞吐提高却让大多数用户更慢，不是成功优化；容量决策必须与业务SLO一起看。

实践重点：按租户公平排队；交互与批任务隔离；遵循429提示与全局配额。

验证抓手：测突发、热点租户和批处理下的尾延迟与公平性。

常见误区：无限扩worker放大429风暴和费用。

OpenAI：Latency optimization；OpenAI：Agent运行时选择。