From 5d22a94814f8963554c43a39003b9fa27ea575e8 Mon Sep 17 00:00:00 2001 From: NoctilumeDev <263493638+NoctilumeDev@users.noreply.github.com> Date: Sat, 29 Aug 2026 19:11:27 +0800 Subject: [PATCH] docs: calibrate agentic scheduler prior art --- README.md | 12 ++++++-- docs/experiment-roadmap.md | 23 +++++++++++---- docs/prior-art.md | 58 ++++++++++++++++++++++++++++++++------ docs/research-questions.md | 12 ++++++++ 4 files changed, 89 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index a9949cb..5f1d849 100644 --- a/README.md +++ b/README.md @@ -22,6 +22,11 @@ OS。它不试图让 AI 接管内核，也不假设人类拥有天然的最终 本仓库现在只保存研究问题、架构假设、实验路线和证据规则。它不是一个已经可运行的内核， 也不把路线图描述成已实现能力。 +AI 调度、runtime assurance、shielding、Capability 与 agentic scheduler control plane 都有直接 +前人工作。FlowKernel 不把这些零件单独宣称为新发明；它只把“多种策略源的运行时有界提案、 +C-first 确定性执行边界、统一授权语义和独立事实验收”作为待反证的组合差异。精确覆盖关系和 +必须复现的直接基线见[前人工作与阅读地图](docs/prior-art.md)。 + ## 实现契约 > C owns mechanism and enforcement; policy sources may only propose bounded actions. @@ -53,8 +58,9 @@ OS。它不试图让 AI 接管内核，也不假设人类拥有天然的最终 - **FlowKernel target：** 用受限 freestanding C 建立最小可启动内核、显式生命周期状态机、 有界能力与资源边界、确定性基线、C Guard、动作执行器和恢复钩子； -- **Linux reference lab：** 使用 Linux、cgroup、`sched_ext` 和 eBPF 作为传统对照组、观测 - 实验台与早期假设验证工具，不把实验台结果冒充 FlowKernel 内核能力。 +- **Linux reference lab：** 使用 Linux、cgroup、`sched_ext` 和 eBPF 建立传统对照组与现有 + agentic control-plane 直接基线，并作为观测实验台和早期假设验证工具；不把实验台结果冒充 + FlowKernel 内核能力。 在这两个边界上逐步研究： @@ -98,7 +104,7 @@ flowchart TD | 阶段 | 研究目标 | 当前状态 | | --- | --- | --- | -| R0 | 固定宪法、可信边界、C 工具链、传统基线与干净机器恢复协议 | Planned | +| R0 | 固定宪法、可信边界、C 工具链、传统与 agentic 基线、干净机器恢复协议 | Planned | | R1 | 最小可启动 C 内核、静态 Principal/Object 句柄与生命周期状态机 | Planned | | R2 | 确定性能力、资源和隔离 Guard，有限执行器与故障回退 | Planned | | R3 | 特权转换来源记录、恢复与外部验收交接 | Planned | diff --git a/docs/experiment-roadmap.md b/docs/experiment-roadmap.md index 2528ac2..dedd019 100644 --- a/docs/experiment-roadmap.md +++ b/docs/experiment-roadmap.md @@ -6,11 +6,15 @@ ## R0：宪法、可信边界、工具链与传统基线 目标：固定执行操作系统宪法、声明的可信边界、受限 C 子集、编译/链接/模拟器工具链，并建立 -可重复 workload、指标和 Linux 传统策略对照组。此阶段不写空内核制造进度。 +可重复 workload、指标、Linux 传统策略对照组和现有 agentic scheduler control-plane 基线。 +此阶段不写空内核制造进度。 最低证据： - 固定硬件、宿主内核、编译器、链接器、模拟器、运行时和 workload 版本； +- 建立带检索方法、时间范围、纳入标准、版本与证据等级的文献矩阵；至少直接比较 Simplex / + runtime assurance、Shielded RL、Kgent、SchedCP、Progent、传统调度和学习型调度，不以博客 + 摘要代替原论文与 artifact； - 明确 C/汇编边界、warning 策略、内存所有权规则和启动镜像格式； - 保存配置、随机种子和原始结果； - 覆盖 CPU-bound、I/O-bound、memory pressure、重试和长任务； @@ -19,6 +23,9 @@ AcceptanceVerdict 和 EpistemicStatus 的语义边界，但不预先冻结模块或 ABI； - 记录宿主、编译器、托管平台和单维护者作为当前外部 failure domain； - 从干净机器只依靠仓库、文档化工具链和网络重建 R0；失败时记录隐藏环境依赖，不降低门槛。 +- 在兼容 Linux、`sched_ext`、硬件和预算边界内，对 SchedCP artifact 完成可复现性审计或有界 + 复跑，记录 workload 分析、策略选择/合成、Execution Verifier、部署 token、canary、fallback、 + Agent 成本和失败结果；条件不满足时标记 `BOUNDARY / PENDING`，不把论文结果冒充本机证据。 ## R1：最小 C 内核、静态身份句柄与生命周期状态机 @@ -32,8 +39,10 @@ ## R2：确定性 authority、资源、隔离与 Guard 目标：实现确定性调度、资源回收、有限动作执行器与 C Guard，并使用 Linux reference lab -中的 cgroup、容器控制器、`sched_ext` 或 eBPF 建立同语义对照。逐步验证静态 Capability 的 -范围、过期、撤销、时限和版本，而不是先实现通用账号系统或动态委托网络。 +中的 cgroup、容器控制器、`sched_ext` 或 eBPF 建立同语义对照。除裸机制和传统调度器外， +SchedCP 式 workload 分析、策略库、验证后部署和受监控回退必须作为 agentic control-plane +直接基线。逐步验证静态 Capability 的范围、过期、撤销、时限和版本，而不是先实现通用账号 +系统或动态委托网络。 退出条件：每个动作都有 Principal、目标 Object、权限边界、资源预算、最大幅度、可逆性分类 和开销数据；撤销后的旧能力、旧快照与重放提案不能继续有效；Guard 或 authority state 崩溃、 @@ -56,11 +65,15 @@ Attention 不获得执行权。 ## R5：受约束策略学习 -目标：在内核外或隔离边界内，依次比较自适应阈值、模仿学习和受 C Guard 约束的强化学习。 +目标：在内核外或隔离边界内，依次比较自适应阈值、模仿学习和受 C Guard 约束的强化学习； +并在相同 workload、观测、预算和回滚条件下，将运行时有界 Proposal 与 SchedCP 式控制面 +策略选择、配置或代码合成分开比较。 退出条件：在相同 workload 和预算下超过已调优规则基线，并通过非法动作、策略超时、 奖励投机、饥饿和控制振荡测试。学习策略只能产生与规则基线同类型的 Proposal；不能因模型 -效果更好而扩大 Capability 或修改硬不变量。 +效果更好而扩大 Capability 或修改硬不变量。若控制面代码合成获胜，必须分别归因于 workload +语义、策略空间、部署前验证或运行时机制，不能把“Agent 生成了代码”本身写成 FlowKernel 的 +贡献。 ## R6：连续性、检查点、迁移与委托 diff --git a/docs/prior-art.md b/docs/prior-art.md index d4faa8f..93fd009 100644 --- a/docs/prior-art.md +++ b/docs/prior-art.md @@ -16,6 +16,11 @@ - [seL4 Capability Distribution Language](https://docs.sel4.systems/projects/capdl/index.html)： capability distribution 会限制系统未来可达状态，可作为静态权限图和最小系统描述的研究 参照。 +- [Progent：Programmable Privilege Control for LLM Agents](https://arxiv.org/abs/2504.11703)： + 以可编程策略在 Agent 执行期对工具调用实施细粒度、确定性的最小权限控制，并定义被拒绝 + 动作的 fallback。它是 FlowKernel 讨论 Agent Principal、有限动作和 complete mediation 时 + 必须比较的应用层基线；其工具调用策略不等于内核 Capability，也不覆盖资源所有权、恢复后 + 权限保持或外部事实验收。 - [NIST Separation of Duty](https://csrc.nist.gov/glossary/term/separation_of_duty)：说明职责与访问 授权可以被拆分，从而减少单一主体独立滥用系统的风险。FlowKernel 只把它作为未来高风险 governance transition 的候选原则，不在单维护者阶段伪造多人治理。 @@ -25,6 +30,11 @@ - [NASA：A Formal Verification Framework for Runtime Assurance](https://ntrs.nasa.gov/citations/20240006522)： Simplex runtime assurance 允许不可信高级控制器工作，并在安全条件不满足时切换到可信回退 控制器。它是“学习策略可失效、确定性 fallback 必须独立存在”的直接参照。 +- [Alshiekh 等：Safe Reinforcement Learning via Shielding](https://doi.org/10.1609/aaai.v32i1.11797)： + 根据时序逻辑安全规范合成 shield，监视学习器动作并在其将违反规范时纠正动作。它比一般的 + 约束策略优化更直接对应“策略建议先经过确定性安全边界”；FlowKernel 必须明确 C Guard 与 + 形式化 shield 在环境抽象、规范完备性、最小干预和收敛保证上的差异，不能只因结构相似就 + 继承 shielding 的证明。 - FlowKernel 的边界比单一控制器切换更宽：还需要 Principal、Capability、来源记录、资源隔离 和外部事实验收。不能因结构相似就宣称已经继承 Simplex 的形式化保证。 @@ -48,6 +58,10 @@ 主要候选边界。 - [`sched-ext/scx`](https://github.com/sched-ext/scx)：上游生态中的调度器和工具集合， 用于建立现有实现基线，避免从演示样例重新发明实验框架。 +- [`sched-ext/scx` Overview](https://github.com/sched-ext/scx/blob/main/OVERVIEW.md)：记录 Meta + 使用小型神经网络预测任务是否即将让出 CPU 的实验，以及 `sched_ext` 在生产 workload 上的 + 部署推进。它证明机器学习进入 Linux 调度实验已是工程事实，但不能据此把某个具体 ML + 调度器描述为已经完成大规模生产部署。 - [Control Group v2](https://docs.kernel.org/admin-guide/cgroup-v2.html)：提供层级化 CPU、 内存、I/O 和进程组织机制，是 workload 资源包络和最低保障的候选执行层。 - [Pressure Stall Information](https://docs.kernel.org/accounting/psi.html)：量化 CPU、内存 @@ -55,6 +69,22 @@ - [Linux BPF 文档](https://docs.kernel.org/bpf/)：覆盖 verifier、maps、helper、kfunc 和 用户态交互。任何 BPF 方案必须继承其验证、权限和可调试边界。 +## Agentic scheduler control plane 与 AI 生成内核策略 + +- [Zheng 等：Towards Agentic OS: An LLM Agent Framework for Linux Schedulers](https://arxiv.org/abs/2509.01245) + 及其 [SchedCP artifact](https://github.com/eunomia-bpf/schedcp)：把 AI 的 workload 语义分析与 + “优化什么”放在控制平面，将实际调度留给 `sched_ext` / eBPF；Execution Verifier 在部署前组合 + eBPF verifier、调度器专用静态检查和 microVM 动态验证，再使用签名部署 token、canary 和 + circuit breaker 限制失败。它直接覆盖“AI 不进入调度热路径”“控制面与执行面分离”“AI 生成或 + 选择调度策略”“验证后部署”这些候选差异，因此这些内容不能再被 FlowKernel 单独表述为新颖性。 + SchedCP 仍主要生成、配置和部署 Linux 调度策略；它没有证明 FlowKernel 计划中的 C-first + 自研内核、多个策略源运行时提交同类型有界 Proposal、完整 Capability 委托/撤销、因果来源与 + 独立 Acceptance 分层。 +- [Zheng 等：Kgent: Kernel Extensions Large Language Model Agent](https://doi.org/10.1145/3672197.3673434)： + 使用 LLM、程序理解、符号执行和反馈循环从自然语言合成并校验 eBPF 程序，是 SchedCP 的直接 + 技术前身。它使“LLM 生成受 verifier 约束的内核扩展”成为必须承认的既有基线；FlowKernel 若 + 研究策略合成，必须比较语义等价验证、误接受和失败回退，而不能把代码生成本身当作贡献。 + ## workload、容器与恢复 - [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec)：定义容器 @@ -84,14 +114,26 @@ 当前只能提出五项待检验差异，不能表述为贡献： -1. 将 workload 生命周期、检查点距离和有效进展作为长期策略状态； -2. 将学习建议与拥有最终否决权的确定性执行边界组合； -3. 同时评价连续性、饥饿、恢复和控制开销，而不是只优化平均完成时间。 -4. 让 Human、Agent、Service 和策略源通过同一有界授权语义参与动作，而不共享隐藏 God Mode； -5. 将授权、执行、来源记录和外部事实验收分层，并验证错误影响与工程恢复边界。 - -R0 开始前，需要建立文献矩阵，逐项记录问题、状态、动作、目标、约束、实验环境和公开 -局限。若已有工作覆盖上述差异，应修改研究问题，而不是维护预设的新颖性。 +1. 不只分类 workload，而是将可验证的生命周期、检查点距离、有效进展和连续价值作为长期 + 策略状态； +2. 让规则、启发式、RL、LLM 等多个策略源在运行时只提交同类型有界 Proposal，并由自研 + C-first 可信核心按 Capability、生命周期、资源和恢复不变量完整调停，而不是让 Agent 生成的 + 代码或配置自然取得执行权； +3. 同时评价连续性、饥饿、恢复和控制开销，而不是只优化平均完成时间； +4. 让 Human、Agent、Service 和策略运行时通过同一有界授权语义参与动作，而不共享隐藏 + God Mode； +5. 将授权、实际执行、观测、来源记录、外部 AcceptanceVerdict 和 EpistemicStatus 分层，并 + 验证错误影响与工程恢复边界。 + +SchedCP 已实质覆盖 AI workload 分析、策略选择/合成、控制面与执行面分离、部署前验证和 +受监控回退。FlowKernel 不再把这些单项当作候选贡献；R0 必须把 SchedCP 作为 Linux agentic +control-plane 直接基线，逐项比较策略更新时机、动作粒度、authority、验证者、fallback、 +运行时开销和公开失败边界。 + +R0 开始前，需要建立文献矩阵，逐项记录问题、状态、动作、目标、策略更新时机、authority、 +验证者、fallback、实验环境、证据强度和公开局限。若已有工作覆盖上述差异，应修改研究问题， +而不是维护预设的新颖性。论文、可运行 artifact、工程博客和未验证实现必须分级记录，不能 +因为名称相似或实现可用就赋予相同证据权重。 ## Linux reference lab 的许可证边界 diff --git a/docs/research-questions.md b/docs/research-questions.md index 1e3e775..e0641e9 100644 --- a/docs/research-questions.md +++ b/docs/research-questions.md @@ -30,6 +30,10 @@ - 静态规则、参数自适应、模仿学习和强化学习分别适合哪些阶段？ - 学习策略是否真的优于经过调优的启发式基线？ - 在线学习是否必要，还是离线训练加受控部署更安全？ +- SchedCP 式离线或控制面策略选择、配置与代码合成，同运行时持续提交有界 ActionProposal + 分别适合哪些决策；两者的更新时机、验证成本和失败半径怎样公平比较？ +- 策略更新单元应是可部署代码、参数配置、版本化 Artifact，还是固定动作集合内的 Proposal； + 什么证据能证明增加动态性带来的收益超过新的 authority 与回滚风险？ - 策略回滚、版本兼容和漂移检测如何设计？ ## RQ5：安全边界如何保持确定性 @@ -46,6 +50,10 @@ - 两边如何表达语义一致的 workload、生命周期状态和有限动作？ - Linux reference lab 的观测与 FlowKernel target 的内核事件存在哪些不可消除差异？ +- 如何把 SchedCP 的 workload 分析、策略库、Execution Verifier、签名部署 token、canary 与 + circuit breaker 作为完整 agentic control-plane 基线，而不是只和裸 `sched_ext` 样例比较？ +- Kgent / SchedCP 的代码生成、配置选择和部署验证，与 FlowKernel 的运行时有界 Proposal + 不能使用同一接口时，怎样避免把平台成熟度、Agent 成本或实现规模误当成机制收益？ - 工具链、模拟器和真实硬件结果如何分别标注，避免跨环境外推？ - C 内核新增机制的复杂度和故障面是否抵消策略收益？ @@ -73,6 +81,8 @@ - Human、Agent、Service 和策略运行时如何进入同一 Principal 模型，而不抹掉各自的责任差异？ - Capability 应怎样绑定 Object、动作、范围、资源预算、时限和版本？ +- SchedCP 式签名部署 token 能证明某个策略通过了哪些验证；它与可衰减、可委托、可撤销并 + 绑定运行时 Object 和预算的 Capability 之间还缺少哪些语义？ - Capability 粒度过粗会扩大爆炸半径，过细会增加传播、校验与撤销成本；怎样找到可测边界？ - 委托如何避免静默扩权，撤销如何对缓存、在途动作和恢复任务完整生效？ - 如何阻止 Agent 借用高权限执行器形成 confused deputy？ @@ -83,6 +93,8 @@ - `ALLOW`、执行器 `SUCCEEDED`、观测结果和 `VERIFIED` 分别由谁产生，怎样避免状态混轴？ - 一个特权转换最少需要记录哪些 Principal、Capability、Proposal、前后状态和恢复引用？ +- 部署前 Execution Verifier、运行时 Guard 和动作后的独立 Acceptance 各自能证明什么；如何 + 防止“代码通过验证”“canary 未触发回退”被提升为世界事实已经成立？ - 来源记录怎样发现缺失、截断、重排、身份冒用和存储损坏？ - provenance、日志和签名各自能证明什么，又不能证明什么？ - 来源记录与独立读回的 CPU、内存、I/O、时延和长期存储成本会不会抵消策略收益？