监督者模式触到了天花板
监督者 agent 在架构图里看起来很优雅。规划器接收一个目标，将其分解为子任务，再把每个子任务路由给一个 worker。worker 返回结果，监督者合并结果，系统输出答案。对于三四个 worker，这个模式没问题。对于三十个并发运行，它就是一个披着分布式外衣的单线程路由器。
两件事会同时崩掉。第一是串行化：每个子任务在到达 worker 之前都要经过一次推理步骤，于是监督者的延迟被叠加到依赖图中的每一跳上。第二是 prompt 膨胀。一个必须区分 N 种 worker 角色的监督者，要在上下文中携带 N 份描述、N 个工具 schema 和 N 个路由示例。路由准确率是一个注意力问题，而注意力会随着候选集合的扩大而退化。监督者不会大声报错；它会先开始错误路由边缘情况，然后是常见情况。
操作系统类比究竟带来了什么
这个类比不是装饰。它点出了监督者 prompt 无法表达的三种机制。
准入控制。 在一个运行启动之前，调度器检查预算、工具配额和依赖图是否允许它启动。父任务尚未完成的运行不予准入。会超出其租户剩余 token 预算的运行不予准入。需要某个已被其他运行占满的工具的运行不予准入。准入控制把一个过载的系统从不可预测地退化，转变为在一个明确定义的边界上拒绝工作。
抢占。 一个长周期运行必须能够在不丢失工作状态的情况下被挂起和恢复。这意味着运行状态不能存放在一个只在进程存活期间存在的对话缓冲区里。它必须被物化：部分计划、已完成的步骤、产出的工件、已经付过费的工具结果。抢占正是让一个短交互请求能够优先于批处理分析、同时又不丢弃该批处理分析的原因。
跨租户的公平性。 当一个团队的批处理任务可以饿死另一个团队的交互式 agent 时，问题就不再是推理质量，而是分配。一个带有按租户队列和明确份额策略的调度器，让饿死成为一个策略决策，而不是一个涌现出来的意外。
一个诚实的权衡：调度器增加了一个本身也需要运维的控制平面。队列状态、租约过期和抢占逻辑会引入新的故障模式，而一个调参不当的调度器会给那些在朴素监督者下本来能顺利完成的运行增加延迟。只有当并发高到竞争真实存在时，调度器才值得它的成本。低于这个阈值，监督者更简单也更便宜。
设计规则
把规划器与调度器分开。 规划器输出一个 DAG：节点是 agent 步骤，边是数据依赖，每个节点声明其资源需求。规划器不知道存在多少 worker。调度器掌握容量、排序和准入。正是这种分离，让路由质量和调度质量可以各自独立改进，而不是在一个 prompt 内部互相权衡。
plan -> DAG { node: { role, inputs, tools, budget } }
|
v
dispatcher: admit(node) if deps_done && budget_ok && quota_ok
enqueue(node) by priority and tenant share
lease(node) -> worker
on timeout or preempt: release lease, persist state
让每个 agent 步骤幂等。 一个可能被抢占并重试的步骤，在相同输入下重新执行时必须产生相同结果，或者必须能够检测到它的效果已经发生过。幂等性让抢占从「小心处理才安全」变成「构造上就安全」。带副作用的工具调用需要一个幂等键，该键派生自步骤身份，而不是墙上时钟时间。
把队列深度和等待时间作为一等遥测暴露出来。 如果队列状态唯一出现的地方是一行日志，运维人员就无法区分是模型慢还是调度器饱和。队列深度、等待时间、准入拒绝次数和抢占次数，应当与 token 用
够从第五步恢复，而无需为第一到第四步重新付费。
该测量什么
分别追踪排队时间与推理时间。 它们是不同的问题，有不同的解法。推理时间上升指向模型或 prompt 变更；排队时间上升指向容量或准入策略。把它们聚合成一个端到端延迟数字，会掩盖究竟是哪一个发生了变化。
在固定工作负载下的抢占率与恢复保真度。 重放一组固定的运行，在步骤边界强制触发抢占，检查被恢复的运行是否产生与未中断运行相同的最终工件。恢复保真度是调度器的正确性测试。
框架的转变
以监督者为中心的编排把集群当作一个推理问题，并寄希望于推理能够扩展。以调度器为中心的编排把它当作一个资源问题，让推理单元变得独立、可恢复、可问责。前一种框架产出的系统在演示中能用，在生产中停滞。后一种产出的系统，其故障模式是可读的：某个运行在等待，原因就在队列状态里。
工作并没有消失。它从 prompt 工程转移到了控制平面工程，而一旦并发成为约束，这本来就是它该待的地方。
封面照片：panumas nikhomkhai / Pexels。