LLM-as-Scheduler 论文速读：多 Agent 工作流该学会早停

多 Agent 工作流过去有一个很自然但昂贵的默认假设：为了可靠，每个请求都走完整流水线。先生成，再反思，再验证，再修复，再集成，再让另一个 Agent 复核。这个设计在 demo 里看起来严谨，在生产里会迅速变成成本黑洞。ACL 2026 论文 “LLM-as-Scheduler: Agentic Workflow Dynamic Scheduling” 正面挑战了这个假设：多 Agent 工作流不应该把所有请求当成一样难。

论文的核心原则很清楚：有些 query 应该在一两个步骤后就退出，有些 query 需要额外验证，有些 query 应该进入修复 Agent，有些 query 应该直接判定为无法解决。系统需要一个显式 scheduler 或 controller，观察中间产物，决定每个请求如何穿过工作流 DAG。

这篇论文速读重点看三个问题：它为什么重要，调度层如何工作，开发者怎样把思想迁移到自己的 Agent 系统。

固定流水线的问题

很多自动生成的多 Agent 工作流会堆叠多个阶段：query refine、code agent、ensemble validation、test、error analysis、fix bugs、再 validation。困难样本确实可能受益，因为额外轮次提供了发现和修复错误的机会。但固定流水线的问题是，它把这些成本均摊给了所有样本。

在真实业务里，请求难度分布通常非常不均匀。客服系统里，大量问题是重复问答；代码修复里，许多失败只是类型错误或缺少边界检查；数据分析里，很多查询只需要一次 SQL。让所有请求都进入同样复杂的多 Agent 流程，相当于每次都用最高成本处理平均问题。

论文把这个问题和早退、条件计算联系起来：模型推理可以根据样本难度调整深度，多 Agent 工作流也应该根据样本难度调整路径。

LAS 的两阶段级联

LLM-as-Scheduler，简称 LAS，被设计成叠在已有工作流之上的策略层。论文里的设计是两阶段 cascade。

第一阶段是低开销 gate unit。它由脚本化检查和小 judge model 组成，在每一步都运行，负责处理明显情况。比如代码任务可以检查是否有语法错误、测试是否通过、输出是否为空、格式是否符合 schema、是否触发安全规则。这一层不应该贵，因为它会被频繁调用。

第二阶段才是 LLM scheduler。当 gate 发现结果不是明显通过或明显失败，而是“有希望但需要判断”时，才调用更强模型做路由决策。这个 scheduler 不读完整聊天历史，而是读一个紧凑的 workflow state，例如当前步骤、候选答案、测试摘要、错误类型、已消耗预算、剩余动作。

这种设计很工程化。它没有幻想用一个大模型替代所有控制逻辑，而是把便宜、确定、可脚本化的判断放在前面，把模糊决策留给模型。

论文结果为什么值得关注

论文报告，在 MBPP 代码生成基准上，LAS 将 token 消耗降低 63.4%，端到端延迟降低 41.9%，准确率最多下降 0.5 个百分点。这个数字真正重要的地方，不是某个 benchmark 上的绝对收益，而是它验证了一个生产直觉：很多多 Agent 成本是冗余控制流造成的，不是任务本身不可避免。

如果你的 Agent 系统每次都做三轮 self-refine、两轮 judge 和一次 fallback，那么成本优化不一定要从模型量化开始。先问一个更直接的问题：哪些步骤根本没必要执行？

工作流状态应该怎样设计

要落地 LAS 思想，第一步是把工作流中间产物结构化。不要只保存一串消息，而要给每个步骤生成 envelope。

type StepEnvelope = {
  stepId: string;
  role: "generator" | "validator" | "repair" | "tool";
  inputHash: string;
  outputSummary: string;
  confidence: number;
  testsPassed?: boolean;
  errorKind?: "syntax" | "runtime" | "semantic" | "policy" | "unknown";
  tokenCost: number;
  latencyMs: number;
};

type WorkflowState = {
  taskId: string;
  currentStep: string;
  envelopes: StepEnvelope[];
  budgetRemaining: number;
  deadlineMs: number;
};

这个 envelope 是 scheduler 的输入，也是审计日志的基础。没有它，调度只能读自然语言 transcript，结果会不稳定，也很难复现。

一个简化调度器

生产系统不必一开始就接入大模型 scheduler。可以先写规则版：

type RouteDecision = "exit" | "verify" | "repair" | "reroute" | "fail";

function route(state: WorkflowState): RouteDecision {
  const last = state.envelopes.at(-1);
  if (!last) return "fail";

  if (last.testsPassed && last.confidence >= 0.85) {
    return "exit";
  }

  if (last.errorKind === "syntax" || last.errorKind === "runtime") {
    return "repair";
  }

  if (state.budgetRemaining <= 0 || state.deadlineMs <= 0) {
    return "fail";
  }

  if (last.confidence >= 0.55) {
    return "verify";
  }

  return "reroute";
}

当规则版跑起来，再把模糊区间交给模型。例如 confidence 在 0.55 到 0.85 之间，测试没有覆盖语义正确性，或者两个 validator 分歧时，才调用 LLM scheduler。

什么时候不能早停

早停不是无脑省钱。高风险动作、不可逆动作、合规动作不能因为第一轮看起来对就直接退出。比如退款、发邮件、删数据、执行迁移、变更权限，都需要更强验证和审批。

更合理的做法是按动作风险设置最小路径：

LAS 的价值不是把所有流程变短，而是让流程长度和任务风险匹配。

与模型路由的关系

很多团队已经在做模型路由：简单请求走小模型，复杂请求走大模型。LAS 更进一步，它路由的是工作流步骤，而不只是模型。一个请求可能先用强模型生成，再用脚本测试早停；另一个请求可能用小模型初筛，再进入强模型修复；第三个请求可能根本不该继续，因为输入不足。

这意味着成本治理要从“每次调用多少钱”升级到“每个任务路径多少钱”。Agent 平台应该记录路径级指标：平均步骤数、早停率、修复率、验证失败率、回滚率、人工接管率。没有这些指标，就无法判断调度层是否真的有效。

局限

论文主要用代码生成等基准展示收益，真实企业工作流会更复杂。业务任务可能没有自动测试，validator 可能和 generator 共享同一类偏差，scheduler 本身也可能误判。尤其是当中间产物摘要丢失关键信息时，LLM scheduler 会做出看似合理但错误的路由。

因此，LAS 最适合和可执行检查结合：单元测试、类型检查、schema 校验、权限检查、预算检查、策略规则。模型负责模糊判断，程序负责硬边界。

工程结论

LLM-as-Scheduler 给多 Agent 系统提供了一个务实方向：不要把可靠性简单等同于更多 Agent、更多轮次、更多验证。可靠性来自正确的步骤在正确的样本上执行。简单样本尽早退出，复杂样本加深推理，高风险动作加强验证，无法解决的问题及时停止。

如果你的 Agent 系统已经有固定流水线，下一步不是重写框架，而是先加三个东西：步骤 envelope、便宜 gate、路径级成本指标。做到这三点后，再引入 LLM scheduler 才有足够上下文，也能真正评估它是否省钱。

参考来源：ACL Anthology 论文 LLM-as-Scheduler: Agentic Workflow Dynamic Scheduling，arXiv 和 Hugging Face Daily Papers 中近期关于 Agent 工作流成本、动态路由和多 Agent 评测的讨论。