docs: calibrate agentic scheduler prior art

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 |

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：连续性、检查点、迁移与委托
 

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,13 +58,33 @@
   主要候选边界。
 - [`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、内存
   和 I/O 资源竞争造成的停滞时间，可作为“资源消耗”之外的生产力损失观测。
 - [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 的许可证边界
 

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、时延和长期存储成本会不会抵消策略收益？