让 AI Agent 调优 Linux 调度器：SchedCP 与 sched-agent 的设计与评测

Linux 调度器根据可运行任务、唤醒事件、优先级和累积的 CPU 时间做出决策，应用却用另一套指标评价结果：编译内核时关心最后一个编译进程何时结束（makespan），在线服务盯着 P99 延迟和吞吐量，一组并行的批处理任务可能被其中最慢的那个拖住（长尾分布）。内核提供机制和测量手段，工作负载决定怎样才算“更好”。这种错位（论文称之为“语义鸿沟”）意味着默认的 EEVDF 调度器在面对需要不同权衡的工作负载时只能用一套通用策略应对。

SchedCP 论文讨论的问题是：LLM Agent 能否在不获取机器完整控制权的前提下弥合这条鸿沟？论文的核心洞察在于架构设计：把“优化什么”（AI 的语义推理领域）与“如何观察和执行”（系统的安全执行领域）分离。SchedCP 通过 MCP 服务端提供工作负载分析、调度策略仓库和执行验证器；sched-agent 调用这些操作来观察工作负载、选择或生成策略、测试并从结果中学习。论文报告的案例包括内核编译最高 1.79 倍加速、调度器生成成本降低 13 倍；这些数字来自初步评测，是早期研究而非生产就绪的结论。

一条调度器生成指令包含多项独立工作

论文先做了一个直接的实验：让拥有 shell 全部权限的 Claude Code 从空目录开始，“用 eBPF 写一个 FIFO 调度器”。三次尝试只有一次得到可工作的调度器，另一次运行 6 分钟后停在伪代码，第三次花了 8 分钟却写成调度追踪器。成功的那次用了 33 分钟、221 次 LLM API 调用和 15 轮以上迭代，成本约 6 美元。生成的策略在部分工作负载上比 EEVDF 更慢，Agent 需要 root 权限，实验失败时可能导致系统崩溃且缺少回退机制。

这条提示词实际上混合了多项工作：学习 sched_ext 接口，编写能通过 eBPF verifier 的代码，安排高权限加载，选择基准测试，确定评价指标并解释测量结果。代码通过编译只完成其中一步；有效的调优还要确认策略是否改善目标工作负载、开销和饥饿是否受控，以及性能下降时能否及时撤回。论文把这些归纳为三个关键挑战：性能（AI 调度器必须优于现有方案）、安全（不能导致崩溃、死锁或饥饿，且应最小化权限）、效率（33 分钟和 6 美元的生成成本不具实用性）。

SchedCP 针对这些挑战把工作分成两个阶段：目标推断和策略合成。目标推断从命令、源码结构、进程行为和性能数据中提取工作负载描述、优化目标与约束；策略合成先在仓库中搜索已有调度器，必要时修改或组合已有组件，只有当复用不能满足需求时才生成新策略。这个顺序很重要：从仓库中选择一个已经测量过的策略，比为每个工作负载重新生成内核代码更快，也更容易验证。

Agent 与 sched_ext 之间的控制平面

SchedCP 向 Agent 提供一组稳定的系统接口，而不是通用的 root shell。论文给出四条设计原则：(1) 解耦与角色分离以保证面向未来的扩展性；(2) 安全优先的接口设计，把 AI 当作潜在的非谨慎行为者，默认阻止灾难性故障；(3) 自适应上下文供给，从最小摘要开始，按需逐步暴露细节以控制 token 成本；(4) 可组合的工具架构，遵循 Unix 哲学，让 Agent 通过推理能力构建新的工作流。

论文将接口归入三项服务。工作负载分析引擎提供分层访问：先给出成本较低的 API 端点（CPU 负载、内存使用摘要），需要时再开放 perf、top、文件读取、应用构建和动态可附加的 eBPF 探针。调度策略仓库保存可执行 eBPF 程序及其元数据（自然语言描述、目标工作负载、历史性能指标），支持语义搜索，让 Agent 在写新代码前找到相关调度器或可组合的代码原语。执行验证器在部署前检查所有 AI 生成的代码和配置。

按照论文设计，验证分三阶段进行：(1) 内核 eBPF verifier 保证内存安全和程序终止；(2) 面向调度器的静态分析检测饥饿、不公平等标准 verifier 检测不出的逻辑缺陷；(3) 隔离在 micro-VM 中的动态测试验证正确性和性能。通过验证的策略获得签名部署令牌，再以带监控和熔断器的金丝雀方式上线，这样 Agent 就不再需要 root 权限。

SchedCP 官方仓库已经提供具体的 MCP 操作：list_schedulers、run_scheduler、stop_scheduler、get_execution_status、create_and_verify_scheduler、system_monitor 和 workload 管理。实现包括使用 clang 编译 BPF 目标的自定义调度器，以及 10 秒钟的内核验证步骤。论文描述的完整 micro-VM、签名令牌和熔断回退路径在当前仓库中还不是端到端可见的实现，因此更适合作为架构设计来理解。

这条边界重新分配了职责。Agent 围绕工作负载目标进行推理并尝试不同方案，调度器加载、测量和策略校验由确定性接口管理；生成的策略通过 Linux sched_ext 原生运行，不会在调度热路径中引入模型推理延迟，这一点优于传统 ML 方法。论文提到框架大约由 4,000 行 Rust 和 6,000 行 Python（含测试）实现。

sched-agent：面向调度器的上下文强化学习

论文在 SchedCP 基础上实现了 sched-agent，一个采用**上下文强化学习（ICRL）**进行调度器优化的多 Agent 系统。它使用 Claude Code 的 subagent 架构，把任务分解给四个拥有独立上下文窗口和定制提示词的专业角色。该框架与容器编排器（Kubernetes、Docker）集成，可在应用部署时自动触发优化。

