调度¶
调度解决的是一个古老的问题：多个需求者竞争同一个稀缺资源，谁先用，用多久，用完之后谁接上。
这个问题 OS 已经解决了 50 年。
OS 调度简史¶
最早的批处理系统没有调度。程序一个接一个跑，上一个跑完才能跑下一个。程序做 IO 时 CPU 空在那里，什么也不做——那个年代的 CPU 利用率报告读起来像一份尴尬报告。
时间片轮转（Round Robin）是第一次真正的突破：每个进程分配一个固定时间片，时间到了强制切换。CPU 利用率提升了，但问题随之暴露——所有进程得到相同的时间，不管它们的工作是否同样紧急。一个实时报警进程和一个后台日志压缩进程轮流占用 CPU，这在直觉上就是错的。
优先级调度解决了这个直觉问题，代价是引入了另一个：如果高优先级进程源源不断地涌入，低优先级进程就永远排不上队——饥饿。一个理论上正确的设计，在实践中可以把某些进程永久搁置。
Linux 的 CFS（完全公平调度器）把这个问题从"谁的优先级高"换了一个问法：追踪每个进程被"亏欠了多少 CPU 时间"，优先补偿亏欠最多的。这不是公平性的退步，而是公平性定义的精化。cgroups 在此之上加了预算管理：每个进程组最多能消耗多少 CPU，超了就限速。
五十年的演化轨迹：从"有没有调度"到"公平"到"优先"到"亏欠最多优先"，每一步都是被上一步的失败逼出来的。
Harness 的调度：编排决策¶
Harness 里的调度发生在应用层，管的不是"哪个 inference request 先进 GPU 队列"，而是哪个任务值得执行、什么顺序执行、是否并行。这是 orchestrator 的核心职责——agent 系统的 kernel 在做 kernel 该做的事。
对照关系是直接的：
| OS 调度模式 | Agent 编排对应 | 核心决策 |
|---|---|---|
| 批处理 | 顺序任务链 | 严格串行，确保依赖 |
| 时间片轮转 | 多 agent 轮流发言（GroupChat） | 公平轮转，防止某 agent 独占 |
| 优先级调度 | 层级委托（主 agent → 子 agent） | 高价值任务优先分配资源 |
| 抢占式中断 | 事件驱动中断（LangGraph interrupt） | 关键条件触发暂停 |
| Peer-to-peer | Agent teams（Claude Code 2026） | 去中心化，任务自组织 |
越来越多的编排模式正在出现——从严格串行到完全去中心化，覆盖的调度哲学谱系和 OS 50 年的演化基本吻合。
Harness 的调度：成本 ROI¶
这是 OS 调度没有的一个维度。
OS 的 cgroups 问的是：这个进程组最多能用多少 CPU？这是计算资源配额——CPU 时间是内部成本，不是逐次显性计费的。
Harness 面对的是一个更复杂的问题：这个任务值得花多少 token？
Token 是显性成本，每次推理都可以精确计量，harness 的调度目标函数因此变了：不只是"资源能不能完成任务"，还要问"完成这个任务值不值得花这么多 token"。OS 从来不需要问这个问题——CPU 时间是内部记账，不是逐次计费。
这个差异渗透进每一个调度决策：任务优先级不再只是"谁更紧急"，还有"质量要求和 token 预算是否匹配"；模型路由不是"最强的模型最好"，而是"这个步骤对推理精度的要求值不值得更高的单次成本"；任务截断不只是超时逻辑，而是"继续消耗的期望收益是否高于截断损失"。
Token 预算 = cgroups，但目标函数不同：OS 的调度追求吞吐量和公平性，harness 的调度还要追求质量/成本比。这个比值 OS 从来没有计算过，因为 CPU 时间不是按决策计费的。
断裂点：语义终止条件¶
OS 调度有一个可靠的终止机制：进程跑完了，退出码非零表示失败，调度器知道它结束了。时间也可以作为终止条件——超时 kill。这些都是精确的、非歧义的信号。
Agent 调度在这里遇到了 OS 没有的问题：什么时候算完，是一个语义判断，不是一个机器可以直接检测的状态。
考虑这样一个场景（用于说明结构）：编辑 agent 审阅一篇文章后批注"语气需要更专业"，写作 agent 修改后交回，编辑 agent 发现"太干了，需要更生动"——两个 agent 都在工作，都在消耗 token，但系统没有在向目标收敛。这不是死锁（没有人停下来等待），是活锁：持续活动，零进展，账单在跑。
OS 的超时机制可以检测活锁，但不能解决它的根本问题。OS 的进程有退出码，agent 没有。"这篇文章改好了"是什么意思——什么状态算"好"——是一个语义判断，不是时间或状态机可以精确捕捉的。
这是 OS 调度进入 agent 世界时必须新发明的那一块：语义终止条件。AgenticOS Workshop（ASPLOS 2026）把"语义感知调度"列为核心研究议题，正是因为这个问题在 OS 工具箱里没有现成答案。
调度正交于模型能力¶
更强的 CPU 没有消灭 CFS——进程还是要争 CPU 时间。更便宜的存储没有消灭虚拟内存调度——页面替换算法还在运行。
更强的 LLM 不消灭 harness 的调度需求，反而在两个方向上加剧：能接更复杂的任务，需要更多 agent 协作，编排决策维度更高；每次推理更贵（能力越强通常定价越高），成本 ROI 的权衡更重要，不是更不重要。
调度是 kernel 层的核心职责之一，不随计算能力的增长而消失。
调度决定谁在什么时候运行。信任边界决定运行时能做什么——工具权限、数据访问范围、越权行为的防护。这是另一根支柱，也是 agent 系统和传统 OS 差异最尖锐的地方。
延伸阅读¶
- Mei, K. et al. (2025). AIOS: LLM Agent Operating System. COLM 2025. arXiv:2403.16971. — 在系统层把 FIFO/RR 调度实现了一遍，和本文讨论的 harness 层编排调度正交互补；读完本文再读这篇，能看到调度问题在两个不同层次上的完整面貌
- AgenticOS Workshop. (2026). 1st Workshop on OS Design for AI Agents. ASPLOS 2026. — 本文提到的"语义终止条件"和"AgentCgroup token 预算管理"在这个 workshop 里被列为核心研究议题，是断裂点指向的前沿
概念与实体¶
本文涉及的核心概念与实体，在项目知识库中有更详细的资料：
- Agent Scheduling — 本文讨论的调度问题在工程层面的详细展开
- Agent Resource Control — token 预算 = cgroups 这一映射的资源控制机制
- Task Lifecycle — 调度决策的对象：任务从创建到终止的完整生命周期
- Long Running Agents — 长时间运行的 agent 对调度机制的特殊需求
- AIOS — 本文引用的 LLM Agent Operating System 项目资料