用排队论解释智能体集群限流

团队一到站会结束就同时启动 Agent，随后排队、重试、撞上额度墙，很容易被归结为「今天限流来得特别早」。作者提出的判断是：先别急着升级套餐，先算清任务涌入的速度，是否超过套餐能够持续处理的速度。

这篇的价值在于把 Agent 限流转成一个可分析的排队问题：什么时候该错峰，什么时候该保存进度，什么时候才需要加钱。不过，文中的算例也有一个关键缺口：并发数和处理速率不能直接画等号。

限流之前，先看任务是怎么涌进来的

作者用一个场景切入：站会结束，5 个人在约 90 秒内各自启动一个 Agent。到了 10:30，有人开始盯着加载动画；中午，本该完成的请求还堵在一起。

这些任务不是随机到达的。站会、午饭结束、Sprint planning，都会让一批人同时开始工作。人的日程制造了流量尖峰，套餐公布的额度却不会配合会议时间临时上涨。

排队论里有两个量：到达率是单位时间进入多少工作，服务率是单位时间完成多少工作。Little's Law 则描述平均在系统中的任务数、平均到达率和平均停留时间之间的关系：

平均在途任务数 = 平均到达率 × 平均停留时间

这里的停留时间包含等待和实际处理。如果输入长期超过处理能力，积压就会持续增加，响应时间也会越来越受队列长度支配。

作者把套餐视为提供服务的一方，将 tokens per minute、requests per minute 和五小时窗口等约束视为容量边界。对程序员来说，关键是先统一计量单位：任务数、请求数、token 数不能混着比较。

短时拥堵先检查调度，全天超载再讨论扩容。

为什么先排队、存进度，再考虑换套餐

作者给出的处理顺序是 batch、checkpoint、degrade，最后才是 upgrade。

Batch 在这里指把任务先放进自己的队列，再按可承受的速度放行，不是调用某个特定的批处理 API。作者认为，一个约 20 行的 drip feeder，就能把 9:02 同时涌入的任务摊开。

它解决的是可控性：由团队决定谁先执行、最多同时执行多少个，避免所有 Agent 一起向服务商争抢额度。任务仍然需要等待，只是等待发生在自己能够观察和管理的地方。

Checkpoint 是保存执行进度。任务撞上额度墙后，下次应当从中断处继续，而不是重新读取材料、重复推理、再次支付已经做过的工作。

这里还有一个反馈循环：触顶导致失败，失败触发重试，重试又增加流量，最终更容易触顶。保存进度能减少重复消耗，但仍需要合理的重试策略。

Degrade 是执行途中降低资源要求：常规步骤交给小模型，关键判断交给大模型，可选工作推迟到窗口重置之后。这要求团队先知道哪些步骤可以降级。原文没有指定模型，也没有提供切换后的质量对照，不能据此认定降级一定划算。

算例说明了拥堵，但没算出完成时间

作者设定，一个套餐能够持续支持 3 个重任务并发。团队在站会后启动 5 个任务，随后一小时又来了 3 个，合计 8 个。

原文接着把 9 点到 10 点的情况写成：来了 8 个，完成 3 个，剩下 5 个等待；到 11 点，大家开始觉得限额格外难用。采用排队调度后，每次放行 3 个，作者称完成时间能从「实际上遥遥无期」变为「下午较早时候」。

这个算例适合解释任务如何堆积，却不足以支持完成时间的结论。

能同时跑 3 个任务，不等于每小时能完成 3 个任务。

还需要知道任务平均耗时，以及每个任务消耗多少 token、发出多少请求。如果任务耗时不同，同样的并发上限会对应完全不同的吞吐量。排队也不会凭空增加容量；在没有重试浪费、竞争开销等因素时，它主要改变放行方式，未必缩短全部任务的总完成时间。

作者自己也承认，真实 Agent 流量包含相关性很强的突发、重试风暴，以及上下文不断增长的问题。下午的任务可能比上午消耗更多 token。因此，平均值适合判断系统处于稳定、临界还是饱和区间，不能准确预告下午 3 点的延迟。

我的判断

我赞成作者把注意力从「还剩多少额度」移到「工作以什么速度进入系统」。尤其是多人共用资源时，一张额度仪表盘很难解释为什么站会后突然变慢，带时间分布的日志更有用。

但「服务商无辜」说得太满。原文没有提供实测日志、套餐规则或对照实验，无法排除服务波动，也不能证明所有拥堵都来自团队调度。「20 行代码解决问题」「下午较早完成」都应当按经验性描述理解。

理论部分也需要收紧。Little's Law 通常用于有稳定长期平均值的系统，不能直接用它给持续超载的队列计算稳定等待时间。五小时累计额度也不等同于平滑、恒定的服务率，它可能要求跨窗口安排工作。

相较于单纯限制并发，按请求速率、token 消耗和累计窗口共同调度更贴近原文讨论的问题，但实现成本也更高。作者称前三种办法免费，准确说是未必需要升级套餐；队列、状态恢复和降级验证仍然要投入工程时间。

能拿来做什么

• 先收集一周使用日志，按工作时段记录任务到达时间、请求数、token 消耗、耗时和重试次数，并标出站会、午饭后的集中启动窗口。作者建议用工作时段总 token 估计到达率，但只看全周平均值会掩盖尖峰。
• 在团队共用的 Node Agent 调度入口增加队列，分别约束并发数和放行速率，再观察等待时间与失败情况。队列等待也应当展示给使用者，避免大家因为看不到进度而重复提交。
• 给多步骤 AI 编程任务保存已完成阶段和必要产物，恢复时复用有效结果；再挑选可验证的常规步骤尝试小模型，比较质量和消耗后决定是否保留。
• 升级前先回答原文最后的问题：当前套餐能持续承载多少并发 Agent，是否会在下午 2 点撞上五小时窗口。作者说可以用计算器花 10 分钟估算，但原文没有给出具体套餐和任务耗时，实际数字需要自己测量。