观察 Agent 通过策略性地查询工作负载分析引擎来构建工作负载画像，先从进程名和命令等高层摘要开始，只有在初始信号不足以判断时才请求更深入的性能剖析（perf stat、top）。它在管理成本与精度权衡的同时，把数据综合成自然语言描述和优化目标。分析内核编译时，它产出的描述类似于：“CPU 密集的并行编译，包含短生命周期进程和进程间依赖，优化目标是最小化 makespan。”

规划 Agent 通过调度策略仓库把画像转化为优化策略，遵循决策层级：先配置已有调度器，再生成补丁，最后才在简单方案不足时从原语组合新调度器。执行 Agent 综合代码工件、提交验证器、根据结果修正代码或解决逻辑问题。学习 Agent 通过分析部署结果（如“makespan 减少 45%”）完成 ICRL 闭环，支持会话内适应，同时把改进后的指标、部署上下文和反模式文档更新到仓库供后续搜索。

闭环里真正值得积累的是工作负载描述、调度策略与测量结果之间的联系。单独记住调度器名称很难指导下一次选择：同一个 scx_rusty 面对不同任务可能得到完全不同的效果；工作负载的并发度或数据分布变化后，原先有效的结论也可能失效。把上下文和结果一起保存，策略复用才有明确的证据范围。

初步评测：四个研究问题

评测围绕四个研究问题展开：RQ1（配置已有调度器）、RQ2（为特定工作负载生成新调度器）、RQ3（生成成本与效率）、RQ4（迭代优化的收益）。实验使用两台机器：一台 86 核 Intel Xeon 6787P、758 GB 内存、Linux 6.14，另一台 8 核 Intel Core Ultra 7 258V、30 GB 内存、Linux 6.13。Agent 由 Claude Code Opus 4 驱动，每个场景运行 3 次后取平均值。论文明确说明完整基准测试仍属于后续工作，且所有实验都成功创建了可工作的自定义配置或 eBPF 程序。

内核编译（RQ1、RQ4）： 采用 tinyconfig 和 make -j 172 编译 Linux 6.14 源码。第一次搜索选择 scx_rusty，平均时间从 EEVDF 的 13.57 秒降至 8.31 秒（1.63 倍加速）；后续迭代改用 scx_layered，达到 7.60 秒，相对 EEVDF 的 1.79 倍。同场比较的预训练强化学习调度器用了 13.79 秒，略慢于默认调度器；论文认为这是因为此类方法需要针对硬件和工作负载进行昂贵的重训练。

从反馈中学习： schbench 场景说明反馈如何纠正一次效果不佳的选择。EEVDF 吞吐量为每秒 910 个请求，P99 延迟为 40.3 毫秒；Agent 第一次选择 scx_bpfland 后，吞吐量降至 741（0.81 倍），P99 延迟升至 46.1 毫秒（0.87 倍）。经过三轮调整，Agent 改用 scx_rusty，吞吐量达到每秒 1,452 个请求（1.60 倍），P99 延迟降至 19.1 毫秒（相对 EEVDF 的 2.11 倍改善）。

新策略生成（RQ2）： 实验包含 8 个批处理工作负载，覆盖压缩、视频转码、软件测试和数据分析。每个工作负载并行运行 40 个任务，呈长尾分布：39 个短任务、1 个长任务。sched-agent 识别出长尾模式后生成最长作业优先（LJF）调度器，使平均延迟降低 20%。Claude Opus 以每次约 0.15 美元的成本正确分类全部 8 个工作负载；论文使用的 Sonnet 级别模型在分类步骤失败。

成本降低（RQ3）： 在 SchedCP 的复用和工具支持下，生成效率提升 13 倍（从 33 分钟缩短到 2.5 分钟），每个工作负载的合成成本为 0.45 美元，相比朴素生成的 6 美元大幅下降。

这些案例能够支持怎样的结论，还有什么问题待解决

在论文给定的条件下，这组实验完成了三类工作：为已知工作负载找到更合适的调度器，用测量反馈纠正一次较差的初始选择，并为结构清楚的长尾任务生成简单策略。它们也说明控制平面为何值得单独存在：Agent 的能力会随模型和提示变化，而验证、部署、测量与策略历史可以由不随模型更新而改变的基础设施管理。

当前证据来自两台机器、少量工作负载、每个场景三次运行，以及 Claude Code Opus 4。评估长期生产部署还需要覆盖更多硬件和内核版本、混合且持续变化的工作负载、故障注入，以及论文所述安全机制自身的测试。官方仓库把 SchedCP 标为实验性项目，并注明面向操作系统优化的 benchmark 仍在建设中。

SchedCP 在现阶段给出了一种具体的职责划分：AI Agent 根据工作负载证据提出调度假设；Linux sched_ext 以内核级安全保证运行策略；控制平面决定哪些实验可以执行，并根据测量结果判断是否值得继续迭代。相比让通用编码 Agent 直接生成高权限内核代码、再把“能够编译”当作完成，这条路径留下了更多可检查、可比较和可撤回的环节。论文把这一方向描述为迈向“Agentic OS”（能够驱动自身优化的系统）的一步，同时明确当前结果仍属初步阶段。

参考资料

• Yusheng Zheng、Yanpeng Hu、Wei Zhang、Andi Quinn：《Towards Agentic OS: An LLM Agent Framework for Linux Schedulers》，arXiv:2509.01245v4，2025 年 9 月。https://arxiv.org/abs/2509.01245
• SchedCP 官方仓库：https://github.com/eunomia-bpf/schedcp
• Linux sched_ext 文档：https://docs.kernel.org/scheduler/sched-ext.html
• Model Context Protocol：https://modelcontextprotocol.io/