预测配额调度：Flowness 如何在用量耗尽前收紧新任务准入

Flowness 同时安排多个 AI Agent 工作时，会遇到一个调度问题：新任务现在还能启动，但所有任务一起运行下去，可能在下一次额度重置前撞上用量限制。届时正在进行的工作会被打断，任务交接和恢复也要付出额外成本。

本文讲的是配额预测与准入规划。它读进用量窗口的观察值、近期消耗变化和正在运行的 Agent 数，算出一份计划：建议的并发上限，以及要不要停止接新工作。这套规则今年 7 月 25 日到 28 日在我们的服务器上定时跑过，当时它的计划只用在新开的工作上，正在跑的不动；7 月 28 日以后它停了，到现在没有再跑。下面讲的是代码里的决策规则，文中的阈值都是代码默认值，和当时的线上配置相同，不是线上读数。

只看“已经用了百分之多少”，会漏掉时间。已经使用 60%，一小时后重置，与四小时后重置，需要承受的剩余运行时长不同。速度也一样重要：每小时消耗 10 个百分点，与每小时消耗 30 个百分点，对未来的影响很不一样。

调度器因此同时读取使用比例、距重置的时间和消耗速率。它还检查观察是否足够新，以及在跑的 Agent 清单是否完整。若这些基础输入已经失真，算出一个精确的小数也没有意义。代码默认的新鲜度是 300 秒，观测过期时，计划不会据此放行新的 Agent。

这套规则使用了项目自己的安全目标。短窗口的目标线是 90%，用到这里，计划就不再接新工作，等窗口重置；95% 是硬停线，用到这里，计划直接把这个窗口判为不可用。这些数字是当前代码中的配置选择，不是模型服务的普遍规则，也没有证据表明它们适合所有工作负载。

预测速度来自三个角度：近期配额变化的平滑速率、token 变化经历史换算得到的速率，以及本窗口累计使用量除以已经过去的时间。程序取三者中较大的一个。

近期变化使用指数加权移动平均，默认权重为 0.35。可以直观理解为，新观察会影响估计，但不会一次抹掉此前的运行情况。累计速度则提供较长视角，避免短暂安静让系统突然判断自己可以大幅增加并发。窗口开始太短时，代码也有相应条件，避免直接用过小的时间作除数。

取最大值会偏保守。它能减少乐观估计导致的过度接单，也可能在负载已经下降时暂时闲置能力。这个取舍需要结合任务完成情况检验，不能只看资源是否始终被用满。

设短窗口已经用了 60%，距离重置还有一小时，目标是不超过 90%。可继续使用的空间就是 30 个百分点，可持续速度因此是每小时 30 个百分点。

如果现在有四个 Agent 在跑，预测总速度也是每小时 30 个百分点，那么按当前速度关系估算，并发目标仍是四个。四个都在跑，便没有余量接第五个。

如果预测总速度是每小时 15 个百分点，其他条件相同，计算出的目标可以达到八个：四乘以 30 除以 15。这个例子中，窗口已经过去四小时，累计使用速度也是每小时 15 个百分点，与三种估计取最大值的规则相容。

实现会把结果向下取整，再套上配置里的并发上限（默认 12）；在跑的 Agent 数、输入缺失和其他预算条件还会影响最终准入。这一步用在跑 Agent 的平均消耗，估算多开几个以后的负载；新任务若更重，预测就可能偏低。因此，这是一项需要持续更新的容量建议。

另一项判断专门处理快到边界的情况。假设已经使用 89%，预测速度为每小时 30 个百分点，距离 95% 硬停线还剩 6 个百分点。按这个速度，十二分钟后就会触线。

代码默认的安全提前量是十五分钟，所以这个状态会触发 drain：计划把这里标成“不再接新工作”。如果离重置还有一小时，可持续速度只剩每小时 1 个百分点，并发目标会算成零。变的只是这份计划，已经在跑的 Agent 不会因此被停掉；怎样等待、收尾或迁移，要由执行层另做。

周预算还会提供另一组限制，不能只通过短窗口检查就认为一定可以启动。将不同窗口一起考虑，是为了避免短期有余量、长期预算却已接近边界的矛盾。

这是一种预测式背压：根据可能到来的容量压力，提前减慢入口。与用尽后再恢复相比，它希望把部分中断成本转化为提前等待。代价是某些时候会少启动几个任务，尤其在预测偏高时。

本文确认了公式、默认参数和规划器最近一次运行的时间，没有取得这项策略的独立成本或质量对照。可以验证的下一步，应当比较同样工作负载下的意外中断、有效完成量和等待时间，同时记录预测偏差。只有这样，才能判断预留空间是否真的让工作更连贯，而不只是让用量曲线更平滑。

更正（2026年10月26日）：此前的正文只写了代码的默认影子模式，读起来像这套规则一直在线上运行，只是不动手。实际上，这套规则 7 月 25 日到 28 日在我们的服务器上定时跑过，当时它的计划只用在新开的工作上，正在跑的不动；7 月 28 日以后它停了，到现在没有再跑。文中的阈值是代码默认值，和当时的线上配置相同，不是线上读数。相关段落已按运行记录改正。另外还改了几处：95% 在代码里是硬停线，用到这里，计划直接把这个窗口判为不可用，此前写作“预警线”；此前写的“并发目标从四降到二”，按代码算不成立：按正文的例子，离重置还有一小时时，并发目标会算成零；后台运行的 Agent 此前写作“会话”，已改；“总并发上限”改成了“并发上限（默认 12）”。机制图上的“当前 4 个会话”“当前默认影子模式”也已改正。

本篇另备有明亮、适合手机连续阅读的公众号排版稿，配图按照本文机制单独绘制。查看公众号版，或下载 Markdown、HTML、PNG 与 SVG 配图包。