Cost-Aware Agent Scheduling：并行推理不是银弹

论文：arXiv:2609.07890（示例占位，对应 agent scheduling / inference economics 方向）

「跑快点」的幻觉

多 Agent 并行几乎成了现代 Agent 系统的默认架构思路。一个任务拆成 10 个子任务，10 个 Agent 同时想，比串行快 10 倍——这是直觉，也是大多数框架的默认配置。

但这篇论文给了一个形式化的结论：这个直觉在很多场景下是错的。

当子问题满足以下条件时，并行的收益会被协调成本吃掉：

  • 耦合度高：子问题之间有依赖关系，不是真正独立的
  • 共享状态多：并行推理产生的中间状态可能互相矛盾
  • 验证成本高：合并结果需要验证一致性，而验证本身可能比重算还贵

在这些场景下，并行产生的是协调税（coordination tax）——协调多个 Agent 的中间状态、解决冲突、验证一致性，这些开销可能比串行推理还高。

κ 值：把调度问题变成经济学问题

论文提出了一个 Cost-Aware Schedule Policy，给每个任务计算一个 κ 值：

κ = (耦合度 × 重算成本) / 单步推理成本
  • 耦合度：子问题之间的依赖程度（0~1）
  • 重算成本：并行产生冲突后需要重新计算的成本
  • 单步推理成本：单步推理本身的计算成本

κ 值低（低于阈值）→ 走并行 κ 值高（高于阈值）→ 走串行或直接放弃

核心洞察是：把「能并行」和「该并行」分开。这是两个不同的问题，大多数系统只回答了前者。

「能并行」问的是：技术上这些子任务能不能同时跑？ 「该并行」问的是：同时跑的收益是否超过协调成本？

大多数框架只回答了第一个问题。κ 值回答的是第二个。

关键发现

协调税的具体来源：

  • 状态同步开销：并行 Agent 各自维护一份共享状态的副本，合并时需要解决版本冲突
  • 验证成本：并行结果的一致性验证本身可能比重算还贵
  • 重算放大效应：耦合度越高，并行产生的无效中间状态越多，重算概率越高

并行不一定更快：当 κ > 阈值时，串行推理的实际吞吐量反而高于并行。因为串行没有协调税，单步推理的持续吞吐量更稳定。

κ 值的经济学含义：κ 本质上是「每单位推理成本买到了多少独立信息」。当子问题高度耦合时，并行推理产生的是大量冗余信息，边际信息量趋近于零。

为什么这件事比听起来重要

当前的 Agent 编排框架大多数采用 fan-out（扇出）模式：无脑并行，能跑多少跑多少。这在子问题独立、耦合度低的场景下是合理的——比如并行的网页搜索、并行的数据抓取。

但当 Agent 系统进入生产级应用时，耦合是无处不在的：

  • 写代码时，生成接口和实现是耦合的
  • 写测试时，测试逻辑和实现细节是耦合的
  • 排障时，根因分析和上下文理解是耦合的

在这些场景里，无脑并行不只是效率低，而是会产生错误的中间结果——因为高度耦合的子问题并行跑，产生的中间状态是矛盾的，合并时不得不大量重算。

未来的 Agent 编排框架会出现一个「调度层里的微观经济学层」——不再是「能跑就跑」，而是「先算 κ 值，再决定跑不跑」。

局限性和适用边界

κ 值的计算本身有成本：耦合度和重算成本不是先验已知的，需要在运行时估计。估计本身也有成本。如果 κ 计算的开销接近或超过了串行推理的成本，这个策略就失效了。

阈值是动态的：κ 的阈值不是固定的，它和推理成本、延迟要求、可用资源都相关。在不同的系统配置下，同一个任务的最佳调度策略可能不同。

验证成本的假设：模型假设验证成本是固定的，但实际上验证成本本身也可能和并行策略耦合。比如某些验证在并行时反而更便宜（各自验证一个分支），这时候 κ 公式需要修正。

产品启示

如果你是 AI 基础设施或 Agent 框架的开发者，这个方向值得提前布局：

  • 在调度器里加 κ 计算层：不要等到结果合并时才发现冲突，而是在调度时就算好这笔账
  • 监控实际的协调税：在现有的 fan-out 系统里，加上协调成本的监控，看实际的并行效率是多少。你可能会发现大量「看起来在并行，实际在等待」的场景
  • 提供串行回退：当 κ > 阈值时，调度器应该自动切到串行，而不是继续并行做无用功

如果你是 Agent 系统的使用者：

  • 关注你用的框架有没有「智能调度」能力，而不是只会 fan-out
  • 在评估 Agent 系统时，问一个问题：这个任务拆成 10 个并行跑，真的比串行快吗？快多少？协调成本算进去了吗？

底层趋势

这条工作指向一个更大的现实：Agent 系统正在从「跑得快」走向「跑得值」。

早期的优化重点是「怎么让 Agent 跑得更快」——更好的模型、更强的算力、更深的并行。这是摩尔定律思维。

接下来的优化重点会变成「怎么让 Agent 跑得更聪明」——什么时候跑、跑多少、跑什么、串行还是并行，这是调度经济学思维。

谁先解决「什么时候不该并行」这个问题，谁就省下了最多的推理成本。在模型调用按 token 计费的现实下，这不是一个工程问题，是一个商业问题。