就绪不等于发车：智能体工作流的「尾延迟」治理
·
0 次浏览
·来源: 866ai
智能体工作流由多轮模型调用与工具交互串联而成，端到端耗时不仅取决于推理速度，还取决于就绪轮次何时被放行。多数运行时在某个轮次就绪后立刻放行，高并发下这种急切策略会让「已放出但未完成」的工作越积越多，且一旦提交便无法被工作流层重新排序，尾延迟随之恶化。新研究把就绪与发布解耦，提出感知尾风险的放行策略，让调度重新成为可能。
跑过复杂智能体工作流的人都有体会：十几轮模型调用加工具交互串下来，99% 的请求耗时能是平均值的好几倍。大家习惯把锅甩给推理速度，但一项新研究指出，真正的问题可能出在调度策略上一个不起眼的细节——每一轮结果一就绪就被立刻放行。
急切放行的代价
「就绪即发车」看起来天经地义：结果都算完了，为什么不发？但在多请求争抢资源的场景下，这套直觉恰恰是尾延迟的来源。发出去的每一个轮次都要占用资源往下跑，排队的工作越积越多；而更关键的是，轮次一旦提交，它就脱离了工作流调度器的管辖——调度层再想根据全局状况重排顺序、错峰执行，已经鞭长莫及。堵车由此形成，而且是最难治的那种：车已经在路上了。
研究者的解法是把两件被默认绑定的事拆开：轮次就绪，和轮次发布。就绪只说明计算完成，发布与否交给一个感知尾风险的调度器决定——它会评估当前资源水位和未完成工作量，故意让部分就绪轮次在手里多等一下，换取全局更稳的尾部表现。这和交通控制里延迟放行匝道车流以避免主线瘫痪，是同一个道理。
对智能体平台的启示
这个发现对正在搭建智能体平台的团队相当实用。过去优化端到端延迟的思路几乎全在压缩单轮耗时：换更快模型、砍提示词长度、并行工具调用。但如果调度策略本身就是急切放行，单轮再快也只是在造一辆更快的车，堵车照旧。把放行时机纳入调度自由度，是比换模型便宜得多的优化。
- 高并发场景优先评估放行策略，而不是急着扩容；
- 为调度器保留重排空间，别让轮次一就绪就脱离管辖；
- 尾延迟指标要按工作流而非单轮来度量。
智能体应用正在从演示走向生产，工程问题开始密集浮现。调度就是这样一类问题——它不性感，却决定用户在 P99 时刻的体验。