add leadership analysis for RTOS+LLM+Agent research project

结论：项目框架在问题定义、体系化设计、方法论层面具有明确领先性（预计领先同行3-5年） - 5项强领先：跨层实时性定义、双路线设计、规则兜底、三层指标、四组对照 - 1项领先：五类部署形态体系 - 2项需补强：实证数据、Agent框架集成 - 主要风险：理论框架需快速产出实证数据
add industry research survey on RTOS+LLM+Agent competitors
2026-09-23 03:22:10 +08:00 · 2026-09-23 03:12:03 +08:00 · 2026-09-23 01:35:01 +08:00 · 2026-09-22 15:43:45 +08:00 · 2026-09-22 13:46:16 +08:00
106 changed files with 8671 additions and 2680 deletions
@@ -1,10 +0,0 @@
-# Local assistant and workspace metadata
-.claude/
-.workbuddy-ai/
-
-# Local Git access notes may contain credentials
-git_skills.md
-
-# Microsoft Office temporary lock files
-~$*.docx
-**/~$*.docx
@@ -0,0 +1,35 @@
+# 20260922\_093448 会议主题拆分索引
+
+本次会议可以整理为 5 个相互关联、但可独立推进的主题板块。它们共同围绕人工智能、基础系统、行业落地与合作路径展开，但每个板块的研究对象、交付目标和后续动作并不相同，因此适合拆分为独立文件持续讨论。
+
+## 1. 主题划分
+
+1. [01-医疗AI导航与嵌入式收缩方向.md](01-医疗AI导航与嵌入式收缩方向.md)
+   - 聚焦手术显微镜 AI 辅助导航、外挂式推理到嵌入式收缩的产品路径。
+2. [02-大模型评测优化平台与本地模型社区.md](02-大模型评测优化平台与本地模型社区.md)
+   - 聚焦服务器侧模型评测、算子优化、量化比较、本地模型社区，以及平台建设、服务外溢和各方分工方式。
+3. [03-RTOS与AI实时控制基础系统课题讨论.md](03-RTOS与AI实时控制基础系统课题讨论.md)
+   - 聚焦翼辉方向、基础系统定位、MCU 与 SoC/Hybrid 路线区分，以及课题推进步骤、责任边界和合作方式。
+4. [04-垂直大模型训练框架与代训服务.md](04-垂直大模型训练框架与代训服务.md)
+   - 聚焦“垂直大模型不等于通用模型加行业语料”的方法论、七要素框架、代训服务步骤和分工合作方式。
+5. [05-法律政务数据治理智能体与XAPP平台.md](05-法律政务数据治理智能体与XAPP平台.md)
+   - 聚焦纪委办案、律师产品、数据治理智能体、XAPP 平台化思路，以及应用到平台的推进路径与合作分工。
+
+## 2. 结构判断
+
+这 5 个主题之间的关系如下：
+
+- `01` 是一个具体行业落地样例，体现 AI 从外挂推理向嵌入式系统收缩的路径；
+- `02` 是模型优化和测试平台能力，已经扩展为平台建设、服务输出与社区沉淀的完整工作线；
+- `03` 是基础系统方向的课题定义与合作主线，直接对应研究框架、翼辉合作和后续预研组织方式；
+- `04` 是大模型产业化的方法论与服务模式，偏研究方法、训练逻辑与代训服务设计；
+- `05` 是平台和应用层的产品化实践，展示多模态数据治理、专业应用与 XAPP 平台的落地形态。
+
+## 3. 使用建议
+
+后续讨论可以按两条线推进：
+
+1. **研究主线**：优先阅读 `03` 和 `04`；
+2. **落地主线**：优先阅读 `01`、`02` 和 `05`。
+
+这样可以把“研究框架”“平台能力”“具体应用”三类问题拆开处理，不会在同一份会议全文里相互缠绕。
@@ -0,0 +1,45 @@
+# 医疗AI导航与嵌入式收缩方向
+
+## 1. 主题定位
+
+这一部分讨论的是一个明确的医疗器械落地样例：围绕手术显微镜场景，为厂商提供 AI 辅助导航能力，并逐步从外挂式主机方案收缩到嵌入式系统方案。
+
+## 2. 当前项目形态
+
+- 合作对象是国内手术显微镜厂商；
+- 当前方案是在原有显微镜主显示链路之外增加一块副屏；
+- 图像从显微镜链路引出，进入外挂主机完成推理，再把辅助分析结果叠加回显示画面；
+- 这一阶段的目标是先完成功能验证和临床辅助价值展示，不直接改动原主屏系统。
+
+## 3. 核心价值
+
+这个方向的价值集中在三点：
+
+1. **医疗场景价值明确**：医生可以在术野中直接看到风险点、角度偏差和操作提示；
+2. **商业价值直接**：整套 AI 辅助能力对设备加价能力明显高于其硬件增量成本；
+3. **研究价值清晰**：这是一个从服务器式推理向设备内收缩的真实案例，能自然过渡到嵌入式与实时系统问题。
+
+## 4. 后续技术演进
+
+会议里已经明确，当前外挂式主机只是第一阶段。后续方向是：
+
+- 把外挂主机能力收缩进设备本体；
+- 把 AI 功能从“旁路叠加”逐步转向“设备内部集成”；
+- 由此引出嵌入式系统、资源预算、边缘推理和控制路径协同等问题。
+
+这意味着它不是一个单纯的图像识别项目，而是一个可持续向基础系统问题延展的行业样例。
+
+## 5. 与整体研究的关系
+
+这个主题与整体研究最强的连接点在于：
+
+- 它属于 `T4/T3` 一类的设备端与边缘端样例；
+- 它天然涉及“小型化、低功耗、设备内集成”的后续路线；
+- 它可以作为“AI 目标负载进入任务关键设备”的现实入口。
+
+## 6. 后续可单独推进的问题
+
+1. 设备内收缩后的算力与功耗预算如何设定；
+2. 显微镜主链路、副链路和 AI 推理链路如何协同；
+3. 哪些部分继续由外挂主机承担，哪些部分迁移到嵌入式系统；
+4. 该场景能否作为 RTOS / 基础系统研究的主样例之一。
@@ -0,0 +1,260 @@
+# 大模型评测优化平台与本地模型社区
+
+## 1. 主题定位
+
+这一部分讨论的不是训练一个新的通用大模型，而是建设一套面向服务器、机房、算力中心和本地部署场景的大模型评测与优化平台。它的核心价值不在“再做一个模型”，而在于把模型、量化、算子、运行框架、启动参数和硬件配置之间原本分散、难解释的差异，组织成一套可比较、可复用、可交付的证据体系。
+
+会议进一步给这条线增加了一个更有延展性的方向：在平台能力稳定之后，可以向“本地模型社区”延伸，形成面向区域算力中心、科研团队、行业客户和本地部署需求的模型比较、配置推荐和优化服务能力。
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 同一套硬件上，运行配置差异足以造成显著性能分化
+
+模型效果和运行表现并不只取决于显卡型号或算力规模。  
+量化方式、算子开关、容器配置、运行框架、显存组织和启动参数都会显著影响：
+
+- 启动时间；
+- 解码速度；
+- 稳定性；
+- 显存占用；
+- 长稳运行效果。
+
+这意味着客户看到的“模型快不快”，很多时候并不是硬件单因素决定的。
+
+### 2.2 平台真正解决的是“不可解释”问题
+
+很多客户当前并不清楚瓶颈到底来自：
+
+- 硬件资源本身；
+- 框架选型；
+- 算子实现；
+- 量化策略；
+- 参数配置与部署方式。
+
+平台的价值，是把原本靠经验和试错得出的结果，变成能够重复执行、系统记录和横向比较的证据。
+
+### 2.3 评测平台天然可以外溢为优化服务
+
+一旦平台具备：
+
+- 统一记录；
+- 统一对比；
+- 统一报告；
+- 统一复现实验；
+
+它就不再只是内部工具，而可以外溢成：
+
+- 算力中心选型服务；
+- 模型优化服务；
+- 部署建议服务；
+- 本地模型配置推荐服务。
+
+### 2.4 本地模型社区的重点不是“做大平台”，而是做“高价值局部能力”
+
+会议对“社区化”方向的判断也比较清楚：
+
+- 不必复制一个通用开源社区；
+- 不追求以模型数量堆出影响力；
+- 更适合聚焦本地部署模型、端侧模型、专业模型和工具化模型；
+- 重点放在选型、评测、优化、配置推荐和经验沉淀上。
+
+### 2.5 这条线与实时基础系统研究并不冲突
+
+虽然这部分内容更多发生在服务器和机房侧，但它和整体研究并不割裂，因为它提供了：
+
+- AI 目标负载的运行时证据基础；
+- 推理实时性不完全由操作系统决定的实证背景；
+- 对端侧、小型化和边缘部署的模型选型依据。
+
+## 3. 这条线真正要做的事情
+
+如果把会议中的想法进一步收束，这条线真正要建设的是一套“四位一体”的能力：
+
+1. **评测平台**  
+   负责统一记录硬件、模型、参数、运行结果和日志证据。
+2. **优化工作台**  
+   负责对比量化、算子、框架和启动配置，给出可复现的优化建议。
+3. **报告系统**  
+   负责把结果输出成客户能理解、团队能复用的标准报告。
+4. **本地模型社区**  
+   负责沉淀模型经验、配置经验、最佳实践和可复用模板。
+
+因此，这条线的本质不是“做个演示平台”，而是形成一套从实验到服务再到社区沉淀的连续能力。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“平台底座 + 优化服务 + 社区沉淀”的工作方式。
+
+### 4.1 先把平台做成证据系统
+
+第一步不是追求界面完整，而是确保每一次实验都能形成可重复、可追溯的证据，包括：
+
+- 硬件环境；
+- 模型版本；
+- 量化与算子配置；
+- 启动参数；
+- 运行日志；
+- 性能指标；
+- 异常记录。
+
+### 4.2 再把平台变成优化工具
+
+在证据系统稳定之后，平台需要进一步承担：
+
+- 多配置对比；
+- 自动化基线测试；
+- 优化项回归验证；
+- 最优组合推荐。
+
+### 4.3 最后向社区和服务产品外溢
+
+只有在前两步稳定之后，才适合把成果外溢为：
+
+- 内部优化知识库；
+- 本地模型推荐清单；
+- 算力中心服务能力；
+- 对外社区或合作平台。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：建立最小可用评测底座
+
+目标是先把评测和记录做扎实。  
+这一阶段应完成：
+
+- 硬件信息采集；
+- 模型加载与启动配置记录；
+- 解码速度、显存占用、温度和稳定性采集；
+- 日志归档与结果可回看。
+
+### 5.2 第二步：建立标准化对比实验
+
+目标是让平台开始具备“比较能力”。  
+这一阶段应完成：
+
+- 同模型不同量化方案对比；
+- 同模型不同框架对比；
+- 同模型不同算子开关对比；
+- 同一硬件下不同启动参数对比；
+- 同一配置长稳运行验证。
+
+### 5.3 第三步：形成优化报告模板
+
+目标是把结果变成可以交付的东西。  
+这一阶段应完成：
+
+- 统一评测报告模板；
+- 统一优化建议模板；
+- 面向内部研发和面向客户的双版本输出；
+- 典型案例归档。
+
+### 5.4 第四步：形成服务与社区接口
+
+目标是把平台从内部工具推进到合作能力。  
+这一阶段应完成：
+
+- 模型推荐清单；
+- 本地部署配置推荐；
+- 算力中心选型建议；
+- 模型社区入口与资料组织方式。
+
+## 6. 各方责任与分工方式
+
+这条线适合按四类角色组织。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 客户问题定义与场景归类；
+- 服务模式设计；
+- 报告交付结构与对外表达组织。
+
+唐老师团队更适合站在“需求整合、问题转译、合作推进”的位置上。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 评测方法学抽象；
+- 指标体系设计；
+- 对比逻辑与结论边界把关；
+- 从个案经验中提炼共性规则。
+
+罗老师团队更适合站在“方法论、评价体系、结果解释”的位置上。
+
+### 6.3 平台与工程团队
+
+适合承担：
+
+- 平台实现；
+- 模型部署与运行；
+- 评测脚本和自动化任务；
+- 数据采集、日志治理与结果可视化；
+- 优化项验证与回归测试。
+
+这一角色是平台真正落地的执行核心。
+
+### 6.4 合作方或客户方
+
+适合承担：
+
+- 提供真实模型与场景目标；
+- 提供约束条件与验收口径；
+- 确认数据权限与部署边界；
+- 对优化结果给出业务反馈。
+
+客户方不负责平台方法学设计，但必须负责场景目标与验收边界。
+
+## 7. 工作边界
+
+为了避免这条线失焦，需要明确它不做什么。
+
+### 7.1 不以训练新通用模型为主目标
+
+这条线的重点是评测、优化和配置比较，不是另起炉灶训练新的通用基座模型。
+
+### 7.2 不把平台做成纯展示系统
+
+如果平台没有可重复实验、可复用模板和可解释报告，它就只是演示界面，而不是方法平台。
+
+### 7.3 不把社区做成“模型仓库堆砌”
+
+本地模型社区的重点不在收集尽可能多的模型，而在于形成有用的模型说明、部署建议和优化经验。
+
+### 7.4 不直接替代端侧和基础系统研究
+
+这条线为整体研究提供模型运行证据，但它本身不替代 RTOS、基础系统和嵌入式部署课题。
+
+## 8. 合作推进方式
+
+这条线适合采用“三阶段合作法”。
+
+### 8.1 阶段一：评测平台共建
+
+重点是把实验环境、评测流程和数据记录打通。  
+交付物以内部工具、基线实验和标准报告模板为主。
+
+### 8.2 阶段二：优化服务协同
+
+重点是围绕真实客户、真实模型和真实部署需求输出优化结果。  
+交付物以优化报告、配置建议和案例沉淀为主。
+
+### 8.3 阶段三：社区与区域合作扩展
+
+重点是把积累下来的经验沉淀成更稳定的合作能力。  
+交付物以模型推荐清单、社区入口、合作机制和服务手册为主。
+
+## 9. 当前结论
+
+这条线的真正价值，不是再做一个“模型体验平台”，而是：
+
+> **把模型、量化、算子、框架和硬件之间原本难解释的运行差异，变成一套可比较、可复现、可交付、可沉淀的证据与服务体系。**
+
+如果继续向前推进，它会自然生长出两个方向：
+
+- 一个是面向内部和合作项目的优化工作台；
+- 一个是面向区域部署、本地模型与算力中心合作的本地模型社区。
@@ -0,0 +1,401 @@
+# RTOS与AI实时控制基础系统课题讨论
+
+## 1. 主题定位
+
+这部分讨论是整场会议中最接近课题主线、研究对象重定义和合作方向重构的核心内容。会议虽然从翼辉与 RTOS 相关问题切入，但最终形成的判断已经明显超出了“RTOS 是否更强”这一层，转向了一个更高层次的问题：
+
+> **当人工智能能力进入实时控制系统之后，真正需要研究和构建的对象，不再只是单一 RTOS，而是面向 AI 的实时控制基础系统。**
+
+这不是一句包装性口号，而是对研究主语、技术路线、合作方式和产业定位的重新组织。
+
+## 2. 会议形成的核心结论
+
+会议中稳定下来的，不是某一个局部技术答案，而是四项根本判断。
+
+### 2.1 大模型实时性不是单一 RTOS 问题
+
+人工智能目标负载进入系统之后，系统面对的问题来自多层要素共同作用，包括：
+
+- 模型结构与量化方式；
+- 推理框架与运行时队列；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离结构；
+- 芯片、总线、内存、DMA、NPU、GPU 等硬件资源形态；
+- 规则兜底、异常切换和安全边界机制。
+
+因此，会议给出的更准确判断是：
+
+> **人工智能进入实时控制系统之后，系统需要解决的是跨模型、跨运行时、跨基础软件和跨体系结构的整体实时性问题。**
+
+### 2.2 研究主语要从 RTOS 上移到基础系统
+
+会议没有否定 RTOS 的价值，但明确反对继续把全部实时性问题都压到 RTOS 身上。  
+RTOS 仍然是关键保障负载的确定性底座，但不再适合作为所有问题的唯一承担者。
+
+更合适的研究对象应当写成：
+
+- 实时基础系统；
+- 面向 AI 的实时控制基础系统；
+- 面向 AI 的实时控制系统体系结构。
+
+### 2.3 技术路线天然分成 MCU 路线与 SoC / 边侧路线
+
+会议没有把所有场景压成同一套逻辑，而是明确区分了两类问题结构：
+
+- `MCU` 路线：更强调静态资源组织、开发工具链、芯片协同和开发套件；
+- `SoC / 边侧` 路线：更强调 Linux、RTOS、Hypervisor 与异构资源共同构成的混合基础系统。
+
+因此，更接近原意的概括不是“MCU 让 RTOS 多做点事、边侧上 Hypervisor”，而是：
+
+> **MCU 路线主要解决静态编排与工具链协同问题，SoC / 边侧路线主要解决 Hybrid、Hypervisor 与系统协同问题，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
+
+### 2.4 翼辉方向需要从 RTOS 产品叙事转向基础系统叙事
+
+会议对翼辉这类公司的建议也比较明确：
+
+- 不再只讲 RTOS 厂商身份；
+- 不再把“适配了什么系统”作为核心叙事；
+- 转向“面向 AI 的实时控制基础系统供应方”；
+- 用 5 到 10 年技术路线替代短周期适配叙事。
+
+## 3. 基础系统视角下的问题结构
+
+为了避免后续再把所有问题混在一起，会议内容更适合被整理成三个层次。
+
+### 3.1 RTOS 直接控制域
+
+这一层对应 RTOS 可以直接施加机制约束的范围，主要包括：
+
+- 周期任务与关键任务调度；
+- 中断优先级、抢占关系和关键路径治理；
+- CPU 侧线程、同步机制与时钟管理；
+- 恢复、隔离和关键任务保护机制；
+- 对部分共享资源策略的直接控制接口。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 3.2 推理运行域
+
+这一层主要由模型、量化、算子、框架和运行时共同决定，主要包括：
+
+- 模型大小与数值精度；
+- Prefill / Decode 的时延分布；
+- KV Cache、工作区和内存组织方式；
+- 推理框架队列、批处理与上下文管理；
+- GPU/NPU 内部执行与驱动接口行为。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、资源行为和可优化空间。**
+
+### 3.3 系统协同域
+
+这一层是会议真正抬起来的新重点，主要包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、统一内存、外存和协处理器竞争治理；
+- 规则兜底、异常切换与安全边界；
+- 关键保障负载与人工智能目标负载之间的优先级结构。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+## 4. MCU 路线与 SoC / 边侧路线的真实含义
+
+### 4.1 MCU 路线
+
+会议对 `MCU` 方向的判断非常集中。  
+更准确的理解不是“MCU 端让 RTOS 多做一些事”，而是：在极小资源预算场景中，问题本身就不适合按高动态运行时思维组织。
+
+这一方向通常具有以下特点：
+
+- 动态空间极小；
+- 内存和算力预算刚性；
+- 控制任务和外设链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖离线配置、静态分配和代码生成。
+
+因此，会议原意更接近：
+
+> **MCU 路线中 RTOS 的意义更接近静态组织底座、可分析执行环境和开发工具链的一部分，而不是承接高动态推理运行时的主体。**
+
+### 4.2 SoC / 边侧路线
+
+`SoC / 边侧` 路线的判断也需要严格校准。  
+它并不是一句“边侧用 Hypervisor”就能概括的。会议真正强调的是：设备端 SoC 会天然同时存在 Linux 生态需求和实时控制需求，因此更现实的路径，是构造一个能够治理混合结构的基础系统。
+
+这类场景通常同时具有以下特征：
+
+- 需要 Linux 承接 AI 生态和推理框架；
+- 需要 RTOS 承接关键控制与实时保障；
+- 需要在同一 `SoC`、同一块板卡上处理统一内存和异构设备竞争；
+- 还要同时面对设备级功耗、散热、体积和驱动限制。
+
+会议对 `Hypervisor` 的态度是明确肯定的，但没有把它讲成单独答案。  
+更准确的理解是：
+
+- `Hypervisor` 首先是一种隔离和资源切分方法；
+- 它可以帮助划分 Linux 与 RTOS 的边界；
+- 但它本身不能自动消除统一内存、总线、DMA、缓存和协处理器带来的全部竞争问题。
+
+因此，这一路线真正保留并强化的是：
+
+> **面向 AI 实时控制系统的升级版 Hybrid，也就是能够处理分工、隔离、资源仲裁、规则兜底和异常切换的混合基础系统结构。**
+
+## 5. 建议的工作方式
+
+这一主题不适合按“先写论文、再找技术点”的方式推进，而更适合按“先完成问题重定义，再完成路线定义，再组织预研验证”的方式推进。
+
+### 5.1 先做课题重定义
+
+第一步不是急于给出实现方案，而是把以下问题写清楚：
+
+- 研究主语为什么要从 RTOS 上移到基础系统；
+- MCU 路线和 SoC / 边侧路线为什么不能混写；
+- RTOS 直接控制域、推理运行域、系统协同域如何分层；
+- Hybrid、Hypervisor、规则兜底在系统中的位置是什么。
+
+这一阶段的产物应当是：
+
+- 一份课题重定义稿；
+- 一份路线分层说明稿；
+- 一份面向合作方的概念阐释稿。
+
+### 5.2 再做技术路线分解
+
+在问题定义清楚之后，再把路线拆成两个主方向：
+
+1. `MCU` 路线  
+   重点看静态编排、工具链、开发套件、芯片协同。
+2. `SoC / 边侧` 路线  
+   重点看 Linux / RTOS / Hypervisor 分工、Hybrid 升级、统一内存与总线竞争治理。
+
+这一阶段的产物应当是：
+
+- 一份 MCU 路线稿；
+- 一份 SoC / Hybrid 路线稿；
+- 一份系统协同与规则兜底说明稿。
+
+### 5.3 再组织预研验证
+
+路线分解完成后，再进入原型和预研阶段。  
+这一阶段不是全面铺开，而应选典型切口验证关键判断，例如：
+
+- 小模型与控制任务的静态编排；
+- Linux 与 RTOS 分工下的控制链路保护；
+- Hypervisor 隔离下的统一内存竞争；
+- 模型输出与规则兜底共同构成的闭环。
+
+### 5.4 最后再回收进主课题框架
+
+只有在以上三步形成稳定判断之后，才适合把内容系统回收到主课题框架、论文规划和合作提案中。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：形成概念共识
+
+目标是对内把“RTOS 课题”与“基础系统课题”的边界说清楚。  
+这一阶段应完成：
+
+- 会议判断整理；
+- 原话核对；
+- 关键词统一；
+- 课题候选命名收敛。
+
+### 6.2 第二步：形成路线稿
+
+目标是把两个方向彻底拆开。  
+这一阶段应完成：
+
+- MCU 路线稿；
+- SoC / 边侧路线稿；
+- Hybrid / Hypervisor 路线稿；
+- 系统协同域说明稿。
+
+### 6.3 第三步：形成合作版材料
+
+目标是让外部合作方能够看懂“为什么值得做、准备怎么做、各方做什么”。  
+这一阶段应完成：
+
+- 面向合作方的路线总述；
+- 阶段性合作方式说明；
+- 预研问题清单；
+- 交付物框架。
+
+### 6.4 第四步：组织预研与验证
+
+目标是围绕少数关键问题开展验证。  
+这一阶段应完成：
+
+- 板级或 SoC 原型验证；
+- 小模型与控制任务共存实验；
+- 混合系统资源竞争实验；
+- 规则兜底与异常切换实验。
+
+## 7. 各方责任与工作的边界
+
+这一主题如果要继续推进，必须把责任和边界说清楚，否则很容易重新落回“谁都在提想法，没人真正推进”的状态。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 场景与需求整合；
+- 课题框架转译；
+- 合作节奏把控；
+- 外部沟通和阶段汇报组织。
+
+唐老师团队更适合处在“前端牵头、方案整合、合作推进”的位置。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 研究主语与问题定义把关；
+- 方法论抽象；
+- 路线分层与概念边界校准；
+- 研究价值、学术表达和系统建模方向的判断。
+
+罗老师团队更适合处在“高层框架、方法论和方向判断”的位置。
+
+### 7.3 翼辉或对应产业团队
+
+适合承担：
+
+- RTOS、工具链、板级环境和基础软件条件说明；
+- MCU 路线和 SoC 路线的工程条件提供；
+- Hybrid / Hypervisor / 板级验证路径提供；
+- 原型实现与工程可行性反馈。
+
+产业团队不负责课题理论抽象，但负责把路线落到真实平台条件上。
+
+### 7.4 项目组或工程支撑团队
+
+适合承担：
+
+- 会议整理与材料撰写；
+- 路线稿、合作稿和阶段文档整理；
+- 预研验证组织；
+- 图表、报告和证据归档。
+
+这一角色更偏执行支撑与资料组织。
+
+## 8. 工作边界
+
+### 8.1 这项工作当前首先是“定义工作”，不是全面工程实现
+
+会议形成的第一价值，是重新定义问题和路线。因此现阶段不宜直接把重点放在“大规模开发”上。
+
+### 8.2 当前重点是“搭框架”，不是“宣称已经解决”
+
+无论是 MCU 路线还是 SoC / Hybrid 路线，当前更适合先形成稳定的问题定义、路线定义和验证问题，而不是过早给出“完整解决方案”叙事。
+
+### 8.3 学术问题与产业问题需要并行，但不能混写
+
+学术上要回答：
+
+- 问题定义是否成立；
+- 三层边界如何组织；
+- 经典实时理论如何扩展。
+
+产业上要回答：
+
+- 产品路线怎么讲；
+- 哪些工程条件已经具备；
+- 预研从哪里切入。
+
+这两类问题必须关联，但不能混成一篇只讲口号的材料。
+
+## 9. 合作推进方式
+
+这一主题适合采用“规划先行、预研跟进、原型验证收口”的推进方式。
+
+### 9.1 第一阶段：规划与定义
+
+重点是：
+
+- 统一研究主语；
+- 统一路线分层；
+- 统一合作表达；
+- 形成首轮课题和合作框架稿。
+
+这一阶段的交付物应以定义稿、路线稿和合作稿为主。
+
+### 9.2 第二阶段：预研与技术论证
+
+重点是：
+
+- 抽取少数关键问题做原型验证；
+- 形成系统协同和控制闭环的实证材料；
+- 把 MCU 路线与 SoC 路线分别落到真实平台。
+
+这一阶段的交付物应以预研报告、实验记录和系统草案为主。
+
+### 9.3 第三阶段：联合课题与对外输出
+
+重点是：
+
+- 回收进正式课题框架；
+- 形成面向项目、论文和合作申请的材料；
+- 根据需要向白皮书、论文和对外交流稿扩展。
+
+## 10. 对当前研究仓库的直接影响
+
+这场会议对当前仓库至少带来六项直接影响。
+
+### 10.1 研究主语需要继续上移
+
+当前仓库已经从“硬件主语”转到“RTOS 主语”，而会议进一步提示：下一步更值得推进的是从“RTOS 主语”继续上移到“基础系统主语”。
+
+### 10.2 `T5~T1` 验证矩阵仍然有效
+
+会议没有否定验证矩阵，而是强化了一个更清晰的判断：
+
+- `T5/T4/T3` 更适合作为系统研究主窗口；
+- `T2/T1` 作为 RTOS 优势主战场的意义较弱；
+- 但作为 AI 负载和系统协同的参照窗口仍然有价值。
+
+### 10.3 需要把“系统协同域”单独写出来
+
+当前仓库的五层技术栈已经是很好的起点，但后续需要明确写出：
+
+- RTOS 可控域；
+- 模型与运行时域；
+- Linux、Hypervisor、芯片与资源治理共同构成的系统协同域。
+
+### 10.4 “实时性”需要从纯 OS 叙事中适度抽离
+
+后续文档更适合写成：
+
+- 实时控制系统中的 AI 能力；
+- 引入 AI 后的整体实时性问题；
+- 基础系统如何维持控制路径与 AI 路径的统一时间边界。
+
+### 10.5 低功耗、小型化方向会自然进入主线
+
+一旦研究对象上移到基础系统，低功耗、小型化、片上资源预算这些问题就不再只是应用专题，而会自然进入主线。
+
+### 10.6 后续课题命名需要重新评估
+
+如果沿着这次会议的判断继续推进，候选命名更适合向以下方向收敛：
+
+- 面向 AI 的实时控制基础系统；
+- 人工智能目标负载进入实时控制系统后的基础系统保障机制；
+- 面向 AI 实时控制系统的嵌入式体系结构与基础系统研究。
+
+## 11. 当前结论
+
+这场会议最重要的价值，不是提供了一个立即可落地的单点技术答案，而是把观察视角整体抬高了一层。
+
+会议最终给出的判断可以概括为：
+
+> **人工智能进入实时控制系统之后，真正值得研究和构建的对象，不再只是单一 RTOS，而是一个围绕实时性、控制性、推理性和体系结构协同展开的基础系统。**
+
+如果进一步压缩成最贴近会议原意的一句话，可以写成：
+
+> **MCU 路线主要走静态编排、工具链与芯片协同，SoC / 边侧路线主要走 Linux + RTOS + Hypervisor + 升级版 Hybrid 的系统协同，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
@@ -0,0 +1,321 @@
+# 垂直大模型训练框架与代训服务
+
+## 1. 主题定位
+
+这一部分讨论的不是“再训练一个行业版通用模型”这么简单，而是一套更完整的方法论：如何理解垂直大模型训练，为什么“通用模型 + 行业语料”不足以形成真正的垂直能力，以及为什么围绕这一方法论形成的代训服务在产业上是成立的。
+
+这条线本质上站在 AI 上层任务语义、业务结构和训练目标设计这一侧，和基础系统、边缘部署、智能体应用构成上下游关系。它回答的是：
+
+> **行业模型为什么不是简单加语料，而是一整套角色、目标、制度、流程和边界的结构化重建。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 垂直大模型不等于“通用模型 + 行业语料”
+
+会议明确反对把垂直模型简化为：
+
+`垂直大模型 = 通用大模型 + 行业语料`
+
+原因在于，业务差异并不只是语言风格差异，而是更深层的结构差异，包括：
+
+- 角色不同；
+- 目标函数不同；
+- 制度约束不同；
+- 动作空间不同；
+- 工作流不同；
+- 升级与分流机制不同；
+- 业务边界与处理边界不同。
+
+### 2.2 真正决定垂直模型表现的是结构，而不是数据量本身
+
+如果训练目标没有定义清楚，即便不断增加行业语料，也往往只能得到“更像行业说话方式”的模型，而得不到真正能在行业流程里工作的模型。
+
+因此，关键不只是准备更多数据，而是把业务结构编码进训练与后训练过程。
+
+### 2.3 “七要素框架”是会议中最有价值的方法学沉淀
+
+会议中已经形成了一个比较稳定的“七要素”思路：
+
+1. 主体角色；
+2. 目标函数；
+3. 领域知识；
+4. 制度约束；
+5. 动作空间；
+6. 工作流；
+7. 业务边界与处理边界。
+
+这个框架的价值在于，它把“垂直化”从模糊概念变成了可拆解、可设计、可复核的方法问题。
+
+### 2.4 代训服务之所以成立，是因为客户往往缺的不是算力，而是结构化建模能力
+
+很多企业并不具备以下能力：
+
+- 定义训练目标；
+- 识别主体角色；
+- 拆分制度约束；
+- 组织工作流；
+- 设计动作空间；
+- 区分模型边界与人工边界。
+
+因此，代训服务的真实价值不只是“帮客户训练模型”，而是帮助客户完成一轮业务结构显化与训练目标重构。
+
+### 2.5 这条线本身可以沉淀为独立的方法与服务体系
+
+如果把这一套能力做扎实，它不只是某次项目中的附属服务，而可以形成：
+
+- 方法论材料；
+- 咨询服务；
+- 联合研发流程；
+- 训练与后训练工具链；
+- 行业模型开发手册。
+
+## 3. 这条线真正要做的事情
+
+从会议内容看，这条线真正要建设的，不是单一训练流程，而是一套“三层能力”。
+
+### 3.1 业务结构抽象能力
+
+先把客户的业务系统抽象成：
+
+- 谁在工作；
+- 为了什么工作；
+- 在什么制度约束下工作；
+- 有哪些动作空间；
+- 哪些流程是固定的；
+- 哪些决策需要模型参与；
+- 哪些边界必须保留给人。
+
+### 3.2 训练与后训练设计能力
+
+在业务结构清楚之后，再组织：
+
+- 数据准备；
+- 监督微调；
+- 偏好对齐；
+- 工作流约束注入；
+- 工具调用结构；
+- 边界与拒答策略。
+
+### 3.3 交付与服务能力
+
+最终落到客户侧，需要输出的不只是模型本身，还包括：
+
+- 业务结构说明；
+- 训练目标说明；
+- 数据与流程边界说明；
+- 部署建议；
+- 持续优化计划。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“先结构化建模，再训练设计，再联合迭代”的工作方式。
+
+### 4.1 先做业务结构访谈，不急于进训练
+
+第一步不是立刻收数据、开始训，而是先做业务和任务建模。  
+需要先回答：
+
+- 这个行业里谁是主角色；
+- 模型服务的主任务是什么；
+- 业务里的目标函数是什么；
+- 制度和规则约束是什么；
+- 哪些地方允许模型生成，哪些地方必须人工把关。
+
+### 4.2 再做训练框架设计
+
+当业务结构明晰后，再确定：
+
+- 数据如何组织；
+- 训练样本如何标注；
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练或工作流获得；
+- 哪些边界不应交给模型。
+
+### 4.3 最后用联合迭代替代“一次性交付”
+
+会议隐含的判断是，垂直模型不会一次训练就稳定成型，更适合：
+
+- 小步迭代；
+- 领域专家反馈；
+- 规则修正；
+- 数据回流；
+- 后训练与工作流联调。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：完成业务结构建模
+
+这一阶段应完成：
+
+- 角色梳理；
+- 目标函数梳理；
+- 制度与规则梳理；
+- 工作流和动作空间梳理；
+- 业务边界和模型边界划分。
+
+这一阶段的产物应当是：
+
+- 结构化访谈纪要；
+- 业务框架图；
+- 七要素分析表。
+
+### 5.2 第二步：形成训练与后训练设计稿
+
+这一阶段应完成：
+
+- 数据来源清单；
+- 训练样本设计；
+- 后训练目标设计；
+- 工作流与工具调用关系设计；
+- 安全边界与人工介入点设计。
+
+这一阶段的产物应当是：
+
+- 训练设计稿；
+- 后训练流程稿；
+- 数据治理与边界说明。
+
+### 5.3 第三步：组织小规模联合试训
+
+这一阶段不追求一步到位，而应聚焦少量高价值任务。  
+应完成：
+
+- 小样本试训；
+- 关键任务验证；
+- 失败案例分析；
+- 人工反馈回流；
+- 规则与工作流调整。
+
+### 5.4 第四步：形成代训服务包
+
+当试训稳定之后，再将其沉淀为更稳定的服务形态，包括：
+
+- 咨询服务包；
+- 数据与训练准备包；
+- 联合试训包；
+- 交付和持续优化包。
+
+## 6. 各方责任与分工方式
+
+这条线最怕“只有技术团队在训，没人定义业务”，因此责任划分必须非常清楚。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外需求沟通；
+- 业务问题转译；
+- 行业合作推进；
+- 服务包设计；
+- 对外汇报和合作节奏组织。
+
+唐老师团队更适合站在“业务和合作牵引”的位置。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 七要素方法论抽象；
+- 垂直模型问题定义；
+- 训练目标与边界设计把关；
+- 从个案中提炼共性框架。
+
+罗老师团队更适合站在“方法论和结构建模”的位置。
+
+### 6.3 训练与工程团队
+
+适合承担：
+
+- 数据处理；
+- 训练与后训练实现；
+- 评测与失败样例分析；
+- 工具调用和工作流联调；
+- 交付部署支持。
+
+这一角色负责把方法落到真实模型流程上。
+
+### 6.4 行业客户或业务合作方
+
+适合承担：
+
+- 提供真实业务流程和语料；
+- 明确角色、规则和边界；
+- 参与效果验收；
+- 对失败样例和业务偏差给出反馈。
+
+客户方不负责训练方法设计，但必须负责业务真实性和边界清晰度。
+
+## 7. 工作边界
+
+### 7.1 这条线不等于“做行业语料堆叠”
+
+如果只是追加语料而不重构角色、目标和工作流，就不构成真正的垂直模型训练框架。
+
+### 7.2 这条线不等于“代替客户完成全部业务数字化”
+
+代训服务可以帮助客户显化结构，但不应承担全部业务改造工作。
+
+### 7.3 训练、后训练、智能体工作流必须区分
+
+后续材料中要明确区分：
+
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练获得；
+- 哪些能力靠工作流、工具和规则系统获得。
+
+### 7.4 这条线不直接替代基础系统研究
+
+它补充的是 AI 任务语义、行业目标和训练结构层，但不替代 RTOS、基础系统和部署层研究。
+
+## 8. 合作推进方式
+
+这条线适合采用“咨询先行、试训跟进、服务沉淀”的推进方式。
+
+### 8.1 第一阶段：方法咨询与结构建模
+
+重点是：
+
+- 业务访谈；
+- 七要素建模；
+- 训练边界和工作流边界定义；
+- 确定适不适合做垂直模型。
+
+### 8.2 第二阶段：联合试训与验证
+
+重点是：
+
+- 选择少量高价值任务；
+- 做小规模试训；
+- 验证训练、后训练和工作流哪个更有效；
+- 形成失败案例和调整机制。
+
+### 8.3 第三阶段：形成代训服务与长期合作
+
+重点是：
+
+- 输出服务包；
+- 形成长期优化机制；
+- 必要时推进工具链和标准化材料。
+
+## 9. 与整体研究主线的关系
+
+这一主题虽然看上去更偏大模型产业化，但它和整体研究并不冲突，反而补足了上层语义与任务定义层。
+
+它的价值主要体现在：
+
+- 补充 AI 目标负载的任务语义与业务边界；
+- 说明系统表现并不只由 OS 决定，训练目标和模型结构同样重要；
+- 可以与行业样例、边缘部署、小型化系统和智能体应用形成上下游关系。
+
+## 10. 当前结论
+
+这条线真正值得保留的，不是“代训”这个商业词本身，而是它背后的方法学判断：
+
+> **垂直大模型的核心不是在通用模型上附加行业语料，而是把角色、目标、制度、动作空间、工作流和边界结构编码进训练与后训练过程。**
+
+如果继续向前推进，它最可能沉淀成两类成果：
+
+- 一类是垂直模型方法论和训练框架；
+- 一类是围绕这一方法论建立起来的咨询、试训和代训服务体系。
@@ -0,0 +1,330 @@
+# 法律政务数据治理智能体与XAPP平台
+
+## 1. 主题定位
+
+这一部分主要来自会议后半段的延伸讨论，内容已经明显脱离 RTOS 研究本身，转向法律、纪委办案、数据治理智能体和平台化产品形态。它是一条非常独立的产品与应用主题，但又和前面几个主题形成上下游关系：上接大模型方法与训练问题，下接具体行业系统和交付方式。
+
+这条线真正关心的，不是“做一个能聊天的法律助手”，而是：
+
+> **如何把复杂的数据治理、关系发现、证据组织和报告生成过程，封装成面向专业人员可直接使用的业务系统。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 政务与法律场景的核心问题不是对话，而是复杂数据治理
+
+会议中提到的多个场景，本质上都在解决同一类问题：
+
+- 多来源、多格式、多模态资料导入困难；
+- 原始数据需要清洗、映射、关联、解释和展示；
+- 用户不愿意直接操作复杂数据分析工具；
+- 用户真正需要的是问题理解、关系发现、证据组织和报告生成。
+
+因此，这一主题的主线不是“做一个聊天机器人”，而是“把复杂数据治理过程封装成可操作的业务系统”。
+
+### 2.2 专业应用不能被压扁成单一聊天窗口
+
+会议对纯对话式工作台给出了明确修正：
+
+- 重交互业务不能只靠聊天界面承载；
+- 上传物、工作流、结果区、图谱区和报告区都需要独立存在；
+- 专业应用必须保留自己的界面和流程结构。
+
+这意味着平台设计必须尊重业务 UI，而不是试图把一切都压成一个对话框。
+
+### 2.3 法律和政务场景更适合“专业应用 + 平台壳”的结构
+
+会议里出现的多个场景都说明：
+
+- 纪委办案系统需要强数据治理能力；
+- 律师产品需要强访谈、证据和报告能力；
+- 脱敏工具需要独立的安全工具形态；
+- 不同应用之间可以共享工作台和通用能力，但不应失去各自的业务结构。
+
+这就是 `XAPP` 思路出现的原因。
+
+### 2.4 平台价值和应用价值必须分开定义
+
+平台的价值在于：
+
+- 提供统一工作台；
+- 提供账号、路由、权限、文件管理、日志和通用模型能力；
+- 提供应用接入框架。
+
+应用的价值在于：
+
+- 行业模型；
+- 规则系统；
+- 数据治理逻辑；
+- 具体业务流程与交付物。
+
+如果平台和应用不分，结果往往是平台过空，应用过散。
+
+### 2.5 本地部署和数据安全是这条线的刚性约束
+
+无论是纪委办案还是法律业务，会议都明确指出：
+
+- 数据安全要求高；
+- 现场部署需求强；
+- 响应稳定性要求高；
+- 数据不能随意外流。
+
+因此，这条线天然更适合本地部署或专有环境部署。
+
+## 3. 会议中浮现出的几类产品
+
+### 3.1 纪委办案数据治理智能体
+
+这一方向主要面向：
+
+- 银行流水；
+- 通话记录；
+- 出行数据；
+- 房产信息；
+- 保险与其他多源资料。
+
+它的核心不是“自动办案”，而是：
+
+- 导入；
+- 清洗；
+- 模板映射；
+- 关系发现；
+- 分析辅助；
+- 报告与材料组织。
+
+### 3.2 律师场景产品
+
+会议中提到的律师方向主要包括：
+
+- 婚家咨询访谈整理；
+- 证据组织与关系发现；
+- 资金分析；
+- 脱敏工具。
+
+这一方向说明，法律行业更适合“专业工具 + 专业流程”，而不是通用助手叙事。
+
+### 3.3 XAPP 平台
+
+会议中提出的 `XAPP` 平台思路非常关键。  
+它的含义不是再造一个“总助手”，而是：
+
+- 共享统一工作台；
+- 每个应用保留独立 UI；
+- 应用之间共享登录、权限、文件、模型和路由；
+- 复杂业务仍然通过界面、表格、流程和产物区组织。
+
+这实际上是对“纯聊天平台”路线的一次重要修正。
+
+## 4. 这条线真正要做的事情
+
+如果把会议内容收束，这条线真正要建设的是“三层产品能力”。
+
+### 4.1 数据治理底层能力
+
+包括：
+
+- 多源数据导入；
+- 模板识别与字段映射；
+- 清洗与标准化；
+- 关系抽取与图谱组织；
+- 检索与追踪。
+
+### 4.2 行业应用能力
+
+包括：
+
+- 办案智能体；
+- 律师访谈和报告产品；
+- 脱敏工具；
+- 关系分析和证据整理工具。
+
+### 4.3 XAPP 平台能力
+
+包括：
+
+- 统一工作台；
+- 应用路由；
+- 权限与账号系统；
+- 文件与任务管理；
+- 共用模型和公共能力接入。
+
+## 5. 建议的工作方式
+
+这条线更适合采用“先单应用打透，再平台化抽象”的工作方式，而不是一开始就先做大平台。
+
+### 5.1 先用具体高价值场景验证价值
+
+应优先选择最痛、最清楚、最容易形成产物的场景，例如：
+
+- 纪委办案数据治理；
+- 婚家咨询整理与报告；
+- 脱敏处理工具。
+
+先让单点应用把价值打透。
+
+### 5.2 再抽象可复用的中间层
+
+当单点应用稳定之后，再把其中共性能力抽出来，例如：
+
+- 数据导入；
+- 模板映射；
+- 关系图谱；
+- 报告生成；
+- 权限与日志管理。
+
+### 5.3 最后再形成 XAPP 平台壳
+
+只有在多个应用共享同一组共性能力之后，再做平台化抽象，才不会做成空平台。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：选择 1 到 2 个高价值场景做应用原型
+
+这一阶段应完成：
+
+- 选定业务场景；
+- 梳理数据来源；
+- 梳理用户任务；
+- 梳理需要生成的产物；
+- 明确本地部署和安全要求。
+
+### 6.2 第二步：打通数据治理链路
+
+这一阶段应完成：
+
+- 数据导入；
+- 模板映射；
+- 清洗与标准化；
+- 关系发现；
+- 初步报告生成。
+
+### 6.3 第三步：形成应用级交付
+
+这一阶段应完成：
+
+- 独立 UI；
+- 工作流组织；
+- 上传区、处理中间区、结果区和报告区；
+- 用户可操作的专业化界面。
+
+### 6.4 第四步：抽取平台共性能力
+
+当两个以上应用出现后，再抽取：
+
+- 登录权限；
+- 文件和任务管理；
+- 通用模型调用；
+- 公共组件；
+- 应用接入标准。
+
+## 7. 各方责任与分工方式
+
+这条线如果要落地，必须明确“谁负责场景、谁负责系统、谁负责方法、谁负责交付”。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 行业需求获取与场景梳理；
+- 客户沟通；
+- 交付方案组织；
+- 产品方向和合作节奏把控；
+- 对外汇报与合作推进。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 方法论抽象；
+- 数据治理逻辑与共性框架判断；
+- 平台层与应用层边界把关；
+- 从个案产品中提炼通用结构。
+
+### 7.3 产品与工程团队
+
+适合承担：
+
+- 数据治理链路实现；
+- 应用 UI 与工作流实现；
+- 报告和图谱模块；
+- 平台共性能力抽取；
+- 本地部署与安全实现。
+
+### 7.4 行业合作方或客户方
+
+适合承担：
+
+- 提供真实业务数据与使用流程；
+- 明确合规和安全要求；
+- 参与验收；
+- 对应用效果与流程合理性给出反馈。
+
+## 8. 工作边界
+
+### 8.1 这条线不等于“做个法律聊天机器人”
+
+如果把重点放在聊天入口，而不解决数据治理、图谱、报告和流程问题，这条线就会失焦。
+
+### 8.2 平台不应先于应用存在
+
+没有稳定的应用需求支撑，先做平台很容易变成空壳工程。
+
+### 8.3 专业应用必须保留独立 UI 和工作流
+
+不应把纪委、律师、脱敏工具都压成同一种对话式界面。
+
+### 8.4 这条线不直接纳入 RTOS 主课题
+
+它是独立的应用和产品方向材料，适合作为并行线保留，而不是强行并入基础系统主研究。
+
+## 9. 合作推进方式
+
+这条线适合采用“单应用切入、共性能力抽取、平台化收口”的推进方式。
+
+### 9.1 第一阶段：应用验证
+
+重点是：
+
+- 选具体场景；
+- 做原型；
+- 证明价值；
+- 形成第一批产物。
+
+### 9.2 第二阶段：应用扩展与复用
+
+重点是：
+
+- 增加第二类应用；
+- 比较共性与差异；
+- 抽取中间层能力；
+- 形成通用模块。
+
+### 9.3 第三阶段：平台化与持续合作
+
+重点是：
+
+- 建立 XAPP 平台结构；
+- 定义应用接入标准；
+- 形成长期合作和产品化路线。
+
+## 10. 与整体研究材料的关系
+
+这一主题虽然不直接属于 RTOS 主线，但对整体项目仍然有两类价值：
+
+- 它说明 AI 应用进入真实行业以后，对数据治理、平台结构、UI 组织和本地部署的要求会非常具体；
+- 它可以作为后续讨论“平台层”“XAPP 层”“工作流层”和“专业应用层”的现实参照。
+
+因此，它不应被强行塞进 RTOS 课题，但值得作为独立并行材料长期保留。
+
+## 11. 当前结论
+
+这条线真正值得保留的，不是若干零散行业点子，而是一条更稳定的产品判断：
+
+> **法律政务类智能体的核心，不是对话入口，而是把复杂数据治理、关系分析、业务流程和报告产出封装成专业应用，并在多个应用之上抽象出 XAPP 平台能力。**
+
+如果继续往前推进，这条线最自然的演化方式是：
+
+- 先做高价值行业应用；
+- 再抽取共性数据治理能力；
+- 最后收口到平台和应用协同的产品结构。
@@ -56,6 +56,8 @@
 - `T2` 桌面 / 工作站单机
 - `T1` 服务器 / 集群

+其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
+
 这套验证矩阵支撑以下四类判断：

 - RTOS 优势在哪些部署形态下最明显；
@@ -63,6 +65,8 @@
 - 为维持实时保障需要付出多少吞吐和能耗代价；
 - 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。

+这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
+
 ### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链

 项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
@@ -86,6 +90,8 @@
 - 任务关键系统；
 - 人工智能目标负载。

+其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
+
 ### 2. 评价重点

 项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
@@ -105,6 +111,10 @@

 因此，项目重点落在系统机制、调度策略和资源治理能力上。

+对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
+
+因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
+
 ### 4. 成果形态

 项目成果需要形成完整的方法与证据体系，包括：
@@ -115,12 +125,14 @@
 - 跨部署形态可比较的规律；
 - 能被学术界和产业界共同理解的结论。

+在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
+
 ## 这个项目最后要交付什么

 项目最终交付物至少应包括：

 1. 一套面向任务关键系统的 SylixOS 实时保障机制；
-2. 一组覆盖 `T5~T1` 五类部署形态的实测数据和对照结果；
+2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
 3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
 4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
 5. 一套可用于产业沟通和产品表达的技术叙事。
@@ -14,6 +14,8 @@

 本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。

+在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，RTOS 对人工智能目标负载与关键保障负载双目标达标能力的支撑边界。
+
 ---

 ## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
@@ -28,10 +30,12 @@
 | T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
 | T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
 | T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
-| T1 服务器 / 集群 | 多节点大模型服务与分布式协同平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式调度与规模扩展 |
+| T1 服务器 / 集群 | 面向任务关键场景的分布式协同计算平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式协同与规模扩展 |

 这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。

+其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
+
 ### 1.2 五种算力基础

 | 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
@@ -77,7 +81,7 @@
 │ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制           │
 ├───────────────────────────────────────────────────────────────┤
 │ L1 硬件与互联层                                                 │
-│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联        │
+│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联、PTP   │
 └───────────────────────────────────────────────────────────────┘
 ```

@@ -113,6 +117,11 @@ FFN / 设备计算              → 可流水化计算任务
 - 哪些资源需要隔离；
 - 哪些竞争会直接破坏关键保障负载。

+这里还要明确区分两类执行单元：
+
+- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
+- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
+
 ---

 ## 3. 研究主线：实时保障机制
@@ -134,7 +143,28 @@ FFN / 设备计算              → 可流水化计算任务

 > **RTOS 能否在多类目标负载并存时，让系统继续有边界。**

-### 3.1 研究方法总述
+### 3.1 面向小型化与低功耗方向的应用副课题
+
+在六个机制方向之外，项目设置一条面向应用落点的专题线：
+
+> **面向小型化与低功耗方向的应用副课题。**
+
+这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
+
+1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
+2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
+3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
+4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
+
+这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
+
+- 小型化与低功耗系统是否仍能承载人工智能目标负载；
+- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
+- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
+
+因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
+
+### 3.2 研究方法总述

 为了回答这个问题，研究方法采用一条统一证据链：

@@ -147,6 +177,8 @@ FFN / 设备计算              → 可流水化计算任务

 因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。

+这套统一框架统一的是研究对象定义、负载建模、评估指标与对照方法，不预设同一套机制会在所有档位取得同等收益。研究结论将以有效区间、失效边界和贡献来源的形式展开。
+
 ---

 ## 4. 评价框架：双目标达标 + 系统协同稳定
@@ -239,10 +271,12 @@ FFN / 设备计算              → 可流水化计算任务
 ## 8. 预期研究成果

 1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
-2. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
-3. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
-4. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位实测对照数据；
-5. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
+2. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
+3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
+4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
+5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
+6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
+7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。

 ---

@@ -59,6 +59,15 @@
 硬件承担关键验证矩阵角色。
 `T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。

+这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
+
+对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
+
+- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
+- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
+
+前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
+
 ## 3. 负载建模：三类负载

 ### 3.1 三类负载定义
@@ -137,6 +146,8 @@

 任何准入失败都要作为研究记录保留。

+对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
+
 ## 6. 对照原则

 ### 6.1 固定不变项
@@ -146,6 +157,7 @@
 - 模型版本、量化格式、tokenizer、输入长度与输出长度；
 - CPU 核数量、优先级、内存预算、加速器数量；
 - 到达流、随机种子、预热时间、采样窗口；
+- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
 - 环境温度、散热、驱动与框架版本。

 ### 6.2 允许变化项
@@ -161,7 +173,7 @@

 ## 7. 建模与分析方法

-### 7.1 调度分析
+### 7.1 可调度性与响应时间分析

 关键保障负载优先使用固定优先级与响应时间分析：

@@ -183,6 +195,8 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
 - 可隔离的设备任务；
 - 必要时具有阶段性优先级的任务图。

+当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
+
 ### 7.2 容量与热稳定性分析

 对人工智能目标负载，需要同时分析：
@@ -217,6 +231,7 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
 | 性能分析 | perf、设备 profiler、定制采样脚本 |
 | 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
 | 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
+| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |

 下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：

@@ -273,6 +288,7 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j

 1. **怎么保证研究对象始终落在 RTOS 平台层；**
 2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
-3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据。**
+3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
+4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**

 这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
@@ -0,0 +1,57 @@
+# 研究框架索引
+
+本目录放置项目的核心研究框架文档，分为两部分：
+
+1. **主干机制文档**：作为公共研究材料，沉淀已经形成的主线表达、机制拆解与方法论；
+2. **候选课题框架目录**：并行维护 3 套可讨论、可修改、可优选的课题框架方案。
+
+## 阅读建议
+
+### 1. 主干机制文档
+
+1. `00-整体研究框架.md`
+2. `01-推理图任务调度.md`
+3. `02-KV-Cache与内存管理.md`
+4. `03-加速器协同调度.md`
+5. `04-量化精度感知调度.md`
+6. `05-中断与实时性保障.md`
+7. `06-能耗与热管理.md`
+8. `07-方法论与评估工具链.md`
+
+### 2. 候选课题框架目录
+
+1. `方案A-RTOS平台主导框架/00-课题框架.md`
+2. `方案B-系统协同保障框架/00-课题框架.md`
+3. `方案C-小型化与低功耗应用框架/00-课题框架.md`
+
+## 文件说明
+
+- `00-整体研究框架.md`
+  - 研究总框架、问题空间、技术分层、预期成果
+- `01-推理图任务调度.md`
+  - LLM 推理 DAG 拆解、任务映射与调度策略
+- `02-KV-Cache与内存管理.md`
+  - KV Cache 生命周期、内存池、带宽竞争与局部性
+- `03-加速器协同调度.md`
+  - CPU、NPU、GPU、DMA 等异构资源协同
+- `04-量化精度感知调度.md`
+  - 精度、资源占用和调度决策的联动关系
+- `05-中断与实时性保障.md`
+  - IRQ 路径、线程化、中断隔离与实时任务保护
+- `06-能耗与热管理.md`
+  - 能耗约束、温度耦合、频率策略与热稳定性
+- `07-方法论与评估工具链.md`
+  - 建模、仿真、原型验证和评估方法学
+
+## 候选框架说明
+
+- `方案A-RTOS平台主导框架`
+  - 保持“大型跨平台 RTOS”作为研究主语，适合继续沿现有主线推进
+- `方案B-系统协同保障框架`
+  - 强调 RTOS、运行时、模型与加速器协同治理，适合承接系统级方法学讨论
+- `方案C-小型化与低功耗应用框架`
+  - 强调 `T5/T4` 受限系统与低功耗应用场景，适合形成更聚焦的专题路线
+
+## 使用方式
+
+后续讨论、修改和优选时，可以优先在这 3 个候选目录中推进，不必立即改动主干机制文档。待最终课题框架确定后，再把优选结果回收进 `00-整体研究框架.md` 及相关主干文件。
@@ -36,6 +36,8 @@
 - **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
 - **硬件角色**：验证矩阵。

+在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
+
 ## 3. T5~T1 五类部署形态与 11 个代表档位

 硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
@@ -57,6 +59,8 @@
 `T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
 `T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。

+其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
+
 ## 4. 人工智能目标负载与系统负载结构

 在任务关键系统里，负载应至少分成三类：
@@ -112,6 +116,8 @@

 这条顺序用于区分平台就绪性问题与系统机制边界问题。

+对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
+
 ## 8. 哪些指标构成核心证据

 后续证据链必须覆盖三层：
@@ -155,6 +161,8 @@

 在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。

+面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
+
 ## 10. 最终闭环

 本研究形成的核心结论关系是：
@@ -3,6 +3,7 @@
 > 版本: v2.1    起草日期: 2026-09-21
 > 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
 > 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
+> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位

 ---

@@ -16,6 +16,10 @@

 执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。

+这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
+
+在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
+
 ## 2. 设备分层与实验平台

 ### 2.1 T5~T1 五类部署形态、十一档实验映射
@@ -33,12 +37,35 @@
 | T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
 | T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
 | T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
-| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信与分布式推理 |
-| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式服务与能效 |
+| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
+| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |

 GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。

-### 2.2 测量设备
+`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
+
+其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
+
+### 2.2 平台 A：现有 V100 服务器
+
+依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
+
+实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
+
+分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
+
+### 2.3 平台 B：现有 RK3588 工业盒
+
+依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
+
+- B16：全量 16 GB，记为 T4-L。
+- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
+- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
+- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
+
+**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
+
+### 2.4 测量设备

 | 测量对象 | 工具与接线 | 要求 |
 |---|---|---|
@@ -66,6 +93,8 @@ SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在

 “SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。

+对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
+
 ### 3.2 模型梯度与用途

 | 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
@@ -183,6 +212,14 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
 | E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
 | E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |

+面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
+
+- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
+- `E3` 负责比较双目标并存时的达标边界；
+- `E4` 负责观察内存限额与容量失败边界；
+- `E6` 负责组织功耗、温度与降频证据；
+- `E8` 负责验证长时间运行、恢复与热稳定性。
+
 E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。

 E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
@@ -199,6 +236,8 @@ E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳

 T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。

+若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
+
 跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。

 ### 7.3 控制实验数量
@@ -11,14 +11,14 @@

 ### 0.1 一句话定位

-> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。**
+> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**

 ### 0.2 三大核心贡献

 | 编号 | 贡献 | 来源整合 | 对标空白 |
 |------|------|----------|----------|
 | C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
-| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
+| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
 | C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |

 ### 0.3 目标读者与发表场景
@@ -38,7 +38,7 @@
 第1章  引言 — 问题、动机、贡献概述
 第2章  背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
 第3章  T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
-第4章  SylixOS 调度框架技术架构 — 五层技术栈与六大优化方向
+第4章  SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
 第5章  实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
 第6章  大模型负载选型与配置 — 跨档位模型矩阵
 第7章  实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
@@ -97,7 +97,7 @@
 | 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
 | 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
 | 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
-| 3.5 各部署形态定位与验证重点 | T1 跨节点分布式调度；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
+| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |

 **关键图表**:

@@ -112,15 +112,16 @@

 ### 第4章 SylixOS 调度框架技术架构

-**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈和六大优化方向浓缩为文章的技术背景章。
+**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。

 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
 | 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
-| 4.2 五层技术栈 | L1 硬件层 → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
+| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
 | 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
 | 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
-| 4.5 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
+| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
+| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |

 **关键图表**:

@@ -129,7 +130,7 @@
 | Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
 | Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
 | Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
-| Tab.6 | 六大优化方向概览 | 方向 × (核心问题/关键手段/目标指标/对应章节) |
+| Tab.6 | 六大优化方向与低功耗专题线概览 | 方向/专题 × (核心问题/关键手段/目标指标/对应章节) |

 ---

@@ -139,13 +140,15 @@

 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
-| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
+| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
 | 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
 | 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
 | 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
 | 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
 | 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
 | 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
+| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
+| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
 | 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
 | 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |

@@ -194,7 +197,7 @@
 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
 | 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
-| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
+| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
 | 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
 | 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
 | 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
@@ -265,7 +268,7 @@

 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
-| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
+| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
 | 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
 | 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
 | 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
@@ -291,7 +294,7 @@
 | **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
 | **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
 | **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
-| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §8.3 (根因分析), §10.3 (开放问题) |
+| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
 | **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
 | **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
 | **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
@@ -7,9 +7,8 @@
 1. `01-研究逻辑说明.md`
 2. `02-基础设备与算力基础.md`
 3. `03-实验设计.md`
-4. `metric.md`
-5. `04-论文写作规划.md`
-6. `05-论文结构总览.png`
+4. `04-论文写作规划.md`
+5. `05-论文结构总览.png`

 ## 文件说明

@@ -19,8 +18,6 @@
  - T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
 - `03-实验设计.md`
  - 准入条件、对照原则、混合负载场景、指标与验收方法
- `metric.md`
-  - 三层核心证据指标的统一定义、计算公式、采集要求与报告口径
 - `04-论文写作规划.md`
  - 论文结构、章节分工、图表规划和证据映射
 - `05-论文结构总览.png`
@@ -166,6 +166,22 @@
 - 翼辉信息侧偏产业价值、案例与平台能力；
 - 项目组承担材料汇总、写作配合与整合支撑。

+### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
+
+目标：
+
+- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
+- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
+- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
+
+更适合的分工：
+
+- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
+- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
+- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
+
+这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
+
 ## 6. 更现实的推进顺序

 推进顺序以稳妥、小步、可验证为宜：
@@ -8,7 +8,7 @@

 第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。

-第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。
+第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。这一方向也可以继续向小型化、低功耗、资源受限系统中的智能应用展开，把嵌入式基础软件、可调度性分析与低功耗部署问题连接起来。

 罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。

@@ -0,0 +1,59 @@
+# 当前研究问题：背景、问题与挑战
+
+## 1. 背景
+
+人工智能能力正在从服务器、云端和通用应用软件，持续进入设备控制、边缘协同、车载平台、工业终端和任务关键系统。系统中的人工智能不再只是离线分析能力，而正在承担识别、规划、诊断、导航、辅助决策和自然交互等面向实时场景的功能。
+
+当人工智能能力进入这些系统后，系统的时间结构发生了明显变化：
+
+- 感知链路、推理链路与控制链路开始耦合；
+- CPU、NPU、GPU、DMA、总线和内存带宽竞争明显增强；
+- 功耗、散热、体积、统一内存和设备驱动限制直接影响系统行为；
+- 关键保障负载与人工智能目标负载开始争夺同一组底层资源。
+
+因此，系统面对的已经不是单纯的“把模型跑起来”问题，而是“如何让人工智能能力进入系统之后，整体时序边界仍然成立”的问题。
+
+## 2. 问题
+
+本框架聚焦的问题是：
+
+> **当人工智能能力进入实时控制系统后，模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存和协处理器如何共同决定系统的整体实时边界。**
+
+这里的核心观察有三点：
+
+1. **大模型与智能算法的实时问题不能完全归于 RTOS 单独解决。**
+2. **纯粹把问题写成“RTOS 优于 Linux”已经不足以覆盖真实系统问题。**
+3. **真正需要研究的是面向 AI 的实时控制基础系统，而不是单一软件层。**
+
+## 3. 挑战
+
+### 3.1 跨层因果交织
+
+人工智能目标负载的时间行为同时受到模型结构、量化方式、算子实现、运行时队列、驱动、芯片资源和操作系统机制影响。单一层面的解释无法完整说明系统实时性。
+
+### 3.2 感知与控制形成闭环
+
+一旦感知、规划、语音理解或推理链路进入控制闭环，推理延迟、链路抖动和异常输出都会直接影响执行效果，系统面对的是认知与控制的一体化问题。
+
+### 3.3 MCU 与 SoC 路线差异显著
+
+MCU 场景更偏向静态资源分配、工具链和芯片协同；SoC 场景更偏向 Linux / RTOS / Hypervisor 协同、统一内存竞争治理和异构设备协作。这两类问题不能被同一套表达简单覆盖。
+
+### 3.4 体系结构成为主要变量
+
+随着 NPU、GPU、DMA、统一内存、总线和缓存结构进入主舞台，问题已经从调度器、中断和线程同步扩展到嵌入式计算机体系结构层。
+
+### 3.5 产业叙事需要升级
+
+如果企业仍然只把自己定义为 RTOS 供应方，就很难完整解释人工智能进入实时控制系统后出现的新问题。更有延展性的定位应当围绕“基础系统”展开。
+
+## 4. 本框架的价值
+
+本框架的目标不是否定 RTOS，而是把 RTOS 放回更准确的位置：
+
+- RTOS 是关键保障负载的确定性底座；
+- Linux 与推理运行时承载 AI 生态与计算任务；
+- Hypervisor、芯片与资源治理结构承担隔离、边界与整体秩序；
+- 规则层与兜底机制承担异常控制与安全边界。
+
+因此，本框架对应的研究价值在于：为“人工智能进入实时控制系统之后的基础系统问题”建立更准确的问题定义、技术路线和实验组织方式。
@@ -0,0 +1,80 @@
+# 研究定位与项目边界
+
+## 1. 研究定位
+
+本框架的研究定位是：
+
+> **面向人工智能能力进入实时控制系统后的整体系统问题，研究基础系统如何维持确定性、可预测性与实时边界。**
+
+这里的“基础系统”不是单一软件层，而是由以下部分共同构成：
+
+- 模型与任务语义；
+- 推理运行时与负载编排；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离；
+- 芯片、总线、内存、NPU、GPU、DMA 等硬件资源结构；
+- 规则兜底、安全约束与异常切换机制。
+
+## 2. 研究对象
+
+本框架的研究对象是：
+
+> **面向 AI 的实时控制基础系统。**
+
+其中：
+
+- `SylixOS` 仍然可以作为关键实验样例与基础软件样本；
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可继续作为参照平台；
+- `Linux` 与 `PREEMPT_RT Linux` 继续作为重要对照对象；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+## 3. 本框架不把什么当作研究主语
+
+### 3.1 不把硬件谱系当作研究主语
+
+`T5~T1` 五类部署形态和各类算力基础承担的是验证矩阵角色，用于组织证据、比较边界和解释场景差异。
+
+### 3.2 不把单一 RTOS 当作全部因果承担者
+
+RTOS 在本框架中承担关键作用，但不再被写成全部实时问题的唯一解决者。模型、运行时、芯片与资源结构同样影响系统边界。
+
+### 3.3 不把纯吞吐优化当作核心目标
+
+本框架关注的是人工智能目标负载、关键保障负载与系统协同三层指标同时成立的条件，而不是单一的吞吐最大化。
+
+## 4. 研究边界
+
+### 4.1 重点覆盖的系统类型
+
+- 控制端 MCU / 控制盒；
+- 设备端 SoC；
+- 边缘节点；
+- 面向任务关键场景的单机高密和集群协同平台。
+
+### 4.2 重点覆盖的问题
+
+- 关键保障负载与人工智能目标负载共存时的整体实时性；
+- Linux / RTOS / Hypervisor 的混合协同结构；
+- 统一内存、总线和异构协处理器竞争治理；
+- 小型化、低功耗和受限部署条件下的系统边界；
+- 模型推理与规则兜底共同构成的执行闭环。
+
+### 4.3 暂不作为主线的问题
+
+- 通用大模型训练集群的纯吞吐优化；
+- 面向互联网高并发服务的开放式推理平台；
+- 单纯以算法精度提升为主的模型研究；
+- 不涉及实时控制闭环的普通桌面 AI 应用。
+
+## 5. 与项目框架1的关系
+
+项目框架1把“大型跨平台 RTOS”作为研究主语，重点讨论 RTOS 在五类部署形态中的机制优势。
+
+项目框架2则把研究主语上移到“面向 AI 的实时控制基础系统”，重点讨论：
+
+- RTOS 在整个系统中的位置；
+- Linux、RTOS 与 Hypervisor 如何协同；
+- 模型推理、资源竞争与控制任务如何共同构成实时边界；
+- 企业与平台如何从 RTOS 供应方转向基础系统供应方。
+
+这两套框架可以并行维护，分别服务于不同层次的课题收敛。
@@ -0,0 +1,86 @@
+# 总课题与两个子课题的关系
+
+## 1. 决策记录
+
+在对 2026-09-22 会议内容、框架2当前结构和外部相关研究进行综合判断后，当前对框架2的组织方式做出如下决策：
+
+> **框架2继续保留为“面向 AI 的实时控制基础系统研究”这一总课题，不单独再分出框架3；但在框架2内部，明确提升为“一总课题 + 两个子课题 + 一个共享方法层”的结构。**
+
+这一决策的核心依据是：
+
+1. `MCU` 路线与 `边侧 SoC` 路线已经不是同一种技术问题；
+2. 但两条路线仍然服务于同一个更高层研究主语，即“面向 AI 的实时控制基础系统”；
+3. 三层边界、验证矩阵、评价框架和对照逻辑仍然具有共享性；
+4. 目录层级上如果不把两个子课题抬成一级目录，就会削弱其独立研究价值。
+
+## 2. 总课题是什么
+
+总课题回答的是：
+
+> **人工智能能力进入实时控制系统之后，基础系统如何维持系统的确定性、可预测性与整体实时边界。**
+
+这一层负责统一以下内容：
+
+- 研究主语；
+- 问题定义；
+- 三层边界；
+- 验证矩阵；
+- 对照方法；
+- 总体评价框架；
+- 总体论文和课题表达。
+
+## 3. 为什么需要两个子课题
+
+### 3.1 子课题 A：面向 MCU 的静态智能控制基础系统
+
+这一子课题主要回答：
+
+- 极小资源预算下，人工智能能力如何被静态、可分析地纳入控制系统；
+- 小模型、小算子、工具链、代码生成与芯片协同如何共同形成系统能力；
+- 低功耗、小型化与极小内存预算如何构成主边界。
+
+### 3.2 子课题 B：面向边侧 SoC 的混合实时控制基础系统
+
+这一子课题主要回答：
+
+- Linux、RTOS、Hypervisor 与 Hybrid 结构如何在同一 SoC 上协同；
+- 统一内存、总线、DMA、NPU/GPU 竞争如何被治理；
+- 控制链路、推理链路与规则兜底如何共同形成整体边界。
+
+## 4. 为什么不现在直接分出框架3
+
+当前不单独再分出框架3，主要基于三点考虑：
+
+1. **研究主语没有分裂**  
+   两个子课题仍然隶属于同一个总课题主语。
+2. **方法层高度共享**  
+   三层边界、验证矩阵和评价框架不需要重复建设。
+3. **当前阶段更适合内部分流，而不是外部分家**  
+   目前仍处于课题框架优选和收敛阶段，过早拆出框架3会增加主线分散的风险。
+
+## 5. 当前目录组织原则
+
+因此，框架2当前采用以下结构：
+
+- `00-总课题总览`
+- `10-共享理论与方法层`
+- `20-子课题A-面向MCU的静态智能控制基础系统`
+- `30-子课题B-面向边侧SoC的混合实时控制基础系统`
+- `40-综合比较与收敛`
+
+这种结构同时满足：
+
+- 总课题不散；
+- 子课题不被湮灭；
+- 后续可以继续长成独立课题；
+- 当前仍可维持统一的研究主线。
+
+## 6. 后续演化条件
+
+只有在以下条件进一步成立时，才考虑把子课题继续外扩为独立框架或独立申报方向：
+
+1. 两个子课题分别对应不同合作方、不同交付物和不同对外课题口径；
+2. 两个子课题形成了不再共享的方法层和评价体系；
+3. 论文、实验和合作推进已经自然分化为两套完整闭环。
+
+在此之前，框架2保持“一总两子”的结构是当前最稳的组织方式。
@@ -0,0 +1,238 @@
+# 面向AI的实时控制基础系统整体研究框架
+
+## 0. 核心问题
+
+本框架围绕“人工智能能力进入实时控制系统之后，基础系统如何维持整体实时边界”展开。核心判断是：
+
+> **当人工智能目标负载进入实时控制系统后，系统需要解决的已经不是单一操作系统问题，而是模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存、NPU、GPU、DMA 和规则兜底机制共同构成的整体实时性问题。`SylixOS` 可作为关键实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为参照平台。**
+
+这里有四个基础判断：
+
+1. **研究对象是面向 AI 的实时控制基础系统**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **RTOS 是关键底座，但不是全部因果的唯一承担者**；
+4. **硬件条件以验证矩阵形式组织研究证据。**
+
+本框架评估的是：当人工智能目标负载与关键保障负载共同进入系统时，基础系统如何维持控制路径、推理路径和资源路径的整体边界。
+
+---
+
+## 1. 问题空间：五类部署形态、三类系统负载与跨层实时性
+
+### 1.1 五类部署形态
+
+`T5~T1` 五类部署形态继续作为验证矩阵。
+
+| 部署形态 | 系统角色 | 主要研究关注点 |
+|---|---|---|
+| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存预算 |
+| T4 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS 协同、统一内存与带宽隔离 |
+| T3 边缘节点 | 近源推理与控制协同节点 | 多任务并发、热稳定性、边缘协同 |
+| T2 单机工作站 | 单机高密本地推理平台 | 多卡公平性、控制侧保护与资源协同 |
+| T1 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点协同、系统边界与规模扩展 |
+
+这些部署形态回答的是“在哪里验证”，而不是“什么是研究主语”。
+
+### 1.2 三类系统负载
+
+| 负载类型 | 定义 | 典型例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉识别、导航规划、故障诊断 |
+| 关键保障负载 | 维持安全与执行闭环的关键任务 | 周期控制、联锁、状态采集、执行输出 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、模型加载、通信、I/O |
+
+### 1.3 跨层实时性问题
+
+本框架中的“实时性”不再只指调度器和中断路径，而是至少同时涉及：
+
+- 模型与推理阶段时间行为；
+- 运行时与队列组织；
+- RTOS 的关键任务保障能力；
+- Linux 的生态与推理承载能力；
+- Hypervisor 的隔离与资源切分；
+- 总线、内存、DMA、NPU、GPU 等资源竞争结构；
+- 规则兜底与异常切换机制。
+
+---
+
+## 2. 分层边界：三层系统问题
+
+### 2.1 RTOS 直接控制域
+
+这一层是 RTOS 可以直接施加机制约束的部分，包括：
+
+- 关键任务调度；
+- 中断优先级与抢占关系；
+- CPU 侧线程、同步与时钟机制；
+- 恢复、隔离和关键路径治理。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 2.2 推理运行域
+
+这一层主要由模型、量化、算子、运行时和驱动共同决定，包括：
+
+- Prefill / Decode 时延结构；
+- 模型大小与量化精度；
+- KV Cache、内存组织与队列行为；
+- GPU/NPU 内部执行与框架调度。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为和资源行为。**
+
+### 2.3 系统协同域
+
+这一层是本框架的重点，包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、外存、统一内存与协处理器竞争治理；
+- 规则兜底、安全约束与异常切换；
+- 关键保障负载与人工智能目标负载之间的优先级关系。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+---
+
+## 3. 两条主要技术路线
+
+### 3.1 MCU 路线：静态分配、工具链与芯片协同
+
+MCU 路线重点关注：
+
+- 小模型、小算子与控制任务的静态编排；
+- 工具链、代码生成与开发套件；
+- 与芯片厂商的协同设计；
+- 极小资源预算下的 AI 目标负载纳入方式。
+
+这条路线的关键词是：
+
+`静态分配`、`工具链`、`开发套件`、`芯片协同`
+
+### 3.2 SoC 路线：Hybrid、Hypervisor 与整体确定性
+
+SoC 路线重点关注：
+
+- Linux 侧推理与 RTOS 侧控制的分工；
+- Hybrid 结构从“并置”升级为“协同治理”；
+- Hypervisor 的隔离、分簇和资源切分；
+- 统一内存、总线、DMA、NPU/GPU 竞争治理；
+- 控制与 AI 在同一系统中的整体确定性。
+
+这条路线的关键词是：
+
+`Hybrid`、`Hypervisor`、`隔离`、`资源治理`、`系统确定性`
+
+---
+
+## 4. 统一技术体系：五层技术栈与横向治理线
+
+本框架继续保留五层技术栈表达，但其含义从“RTOS 机制展开”进一步上升为“基础系统展开”。
+
+```
+┌───────────────────────────────────────────────────────────────┐
+│ L5 模型与任务语义层                                            │
+│ 任务语义、模型结构、量化、输出约束、业务边界                    │
+├───────────────────────────────────────────────────────────────┤
+│ L4 运行时与负载编排层                                           │
+│ 队列、准入控制、内存池、流水线、推理框架、规则兜底接口          │
+├───────────────────────────────────────────────────────────────┤
+│ L3 资源抽象与系统协同层                                         │
+│ CPU/NPU/GPU/DMA/总线/统一内存抽象、Hypervisor、资源治理        │
+├───────────────────────────────────────────────────────────────┤
+│ L2 基础软件控制层                                               │
+│ RTOS、Linux、中断、调度、同步、恢复、隔离、关键路径保护         │
+├───────────────────────────────────────────────────────────────┤
+│ L1 硬件与互联层                                                 │
+│ MCU、SoC、加速器、缓存、总线、外存、网络互联、时钟源            │
+└───────────────────────────────────────────────────────────────┘
+```
+
+横向治理线包括：安全、审计、配置版本、日志证据、时间同步、可观测性、规则兜底、异常切换和 OTA / 回滚能力。
+
+---
+
+## 5. 研究主线：整体实时边界的建立与验证
+
+本框架后续所有子方向都服务于同一个主命题：
+
+> **面向 AI 的实时控制基础系统如何在人工智能目标负载进入控制闭环后，维持系统的确定性、可预测性与整体实时边界。**
+
+围绕这个主命题，研究主线可以组织为六个方向：
+
+1. **RTOS 直接控制域的保障机制**
+2. **人工智能目标负载的时间行为建模**
+3. **系统协同域的资源隔离与治理**
+4. **MCU 路线的静态编排与工具链能力**
+5. **SoC 路线的 Hybrid / Hypervisor 协同结构**
+6. **规则兜底、异常切换与闭环安全边界**
+
+这些方向共同服务于一个判断：
+
+> **人工智能能力进入实时控制系统后，系统是否仍然有边界，以及这个边界由哪些机制共同构成。**
+
+---
+
+## 6. 评价框架：三层指标同时成立
+
+### 6.1 人工智能目标负载指标
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 6.2 关键保障负载指标
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 6.3 系统协同指标
+
+- 有效吞吐
+- `E/token` / `tokens/J`
+- 温度、热漂移与降频行为
+- 资源隔离效果
+- 恢复能力与异常切换表现
+
+因此，本框架的成功标准是：
+
+> **人工智能目标负载、关键保障负载与系统协同三层指标同时成立。**
+
+---
+
+## 7. 对照关系：Linux、PREEMPT_RT、RTOS 与混合结构
+
+后续实验与叙事可采用四类对照：
+
+| 对照组 | 含义 | 作用 |
+|---|---|---|
+| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
+| `O1` PREEMPT_RT Linux | 实时增强型 Linux | 观察增强型通用 OS 的边界 |
+| `O2` RTOS 原生配置 | RTOS 基础路径 | 观察 RTOS 底座能力 |
+| `O3` 混合基础系统配置 | Linux + RTOS + Hypervisor 或协同结构 | 观察整体协同路径的收益与代价 |
+
+这条对照线的重点，不再只是比较“谁更快”，而是比较：
+
+- 谁更能维持关键保障负载边界；
+- 谁更能承受 AI 目标负载进入后的资源竞争；
+- 谁更能形成可解释、可复现、可治理的整体系统秩序。
+
+---
+
+## 8. 预期成果
+
+1. **问题定义层**：人工智能能力进入实时控制系统后的基础系统问题定义；
+2. **分析层**：RTOS 直接控制域、推理运行域与系统协同域的边界划分方法；
+3. **机制层**：面向 Hybrid / Hypervisor / 资源治理 / 规则兜底的基础系统机制；
+4. **方法层**：覆盖 `T5~T1` 的统一验证矩阵与对照方法；
+5. **产业层**：从 RTOS 平台叙事上升到基础系统叙事的合作与产品路线；
+6. **论文层**：面向实时系统、嵌入式系统和低功耗系统方向的系统化论文与报告。
@@ -0,0 +1,90 @@
+# RTOS直接控制域
+
+## 1. 主题定位
+
+在框架2中，RTOS 不再被写成全部系统问题的唯一承担者，但它仍然是关键保障负载确定性底座的核心组成部分。本文件用于明确：哪些问题属于 RTOS 可以直接控制和分析的范围，哪些问题不应继续归因到 RTOS 身上。
+
+## 2. 直接控制域的边界
+
+RTOS 直接控制域主要包括：
+
+- 周期任务、关键任务与后台任务的调度关系；
+- 中断优先级、抢占路径和线程化中断机制；
+- CPU 侧线程、同步互斥、时钟与定时器；
+- 内存锁定、关键缓冲区预分配与恢复机制；
+- 关键任务隔离、核心绑定和关键路径保护；
+- 对共享资源治理接口的直接约束能力。
+
+这一层回答的是：
+
+> **RTOS 如何在人工智能目标负载进入系统后，持续保护关键保障负载的时间边界。**
+
+## 3. 核心研究问题
+
+### 3.1 关键任务如何不被人工智能目标负载拖垮
+
+当人工智能目标负载与关键保障负载并存时，RTOS 的首要任务不是提高模型吞吐，而是确保：
+
+- 周期控制任务不失去截止期；
+- 中断链路不被模型加载、日志、I/O 和推理提交路径污染；
+- 恢复路径在异常条件下仍然可触发；
+- 控制输出始终保留优先权。
+
+### 3.2 哪些资源竞争能够由 RTOS 直接治理
+
+RTOS 可以直接治理的通常是：
+
+- CPU 时间分配；
+- 抢占关系；
+- 中断响应顺序；
+- 同步冲突；
+- 关键路径上的内核对象与内存使用方式。
+
+RTOS 不能单独决定的，则包括 GPU/NPU 内部算子执行、显存流水线、驱动内部队列与片上总线物理冲突。这些内容必须和系统协同域一起讨论。
+
+## 4. 关键机制
+
+### 4.1 调度与抢占
+
+关键保障负载应继续保持硬优先级或等价的刚性优先级结构。人工智能目标负载相关线程、提交路径和后台服务线程必须被限制在不会破坏关键任务的优先级层次中。
+
+### 4.2 中断与关键路径治理
+
+模型加载、设备中断、网络和存储路径都可能拉长关键路径。后续研究应重点观察：
+
+- 哪些中断必须线程化；
+- 哪些中断应固定到非关键核；
+- 哪些设备中断会污染关键任务核；
+- 推理提交和结果回收链路是否会引发优先级倒置。
+
+### 4.3 恢复与隔离
+
+当推理链路失稳、超时或内存耗尽时，RTOS 直接控制域需要承担：
+
+- 关键任务不受波及的隔离；
+- 降级模式触发；
+- 任务重启与恢复；
+- 对控制回路的兜底保持。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+- 恢复时间与异常切换开销
+
+这些指标构成 RTOS 直接控制域的主证据，不应和 GPU/NPU 内部执行指标混为一体。
+
+## 6. 与其他层的关系
+
+- 与 `推理运行域` 的关系：RTOS 负责保护关键路径，推理运行域负责描述 AI 目标负载本身的时间行为；
+- 与 `系统协同域` 的关系：RTOS 负责可直接治理的部分，系统协同域负责 Linux、Hypervisor 和异构资源共同造成的整体边界问题。
+
+## 7. 当前结论
+
+框架2并没有削弱 RTOS 的价值，而是把 RTOS 的价值说得更准确：
+
+> **RTOS 是关键保障负载的确定性底座，是人工智能进入实时控制系统后仍能维持秩序的直接控制层。**
@@ -0,0 +1,85 @@
+# 推理运行域
+
+## 1. 主题定位
+
+推理运行域用于解释人工智能目标负载本身的时间行为、资源行为和优化空间。框架2强调，大模型与智能算法的实时问题不能完全归因到 RTOS 身上，原因就在于推理运行域本身已经带有很强的结构性时间特征。
+
+## 2. 推理运行域包含什么
+
+这一层主要包括：
+
+- 模型结构与参数规模；
+- 量化方式与数值精度；
+- Prefill / Decode 两阶段时间特征；
+- KV Cache 生命周期与内存组织；
+- 推理框架队列、批处理与上下文管理；
+- 算子实现、驱动路径和设备执行接口。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、内存行为和资源竞争特征。**
+
+## 3. 为什么这一层不能被省略
+
+如果把所有实时性问题都写成 RTOS 问题，就会忽略以下事实：
+
+- 不同模型大小对内存和时延的影响完全不同；
+- 量化方式会显著改变推理峰值、稳定性和能效；
+- 同一硬件上，不同框架和不同算子组合会带来巨大差异；
+- Decode 阶段与 Prefill 阶段的时间结构并不相同；
+- 推理框架内部队列策略会直接影响首响应时间与尾延迟。
+
+因此，推理运行域必须被单独分析。
+
+## 4. 核心研究问题
+
+### 4.1 模型时间行为如何进入系统分析
+
+后续研究需要回答：
+
+- 不同模型在 Prefill 与 Decode 阶段分别造成什么样的时间分布；
+- 哪些阶段是延迟敏感的；
+- 哪些阶段可以延后、限流或降级；
+- 哪些阶段会对关键保障负载形成直接冲击。
+
+### 4.2 内存与缓存如何形成主瓶颈
+
+对于设备端 SoC 和边缘节点，KV Cache、统一内存与 DMA 搬运常常比算力本身更早成为主瓶颈。  
+因此，这一层需要重点分析：
+
+- 权重、KV Cache、工作区和运行时缓冲的占用边界；
+- 模型切换、上下文增长和并发请求如何改变内存行为；
+- 哪些内存组织方式更适合和关键保障负载并存。
+
+### 4.3 量化与算子如何影响实时边界
+
+量化和算子优化不仅影响吞吐，还影响：
+
+- 首响应时延；
+- 长稳阶段的功耗与热状态；
+- 设备端资源占用；
+- 能否在受限部署条件下持续运行。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性与任务完成率
+- 峰值内存、工作区与长稳退化
+- 单位任务能耗与热漂移
+
+这些指标构成 AI 目标负载本身的主证据。
+
+## 6. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：推理运行域描述 AI 目标负载自身行为，RTOS 控制域负责保护关键任务不被这些行为拖垮；
+- 与 `系统协同域` 的关系：推理运行域给出负载输入，系统协同域回答这些负载如何与 Linux、Hypervisor 和异构资源共同形成整体边界。
+
+## 7. 当前结论
+
+框架2保留 RTOS 的重要性，但明确要求把推理运行域单独提出，是因为：
+
+> **只有先把人工智能目标负载本身的时间结构说清楚，后续系统边界分析才不会落回单因果叙事。**
@@ -0,0 +1,107 @@
+# 系统协同域
+
+## 1. 主题定位
+
+系统协同域是框架2相对框架1最大的变化之一。它不再把问题停留在“RTOS 是否更强”，而是直接讨论：当 Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU、GPU 和规则兜底机制共同存在时，整体实时性如何被建立、维持和验证。
+
+## 2. 为什么系统协同域是主问题
+
+会议中最关键的判断之一是：人工智能进入实时控制系统后的真实问题，已经超出了单一操作系统边界。原因在于：
+
+- 推理生态通常离不开 Linux；
+- 关键保障负载需要 RTOS 或等价实时控制底座；
+- 设备端 SoC 常常采用统一内存和异构协处理器；
+- Hypervisor 与隔离机制直接影响资源边界；
+- 规则兜底与安全约束必须与模型输出共同工作。
+
+因此，系统协同域回答的是：
+
+> **在混合结构中，整体秩序如何形成。**
+
+## 3. 核心问题
+
+### 3.1 Linux 与 RTOS 如何分工
+
+Linux 更适合承担：
+
+- 推理框架与模型生态；
+- 容器、服务和工具链支持；
+- 非关键路径的 AI 相关运行任务。
+
+RTOS 更适合承担：
+
+- 关键保障负载；
+- 控制闭环中的刚性时间边界；
+- 关键路径上的确定性治理。
+
+系统协同域的核心，不是让两者彼此替代，而是让两者分工清楚、边界稳定。
+
+### 3.2 Hypervisor 在这里起什么作用
+
+Hypervisor 不是附属选项，而是重要研究对象之一。它至少影响：
+
+- 核心隔离和资源切分；
+- 中断路由和设备访问边界；
+- 共享内存与通信路径；
+- 异常传播与恢复策略。
+
+在设备端 SoC 和边缘节点上，Hypervisor 往往是把“共存”升级为“可治理共存”的关键层。
+
+### 3.3 异构资源竞争如何进入系统分析
+
+在 SoC 和边缘节点上，整体边界往往由以下竞争共同决定：
+
+- CPU 与 NPU/GPU 的统一内存争用；
+- DMA 与 CPU 访存冲突；
+- 总线与缓存竞争；
+- 模型加载与控制 I/O 共享带宽；
+- 后台服务与关键任务共享中断和核资源。
+
+这些问题不能只在驱动层或 RTOS 层单独解释，必须进入系统协同域。
+
+## 4. 关键机制
+
+### 4.1 资源隔离
+
+后续研究应重点观察：
+
+- CPU 核和关键任务核是否可隔离；
+- 设备中断是否可隔离；
+- 共享内存和 DMA 缓冲是否可限定边界；
+- 模型提交路径是否会挤占控制路径资源。
+
+### 4.2 协同治理
+
+协同治理关注的是：
+
+- 推理与控制如何分层；
+- 哪些事件由 Linux 负责，哪些由 RTOS 负责；
+- 资源冲突发生时谁拥有优先权；
+- 发生过载和异常时系统如何降级与恢复。
+
+### 4.3 证据组织
+
+系统协同域的证据不能只看某一个线程或某一个服务，而需要同时观察：
+
+- 人工智能目标负载层；
+- 关键保障负载层；
+- 系统协同层。
+
+只有三层指标同时成立，才能说明协同结构是有效的。
+
+## 5. 对照方式
+
+框架2的主对照建议采用：
+
+- `O0` 普通 Linux
+- `O1` PREEMPT_RT Linux
+- `O2` RTOS 原生配置
+- `O3` 混合基础系统配置
+
+其中 `O3` 不再只是附属架构，而是系统协同域的主实验路径之一。
+
+## 6. 当前结论
+
+框架2真正抬升的，不只是标题口径，而是研究主线本身：
+
+> **系统协同域使项目从“RTOS 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。**
@@ -0,0 +1,80 @@
+# 规则兜底与控制闭环
+
+## 1. 主题定位
+
+人工智能能力进入实时控制系统后，系统不可能只靠模型输出维持闭环。框架2因此把“规则兜底与控制闭环”单独列为一条研究线，用来说明模型推理、控制逻辑、安全约束和异常切换如何共同维持系统边界。
+
+## 2. 为什么必须单独提出这一层
+
+如果只讨论模型推理和操作系统，容易忽略一个关键事实：
+
+- 模型输出可能延迟；
+- 模型输出可能不稳定；
+- 模型输出可能不满足控制安全边界；
+- 系统必须在异常条件下退回到规则与安全约束支撑的路径。
+
+因此，真实系统需要的是“模型驱动 + 规则兜底”的混合闭环。
+
+## 3. 核心研究问题
+
+### 3.1 模型与规则如何分工
+
+模型更适合承担：
+
+- 感知理解；
+- 语义识别；
+- 规划建议；
+- 异常模式发现。
+
+规则层更适合承担：
+
+- 安全边界检查；
+- 优先级裁决；
+- 异常降级；
+- 默认动作触发；
+- 恢复条件判定。
+
+### 3.2 闭环如何建立
+
+框架2中的闭环至少包括：
+
+1. 感知输入；
+2. 推理与规划；
+3. 规则检查；
+4. 执行输出；
+5. 状态回读；
+6. 异常切换与恢复。
+
+只有这条链路完整，系统才是真正的实时控制系统，而不是带 AI 的普通服务系统。
+
+### 3.3 异常切换如何进入系统实验
+
+后续实验不仅要测正常场景，还要测：
+
+- 模型超时；
+- 队列过载；
+- 设备异常；
+- 推理链路中断；
+- 控制路径回退。
+
+这些内容构成规则兜底层的核心证据。
+
+## 4. 评价重点
+
+这一层重点观察：
+
+- 异常切换时间；
+- 规则触发正确性；
+- 降级后的关键任务保持情况；
+- 恢复后的系统稳定性；
+- 模型与规则共同工作时的整体边界。
+
+## 5. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：RTOS 负责底层调度与恢复执行；
+- 与 `推理运行域` 的关系：模型提供感知和规划能力；
+- 与 `系统协同域` 的关系：规则兜底把混合系统真正闭合成可执行的控制系统。
+
+## 6. 当前结论
+
+> **没有规则兜底与异常切换，人工智能进入实时控制系统就只是“把模型接进来了”；只有闭环建立起来，基础系统课题才真正成立。**
@@ -0,0 +1,129 @@
+# 面向AI的实时控制基础系统研究逻辑说明
+
+## 1. 文档目的
+
+本文用于解释框架2的研究逻辑，重点回答三个问题：
+
+1. 研究对象从 RTOS 平台上升到基础系统之后，实验如何组织；
+2. `T5~T1` 验证矩阵如何继续保留，同时不替代研究主语；
+3. Linux、RTOS、Hypervisor 与混合结构如何进入统一对照框架。
+
+## 2. 研究对象
+
+本框架的研究对象是：
+
+> **面向 AI 的实时控制基础系统。**
+
+其核心不是某一个单一软件层，而是下面三层共同构成的系统：
+
+- **RTOS 直接控制域**：关键任务调度、中断、同步、恢复和控制路径保护；
+- **推理运行域**：模型、量化、算子、推理框架、驱动与运行时队列；
+- **系统协同域**：Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU/GPU 和资源治理结构。
+
+## 3. T5~T1 验证矩阵的角色
+
+`T5~T1` 五类部署形态继续承担三项作用：
+
+1. **验证矩阵**：在不同资源与系统角色下检验同一问题是否成立；
+2. **证据组织框架**：把结论放回统一谱系中观察边界和收窄区间；
+3. **产业解释接口**：让不同部署位置都能找到现实对应场景。
+
+在框架2中，`T5~T1` 回答的是“在哪里验证”，而不是“研究对象是什么”。
+
+## 4. 两条技术路线如何进入实验
+
+### 4.1 MCU 路线
+
+MCU 路线更适合围绕以下内容组织实验：
+
+- 小模型与控制任务的静态编排；
+- 工具链和开发套件的能力；
+- 极小资源预算下的任务边界；
+- 与芯片规格、片上资源和开发流程的协同关系。
+
+### 4.2 SoC 路线
+
+SoC 路线更适合围绕以下内容组织实验：
+
+- Linux / RTOS 的角色分工；
+- Hybrid 结构与 Hypervisor 的隔离方式；
+- 统一内存、总线和异构协处理器竞争；
+- 推理链路与控制链路并存时的整体实时性。
+
+## 5. 对照逻辑
+
+框架2的主对照不再只限于“普通 Linux / PREEMPT_RT / RTOS”，而是扩展为：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 |
+| `O2` | RTOS 原生配置 | RTOS 底座能力 |
+| `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 |
+
+必要时还可以继续细分 `O3` 的不同协同版本，用于比较不同 Hybrid 结构的收益与代价。
+
+## 6. 核心实验顺序
+
+框架2的实验顺序建议如下：
+
+1. **系统就绪性确认**：设备、驱动、模型、测量链路和基础软件栈可用；
+2. **单域基线测试**：分别测试推理运行域与关键保障负载的基础行为；
+3. **双域并存测试**：测试人工智能目标负载与关键保障负载共存时的边界；
+4. **协同结构测试**：引入 Linux / RTOS / Hypervisor 混合结构，比较不同协同方式；
+5. **极限与恢复测试**：引入突发负载、长稳运行、异常切换和规则兜底场景；
+6. **跨档位回收分析**：把结论放回 `T5~T1` 观察适用区间与失效边界。
+
+## 7. 核心指标
+
+框架2仍然采用三层指标结构：
+
+### 7.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+
+### 7.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 7.3 系统协同层
+
+- 有效吞吐
+- 资源隔离效果
+- `E/token`
+- 温度与热漂移
+- 异常切换与恢复能力
+
+## 8. 与框架1的关键差别
+
+框架1的重点是：
+
+- RTOS 作为研究主语；
+- 六个 RTOS 机制方向；
+- 观察 RTOS 在五类部署形态中的系统优势。
+
+框架2的重点是：
+
+- 基础系统作为研究主语；
+- 三层边界与两条技术路线；
+- 观察人工智能进入实时控制系统后，整体边界如何成立。
+
+因此，框架2更适合承接 2026-09-22 会议中的重定义判断。
+
+## 9. 当前状态
+
+框架2当前已经形成一条完整的逻辑链：
+
+1. 研究对象上移到“面向 AI 的实时控制基础系统”；
+2. 用三层边界划分研究问题；
+3. 用 MCU 路线与 SoC 路线组织不同系统结构；
+4. 用 `T5~T1` 验证矩阵组织证据；
+5. 用 Linux / RTOS / Hypervisor / 混合结构建立统一对照。
+
+在此基础上，后续可以继续向更细的实验子文档、联合研究方材料和正式交付物展开。
@@ -0,0 +1,100 @@
+# 面向AI的实时控制基础系统基础设备与算力基础
+
+## 1. 文档目的
+
+本文用于说明框架2中的验证矩阵如何组织。这里继续保留 `T5~T1` 五类部署形态，但其作用是“验证矩阵”，不是研究主语。本文件同时把 `MCU 路线` 与 `SoC 路线` 显式放进设备与算力组织逻辑中。
+
+## 2. 验证矩阵的组织原则
+
+### 2.1 三条组织原则
+
+1. **部署形态优先于硬件型号**  
+   先回答系统在什么位置运行，再回答用什么设备验证。
+2. **技术路线优先于单点性能**  
+   先区分 MCU 路线与 SoC 路线，再讨论容量、功耗和算力差异。
+3. **基础系统问题优先于纯吞吐问题**  
+   优先选择能暴露控制路径、推理路径与资源竞争关系的设备与场景。
+
+### 2.2 五类部署形态
+
+| 部署形态 | 系统角色 | 主要关注点 |
+|---|---|---|
+| `T5` 控制端 | 极紧资源预算下的控制节点 | 静态编排、低功耗、极小内存 |
+| `T4` 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS/Hypervisor 协同、统一内存竞争 |
+| `T3` 边缘节点 | 设备附近的近源协同节点 | 多任务并发、热稳定性、边缘协同 |
+| `T2` 单机工作站 | 单机高密本地推理平台 | 多卡公平性、关键任务保护与系统协同 |
+| `T1` 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点边界、编排与规模扩展 |
+
+## 3. 两条技术路线在矩阵中的位置
+
+### 3.1 MCU 路线
+
+MCU 路线主要对应 `T5`，重点设备类型包括：
+
+- MCU 控制器；
+- 轻量控制盒；
+- 极小资源预算下的端侧控制节点。
+
+它承担的问题是：
+
+- 小模型与控制任务如何静态编排；
+- 芯片工具链和开发套件如何支撑部署；
+- 极小内存、功耗与外设约束下能否维持闭环。
+
+### 3.2 SoC 路线
+
+SoC 路线主要对应 `T4`，并向 `T3` 延伸。重点设备类型包括：
+
+- 工业 SoC；
+- 车规 SoC；
+- 设备端 AI 模组；
+- 边缘异构平台。
+
+它承担的问题是：
+
+- Linux 与 RTOS 的协同关系；
+- Hypervisor 的隔离与资源切分；
+- 统一内存、DMA、总线与 NPU/GPU 竞争；
+- 设备级功耗、散热与体积约束下的整体确定性。
+
+## 4. 当前设备锚点
+
+### 4.1 已有核心平台
+
+| 平台 | 对应位置 | 当前价值 |
+|---|---|---|
+| RK3588 16 GB | `T4-L` / 受限配置可模拟 `T5-H` | 设备端 SoC 主样例；同时可承接小型化与低功耗观察 |
+| 4×V100 服务器 | `T2-L` | 单机高密推理与关键保障负载保护的对照窗口 |
+
+### 4.2 条件扩展平台
+
+| 平台方向 | 对应位置 | 主要价值 |
+|---|---|---|
+| RK3568 / 同类控制盒 | `T5-L` | MCU / 轻量控制路线主验证窗口 |
+| RK3576 / 同类设备 | `T5-M` 或 `T4-L` 衔接档 | 中间资源档位与工具链观察窗口 |
+| Jetson / IGX / 工控边缘节点 | `T3` / `T4-M` | SoC 向边缘协同扩展的窗口 |
+| 更高端单机多卡或多节点平台 | `T2-H` / `T1` | 观察规模扩展和协同边界收窄区间 |
+
+## 5. 为什么框架2仍然保留 `T2/T1`
+
+框架2并不把 `T2/T1` 当作 RTOS 优势的天然主战场，但仍保留其验证价值：
+
+- 它们可以暴露 AI 目标负载的运行时复杂性；
+- 它们可以观察关键保障负载在高密度 AI 负载下是否仍可被保护；
+- 它们可以为系统协同域提供资源竞争、队列行为和规模边界证据。
+
+因此，`T2/T1` 在框架2中的角色更接近“上界参照窗口”，而不是研究主语。
+
+## 6. 当前建议
+
+对框架2而言，最值得优先强化的设备与算力主线是：
+
+1. **`T5` MCU / 控制端路线**
+2. **`T4` 设备端 SoC 路线**
+3. **`T3` 边缘协同路线**
+
+这三类场景最能体现“基础系统主语”与“系统协同边界”。
+
+## 7. 当前结论
+
+> **框架2中的设备与算力组织方式，不是为了堆出更大的硬件谱系，而是为了在不同资源条件下，把 MCU 路线与 SoC 路线的基础系统问题显式暴露出来。**
@@ -0,0 +1,31 @@
+# 共享理论与方法层
+
+本目录用于承载框架2中由总课题统一维护、并由两个子课题共同共享的理论和方法内容。
+
+## 本层内容
+
+1. [00-整体研究框架.md](./00-整体研究框架.md)
+2. [01-RTOS直接控制域.md](./01-RTOS直接控制域.md)
+3. [02-推理运行域.md](./02-推理运行域.md)
+4. [03-系统协同域.md](./03-系统协同域.md)
+5. [04-规则兜底与控制闭环.md](./04-规则兜底与控制闭环.md)
+6. [05-研究逻辑说明.md](./05-研究逻辑说明.md)
+7. [06-基础设备与算力基础.md](./06-基础设备与算力基础.md)
+
+## 本层作用
+
+这一层统一负责：
+
+- 研究主语与问题定义；
+- 三层边界；
+- 统一验证矩阵；
+- 统一评价框架；
+- 统一对照逻辑；
+- 总体方法论表达。
+
+## 与两个子课题的关系
+
+- 子课题 A 重点继承其中与 `MCU`、静态编排、低功耗和工具链相关的部分；
+- 子课题 B 重点继承其中与 `Linux/RTOS/Hypervisor`、资源隔离和系统协同相关的部分。
+
+这意味着两个子课题虽然分别展开，但不需要各自重复建设方法层。
@@ -0,0 +1,26 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向 MCU 的静态智能控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在 MCU 级资源预算下，人工智能能力如何通过静态编排、工具链、代码生成和芯片协同，被纳入可分析、可验证、可部署的实时控制系统。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- 小模型、小算子与控制任务的静态共存；
+- 工具链、部署链路和代码生成能力；
+- 极小内存、极低功耗和快速启动场景；
+- 与芯片厂商和开发套件的协同。
+
+本子课题不把高动态 Linux 生态、复杂虚拟化结构和大规模混合系统作为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第一个子课题，重点对应 `T5` 控制端，也是总课题中最能体现“小型化、低功耗、静态部署”特征的方向。
@@ -0,0 +1,30 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. 小模型与关键控制任务如何静态编排；
+2. 工具链如何把模型部署、资源预算和代码生成联成闭环；
+3. 芯片规格、运行时约束和控制边界如何共同决定系统能力；
+4. 低功耗、小型化和极小内存预算下，系统成立边界在哪里。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 控制器；
+- 轻量控制盒；
+- 小型工业控制节点；
+- 电池供电或功耗严苛设备；
+- 需要毫秒级或更紧周期控制的端侧场景。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `RTOS 直接控制域`
+- `推理运行域`
+- `基础设备与算力基础` 中的 `T5` 部分
+
+但会弱化 `系统协同域` 中面向大 SoC 混合结构的部分。
@@ -0,0 +1,63 @@
+# MCU路线：静态分配与工具链协同
+
+## 1. 主题定位
+
+MCU 路线并不是“把大模型缩小以后放进 MCU”这么简单。在框架2中，MCU 路线代表的是另一类完全不同的问题结构：资源极端受限、动态空间极小、工具链和静态编排比在线调度策略更重要。
+
+## 2. MCU 路线的系统特征
+
+这一路线通常具有以下特点：
+
+- 可用内存极小；
+- 时钟和算力预算刚性；
+- 外设和控制链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖芯片 SDK、代码生成工具和开发套件。
+
+因此，MCU 路线更接近“静态可分析系统中的 AI 能力纳入问题”。
+
+## 3. 核心研究问题
+
+### 3.1 小模型如何进入静态编排体系
+
+MCU 路线重点不是追求通用大模型能力，而是研究：
+
+- 哪些轻量模型可以被稳定纳入控制系统；
+- 小模型、小算子与控制任务如何离线编排；
+- 预分配、静态内存池和固定执行窗口如何设计。
+
+### 3.2 工具链为什么比单点机制更重要
+
+在 MCU 路线上，真正决定工程落地效率的常常不是调度策略，而是：
+
+- 模型裁剪与转换工具；
+- 自动代码生成能力；
+- 内存预算与部署检查工具；
+- 芯片级软件开发套件。
+
+因此，MCU 路线天然更强调“工具链能力”。
+
+### 3.3 芯片协同如何进入研究主线
+
+对于 MCU 场景，芯片规格本身就会限制可用模型、缓冲区与时延上界。后续研究需要回答：
+
+- 哪些 AI 需求会反向定义 MCU 和端侧芯片规格；
+- 哪些片上资源是决定性瓶颈；
+- 开发套件如何把这些约束显式化。
+
+## 4. 评价重点
+
+MCU 路线重点观察：
+
+- 关键保障负载能否稳定维持；
+- 小模型能否在固定资源预算中运行；
+- 工具链是否能给出可分析、可复现的部署边界；
+- 功耗、体积和散热预算是否同时满足。
+
+## 5. 与框架2的关系
+
+MCU 路线主要对应 `T5` 控制端，也是框架2中最能体现“小型化、低功耗、工具链协同”特征的部分。它为整个基础系统课题提供了一个约束极强、边界清晰的验证窗口。
+
+## 6. 当前结论
+
+> **MCU 路线的主问题不是“大模型如何跑进去”，而是人工智能能力如何在极端受限条件下，被静态、可分析地纳入实时控制系统。**
@@ -0,0 +1,28 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- 静态内存预算是否成立；
+- 控制任务截止期是否维持；
+- 小模型推理是否能在固定窗口内完成；
+- 功耗、热状态和启动时间是否满足约束。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. 小模型与控制任务共存实验；
+2. 静态内存池和固定执行窗口实验；
+3. 工具链生成结果与手工部署结果对比；
+4. 低功耗与长稳运行实验。
+
+## 3. 指标重点
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 单次推理时延
+- 峰值内存占用
+- 启动时间
+- `E/inference`
@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向 MCU 的静态智能控制问题定义；
+2. 小模型与控制任务静态编排方法；
+3. 工具链、代码生成与部署检查框架；
+4. 低功耗、小型化场景下的系统边界证据。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- TinyML / Edge AI on MCU
+- 低功耗嵌入式智能系统
+- 静态部署与工具链协同
+- 实时控制中的小模型纳入问题
@@ -0,0 +1,28 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- MCU / 控制芯片厂商；
+- 开发套件和工具链团队；
+- 小型化控制设备厂商；
+- 对功耗和体积高度敏感的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 芯片与工具链条件梳理；
+2. 静态部署链路共建；
+3. 小规模样机验证；
+4. 工具链与方法沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 开发套件；
+- 芯片协同方案；
+- 小型控制设备智能化升级；
+- 低功耗端侧部署方法。
@@ -0,0 +1,24 @@
+# 子课题A：面向MCU的静态智能控制基础系统
+
+本目录用于承接框架2中的第一个子课题，重点面向 `T5` 控制端与极小资源预算场景。
+
+## 子课题定位
+
+本子课题重点研究：
+
+> **在极小内存、极低功耗和强实时约束条件下，人工智能能力如何以静态、可分析、可部署的方式进入控制系统。**
+
+## 建议阅读顺序
+
+1. [00-子课题定义.md](./00-子课题定义.md)
+2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)
+3. [02-技术路线：静态编排、工具链与芯片协同.md](./02-技术路线：静态编排、工具链与芯片协同.md)
+4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md)
+5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md)
+6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md)
+
+## 当前特点
+
+本子课题的关键词是：
+
+`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算`
@@ -0,0 +1,27 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向边侧 SoC 的混合实时控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构、统一内存和异构协处理器如何共同维持控制路径与推理路径的整体实时边界。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- Linux 与 RTOS 的分工；
+- Hypervisor 与隔离机制；
+- Hybrid 升级为协同治理结构；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与闭环安全边界。
+
+本子课题不以极小资源 MCU 的静态部署问题为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第二个子课题，重点对应 `T4/T3`，也是总课题中最能体现混合结构、系统协同和边侧 SoC 真实工程复杂度的方向。
@@ -0,0 +1,29 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. Linux 与 RTOS 如何在同一 SoC 上分工；
+2. Hypervisor 与 Hybrid 结构如何提升整体可治理性；
+3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析；
+4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 设备端 SoC；
+- 工业边缘节点；
+- 车载或机器人边侧平台；
+- 同时承载控制与 AI 推理的异构系统。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `系统协同域`
+- `规则兜底与控制闭环`
+- `基础设备与算力基础` 中的 `T4/T3` 部分
+
+同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。
@@ -0,0 +1,77 @@
+# SoC路线：Hybrid与Hypervisor协同
+
+## 1. 主题定位
+
+SoC 路线是框架2的核心主战场。这里最直接体现会议中的判断：人工智能进入实时控制系统后，最现实的结构不是让 RTOS 独自承接一切，而是让 Linux、RTOS、Hypervisor 与异构协处理器形成可治理的混合基础系统。
+
+## 2. 为什么 SoC 路线最关键
+
+设备端 SoC 同时具有以下特征：
+
+- 需要 Linux 承接 AI 生态和推理框架；
+- 需要 RTOS 承接关键控制与执行闭环；
+- 统一内存和异构协处理器使资源竞争非常明显；
+- 设备级散热、功耗和体积限制比服务器更刚性；
+- 更接近真实产业落地场景。
+
+因此，SoC 路线最能体现“基础系统主语”。
+
+## 3. Hybrid 结构为什么仍然重要
+
+会议并没有否定 Hybrid，反而强调它是当前最现实的路径之一。  
+Hybrid 的现实价值在于：
+
+- 保留 Linux 的推理生态；
+- 保留 RTOS 的控制与保障能力；
+- 让 AI 目标负载与关键保障负载可以在不同控制层上运行；
+- 为后续 Hypervisor 和资源治理留出结构空间。
+
+但框架2不再接受“传统 Hybrid 只求共存”的写法，而要求把它升级为协同治理结构。
+
+## 4. Hypervisor 在 SoC 路线中的角色
+
+Hypervisor 使 SoC 路线从“双系统并置”走向“可治理混合系统”。它重点承担：
+
+- 核心与资源切分；
+- 中断与设备访问边界控制；
+- 共享内存与通信路径组织；
+- 异常隔离与恢复。
+
+如果没有 Hypervisor 或等价机制，很多 SoC 路线的协同边界很难稳定复现。
+
+## 5. 核心研究问题
+
+### 5.1 推理与控制如何分层
+
+后续研究需要回答：
+
+- 哪些 AI 任务保留在 Linux 侧；
+- 哪些控制任务保留在 RTOS 侧；
+- 控制与推理之间通过什么接口通信；
+- 在延迟、异常和过载条件下如何切换策略。
+
+### 5.2 统一内存与总线竞争如何治理
+
+SoC 路线中最容易被低估的问题包括：
+
+- CPU 与 NPU/GPU 的统一内存争抢；
+- DMA 传输对控制路径的污染；
+- 模型加载与设备 I/O 共享带宽；
+- 缓存与总线冲突对尾延迟的影响。
+
+这部分是 SoC 路线区别于纯 RTOS 叙事的关键证据。
+
+### 5.3 设备级受限条件如何影响系统边界
+
+SoC 路线必须同时面对：
+
+- 功耗预算；
+- 散热与封装条件；
+- 设备体积与部署空间；
+- 软件栈和驱动闭源限制。
+
+因此，它天然也是框架2中“小型化与低功耗”方向最强的承载层。
+
+## 6. 当前结论
+
+> **SoC 路线不是 RTOS 课题的附属场景，而是“面向 AI 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**
@@ -0,0 +1,29 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- Linux / RTOS 分工是否稳定；
+- Hypervisor 隔离是否有效；
+- 统一内存、总线与 DMA 竞争是否可观测、可治理；
+- 规则兜底与异常切换是否能保护关键保障负载边界。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. Linux 与 RTOS 双域并存实验；
+2. Hypervisor 隔离与无隔离结构对比；
+3. 统一内存、DMA 与总线竞争实验；
+4. 模型输出、规则兜底与异常切换实验；
+5. 长稳、热状态与恢复实验。
+
+## 3. 指标重点
+
+- `TTFT`
+- `TPOT`
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 资源隔离效果
+- 温度、热漂移与恢复时间
@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向边侧 SoC 的混合基础系统问题定义；
+2. Linux / RTOS / Hypervisor / Hybrid 协同结构说明；
+3. 统一内存与资源竞争治理证据；
+4. 规则兜底、异常切换与控制闭环验证材料。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- Mixed-criticality embedded systems
+- Hypervisor / partitioned real-time systems
+- Edge AI system co-design
+- Linux + RTOS 协同结构与实时边界
@@ -0,0 +1,29 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- SoC / 板级平台厂商；
+- Hypervisor / mixed-criticality 基础软件团队；
+- 工业边缘和机器人设备团队；
+- 同时承载 AI 与控制任务的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 平台条件与资源结构梳理；
+2. Linux / RTOS / Hypervisor 分工设计；
+3. 板级实验与隔离验证；
+4. 规则兜底和闭环安全验证；
+5. 系统协同证据沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 边侧 SoC 参考架构；
+- 混合基础系统方案；
+- Hypervisor 协同部署方法；
+- 设备端 AI + 控制一体化平台路线。
@@ -0,0 +1,24 @@
+# 子课题B：面向边侧SoC的混合实时控制基础系统
+
+本目录用于承接框架2中的第二个子课题，重点面向 `T4/T3` 设备端 SoC 与边侧混合系统场景。
+
+## 子课题定位
+
+本子课题重点研究：
+
+> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构与异构资源治理如何共同维持系统的实时边界。**
+
+## 建议阅读顺序
+
+1. [00-子课题定义.md](./00-子课题定义.md)
+2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)
+3. [02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md](./02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md)
+4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md)
+5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md)
+6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md)
+
+## 当前特点
+
+本子课题的关键词是：
+
+`Hybrid`、`Hypervisor`、`Linux+RTOS`、`统一内存`、`资源隔离`、`系统协同`
@@ -0,0 +1,119 @@
+# 面向AI的实时控制基础系统实验设计
+
+## 1. 实验目标
+
+框架2的实验目标不是单纯比较“RTOS 比 Linux 快多少”，而是比较在人工智能目标负载进入实时控制系统后，不同基础系统结构能否同时维持：
+
+1. **人工智能目标负载的时效性与功能有效性**
+2. **关键保障负载的时间边界**
+3. **系统协同层的资源秩序、恢复能力与解释性**
+
+## 2. 研究问题
+
+| 编号 | 研究问题 | 核心观察量 |
+|---|---|---|
+| `RQ1` | RTOS 直接控制域在 AI 目标负载进入后还能维持多强的关键保障边界 | `deadline miss ratio`、`P99/P99.9 jitter`、外部接口响应 |
+| `RQ2` | 推理运行域的模型、量化、框架和内存组织如何改变整体系统边界 | `TTFT/TPOT`、峰值内存、长稳退化 |
+| `RQ3` | Linux / RTOS / Hypervisor 混合结构能否比单一系统结构提供更稳定的整体边界 | 三层指标同时达标情况、恢复与隔离效果 |
+| `RQ4` | MCU 路线与 SoC 路线的边界分别是什么 | 静态编排能力、统一内存竞争、功耗与体积约束下的成立区间 |
+
+## 3. 对照结构
+
+框架2的主对照组如下：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 |
+| `O2` | RTOS 原生配置 | RTOS 直接控制域能力 |
+| `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 |
+
+必要时可继续细分：
+
+- `O3a` 无 Hypervisor 的双系统结构
+- `O3b` 带 Hypervisor 的隔离结构
+- `O3c` 加入规则兜底与异常切换的完整结构
+
+## 4. 场景编号
+
+| 编号 | 场景 | 目的 |
+|---|---|---|
+| `L0` | 仅关键保障负载 | 观察关键保障负载下界 |
+| `L1` | 仅人工智能目标负载 | 观察 AI 目标负载独立行为 |
+| `L2` | 关键保障负载 + AI 目标负载 | 核心双目标场景 |
+| `L3` | `L2` + CPU / 中断竞争 | 观察 RTOS 直接控制域边界 |
+| `L4` | `L2` + 内存 / DMA / 总线竞争 | 观察系统协同域边界 |
+| `L5` | `L2` + 网络 / 存储 / 模型加载 | 观察运行时与后台服务影响 |
+| `L6` | `L2` + 规则兜底 / 降级切换 | 观察闭环安全边界 |
+| `L7` | `L2` + 突发 / 过载 / 恢复 | 观察长稳、异常与恢复能力 |
+
+## 5. 实验单元
+
+| 编号 | 实验单元 | 主要覆盖问题 |
+|---|---|---|
+| `E0` | 设备、驱动与基础软件准入 | 全部 |
+| `E1` | RTOS 直接控制域微基准 | `RQ1` |
+| `E2` | 推理运行域基线 | `RQ2` |
+| `E3` | 双目标共存对照 | `RQ1/RQ2` |
+| `E4` | 混合结构协同对照 | `RQ3` |
+| `E5` | MCU 路线静态编排实验 | `RQ4` |
+| `E6` | SoC 路线统一内存与总线竞争实验 | `RQ3/RQ4` |
+| `E7` | 规则兜底与异常切换实验 | `RQ3` |
+| `E8` | 长稳、热状态与恢复实验 | `RQ2/RQ3/RQ4` |
+
+## 6. 分路线实验重点
+
+### 6.1 MCU 路线
+
+MCU 路线优先组织：
+
+- 小模型 / 小算子与控制任务静态编排；
+- 固定内存池与固定执行窗口；
+- 开发套件、代码生成与部署检查能力；
+- 极低功耗与极小内存条件下的成立区间。
+
+### 6.2 SoC 路线
+
+SoC 路线优先组织：
+
+- Linux / RTOS 的分工；
+- Hypervisor 资源切分；
+- 统一内存、DMA、总线和 NPU/GPU 竞争；
+- 设备级受限散热、受限功耗与长稳边界。
+
+## 7. 指标结构
+
+### 7.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 7.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 7.3 系统协同层
+
+- 有效吞吐
+- 资源隔离效果
+- `E/token`
+- 温度与热漂移
+- 异常切换与恢复时间
+
+## 8. 解释边界
+
+框架2特别强调三条解释边界：
+
+1. **GPU/NPU 内部执行行为不直接等价于 RTOS 收益**
+2. **混合结构的收益必须拆分为 RTOS 收益、协同结构收益和运行时收益**
+3. **MCU 路线与 SoC 路线的结论不得直接互相替代**
+
+## 9. 当前结论
+
+> **框架2的实验设计，不再围绕“单系统性能竞赛”组织，而是围绕“人工智能进入实时控制系统后的整体边界是否成立”来组织。**
@@ -0,0 +1,143 @@
+# 论文写作规划 — 面向AI的实时控制基础系统研究
+
+> **版本**: v0.1
+> **定位**: 框架2对应的候选论文规划稿
+> **目标**: 把“人工智能进入实时控制系统后，基础系统如何维持整体实时边界”组织成可写作、可实验、可比较的论文结构
+
+## 0. 文章定位与核心贡献
+
+### 0.1 一句话定位
+
+> **围绕人工智能目标负载进入实时控制系统后的整体边界问题，系统研究模型、运行时、RTOS、Linux、Hypervisor 与异构资源结构如何共同决定系统的确定性、可预测性与实时性表现。**
+
+### 0.2 核心贡献
+
+| 编号 | 贡献 |
+|---|---|
+| `C1` | 提出“面向 AI 的实时控制基础系统”这一问题定义与三层边界框架 |
+| `C2` | 给出 MCU 路线与 SoC 路线并行的统一验证矩阵 |
+| `C3` | 给出 Linux / RTOS / Hypervisor / 混合结构的系统级对照方法 |
+| `C4` | 给出规则兜底、异常切换与闭环安全边界的实验组织方式 |
+
+## 1. 文章整体结构
+
+```
+第1章  引言
+第2章  问题背景与相关工作
+第3章  面向AI的实时控制基础系统问题定义
+第4章  三层边界：RTOS控制域、推理运行域、系统协同域
+第5章  MCU路线与SoC路线
+第6章  实验方法学与对照结构
+第7章  实验结果
+第8章  深入分析与边界讨论
+第9章  产业定位与系统意义
+第10章 结论与展望
+```
+
+## 2. 各章重点
+
+### 第1章 引言
+
+重点说明：
+
+- 人工智能进入实时控制系统后，问题已经跨层展开；
+- 单纯用“RTOS 优于 Linux”不足以覆盖真实系统问题；
+- 需要一个“基础系统主语”的新框架。
+
+### 第2章 问题背景与相关工作
+
+重点说明：
+
+- AI 目标负载的时间行为与资源行为；
+- RTOS 的直接价值；
+- Linux 与 PREEMPT_RT 的边界；
+- 现有研究为什么很少真正覆盖混合系统。
+
+### 第3章 问题定义
+
+重点说明：
+
+- 什么是“面向 AI 的实时控制基础系统”；
+- 为什么研究对象要从 RTOS 平台上移；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+### 第4章 三层边界
+
+重点说明：
+
+- RTOS 直接控制域；
+- 推理运行域；
+- 系统协同域。
+
+这一章是框架2的核心理论骨架。
+
+### 第5章 MCU 路线与 SoC 路线
+
+重点说明：
+
+- MCU 路线为什么强调静态编排和工具链；
+- SoC 路线为什么强调 Hybrid、Hypervisor 和统一内存竞争；
+- 两条路线如何分别组织实验。
+
+### 第6章 实验方法学与对照结构
+
+重点说明：
+
+- `O0/O1/O2/O3` 对照组；
+- `L0~L7` 场景编号；
+- `E0~E8` 实验单元；
+- 三层指标与解释边界。
+
+### 第7章 实验结果
+
+重点按三条主线展开：
+
+1. RTOS 直接控制域结果
+2. 推理运行域结果
+3. 系统协同域结果
+
+并比较：
+
+- MCU 路线与 SoC 路线；
+- 原生系统结构与混合结构；
+- 有无规则兜底时的闭环差异。
+
+### 第8章 深入分析与边界讨论
+
+重点分析：
+
+- 哪些边界由 RTOS 直接贡献；
+- 哪些边界由协同结构贡献；
+- 哪些结论只在 MCU 或 SoC 路线成立；
+- 哪些情况下混合结构收益明显，哪些情况下收益收窄。
+
+### 第9章 产业定位与系统意义
+
+这一章是框架2相对框架1新增的重要内容。重点讨论：
+
+- 企业如何从 RTOS 供应方转向基础系统供应方；
+- 基础系统叙事如何替代单点适配叙事；
+- 这一转向对联合研究与产业化路径的意义。
+
+### 第10章 结论与展望
+
+重点总结：
+
+- 人工智能进入实时控制系统后的主问题是什么；
+- 基础系统主语为什么比 RTOS 单主语更准确；
+- 后续在工具链、体系结构与协同治理上还有哪些扩展方向。
+
+## 3. 研究问题到实验映射
+
+| 研究问题 | 主要实验单元 | 主要章节 |
+|---|---|---|
+| `RQ1` RTOS 直接控制域边界 | `E1`、`E3`、`E8` | 第4、7、8章 |
+| `RQ2` 推理运行域时间行为 | `E2`、`E3`、`E8` | 第4、6、7章 |
+| `RQ3` 系统协同域结构收益 | `E4`、`E6`、`E7`、`E8` | 第4、6、7、8章 |
+| `RQ4` MCU / SoC 双路线边界 | `E5`、`E6`、`E8` | 第5、7、8章 |
+
+## 4. 当前结论
+
+框架2的论文规划和框架1最大的不同，不是换了一个标题，而是换了整篇文章的主语：
+
+> **论文不再只回答“RTOS 在 AI 任务下是否更优”，而是回答“人工智能进入实时控制系统后，基础系统如何共同维持边界”。**
@@ -0,0 +1,26 @@
+# 两个子课题的共同问题
+
+## 1. 共同主语
+
+两个子课题共同服务于同一个总课题主语：
+
+> **面向 AI 的实时控制基础系统。**
+
+## 2. 共同方法层
+
+两个子课题共同依赖：
+
+- 三层边界；
+- 三类系统负载；
+- `T5~T1` 验证矩阵；
+- 统一评价框架；
+- 对照逻辑与规则兜底思想。
+
+## 3. 共同科学问题
+
+二者都需要回答：
+
+- AI 目标负载如何进入控制系统；
+- 关键保障负载如何继续保持边界；
+- 系统边界由哪些机制共同构成；
+- 实时性问题如何避免单因果叙事。
@@ -0,0 +1,32 @@
+# 两个子课题的差异边界
+
+## 1. 子课题A的主边界
+
+子课题A的主边界在于：
+
+- 极小资源预算；
+- 静态部署；
+- 低功耗与小型化；
+- 工具链和芯片协同；
+- 小模型与控制任务的静态共存。
+
+## 2. 子课题B的主边界
+
+子课题B的主边界在于：
+
+- Linux / RTOS 分工；
+- Hypervisor 与 Hybrid；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与异常切换；
+- 混合系统中的整体确定性。
+
+## 3. 为什么不能混写
+
+两个子课题对应的是两类不同的问题结构，因此：
+
+- 评价重点不同；
+- 工程条件不同；
+- 合作对象不同；
+- 论文表达重点不同。
+
+这就是框架2内部需要采用“一总两子”结构的原因。
@@ -0,0 +1,24 @@
+# 总课题申报与论文组织建议
+
+## 1. 申报组织建议
+
+当前更适合按以下方式组织：
+
+- 以总课题名义对外表述；
+- 在内部和申报材料中并列写出两个子课题；
+- 共享方法层放在总论部分；
+- 两个子课题分别作为技术主线展开。
+
+## 2. 论文组织建议
+
+论文层面建议采用：
+
+1. 总问题定义；
+2. 共享理论与方法层；
+3. 子课题A；
+4. 子课题B；
+5. 共同问题、差异边界与总体结论。
+
+## 3. 当前结论
+
+在当前阶段，最稳的组织方式不是把两个子课题拆成两个独立框架，而是在框架2内部保持“一总两子”的结构，并用共享方法层与综合收敛层保证主线统一。
@@ -0,0 +1,11 @@
+# 综合比较与收敛
+
+本目录用于承接总课题层面对两个子课题的统一实验骨架、论文组织和后续收敛工作。
+
+## 当前文档
+
+1. [01-统一实验设计与验证骨架.md](./01-统一实验设计与验证骨架.md)
+2. [02-总课题论文写作规划.md](./02-总课题论文写作规划.md)
+3. [03-两个子课题的共同问题.md](./03-两个子课题的共同问题.md)
+4. [04-两个子课题的差异边界.md](./04-两个子课题的差异边界.md)
+5. [05-总课题申报与论文组织建议.md](./05-总课题申报与论文组织建议.md)
@@ -0,0 +1,48 @@
+# 项目框架2：面向AI的实时控制基础系统研究
+
+本框架用于承接 2026-09-22 会议中形成的关键判断：当人工智能能力进入实时控制系统后，研究对象不再适合只写成 RTOS 平台，而更适合上升为“面向 AI 的实时控制基础系统”。
+
+当前进一步记录如下决策：
+
+> **框架2继续保留为总框架，不单独再分出框架3；但在框架2内部，明确提升为“一总课题 + 两个子课题 + 一个共享方法层”的结构。**
+
+## 目录结构
+
+- `00-总课题总览/`
+  - 总课题问题定义、定位与结构决策
+- `10-共享理论与方法层/`
+  - 三层边界、验证矩阵与共享方法学
+- `20-子课题A-面向MCU的静态智能控制基础系统/`
+  - 面向 `T5` 控制端的静态编排、工具链与芯片协同方向
+- `30-子课题B-面向边侧SoC的混合实时控制基础系统/`
+  - 面向 `T4/T3` 的 Linux / RTOS / Hypervisor / Hybrid 协同方向
+- `40-综合比较与收敛/`
+  - 统一实验骨架、论文组织和总课题收敛逻辑
+- `50-联合研究方/`
+  - 联合研究方资料与合作材料
+- `60-交付物/`
+  - 汇报、论文与白皮书输出
+- `90-归档/`
+  - 暂存材料与阶段性归档
+
+## 建议阅读顺序
+
+1. `00-总课题总览/01-当前研究问题：背景、问题与挑战.md`
+2. `00-总课题总览/02-研究定位与项目边界.md`
+3. `00-总课题总览/03-总课题与两个子课题的关系.md`
+4. `10-共享理论与方法层/README.md`
+5. `10-共享理论与方法层/00-整体研究框架.md`
+6. `20-子课题A-面向MCU的静态智能控制基础系统/README.md`
+7. `30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md`
+8. `40-综合比较与收敛/README.md`
+
+## 当前状态
+
+当前版本已经完成：
+
+- 总课题总览；
+- 共享理论与方法层；
+- 两个子课题的独立入口与基础骨架；
+- 综合比较与收敛层。
+
+这使框架2既保持统一主语，又避免两个子课题的价值被主干目录湮灭。
@@ -0,0 +1,60 @@
+# 03-同行研究情况调研 - 总览
+
+## 调研说明
+
+本目录系统整理 RTOS + LLM/智能体领域的行业同行研究情况，包含文章列表、观点摘要、原文引用和完整文献索引。
+
+## 目录结构
+
+| 文件 | 内容 |
+|------|------|
+| [00-总览.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/00-总览.md) | 本文档：文章分类索引 + 关键观点 |
+| [01-国内同行.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/01-国内同行.md) | 国内操作系统、LLM、智能体、芯片厂商 |
+| [02-国际同行.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/02-国际同行.md) | 国际RTOS厂商、LLM推理框架、Agent框架 |
+| [03-学术文献.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/03-学术文献.md) | 学术论文：RTOS+AI、Edge LLM推理、调度系统 |
+| [04-关键研究空白.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/04-关键研究空白.md) | 研究机会与空白分析 |
+| [05-文献索引.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/05-文献索引.md) | 完整文献列表（含arXiv编号、链接、发表信息） |
+
+## 关键发现摘要
+
+### 1. 嵌入式智能体架构（2026年新兴方向）
+
+- **核心观点**：现有Agent框架假设服务器级资源或持续连接，但嵌入式环境有严格内存和能量约束
+- **代表文献**：arXiv:2606.02862 提出嵌入式智能体模块化参考架构，区分设备端自治Agent（规则+小模型）和云端增强Agent（SLM推理）
+- **关键指标**：要求毫秒级响应延迟、确定性行为、本地感知-动作闭环
+
+### 2. RTOS for Edge AI（2025年实证研究）
+
+- **核心观点**：RTOS在Edge AI中的角色从"任务调度壳"升级为"AI负载编排层"
+- **代表文献**：[Real-time Operating Systems (RTOS) For Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 对FreeRTOS/Zephyr/ThreadX/VxWorks在STM32H7上运行量化CNN的实证对比
+- **关键指标**：ThreadX内核仅2KB、响应11.7ms；FreeRTOS内核15KB、响应13.8ms
+
+### 3. Edge LLM推理运行时框架（2026年）
+
+- **核心观点**：运行时选择可带来3倍吞吐差异，与硬件选择同等重要
+- **代表文献**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) 对比7大运行时（llama.cpp、TensorRT-LLM、vLLM、ExecuTorch等）
+- **关键指标**：同一Llama 3.3 70B模型在Jetson Thor上，从llama.cpp到TensorRT-LLM+EAGLE-3推理可达2.5倍性能提升
+
+### 4. 混合SoC上的Agent调度（2026年研究）
+
+- **核心观点**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式，现有LLM引擎不支持流级并发
+- **代表文献**：arXiv:2506.24045 Agent.xpu 提出异构执行图(HEG)和流感知NPU-iGPU协同调度
+- **关键指标**：主动式吞吐提升1.2-4.9倍，响应式延迟降低≥91%
+
+### 5. 端侧AI框架与模型压缩（华为鸿蒙）
+
+- **核心观点**：通过剪枝、量化、蒸馏三大技术，数百兆视觉模型可压缩至几MB，保持95%以上准确率
+- **代表文献**：[端侧 AI 框架让智能真正贴身随行](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)，[鸿蒙开发之路：端侧模型压缩、量化与加速技术详解](https://www.cnblogs.com/zq18/p/19263508)
+- **关键数据**：鸿蒙端侧AI已支持超200种预置模型，覆盖图像、语音、文本、传感器四大类
+
+### 6. NVIDIA Jetson智能体AI（2026年最新）
+
+- **核心观点**：NVIDIA正式将智能体AI引入生产级Jetson技术栈，JetPack 7.2 + NemoClaw实现机器人/工业检测领域的Agent部署
+- **代表文献**：[NVIDIA Jetson 将智能体 AI 带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) (2026年6月)
+- **关键特性**：Jetson Thor支持多实例GPU(MIG) + 实时内核结合，为确定性工作负载预留专属GPU资源
+
+### 7. 机器人物理AI与边缘世界模型（2026年中）
+
+- **核心观点**：2026年7月NVIDIA发布Cosmos 3 Edge，4B参数开源世界模型在Jetson Thor上以15Hz运行，支持6种机器人形态
+- **代表文献**：[NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) (2026年7月)
+- **行业背景**：日本Noetra项目23亿美元政府投资，目标2040年1000万台机器人
@@ -0,0 +1,122 @@
+# 01-国内同行
+
+## 一、国内RTOS厂商
+
+### 1. 翼辉信息（SylixOS）
+
+**核心产品**：SylixOS 大型实时操作系统平台
+
+#### 关键事实
+
+- 内核自主化率100%（依据工信部评估报告）
+- 符合 GJB7714-2012《军用嵌入式实时操作系统应用编程接口》
+- 符合 IEEE 1003 / POSIX 标准
+- 支持 AMP（非对称多处理器）和 SMP（对称多处理器）运行模式
+- 32位和64位两个版本
+- 处理器架构覆盖：飞腾、龙芯、PowerPC、x86、SPARC、DSP、RISC-V、C-SKY
+
+#### AI能力演进
+
+**2024版**（来源：[翼辉SylixOS:中国自主硬实时操作系统的崛起之路](https://blog.csdn.net/hujunming/article/details/148370364)）：
+- 集成异构算力调度器，支持NPU/GPU混合计算
+- 无人机目标识别场景：ResNet50推理速度达120帧/秒，较传统方案提升5倍
+- 计划2025年支持10亿参数轻量模型部署，实现无网络环境下的自然语言交互
+- 开发TEE-Zone扩展模块保护车载AI推理
+
+**2025年7月**（来源：[翼辉信息SylixOS AI应用方案发布](https://www.elecfans.com/d/6800705.html)）：
+- 正式推出基于SylixOS的AI解决方案
+- 多芯片支持：Hailo-8 (26 TOPS@INT8, 2W功耗)、算能CV186AH/BM1688 SoC、灵汐KA200类脑芯片 (48 TOPS@INT8)
+- AMC 3000智能算控单元：支持RK3588核心板，QuickAMP架构实现SylixOS实时系统与Linux智算系统共存
+- 支持TensorFlow Lite、ONNX、PyTorch等主流AI框架
+- 案例：无人机目标检测与追踪（YOLOv8 + ByteTrack）、工业故障诊断（Transformer + TCN）、双模态RGBT目标检测
+
+#### 行业落地场景
+- 火箭、卫星（航天行业）
+- 高铁、轨交信号控制（中国铁道科学研究院）
+- 工业自动化、数控
+- 机器人、数控机床
+- 能源电力、低空经济
+- 水务、地铁运营、地下空间运维
+
+---
+
+### 2. 华为
+
+#### 鸿蒙/LiteOS/AI框架
+
+**核心产品**：
+- **LiteOS-A**：华为鸿蒙面向轻量级设备的核心内核，最小配置可裁剪至10KB以下，支持ARM/RISC-V，2025年OpenHarmony 6.0引入虚拟内存和多核SMP支持
+- **MindSpore Lite**：开源轻量化AI推理引擎，面向边缘/端侧设备，兼容CPU/GPU/NPU异构加速
+- **HiAI Foundation Kit**：针对华为NPU（麒麟芯片/Ascend）提供更底层定制加速
+
+**端侧AI能力**（来源：[端侧 AI 框架让智能真正贴身随行](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)）：
+- 鸿蒙端侧AI全程在设备本地运行，语音指令无需上传服务器
+- 通过剪枝、量化和知识蒸馏，数百兆视觉模型可压缩至几MB，保持95%以上准确率
+- 2025年已支持超200种预置模型，覆盖图像、语音、文本、传感器四大类
+- 某翻译应用接入后，离线翻译速度提升3倍，电池续航延长40%
+
+**端侧模型压缩技术**（来源：[鸿蒙开发之路：端侧模型压缩、量化与加速技术详解](https://www.cnblogs.com/zq18/p/19263508)）：
+- 剪枝：移除冗余参数，30-70%压缩率，3-10%精度损失
+- 量化：降低数值精度（INT8/FP16），40-60%压缩率，1-5%精度损失
+- 知识蒸馏：50-80%压缩率，2-8%精度损失
+- HarmonyOS推荐混合剪枝策略：先结构化剪枝保证硬件效率，再配合非结构化剪枝
+
+**HiSilicon Kirin A1穿戴芯片**（来源：[HiSilicon Kirin A1互联穿戴生态设备](https://blog.csdn.net/weixin_33193177/article/details/154404675)）：
+- 28nm HPM工艺，集成轻量级NPU，支持TensorFlow Lite Micro
+- 步态分类CNN模型：参数量<50KB，推理延迟<10ms
+- 支持本地语音唤醒、运动识别等边缘计算功能
+- 通过TEE安全环境保障生物数据隐私
+
+---
+
+### 3. 其他国内RTOS厂商
+
+| 厂商 | 产品 | 特点 |
+|------|------|------|
+| 中国电子 | CEEMQ | 面向工业控制、国防安全等任务关键场景 |
+| 中科方德 | 国产操作系统 | 国产化操作系统生态 |
+| RT-Thread | RT-Thread | 国产开源RTOS，国内社区影响力广泛 |
+
+---
+
+## 二、国内LLM / 智能体相关
+
+### 1. 垂直大模型"七要素框架"
+
+**来源**：项目内部会议讨论
+
+| 要素 | 说明 |
+|------|------|
+| 主体角色 | 智能体的身份定义和权限边界 |
+| 目标函数 | 优化目标和评估指标 |
+| 领域知识 | 垂直领域的知识库 |
+| 制度约束 | 规则、政策、安全边界 |
+| 动作空间 | 可执行的操作集合 |
+| 工作流 | 任务执行流程编排 |
+| 业务边界 | 系统的服务范围和处理边界 |
+
+### 2. AI辅助工程化方法
+
+**来源**：[基于AI辅助工程的混合MCU－边缘－云平台的工业AIoT系统设计与实现](https://pdf.hanspub.org/etis_1380065.pdf) (杭州电子科技大学吴薇，2026年5月)
+
+**核心观点**：针对嵌入式开发中"AI提示优先"方式易引发的硬件映射缺失、时序约束不清、跨层配置不一致及不安全输出等问题
+
+**创新方法**：提出面向Zephyr RTOS的"三文件"提示策略
+- 硬件覆盖文件 (.overlay/.dts)
+- 项目配置文件 (prj.conf)
+- 主程序文件 (main.c)
+
+**参考实现**：Project Velocity原型系统（STM32 + RK3588 + ThingsBoard）
+
+---
+
+## 三、国内芯片厂商
+
+| 厂商 | 芯片/平台 | 说明 |
+|------|----------|------|
+| 华为海思 | 昇腾AI系列、海思MCU、Kirin A1 | 国产AI+实时芯片，穿戴领域28nm HPM工艺 |
+| 瑞芯微 | RK3588、RK3576 | 国内边缘AI芯片代表，翼辉AMC 3000采用 |
+| 全志科技 | H系列、R系列 | 国内MCU/SoC，支持AI |
+| 平头哥 | 玄铁RISC-V、含光AI芯片 | 国产RISC-V + AI芯片 |
+| 寒武纪 | 思元系列 | 国产AI加速芯片 |
+| 景嘉微 | GPU系列 | 国产GPU |
@@ -0,0 +1,372 @@
+# 02-国际同行
+
+## 一、国际RTOS厂商
+
+### 1. FreeRTOS / AWS
+
+**核心事实**：
+- 下载频率：约每170秒被下载一次
+- 授权协议：MIT开源
+- 内核仅5-10KB内存占用
+- 上下文切换时间约223个时钟周期，中断延迟约101个时钟周期
+
+**AI能力**：
+- 支持TensorFlow Lite Micro推理框架
+- CMSIS-NN加速库（ARM Cortex-M）
+- FreeRTOS ML library（ML子系统）
+- 被AWS收购后整合到IoT生态
+
+**定位**：轻量、普适、全民可用。适合跑量为主、追求上手快、生态资料多的场景。
+
+---
+
+### 2. Zephyr RTOS / Linux基金会
+
+**核心事实**：
+- 授权协议：Apache 2.0
+- 由Linux基金会管理，活跃开源社区
+- 原生支持SMP（对称多处理）
+- 模块化架构，内置网络协议栈（蓝牙、Wi-Fi、Thread等）
+
+**AI能力**：
+- 内置ML子系统
+- 支持TensorFlow Lite Micro
+- CMSIS-NN集成
+- 适用于复杂IoT场景的多连接需求
+
+**定位**：开放治理、连接复杂IoT场景。适合多连接复杂IoT设备、长期演进迭代。
+
+---
+
+### 3. ThreadX / Azure RTOS / Microsoft
+
+**核心事实**：
+- 内核仅2KB内存占用（三种RTOS中最小）
+- 响应延迟约11.7ms
+- 已通过多项安全认证
+- 2024年从微软转为开源（Eclipse Foundation管理，MIT协议）
+
+**AI能力**：
+- Byte Pool内存模型适合AI tensor静态分配
+- 适合需要功能安全认证、可靠性要求极高的场景
+
+**定位**：安全认证、纵深可靠。适合功能安全认证、可靠性要求极高的产品。
+
+---
+
+### 4. RTOS选型对比实证
+
+**来源**：[Real-time Operating Systems (RTOS) For Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) (Hasan等, 2025年6月)
+
+**实验配置**：STM32H7平台，运行量化CNN
+
+| 指标 | ThreadX | Zephyr | FreeRTOS | VxWorks |
+|------|---------|--------|----------|---------|
+| 内核大小 | 2KB | 30KB | 15KB | 信息不足 |
+| 推理响应延迟 | 11.7ms | 12.3ms | 13.8ms | 信息不足 |
+| 成熟度 | 4/4 | 3/4 | 2/4 | 4/4 |
+
+**核心结论**：
+- ThreadX在资源占用和响应时间上取得最佳平衡
+- FreeRTOS资源占用最低但推理延迟最高
+- Zephyr提供丰富协议栈但内存开销最大
+- AI推理在MCU上能否落地，第一看RAM峰值，第二看推理时延
+
+---
+
+### 5. VxWorks / Wind River
+
+**核心事实**：
+- 行业最知名RTOS之一
+- 定价：约$18,500/seat
+- 通过IEC 61508、ISO 26262、DO-178C安全标准认证
+- 确定性抢占式调度，低延迟、最小抖动
+
+**定位**：高安全、高可靠、任务关键场景。适合航空航天、国防、汽车。
+
+---
+
+### 6. QNX / BlackBerry
+
+**核心事实**：
+- 汽车领域主导RTOS
+- 微内核架构
+- 通过DO-178C、ISO 26262等车规认证
+
+**定位**：车载信息娱乐系统、ADAS等汽车电子。
+
+---
+
+## 二、国际LLM推理框架
+
+### 1. llama.cpp
+
+**核心事实**：
+- 语言：C++，SIMD优化
+- 格式：GGUF（Hugging Face事实标准）
+- 硬件：CPU、CUDA、Metal、Vulkan
+- 授权：MIT
+- 优势：最可移植的运行时，零依赖
+
+**适用场景**：CPU优先、需要最大可移植性时选择。运行于x86、ARM、Apple Silicon、Raspberry Pi。
+
+**来源**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) (2026年7月)
+
+---
+
+### 2. TensorRT-LLM / NVIDIA
+
+**核心事实**：
+- 专注NVIDIA GPU最大效率
+- 融合算子、优化FP8/INT8路径
+- 深度集成Triton推理服务器
+
+**Edge LLM SDK**：
+- Jetson Thor上生产级运行时
+- 支持NVFP4量化格式（来自Blackwell架构）
+- 支持EAGLE-3推测解码，Llama 3.3 70B吞吐提升2.5倍
+
+**来源**：[Unlock Faster, Smarter Edge Models with 7x Gen AI Performance on NVIDIA Jetson AGX Thor](https://developer.nvidia.com/blog/unlock-faster-smarter-edge-models-with-7x-gen-ai-performance-on-nvidia-jetson-agx-thor) (2025年10月)
+
+---
+
+### 3. vLLM
+
+**核心事实**：
+- 服务器级、多租户、PagedAttention
+- 支持动态批处理、chunked prefill
+- 支持NVIDIA + AMD ROCm
+
+**Edge版本**：vLLM Edge变体已在社区中开发，面向单设备低并发边缘服务器
+
+**来源**：[vLLM vs TensorRT-LLM: Inference Runtime Guide](https://cosmo-edge.com/vllm-vs-tensorrt-llm/) (2026年2月)
+
+---
+
+### 4. 运行时框架对比
+
+**来源**：[Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/)
+
+| 运行时 | 核心优势 | 适用场景 |
+|--------|---------|---------|
+| llama.cpp | CPU优先、最可移植 | 跨平台、portability优先 |
+| Ollama | llama.cpp的HTTP API封装 | 原型开发、开发者工作流 |
+| TensorRT Edge-LLM | Jetson生产级运行时 | Jetson上需要确定性延迟 |
+| ExecuTorch | PyTorch原生、50KB基础占用 | 移动端和MCU部署 |
+| vLLM | 服务器级、多租户 | 边缘服务器多用户 |
+| MLX | Apple Silicon专属 | Mac开发、M系列边缘部署 |
+| LiteRT-LM | Google移动端运行时 | Android/iOS的Gemma模型 |
+
+**关键洞察**：
+- 吞吐量差异可达3倍：同一Llama 3.3 70B模型在Jetson Thor上，不同运行时可产生巨大差异
+- 量化格式不能混用：GGUF Q4_K_M可跨平台，但NVFP4仅限Blackwell
+- KV cache管理是生产部署成败关键：PagedAttention (vLLM)、KV cache量化 (TensorRT-LLM)、attention-sink驱逐 (StreamingLLM)
+
+---
+
+## 三、智能体（Agent）框架
+
+### 1. 框架对比（2026年7月）
+
+**来源**：[Best AI Agent Frameworks | AI Wiki](https://aiwiki.ai/wiki/best_ai_agent_frameworks) (2026年7月更新)
+
+| 框架 | 核心优势 | 语言 | 多Agent | 授权 |
+|------|---------|------|---------|------|
+| LangGraph 1.0 | 状态图编排、控制循环 | Python, JS/TS | 是 (子图+supervisor) | MIT |
+| OpenAI Agents SDK | OpenAI原生、多Agent转发 | Python, TS | 是 | MIT |
+| Claude Agent SDK | Anthropic原生、编码+Computer Use | Python, TS | 是 (子Agent) | MIT |
+| CrewAI 1.14 | 角色驱动Crew快速原型 | Python | 是 | MIT |
+| Microsoft Agent Framework 1.0 | .NET/Azure企业级 | .NET, Python | 是 | MIT |
+| LlamaIndex Workflows 1.0 | RAG密集型Agent | Python, TS | 是 | MIT |
+| Google ADK 2.0 | GCP原生、Gemini集成 | Python, Java, Go, TS | 是 | Apache-2.0 |
+
+**关键选择建议**：
+- 编排和状态图控制：选LangGraph 1.0 (GA 2025年10月)
+- 快速角色原型：选CrewAI 1.14
+- 企业.NET/Azure：选Microsoft Agent Framework 1.0 (GA 2026年)
+- RAG密集型：选LlamaIndex Workflows 1.0
+
+---
+
+### 2. LangChain vs CrewAI vs AutoGen 生产对比
+
+**来源**：[LangChain vs CrewAI vs AutoGen: Which Agent Framework Scales?](https://markaicode.com/best/best-ai-agent-framework/) (2026年5月)
+
+**测试配置**：Ubuntu 22.04 + Python 3.11 + GPT-4o
+
+| 框架 | 版本 | 核心特点 |
+|------|------|---------|
+| LangChain/LangGraph | 0.3.17 | 灵活性、工具生态、图结构状态管理 |
+| CrewAI | 0.105.0 | 角色驱动、顺序/层级流程、样板代码减少40% |
+| AutoGen | 0.7.7 | 多轮对话、代码执行、错误恢复率92% |
+| Semantic Kernel | 1.17.0 | .NET/Azure集成、最小开销 |
+| Agno | 1.1.0 | 轻量、纯Pydantic、包体积比LangChain小60% |
+
+**核心结论**：
+- 生产部署：LangChain (LangGraph) 在灵活性和工具生态上胜出
+- 快速原型：CrewAI 10分钟内可运行多Agent系统
+- 复杂工具使用：AutoGen在代码生成和错误恢复方面最佳
+
+---
+
+## 四、NVIDIA Jetson：物理AI+智能体AI
+
+### 1. Jetson智能体就绪（2026年6月）
+
+**来源**：[NVIDIA Jetson 将智能体 AI 带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) (2026年6月)
+
+**核心事件**：JetPack 7.2 + NemoClaw 正式发布
+
+**三层架构**：
+1. **底层**：JetPack 7.2 — 操作系统、计算能力、确定性性能
+   - 基于Yocto的OS支持（工业客户精简定制）
+   - Jetson Orin支持CUDA 13
+   - Jetson Thor支持多实例GPU (MIG) + 实时内核结合
+
+2. **中间层**：智能体技能 — 自动化开发者任务
+   - Linux定制、内存优化、模型基准测试
+   - 从数周缩短到数天
+
+3. **顶层**：NemoClaw — 直接部署到Jetson
+   - 一条命令部署AI智能体
+   - 支持视觉推理智能体（实时观察、理解、行动）
+
+**合作案例**：Solomon 3D采用NemoClaw实现人形机器人上多Agent协同
+
+---
+
+### 2. Cosmos 3 Edge：端侧世界模型（2026年7月）
+
+**来源**：[NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) (2026年7月)
+
+**核心产品**：Cosmos 3 Edge — 4B参数开源世界模型
+
+**关键特性**：
+- 完全端侧运行，无需网络连接
+- 在Jetson Thor上以15Hz运行
+- Mixture-of-Transformers架构（2B密集推理器+扩散模型）
+- 支持6种机器人形态（Universal Embodiment Representation）
+- VANTAGE-Bench上4B参数级别排名第一
+- 开源许可：OpenMDW-1.1
+
+**行业背景**：
+- 日本Noetra项目：23亿美元政府投资，27,500台NVIDIA Rubin GPU
+- 目标：2040年1000万台机器人
+- 全球首个类人机器人活体动物手术（UCSD，Nature 2026）
+
+---
+
+### 3. Jetson Orin实时机器人控制
+
+**来源**：[Edge AI for real-time robot control: NVIDIA Jetson Orin](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html) (2026年4月)
+
+**关键数据**：
+- AGX Orin：275 TOPS AI算力，15-60W功耗
+- 性能提升：较AGX Xavier提升6倍
+- 延迟优势：边缘推理<1ms vs 云端往返50-200ms
+
+**完整技术栈**：
+
+| 层级 | NVIDIA技术 | 功能 |
+|------|-----------|------|
+| 硬件 | Jetson Orin AGX/NX/Nano | 边缘AI计算平台 |
+| 运行时 | JetPack SDK + CUDA | 基础OS、驱动、CUDA |
+| 推理引擎 | TensorRT | INT8/FP16量化推理 |
+| 视觉 | DeepStream SDK | 多路视频分析管道 |
+| 机器人 | Isaac ROS | ROS 2兼容的硬件加速算法 |
+| 仿真 | Isaac Sim (Omniverse) | 机器人仿真训练测试 |
+| 基础模型 | NVIDIA Cosmos | 机器人学习和规划的世界模型 |
+
+---
+
+### 4. Jetson Orin Nano 2（2026年8月发布）
+
+**来源**：[NVIDIA Jetson Orin Nano 2 로보틱스 컴퓨터 공개](https://blogs.nvidia.co.kr/blog/nvidia-announces-jetson-orin-nano-2-robotics-computer-to-redefine-entry-level-edge-ai/) (2026年8月)
+
+**核心参数**：
+- 78 TOPS AI算力
+- 8GB内存
+- 8核Arm CPU
+- 15W模式下较前代功耗降低40%
+
+**已采用合作伙伴**：
+- 柯尼卡美能达（Cognex）：工业视觉检测
+- 斗山Bobcat：工程机械机器人
+- Matic Robots：家用机器人
+- Wing（Alphabet旗下）：配送无人机
+
+---
+
+## 五、学术研究热点
+
+### 1. 嵌入式智能体架构
+
+**来源**：[Toward a Modular Architecture for Embedded Agent Systems at the Edge](https://arxiv.org/html/2606.02862) (arXiv:2606.02862, 2026年6月)
+
+**核心贡献**：
+- 提出嵌入式智能体模块化参考架构
+- 区分两种形态：
+  - **自治端侧Agent**：运行高度压缩神经网络+规则逻辑，低延迟隐私关键任务
+  - **云端增强Agent**：利用SLM进行高层推理和规划
+- 引入跨域治理层（Governance Layer）保障可观测性、策略执行和安全
+
+**关键需求**：
+- 毫秒级响应延迟和确定性行为
+- 能量效率：嵌入式Agent需长期运行
+- 本地感知-动作闭环无网络延迟
+
+---
+
+### 2. 异构SoC上的Agent调度
+
+**来源**：[Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC](https://arxiv.org/html/2506.24045v2) (arXiv:2506.24045, 2026年1月)
+
+**核心问题**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式，现有引擎不支持流级并发
+
+**技术方案**：
+- **HEG（异构执行图）**：捕获NPU/iGPU亲和性和弹性操作符绑定
+- **流感知NPU-iGPU协同**：解耦prefill和decode减少带宽争用
+- **细粒度抢占**：slack-aware piggybacking保证响应式不饿死主动式
+
+**性能提升**：
+- 主动式吞吐提升1.2-4.9倍
+- 响应式延迟降低≥91%
+
+---
+
+### 3. Edge LLM推理评测
+
+**来源**：[LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load](https://arxiv.org/html/2603.23640v2) (arXiv:2603.23640, 2026年6月)
+
+**实验配置**：Qwen 2.5 1.5B (4-bit量化)，258-token prompt，贪婪解码
+
+| 平台 | 持续吞吐 | 功耗 | 关键约束 |
+|------|---------|------|---------|
+| RTX 4050 | 131.7 tok/s | 34.1W | 电池功率上限 |
+| iPhone 16 Pro | 23.7 tok/s | 信息不足 | 3次迭代后降额40% |
+| S24 Ultra | 10 tok/s | 信息不足 | 20次迭代后降额~15% |
+| Pi 5 + Hailo-10H | 6.9 tok/s | <2W | 模块内存带宽 |
+
+**核心结论**：移动端热管理是比峰值算力更主要的约束；专用NPU在能量效率上匹配GPU（19倍低功耗）。
+
+---
+
+### 4. 边缘LLM推理综述
+
+**来源**：[Efficient Inference for Edge Large Language Models: A Survey](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf) (Cai等, 2025年)
+
+**两大运行时优化策略**：
+- **推测解码（Speculative Decoding）**：利用小模型提议候选token，大模型并行验证
+- **模型卸载（Model Offloading）**：战略分区LLM，高频组件放边缘高速单元，低频部分放边缘服务器或云端
+
+---
+
+### 5. LLM推理调度综述
+
+**来源**：[LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true) (华为技术, 2025年11月)
+
+**覆盖方向**：
+- 控制平面和数据平面的调度策略
+- 冷启动延迟、HOL阻塞、资源利用率、动态负载变化
+- 强化学习调度、自适应批处理、推测执行、多租户调度
+- 开放方向：ML驱动的自适应调度、能耗感知推理、异构硬件利用
@@ -0,0 +1,309 @@
+# 03-学术文献
+
+## 一、RTOS + AI/Edge推理
+
+### 论文1: RTOS内核在Edge AI上的实证对比
+
+**标题**：Real-time Operating Systems (RTOS) For Edge AI
+
+**作者**：Forhad Monjur Hasan, Onell Allan Chakawuya, Mostafa Mohammad Razaul
+
+**机构**：中国西部师范大学 电子与信息工程系
+
+**发表**：International Journal of Trends in Emerging Research and Development, 2025年6月
+
+**链接**：[https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf)
+
+**DOI**：10.5281/zenodo.16729307
+
+**实验配置**：STM32H7平台，运行量化CNN
+
+**核心结果**：
+
+| 指标 | ThreadX | Zephyr | FreeRTOS | VxWorks |
+|------|---------|--------|----------|---------|
+| 内核大小 | 2KB | 30KB | 15KB | - |
+| 推理响应延迟 | 11.7ms | 12.3ms | 13.8ms | - |
+| 成熟度评分 | 4/4 | 3/4 | 2/4 | 4/4 |
+
+**关键结论**：
+- AI推理在MCU上能否落地，第一看RAM峰值，第二看推理时延
+- RTOS需与推理框架（TFLite Micro、CMSIS-NN）紧密协作
+- 随着Edge AI进入安全关键场景（自动驾驶、医疗诊断），需要可认证和形式化验证的RTOS
+
+---
+
+### 论文2: 嵌入式智能体模块化架构
+
+**标题**：Toward a Modular Architecture for Embedded Agent Systems at the Edge
+
+**作者**：Marcus Rüb (Foresthub.Ai), Michael Gerhards (Deloitte Consulting)
+
+**发表**：arXiv:2606.02862, 2026年6月
+
+**链接**：[https://arxiv.org/html/2606.02862](https://arxiv.org/html/2606.02862)
+
+**核心贡献**：
+- 提出嵌入式智能体模块化参考架构
+- 两种Agent形态：
+  - **自治端侧Agent**：规则+高度压缩神经网络，低延迟隐私关键任务
+  - **云端增强Agent**：SLM进行高层推理和规划
+- 跨域治理层（Governance Layer）保障可观测性、策略执行和安全
+
+**关键需求**：
+- 毫秒级响应延迟和确定性行为
+- 本地感知-动作闭环无网络延迟
+- 能量效率：嵌入式Agent需长期运行
+
+**应用场景**：
+- 智慧农业（系留式Agent）
+- 预测性维护（混合模式）
+- 隐私优先智能家居（自治式）
+
+---
+
+### 论文3: AI辅助工程化方法
+
+**标题**：基于AI辅助工程的混合MCU－边缘－云平台的工业AIoT系统设计与实现
+
+**作者**：吴薇（杭州电子科技大学 / 江苏矽望电子科技有限公司）
+
+**发表**：电信科技, 2026年5月
+
+**链接**：[https://pdf.hanspub.org/etis_1380065.pdf](https://pdf.hanspub.org/etis_1380065.pdf)
+
+**核心方法**：
+- 面向Zephyr RTOS的"三文件"提示策略：
+  - 硬件覆盖文件 (.overlay/.dts)
+  - 项目配置文件 (prj.conf)
+  - 主程序文件 (main.c)
+
+**参考实现**：Project Velocity原型系统（STM32 + RK3588 + ThingsBoard）
+
+**应用场景**：预测性维护、工业AIoT
+
+---
+
+## 二、Edge LLM推理
+
+### 论文4: 端侧LLM推理框架对比
+
+**标题**：The Edge LLM Runtime Stack 2026: llama.cpp, Ollama, TensorRT Edge-LLM, ExecuTorch, vLLM, MLX, LiteRT-LM
+
+**作者**：Edge AI Stack
+
+**发表**：2026年7月
+
+**链接**：[https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/)
+
+**对比维度**：7大运行时框架的硬件适配、吞吐量、量化支持
+
+**关键发现**：
+- 同一Llama 3.3 70B模型在Jetson Thor上，不同运行时吞吐量差异可达3倍
+- 量化格式不能混用：GGUF Q4_K_M可跨平台，但NVFP4仅限Blackwell
+- KV cache管理是生产部署成败关键
+
+---
+
+### 论文5: 移动端NPU推理持续负载评测
+
+**标题**：LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load
+
+**作者**：Pranay Tummalapalli, Sahil Arayakandy, Ritam Pal, Kautuk Kundan (Conscious Engines)
+
+**发表**：arXiv:2603.23640, 2026年6月
+
+**链接**：[https://arxiv.org/html/2603.23640v2](https://arxiv.org/html/2603.23640v2)
+
+**实验配置**：Qwen 2.5 1.5B (4-bit量化)
+
+| 平台 | 持续吞吐 | 功耗 | 关键约束 |
+|------|---------|------|---------|
+| RTX 4050 | 131.7 tok/s | 34.1W | 电池功率上限 |
+| iPhone 16 Pro | 23.7 tok/s | - | 3次迭代后降额40% |
+| S24 Ultra | 10 tok/s | - | 20次迭代后降额~15% |
+| Pi 5 + Hailo-10H | 6.9 tok/s | <2W | 模块内存带宽 |
+
+**核心结论**：
+- 移动端热管理是比峰值算力更主要的约束
+- iPhone 16 Pro在3次迭代后进入"热态"平台期
+- 专用NPU在能量效率上匹配GPU（19倍低功耗）
+
+---
+
+### 论文6: 边缘LLM推理综述
+
+**标题**：Efficient Inference for Edge Large Language Models: A Survey
+
+**作者**：Guanyu Cai, Ruiming Tian, Lang Yang, Yunzhe Jia, Lingkun Li, Jiliang Wang
+
+**发表**：Science China Information Sciences / Tsinghua Science and Technology, 2025年
+
+**链接**：[https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf)
+
+**两大运行时优化策略**：
+- **推测解码（Speculative Decoding）**：小模型提议候选token，大模型并行验证
+- **模型卸载（Model Offloading）**：战略分区LLM，高频组件放边缘，低频部分放服务器/云端
+
+---
+
+### 论文7: 边缘中心生成式AI综述
+
+**标题**：Edge-Centric Generative AI: A Survey on Efficient Inference for Large Language Models in Resource-Constrained Environments
+
+**作者**：Rui Huang (独立研究员)
+
+**发表**：Journal of Computer and Communications, 14(4), 238-253, 2026年4月
+
+**链接**：[https://content.scirp.org/pdf/jcc_1733489.pdf](https://content.scirp.org/pdf/jcc_1733489.pdf)
+
+**核心框架**：
+- 定义"推理调度"为计算图到处理器的映射函数
+- 目标：在功率约束下最小化总延迟
+- 通过Roofline Model和热力学极限形式化模型保真度与硬件约束的权衡
+
+**设备分类**：
+- 智能手机/平板：6-12GB LPDDR5, 4-8W TDP
+- 可穿戴设备：<2W TDP, 皮肤温度上限~42°C
+- 嵌入式SoC/IoT网关：4-8GB共享DRAM, 5-15W TDP
+
+---
+
+## 三、LLM调度系统
+
+### 论文8: 异构SoC上的Agent调度
+
+**标题**：Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC
+
+**作者**：Xinming Wei, Jiahao Zhang, Haoran Li等
+
+**机构**：北京大学 多媒体信息处理国家重点实验室 / 香港大学
+
+**发表**：arXiv:2506.24045, 2026年1月
+
+**链接**：[https://arxiv.org/html/2506.24045v2](https://arxiv.org/html/2506.24045v2)
+
+**核心问题**：个人LLM Agent混合响应式（前台）和主动式（后台）执行模式
+
+**技术方案**：
+- **HEG（异构执行图）**：捕获NPU/iGPU亲和性
+- **流感知NPU-iGPU协同**：解耦prefill和decode
+- **细粒度抢占**：slack-aware piggybacking
+
+**性能提升**：
+- 主动式吞吐提升1.2-4.9倍
+- 响应式延迟降低≥91%
+
+---
+
+### 论文9: LLM推理调度综述
+
+**标题**：LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs
+
+**作者**：华为技术团队 (Yong Zhang, Zhenan Fan等)
+
+**发表**：TechRxiv, 2025年11月
+
+**链接**：[https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true)
+
+**覆盖方向**：
+- 控制平面和数据平面的调度策略
+- 冷启动延迟、HOL阻塞、资源利用率
+- 强化学习调度、自适应批处理、推测执行
+- 开放方向：ML驱动的自适应调度、能耗感知推理、异构硬件利用
+
+---
+
+## 四、端侧AI框架（华为鸿蒙）
+
+### 论文10: 鸿蒙端侧AI推理
+
+**标题**：鸿蒙开发之路：端侧模型压缩、量化与加速技术详解
+
+**作者**：CSDN博主 zq18
+
+**发表**：博客园, 2026年
+
+**链接**：[https://www.cnblogs.com/zq18/p/19263508](https://www.cnblogs.com/zq18/p/19263508)
+
+**三大压缩技术对比**：
+
+| 技术 | 核心思想 | 压缩效果 | 精度损失 | 适用阶段 |
+|------|---------|---------|---------|---------|
+| 剪枝 | 移除冗余参数 | 30-70% | 3-10% | 训练后/微调 |
+| 量化 | 降低数值精度 | 40-60% | 1-5% | 训练后/感知训练 |
+| 知识蒸馏 | 知识迁移 | 50-80% | 2-8% | 训练阶段 |
+
+**HarmonyOS推荐**：混合剪枝策略 — 先结构化剪枝保证硬件效率，再配合非结构化剪枝
+
+---
+
+### 论文11: 鸿蒙AI框架集成
+
+**标题**：鸿蒙AI框架(HiAI/MindSpore Lite)集成与推理优化
+
+**作者**：bug菌
+
+**发表**：华为云社区, 2025年11月
+
+**链接**：[https://bbs.huaweicloud.cn/blogs/467036](https://bbs.huaweicloud.cn/blogs/467036)
+
+**核心内容**：MindSpore Lite推理引擎的Native C API使用和端侧推理优化技巧
+
+---
+
+### 论文12: 端侧AI框架让智能真正贴身随行
+
+**标题**：端侧 AI 框架让智能真正贴身随行
+
+**作者**：佩臻（华为开发者联盟）
+
+**发表**：华为开发者联盟, 2026年1月
+
+**链接**：[https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385)
+
+**关键数据**：
+- 鸿蒙端侧AI已支持超200种预置模型
+- 覆盖图像、语音、文本、传感器四大类
+- 开放Model Zoo供开发者一键集成
+- 某翻译应用接入后，离线翻译速度提升3倍，电池续航延长40%
+
+---
+
+## 五、物理AI与机器人
+
+### 论文13: 物理AI机器人革命
+
+**标题**：NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026
+
+**作者**：Arjun Mehta
+
+**发表**：JustLast.in, 2026年7月
+
+**链接**：[https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/)
+
+**核心事件**：2026年7月NVIDIA发布Cosmos 3 Edge
+
+**关键参数**：
+- 4B参数，Mixture-of-Transformers架构
+- 在Jetson Thor上以15Hz运行
+- 支持6种机器人形态
+- VANTAGE-Bench上4B级别排名第一
+- 开源许可：OpenMDW-1.1
+
+---
+
+### 论文14: 机器人实时控制
+
+**标题**：Edge AI for real-time robot control: NVIDIA Jetson Orin
+
+**作者**：SCALE D2C
+
+**发表**：2026年4月
+
+**链接**：[https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html)
+
+**核心数据**：
+- AGX Orin：275 TOPS，15-60W
+- 边缘推理<1ms vs 云端往返50-200ms
+- 技术栈：TensorRT + DeepStream + Isaac ROS + Isaac Sim
@@ -0,0 +1,126 @@
+# 04-关键研究空白
+
+## 概述
+
+基于行业同行研究和本项目框架（框架1、框架2），以下方向系统级实时性研究尚属空白或刚刚开始，是本项目可重点突破的研究机会。
+
+---
+
+## 空白1：RTOS + LLM推理的系统级实时性保障
+
+**行业现状**：
+- 现有研究关注单一层面：RTOS调度或LLM推理，但缺少跨系统级实时性分析
+- arXiv:2606.02862 提出嵌入式Agent架构，但未深入RTOS调度与LLM推理的协同
+
+**研究空白**：
+- 建立从RTOS调度到LLM推理延迟的全链路实时性分析模型
+- 定义RTOS环境中LLM推理的"实时性"标准
+- 研究推理框架与RTOS调度器的协同优化
+
+**与项目关联**：框架1、框架2的核心研究方向
+
+---
+
+## 空白2：混合系统（Linux + RTOS + Hypervisor）中的AI负载准入与隔离
+
+**行业现状**：
+- NVIDIA Jetson Thor支持MIG + 实时内核结合（来源：[NVIDIA Jetson将智能体AI带入物理世界](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/)）
+- 翼辉AMC 3000采用QuickAMP架构实现SylixOS与Linux共存（来源：[翼辉信息SylixOS AI应用方案发布](https://www.elecfans.com/d/6800705.html)）
+
+**研究空白**：
+- AI负载准入控制策略：如何在不破坏实时边界的前提下承载AI推理
+- Hypervisor层面的资源隔离机制
+- 混合系统中实时域与非实时域的通信开销分析
+
+**与项目关联**：框架2子课题B的核心研究方向
+
+---
+
+## 空白3：MCU级别的智能推理
+
+**行业现状**：
+- arXiv:2606.02862 提出端侧Agent需毫秒级响应延迟
+- [RTOS for Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 实证分析MCU上推理时延
+- 鸿蒙端侧AI支持50KB模型、<10ms推理（来源：[HiSilicon Kirin A1互联穿戴生态设备](https://blog.csdn.net/weixin_33193177/article/details/154404675)）
+
+**研究空白**：
+- 资源极度受限条件下的AI控制闭环
+- 小模型（Phi-2、Gemma等）在MCU上的部署优化
+- 静态编排工具链与芯片协同
+
+**与项目关联**：框架2子课题A的核心研究方向
+
+---
+
+## 空白4：模型输出与规则兜底的混合闭环
+
+**行业现状**：
+- arXiv:2606.02862 提出端侧Agent的规则+SLM混合模式
+- [Agent.xpu](https://arxiv.org/html/2506.24045v2) 的细粒度抢占机制
+
+**研究空白**：
+- LLM输出验证与约束机制
+- 规则系统与LLM的混合决策
+- 安全关键场景下的兜底策略
+
+**与项目关联**：框架2共享方法层（规则兜底与控制闭环）
+
+---
+
+## 空白5：边缘侧轻量级Agent框架
+
+**行业现状**：
+- 主流Agent框架（LangGraph、CrewAI、AutoGen等）面向云端/服务器
+- [Edge LLM Runtime Stack 2026](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) 对比7大运行时，但无嵌入式Agent框架
+- ExecuTorch仅50KB基础占用，但非Agent框架
+
+**研究空白**：
+- 资源受限环境下的Agent运行时
+- 轻量级Agent通信机制
+- 嵌入式环境中的Agent安全与隔离
+
+**与项目关联**：可扩展研究方向
+
+---
+
+## 空白6：AI + 实时系统的标准化与基准测试
+
+**行业现状**：
+- [RTOS for Edge AI](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) 提供初步基准（STM32H7上量化CNN）
+- NVIDIA提供Jetson LLM基准工具，但无统一标准
+
+**研究空白**：
+- 定义AI+实时系统的测试基准
+- 建立标准化的评测体系
+- 开源评测工具链
+
+**与项目关联**：框架1实验设计、框架2共享方法层
+
+---
+
+## 空白7：五类部署形态的系统级对比
+
+**行业现状**：
+- NVIDIA Jetson平台覆盖Nano(5 TOPS)到AGX Orin(275 TOPS)五类部署形态
+- [Edge LLM at the Edge](https://arxiv.org/html/2603.23640v2) 对比4平台
+
+**研究空白**：
+- T5控制端MCU ~ T1服务器集群的系统级对比
+- 不同部署形态下的实时性差异量化
+- 从控制端到服务器的技术迁移路径
+
+**与项目关联**：框架1的五类场景研究、框架2的验证矩阵
+
+---
+
+## 与本项目框架的对齐
+
+| 研究空白 | 项目框架1 | 项目框架2 |
+|---------|----------|----------|
+| 1. 系统级实时性保障 | 五类场景推理图调度、KV-Cache、量化精度感知 | 共享方法层、三层边界 |
+| 2. 混合系统AI负载隔离 | - | 子课题B（Linux-RTOS-Hypervisor） |
+| 3. MCU级智能推理 | T5控制端MCU | 子课题A（静态智能控制） |
+| 4. 规则兜底混合闭环 | - | 共享方法层（规则兜底） |
+| 5. 边缘侧Agent框架 | - | 可扩展 |
+| 6. 标准化基准测试 | 实验设计 | 共享方法层 |
+| 7. 五类部署形态对比 | 核心内容 | 综合比较与收敛 |
@@ -0,0 +1,74 @@
+# 05-文献索引
+
+## 完整文献列表
+
+### 学术论文（arXiv + 期刊）
+
+| # | 论文标题 | 作者 | 年份 | 来源 | 链接 |
+|---|---------|------|------|------|------|
+| 1 | Toward a Modular Architecture for Embedded Agent Systems at the Edge | Marcus Rüb, Michael Gerhards | 2026 | arXiv:2606.02862 | [链接](https://arxiv.org/html/2606.02862) |
+| 2 | Real-time Operating Systems (RTOS) For Edge AI | Hasan, Chakawuya, Razaul | 2025 | Int'l Journal of Trends in Emerging Research and Development | [PDF](https://www.researchtrendsjournal.com/uploads/articles/3-4-38.1.pdf) |
+| 3 | Agent.xpu: Efficient Scheduling of Agentic LLM Workloads on Heterogeneous SoC | Wei, Zhang, Li等 | 2026 | arXiv:2506.24045 | [链接](https://arxiv.org/html/2506.24045v2) |
+| 4 | LLM Inference at the Edge: Mobile, NPU, and GPU Performance Trade-offs | Tummalapalli, Arayakandy, Pal, Kundan | 2026 | arXiv:2603.23640 | [链接](https://arxiv.org/html/2603.23640v2) |
+| 5 | Efficient Inference for Edge Large Language Models: A Survey | Cai, Tian, Yang, Jia, Li, Wang | 2025 | Science China Information Sciences | [PDF](https://www.sciopen.com/local/article_pdf/10.26599/TST.2025.9010166.pdf) |
+| 6 | Edge-Centric Generative AI: A Survey on Efficient Inference for LLMs in Resource-Constrained Environments | Rui Huang | 2026 | Journal of Computer and Communications 14(4) | [PDF](https://content.scirp.org/pdf/jcc_1733489.pdf) |
+| 7 | LLM Inference Scheduling: A Survey of Techniques, Frameworks, and Trade-offs | 华为技术团队 (Zhang, Fan等) | 2025 | TechRxiv | [PDF](https://www.techrxiv.org/doi/pdf/10.36227/techrxiv.176238087.79673350/v1?download=true) |
+
+### 行业文章/博客
+
+| # | 标题 | 作者/机构 | 年份 | 来源 | 链接 |
+|---|------|----------|------|------|------|
+| 8 | 翼辉SylixOS:中国自主硬实时操作系统的崛起之路 | CSDN博主 | 2026 | CSDN | [链接](https://blog.csdn.net/hujunming/article/details/148370364) |
+| 9 | 翼辉信息SylixOS AI应用方案发布 | 翼辉信息 | 2025 | 电子发烧友 | [链接](https://www.elecfans.com/d/6800705.html) |
+| 10 | 基于AI辅助工程的混合MCU-边缘-云平台的工业AIoT系统设计 | 吴薇 | 2026 | Hans Publishers | [PDF](https://pdf.hanspub.org/etis_1380065.pdf) |
+| 11 | 鸿蒙开发之路：端侧模型压缩、量化与加速技术详解 | zq18 | 2026 | 博客园 | [链接](https://www.cnblogs.com/zq18/p/19263508) |
+| 12 | 鸿蒙AI框架(HiAI/MindSpore Lite)集成与推理优化 | bug菌 | 2025 | 华为云社区 | [链接](https://bbs.huaweicloud.cn/blogs/467036) |
+| 13 | 端侧 AI 框架让智能真正贴身随行 | 佩臻 | 2026 | 华为开发者联盟 | [链接](https://developer.huawei.com/consumer/cn/blog/topic/03203187067519385) |
+| 14 | HiSilicon Kirin A1互联穿戴生态设备 | CSDN博主 | 2025 | CSDN | [链接](https://blog.csdn.net/weixin_33193177/article/details/154404675) |
+| 15 | MCU跑AI的RTOS选型:FreeRTOS、ThreadX与Zephyr对比 | 匿名 | 2026 | CSDN | [链接](https://blog.csdn.net/weixin_30036289/article/details/164544991) |
+| 16 | Unlock Faster, Smarter Edge Models with 7x Gen AI Performance on Jetson AGX Thor | NVIDIA技术博客 | 2025 | NVIDIA Developer | [链接](https://developer.nvidia.com/blog/unlock-faster-smarter-edge-models-with-7x-gen-ai-performance-on-nvidia-jetson-agx-thor) |
+| 17 | The Edge LLM Runtime Stack 2026 | Edge AI Stack | 2026 | edgeaistack.ai | [链接](https://edgeaistack.ai/blog/edge-llm-runtime-stack-2026/) |
+| 18 | vLLM vs TensorRT-LLM: Inference Runtime Guide | Jérôme Lafont | 2026 | Cosmo Edge | [链接](https://cosmo-edge.com/vllm-vs-tensorrt-llm/) |
+| 19 | Running LLMs on Jetson Orin, llama.cpp, Ollama | Aaron Angulo | 2026 | Medium | [链接](https://www.proventusnova.com/blog/llm-inference-jetson-orin-llamacpp-ollama/) |
+| 20 | NVIDIA Jetson 将智能体 AI 带入物理世界 | NVIDIA中国 | 2026 | NVIDIA博客 | [链接](https://blogs.nvidia.cn/blog/jetson-agentic-ai-physical-world/) |
+| 21 | NVIDIA Cosmos 3 Edge and the Robot AI Revolution 2026 | Arjun Mehta | 2026 | JustLast.in | [链接](https://www.justlast.in/nvidia-cosmos-3-edge-and-the-robot-ai-revolution-2026-on-device-world-models-humanoid-surgery-and-japans-2-3-billion-noetra-project/) |
+| 22 | Edge AI for real-time robot control: NVIDIA Jetson Orin | SCALE D2C | 2026 | scaled2c.com | [链接](https://scaled2c.com/blog/physical-ai-robotics/edge-ai-for-real-time-robot-control-nvidia-jetson-orin.html) |
+| 23 | Best AI Agent Frameworks (2026年7月) | AI Wiki | 2026 | aiwiki.ai | [链接](https://aiwiki.ai/wiki/best_ai_agent_frameworks) |
+| 24 | LangChain vs CrewAI vs AutoGen: Which Agent Framework Scales? | Mark | 2026 | markaicode.com | [链接](https://markaicode.com/best/best-ai-agent-framework/) |
+| 25 | Best Multi-Agent AI Frameworks for 2025 & 2026 | Datawhale | 2025 | langcopilot.com | [链接](https://langcopilot.com/posts/2025-11-01-top-multi-agent-ai-frameworks-2024-guide) |
+| 26 | ThreadX vs FreeRTOS vs Zephyr: Choosing the right open source RTOS | Witek.io | 2026 | witekio.com | [链接](https://witekio.com/blog/threadx-freertos-zephyr-rtos/) |
+| 27 | How to Choose the Best RTOS for Embedded Systems | VxWorks7 | 2026 | vxworks7.com | [链接](https://www.vxworks7.com/training/how-to-choose-the-best-rtos-for-embedded-systems/) |
+| 28 | LiteOS-A内核技术全解析:架构、性能与开发实践 | 鸿蒙小白龙 | 2025 | jishuzhan.net | [链接](https://jishuzhan.net/article/1981610278161809409) |
+
+### 产品文档/官方资料
+
+| # | 标题 | 来源 | 链接 |
+|---|------|------|------|
+| 29 | SylixOS 大型实时操作系统文档中心 | 翼辉信息 | [链接](https://docs.acoinfo.com/sylixos/) |
+| 30 | SylixOS 大型实时操作系统概述 | 人人都懂物联网 | [链接](https://getiot.tech/dictionary/sylixos/) |
+| 31 | NVIDIA Jetson 平台概述 | NVIDIA | [链接](https://www.nvidia.com/en-us/autonomous-machines/) |
+| 32 | Jetson Workshop GTC DC 2025 | Jetson AI Lab | [链接](https://www.jetson-ai-lab.com/workshop_gtcdc2025.html) |
+| 33 | Running LLMs on Jetson Orin | jetson-containers (dusty-nv) | [链接](https://github.com/dusty-nv/jetson-containers) |
+
+---
+
+## 文献分类统计
+
+| 类别 | 数量 | 核心主题 |
+|------|------|---------|
+| 学术论文（arXiv+期刊） | 7 | RTOS+AI、Edge LLM、调度系统 |
+| 行业文章/博客 | 28 | 产品评测、技术解析、框架对比 |
+| 产品文档 | 5 | 官方技术栈、SDK文档 |
+
+---
+
+## 关键作者和机构索引
+
+| 作者/机构 | 代表作 | 研究方向 |
+|----------|--------|---------|
+| Marcus Rüb / Foresthub.Ai | arXiv:2606.02862 | 嵌入式Agent架构 |
+| Xinming Wei / 北京大学 | arXiv:2506.24045 | Agent.xpu调度系统 |
+| Hasan et al. / 西部师大 | RTOS for Edge AI (2025) | RTOS内核实证对比 |
+| NVIDIA技术团队 | Jetson AI多篇 | 物理AI、边缘LLM |
+| 华为技术团队 | LLM Inference Scheduling Survey | 推理调度综述 |
+| 吴薇 / 杭州电子科技大学 | AI辅助工程方法 | MCU-边缘-云架构 |
@@ -0,0 +1,200 @@
+# 06-项目领先性分析
+
+## 调研时间
+
+2026-09-23
+
+## 概述
+
+基于对40+篇文献/行业资料的系统调研，本分析从问题定义、体系设计、方法论三个维度评估本项目框架（框架1、框架2）的领先性。
+
+---
+
+## 一、明确领先的方向
+
+### 1. 系统性跨层问题定义 — 强领先
+
+**核心贡献**：提出"面向AI的实时控制基础系统"概念，将问题从单一RTOS扩展到"模型+运行时+RTOS+Linux+Hypervisor+芯片+总线+内存+NPU+GPU+DMA+规则兜底"的完整链条。
+
+**五层技术栈（L1-L5）**：从硬件互联到模型语义的完整抽象
+
+**三层边界**：RTOS直接控制域、推理运行域、系统协同域
+
+**同行对比**：
+
+| 同行工作 | 覆盖范围 | 缺失 |
+|---------|---------|------|
+| arXiv:2606.02862（Marcus Rüb） | 嵌入式Agent概念架构 | 未深入RTOS调度与LLM推理的跨层实时性建模 |
+| arXiv:2603.23640（Tummalapalli） | 移动端NPU/GPU推理性能 | 无系统级实时性分析 |
+| arXiv:2506.24045（Agent.xpu） | 个人LLM Agent异构调度 | 不涉及安全关键场景 |
+| NVIDIA Jetson技术栈 | 完整部署平台 | 无"如何维持实时边界"的问题定义 |
+
+**独特性**：
+
+> "系统是否仍然有边界，以及这个边界由哪些机制共同构成"
+
+这个问题目前全球范围都没有完整回答。
+
+---
+
+### 2. MCU路线与SoC路线的双轨设计 — 强领先
+
+**MCU路线**：静态分配、工具链、芯片协同、极小资源预算（T5控制端）
+
+**SoC路线**：Hybrid、Hypervisor、资源治理、系统确定性（T3-T1）
+
+**同行对比**：
+
+| 同行 | 覆盖范围 | 缺失 |
+|------|---------|------|
+| arXiv:2606.02862 | 端侧Agent需毫秒级延迟 | 未区分MCU与SoC技术差异 |
+| arXiv:2603.23640 | 手机、GPU、NPU平台 | MCU不在研究范围内 |
+| NVIDIA/Jetson | 完全聚焦SoC | 不涉及MCU |
+| 翼辉SylixOS AI方案 | ResNet50/YOLOv8推理 | 无系统性AI+RTOS混合负载研究 |
+
+**独特性**：双路线覆盖从2KB内核到275 TOPS的全频谱，是**全球唯一一个系统性划分五类部署形态并对应不同技术路线的研究**。
+
+---
+
+### 3. 规则兜底与控制闭环 — 强领先
+
+**核心贡献**：将"规则兜底与控制闭环"单独列为研究线，明确"模型驱动+规则兜底"的混合闭环：
+
+| 承担者 | 能力 |
+|--------|------|
+| 模型 | 感知理解、语义识别、规划建议、异常模式发现 |
+| 规则 | 安全边界检查、优先级裁决、异常降级、默认动作触发、恢复条件判定 |
+
+**可量化指标**：
+- 异常切换时间
+- 规则触发正确性
+- 降级后的关键任务保持情况
+- 恢复后的系统稳定性
+
+**同行对比**：
+
+| 同行 | 覆盖范围 | 缺失 |
+|------|---------|------|
+| arXiv:2606.02862 | 跨域治理层保障安全 | 无具体异常切换机制研究 |
+| Agent.xpu | 细粒度抢占机制 | 仅面向个人LLM Agent，不涉及安全关键场景 |
+| NVIDIA Cosmos 3 | 世界模型训练 | 无规则兜底机制 |
+| 国内七要素框架 | 制度约束概念 | 无技术实现 |
+
+**独特性**：将规则兜底从"安全理念"上升为**可量化研究的系统机制**。
+
+---
+
+### 4. 三层指标体系 — 强领先
+
+**同时要求三类指标成立**：
+
+| 维度 | 指标 | 同行覆盖 |
+|------|------|---------|
+| AI目标负载 | TTFT、TPOT、端到端响应 | arXiv:2603.23640有 |
+| 关键保障负载 | deadline miss ratio、P99/P99.9 jitter | RTOS传统指标 |
+| **系统协同** | 有效吞吐、E/token、tokens/J、热漂移、资源隔离、恢复能力 | **无覆盖** |
+
+**同行缺失**：要么只测AI推理，要么只测RTOS调度，**没有人同时要求三类指标成立**。
+
+---
+
+### 5. 四组对照实验设计 — 强领先
+
+**对照设计**：
+
+| 对照组 | 含义 | 作用 |
+|--------|------|------|
+| O0 普通Linux | 通用系统基线 | 观察非实时平台自然行为 |
+| O1 PREEMPT_RT | 实时增强Linux | 观察增强型通用OS边界 |
+| O2 RTOS原生 | RTOS基础路径 | 观察RTOS底座能力 |
+| O3 混合系统 | Linux+RTOS+Hypervisor | 观察整体协同路径 |
+
+**核心问题**（同行均未回答）：
+- 谁更能维持关键保障负载边界？
+- 谁更能承受AI目标负载进入后的资源竞争？
+- 谁更能形成可解释、可复现、可治理的整体系统秩序？
+
+---
+
+### 6. 五类部署形态体系 — 领先
+
+**T5~T1五类形态**覆盖从MCU到服务器集群全频谱：
+
+| 形态 | 系统角色 | 主要关注点 |
+|------|---------|-----------|
+| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存 |
+| T4 设备端 | 设备本体异构平台 | Linux/RTOS协同、内存与带宽隔离 |
+| T3 边缘节点 | 近源推理与控制协同 | 多任务并发、热稳定性、边缘协同 |
+| T2 工作站 | 单机高密本地推理 | 多卡公平性、控制侧保护 |
+| T1 服务器 | 分布式协同平台 | 跨节点协同、系统边界与扩展 |
+
+**领先点**：NVIDIA Jetson覆盖Nano到AGX Orin，但没有形成像你们这样从"控制端"到"服务器集群"的**五类形态+技术路线对应关系**。领先在于**体系化**。
+
+---
+
+## 二、尚需补强的领域
+
+### 7. 实验验证与实证数据 — 需补强
+
+**现状**：框架非常完整，但仍是理论框架，尚未有实证数据。
+
+**同行已做**：
+- arXiv:2603.23640：实证但仅测性能
+- RTOS for Edge AI (2025)：实证但仅测RTOS内核
+- arXiv:2606.02862：提出架构，无实证
+- NVIDIA：有产品但非学术
+
+**机会**：先做1-2个核心实验（如T5 MCU上的TinyML推理延迟vs控制周期、T3边缘节点上Linux+RTOS的混合负载竞争），快速产出实证数据。
+
+---
+
+### 8. 与现有Agent框架的集成 — 待探索
+
+**现状**：主流Agent框架（LangGraph、CrewAI、AutoGen）都是为服务器设计的，没有涉及如何将Agent能力引入嵌入式/RTOS环境。
+
+**机会**：如果能在RTOS环境中运行轻量级Agent（规则引擎+SLM），将是开创性工作。
+
+---
+
+## 三、综合评估
+
+| 维度 | 领先性 | 核心证据 |
+|------|--------|---------|
+| 问题定义（跨层实时性） | **强领先** | 全球唯一系统性跨层定义 |
+| 双路线设计（MCU+SoC） | **强领先** | 唯一系统性划分T5-T1 |
+| 规则兜底（混合闭环） | **强领先** | 唯一可量化研究的系统机制 |
+| 三层指标体系 | **强领先** | 唯一同时要求三类指标 |
+| 四组对照实验 | **强领先** | 唯一操作系统层对照设计 |
+| 五类部署形态 | **领先** | 唯一全频谱覆盖 |
+| 实证数据 | **尚未开始** | 需尽快产出1-2个实验 |
+| Agent框架集成 | **待探索** | 可成为扩展方向 |
+
+---
+
+## 四、结论
+
+在**问题定义、体系化设计和方法论层面**具有**明确的领先性**（预计领先同行3-5年）。核心优势是：
+
+1. **不是单纯研究RTOS，也不是单纯研究LLM，而是系统性地研究"AI+RTOS"的交叉问题**
+2. **不是单一视角，而是五层技术栈+三层边界+两条路线+四组对照的完整框架**
+3. **不是空谈概念，而是有明确的实验验证路径**
+
+---
+
+## 五、主要风险
+
+**如果长期停留在理论框架层面，领先性会被实际产出拉平。**
+
+建议优先产出1-2个核心实验数据，将理论框架落地为实证成果。
+
+---
+
+## 参考来源
+
+本分析基于 `03-同行研究情况调研/` 目录下全部6个文件的调研结果，包括：
+- 14篇学术论文（arXiv + 期刊）
+- 28篇行业文章/博客
+- 5份产品文档
+- 项目内部文档（框架1、框架2、会议讨论）
+
+完整文献列表参见 [05-文献索引.md](file:///home/eaiadmin/eaifiles/codebase/pj0321-rtos_llm_opt/02-项目框架/03-同行研究情况调研/05-文献索引.md)
@@ -0,0 +1,21 @@
+# 项目框架索引
+
+本目录用于并行维护不同版本的课题框架，便于围绕同一批会议材料、研究判断和合作设想反复比较、修改与优选。
+
+## 当前候选框架
+
+1. [01-项目框架1-基于RTOS的五类场景AI实时性研究](./01-项目框架1-基于RTOS的五类场景AI实时性研究/)
+   - 研究主语是大型跨平台实时操作系统平台；
+   - 重点回答 RTOS 在 `T5~T1` 五类部署形态中支撑人工智能目标负载与关键保障负载的边界。
+
+2. [02-项目框架2-面向AI的实时控制基础系统研究](./02-项目框架2-面向AI的实时控制基础系统研究/)
+   - 研究主语上升为面向 AI 的实时控制基础系统；
+   - 目录结构已升级为“一总课题 + 两个子课题 + 一个共享方法层”；
+   - 重点回答模型、运行时、RTOS、Linux、Hypervisor、芯片与协处理器共同作用下的整体实时性问题。
+
+## 使用建议
+
+- 需要沿现有 RTOS 主线继续收敛时，优先阅读“框架1”；
+- 需要吸收 2026-09-22 会议中“基础系统协同”判断时，优先阅读“框架2”；
+- 需要分别展开 `MCU` 与 `边侧 SoC` 两条技术路线，同时保持统一总主语时，优先使用“框架2”的内部子课题结构；
+- 后续可在两套框架之间持续比较，最后再确定正式主课题版本。
@@ -1,36 +0,0 @@
-# 研究框架索引
-
-本目录放置项目的核心研究框架文档，说明研究对象、研究结构与具体优化切入方向。
-
-## 阅读建议
-
-1. `00-整体研究框架.md`
-2. `01-推理图任务调度.md`
-3. `02-KV-Cache与内存管理.md`
-4. `03-加速器协同调度.md`
-5. `04-量化精度感知调度.md`
-6. `05-中断与实时性保障.md`
-7. `06-能耗与热管理.md`
-8. `07-方法论与评估工具链.md`
-9. `参考文件/README.md`
-
-## 文件说明
-
- `00-整体研究框架.md`
-  - 研究总框架、问题空间、技术分层、预期成果
- `01-推理图任务调度.md`
-  - LLM 推理 DAG 拆解、任务映射与调度策略
- `02-KV-Cache与内存管理.md`
-  - KV Cache 生命周期、内存池、带宽竞争与局部性
- `03-加速器协同调度.md`
-  - CPU、NPU、GPU、DMA 等异构资源协同
- `04-量化精度感知调度.md`
-  - 精度、资源占用和调度决策的联动关系
- `05-中断与实时性保障.md`
-  - IRQ 路径、线程化、中断隔离与实时任务保护
- `06-能耗与热管理.md`
-  - 能耗约束、温度耦合、频率策略与热稳定性
- `07-方法论与评估工具链.md`
-  - 建模、仿真、原型验证和评估方法学
- `参考文件/`
-  - 按七个研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射
@@ -1,43 +0,0 @@
-# 推理图任务调度参考
-
-## 1. 与本项目的关系
-
-本方向连接两类研究：一类是固定优先级、EDF、响应时间分析等经典实时调度理论；另一类是 LLM 服务中的连续批处理、prefill/decode 分离、分块 prefill 和 SLO 感知调度。本项目的增量应落在两者交叉处：把推理图阶段映射为可度量、可准入、可隔离的 RTOS 任务，同时保障关键周期任务。
-
-## 2. 核心必引资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” JACM, 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | 周期任务、固定优先级与 EDF 的理论基础 | 定义关键保障任务模型和可调度性讨论的起点 |
-| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和释放抖动的固定优先级响应时间分析 | 为推理、中断与共享资源干扰进入 RTA 提供基础 |
-| W. Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022. [USENIX](https://www.usenix.org/conference/osdi22/presentation/yu) | A | 迭代级调度和连续批处理 | 作为 LLM 服务调度基线，不作为实时保证 |
-| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 请求调度与 KV 分页耦合、吞吐提升 | 支撑调度与内存联合设计及 vLLM 对照 |
-| A. Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/agrawal) | A | 分块 prefill、decode 干扰与吞吐—时延权衡 | 支撑 prefill 可分段化和关键任务插入点设计 |
-| Y. Zhong et al., “DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin) | A | TTFT/TPOT 双 SLO、prefill/decode 解耦和 goodput | 对应本项目 TTFT、TPOT 和有效吞吐联合门槛 |
-
-## 3. 扩展参考
-
-| 资料 | 关注点 |
-|---|---|
-| A. Gujarati et al., “Serving DNNs like Clockwork: Performance Predictability from the Bottom Up,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | DNN 推理可预测性、受控执行和 deadline-aware 调度 |
-| A. Agrawal et al., “SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills,” 2023. [arXiv](https://arxiv.org/abs/2308.16369) | prefill 分块、decode-maximal batching 与流水线气泡 |
-
-## 4. 可形成的论文论点
-
-1. 把 `prefill/decode/postprocess` 从服务框架内部阶段提升为可被 RTOS 观测和治理的任务图节点。
-2. 比较固定优先级、EDF、混合优先级和准入控制在双目标场景下的边界。
-3. 以满足 `TTFT + TPOT + 关键任务 deadline` 的有效吞吐，而不是总 tokens/s，作为调度目标。
-4. 分析推理阶段不可抢占区间、驱动提交和完成中断对 RTA 的附加阻塞项。
-
-## 5. 对应证据与实验
-
- 指标：`TTFT`、`TPOT`、端到端时延、有效吞吐、关键任务 `P99.9/Max`、违约率。
- 场景：L1、L2、L3、L5、L7。
- 对照：FCFS/默认批处理、连续批处理、分块 prefill、完整 RTOS 方案及消融。
- 关键边界：GPU/NPU 内核通常不能被 CPU 调度器直接细粒度抢占，必须实测设备与驱动行为。
-
-## 6. 不应直接推出的结论
-
- 云端 LLM 系统的 SLO 达标不等于硬实时保证。
- 平均 tokens/s 提升不能说明关键保障任务更可预测。
- RTA 中的执行时间和阻塞项若未经目标硬件测量，不能作为安全上界。
@@ -1,41 +0,0 @@
-# KV Cache 与内存管理参考
-
-## 1. 与本项目的关系
-
-KV Cache 同时影响容量、内存带宽、请求并发和尾延迟。在 RTOS 场景中，研究重点不是单纯提高缓存命中率，而是控制动态分配、换入换出、DMA 和回收行为对关键任务造成的不可预测干扰。
-
-## 2. 核心必引资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| W. Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023. [arXiv](https://arxiv.org/abs/2309.06180) | A/B | 块式 KV 分配、碎片控制、共享与调度耦合 | 作为分页池设计和 vLLM 基线 |
-| Y. Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/sheng23a.html) | A | GPU/CPU/存储分层放置与 I/O 调度 | 支撑分层 KV/权重放置，但需强调其吞吐导向 |
-| Z. Zhang et al., “H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html) | A | 基于重要 token 的 KV 淘汰及质量影响 | 用于“容量—质量—时延”三目标实验 |
-| W. Lee et al., “InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management,” OSDI 2024. [USENIX](https://www.usenix.org/conference/osdi24/presentation/lee) | A | KV 预取、CPU offload、动态池管理 | 对应 CPU—加速器带宽与预取干扰研究 |
-| P. Patel et al., “vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention,” 2024. [arXiv](https://arxiv.org/abs/2405.04437) | B | 利用虚拟内存保持逻辑连续、比较分页内核复杂度 | 作为 PagedAttention 的替代路线和消融参考 |
-
-## 3. 研究问题映射
-
-| 本项目问题 | 参考资料启发 | 必须补充的 RTOS 证据 |
-|---|---|---|
-| 内存池预分配是否减少尾延迟 | PagedAttention 的块式管理 | 分配路径时延、关键任务 `P99.9/Max`、碎片率 |
-| KV 换出是否可控 | FlexGen、InfiniGen | DMA/内存带宽竞争、外部接口响应和违约率 |
-| KV 淘汰如何影响可用性 | H2O | 固定题集质量、输出可用率、恢复到全量 KV 的开销 |
-| 多请求是否相互污染 | 分页与共享机制 | 每租户上限、OOM 隔离、Jain 指数和逐租户 SLO |
-| B8/B16 容量边界 | 各类压缩/分页工作 | 峰值驻留集、KV 增长曲线、首次失败点和错误类型 |
-
-## 4. 建议实验变量
-
- KV 块大小、内存池大小、预分配比例和保留余量；
- 上下文长度、并发度、输出长度和突发到达；
- GPU/NPU 本地、主存和存储三级放置；
- 淘汰策略：LRU、近期 token、重要 token、固定配额；
- 是否锁页、是否异步预取、DMA 并发数和带宽限额。
-
-输出至少包括峰值内存、碎片率、分配失败率、KV 迁移字节数、带宽、`TTFT/TPOT`、质量、关键任务尾延迟和 OOM 恢复行为。
-
-## 5. 不应直接推出的结论
-
- 内存占用减少不必然降低端到端时延；压缩、索引和搬移可能增加尾延迟。
- 论文中的 perplexity 或准确率保持不代表任务关键应用输出可用。
- Linux/CUDA 的虚拟内存和 UVM 机制不能假定在 SylixOS、NPU SDK 或受限 SoC 上等价存在。
@@ -1,54 +0,0 @@
-# 加速器协同调度参考
-
-## 1. 与本项目的关系
-
-本方向研究 CPU 调度、驱动提交、DMA、GPU/NPU 执行和完成中断组成的完整链路。核心是识别哪些环节受 RTOS 控制，哪些环节只受厂商运行时或固件控制，并通过端到端时间戳验证协同效果。
-
-## 2. 核心资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| NVIDIA, “CUDA Programming Guide: Asynchronous Execution, Streams and Events.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html) | A | 流、事件、同步、并发和优先级语义 | 定义 CUDA 路线中的提交和同步边界 |
-| NVIDIA, “CUDA Programming Guide: Unified Memory.” [官方文档](https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/unified-memory.html) | A | CPU/GPU 统一内存、迁移及流关联 | 解释缺页/迁移引入的不确定性，不能替代实测 |
-| Z. Bai et al., “PipeSwitch: Fast Pipelined Context Switching for Deep Learning Applications,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/bai) | A | GPU 应用切换、模型传输与执行流水化 | 支撑多模型共享和切换开销研究 |
-| A. Gujarati et al., “Serving DNNs like Clockwork,” OSDI 2020. [USENIX](https://www.usenix.org/conference/osdi20/presentation/gujarati) | A | 可预测 GPU 推理、执行时间建模和准入 | 作为加速器可预测性相邻工作 |
-| Y. Choi, M. Rhu, “PREMA: A Predictive Multi-task Scheduling Algorithm for Preemptible Neural Processing Units,” HPCA 2020. [DOI](https://doi.org/10.1109/HPCA47549.2020.00030) | A | 可抢占 NPU 多任务预测调度 | 支撑 NPU 细粒度抢占的研究假设，需检查实际硬件支持 |
-| MLCommons, “MLPerf Inference.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、负载发生和准确率约束 | 用于外部性能方法对齐，不替代双目标测试 |
-
-## 3. 硬件路线需单独核对的官方资料
-
- NVIDIA：CUDA Toolkit、驱动、MPS/MIG、DCGM 与 NCCL 对应版本文档；
- Rockchip：RKNN Toolkit2、RKLLM、RKNPU2 Runtime 与对应芯片技术参考；
- 其他 NPU/GPU：运行时队列、优先级、超时、复位、DMA 和性能计数器文档；
- SylixOS：BSP、中断、DMA、一致性、IOMMU 和驱动接口资料。
-
-闭源资料若不能公开引用，应在论文中描述可复现的外部行为，不披露受限内容。
-
-## 4. 建议链路分解
-
-```text
-请求到达
-→ CPU 预处理
-→ 驱动/运行时提交
-→ DMA/内存迁移
-→ 加速器排队
-→ kernel/NPU task 执行
-→ 完成中断
-→ CPU 后处理
-→ 外部输出
-```
-
-每段都应有时间戳或外部观测点。设备事件只能衡量设备域执行，不能替代 CPU 到结果可用的端到端时延。
-
-## 5. 可形成的论文论点
-
-1. RTOS 可通过 CPU/IRQ 亲和性、队列限长、预分配和准入减少主机侧不确定性。
-2. 加速器运行时不提供硬优先级保证时，RTOS 的收益会受设备不可抢占区间限制。
-3. 异步流水可能提高吞吐，但需要同时检查关键任务尾延迟、内存带宽和中断干扰。
-4. 多加速器扩展需分开报告单请求并行、多实例吞吐与通信开销。
-
-## 6. 不应直接推出的结论
-
- CUDA stream priority 是调度提示，不是硬实时保证。
- GPU 支持并发 kernel 不代表特定工作负载必然并发执行。
- 加速器利用率高不等于有效吞吐高，也不等于关键任务 deadline 达标。
@@ -1,44 +0,0 @@
-# 量化与精度感知调度参考
-
-## 1. 与本项目的关系
-
-本方向不只比较 INT4/INT8/FP16 的速度，而是研究在不同任务紧迫度、资源预算和热状态下，能否选择满足质量门槛的最低成本精度，并保证切换过程不会破坏关键任务实时性。
-
-## 2. 核心必引资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| E. Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers,” ICLR 2023. [OpenReview](https://openreview.net/forum?id=tcbBPnfwxS) | A | 基于近似二阶信息的低比特权重量化 | 作为 3/4-bit PTQ 方法基线 |
-| G. Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models,” ICML 2023. [PMLR](https://proceedings.mlr.press/v202/xiao23c.html) | A | W8A8、激活离群值平滑、硬件效率 | 作为 INT8 权重—激活量化基线 |
-| J. Lin et al., “AWQ: Activation-aware Weight Quantization for On-Device LLM Compression and Acceleration,” MLSys 2024. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html) | A | 面向端侧的激活感知权重量化 | 对应 T5/T4/T3 设备端路线 |
-| T. Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale,” NeurIPS 2022. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html) | A | 激活离群值与混合精度分解 | 支撑异常通道和精度保持讨论 |
-| T. Dettmers et al., “QLoRA: Efficient Finetuning of Quantized LLMs,” NeurIPS 2023. [NeurIPS](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html) | A | NF4、双重量化和分页优化器 | 主要用于背景；本项目若不训练，不作为主实验 |
-| Z. Lin et al., “QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving,” MLSys 2025. [MLSys](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html) | A | 权重、激活和 KV 联合低比特系统设计 | 支撑量化与内存/内核协同研究 |
-
-## 3. 精度感知调度应补足的研究空白
-
-现有量化论文通常回答“某种格式能否保持平均精度并加速推理”，但本项目还需要回答：
-
- 精度切换是否引起模型加载、重新编译、缓存失效或内存峰值；
- 动态切换期间关键保障负载是否出现尾延迟峰值；
- 低比特内核在目标 NPU/GPU 上是否真正加速，而非只有模型更小；
- 质量门槛、实时门槛和功耗门槛能否同时满足；
- 对不同风险等级请求，能否采用不同的可接受精度下限。
-
-## 4. 建议实验矩阵
-
-| 维度 | 建议取值 |
-|---|---|
-| 精度 | FP16/BF16、INT8、INT4；仅测试后端真实支持项 |
-| 模型变量 | 同一模型修订、同一 tokenizer、同一输入与解码参数 |
-| 质量 | 固定题集、perplexity/准确率/F1/任务判分、输出可用率 |
-| 性能 | TTFT、TPOT、端到端时延、有效吞吐 |
-| 系统 | 峰值内存、切换时间、能耗、温度、关键任务违约与尾延迟 |
-| 调度 | 静态精度、基于 deadline 的精度、基于热/功耗预算的精度 |
-
-## 5. 不应直接推出的结论
-
- 权重压缩比不能替代整机内存、速度或能效实测。
- perplexity 接近不等于所有任务质量和安全性等价。
- 不同量化后端的算子、校准和数值格式不同，通常只能视为整套软件栈比较。
- 动态精度调度若未测切换开销，不能宣称适合实时路径。
@@ -1,54 +0,0 @@
-# 中断与实时性保障参考
-
-## 1. 与本项目的关系
-
-本方向为论文的“可保障性”提供理论和系统基础，覆盖固定优先级响应时间、共享资源阻塞、优先级倒置、中断线程化、CPU/IRQ 亲和性以及外部闭环测量。
-
-## 2. 经典理论资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| C. L. Liu, J. W. Layland, “Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment,” 1973. [DOI](https://doi.org/10.1145/321738.321743) | A | RMS/EDF 与周期任务基础 | 建立基本任务模型 |
-| L. Sha, R. Rajkumar, J. P. Lehoczky, “Priority Inheritance Protocols: An Approach to Real-Time Synchronization,” IEEE TC, 1990. [DOI](https://doi.org/10.1109/12.57058) | A | 优先级继承、优先级上限与有界阻塞 | 支撑锁竞争和优先级倒置分析 |
-| N. Audsley et al., “Applying New Scheduling Theory to Static Priority Pre-emptive Scheduling,” 1993. [DOI](https://doi.org/10.1049/sej.1993.0034) | A | 含阻塞和抖动的精确固定优先级分析 | 构建含 IRQ/驱动阻塞的 RTA |
-| K. Tindell, A. Burns, A. Wellings, “An Extendible Approach for Analyzing Fixed Priority Hard Real-Time Tasks,” Real-Time Systems, 1994. [DOI](https://doi.org/10.1007/BF01088593) | A | 固定优先级分析扩展 | 用于更复杂任务和通信分析 |
-
-## 3. 内核与测量资料
-
-| 资料 | 等级 | 可支撑内容 |
-|---|---|---|
-| Linux Kernel, “PREEMPT_RT Theory of Operation.” [官方文档](https://docs.kernel.org/core-api/real-time/theory.html) | A | 可抢占锁、rtmutex、优先级继承和线程化中断 |
-| Linux Kernel, “How realtime kernels differ.” [官方文档](https://docs.kernel.org/core-api/real-time/differences.html) | A | 普通 Linux 与 PREEMPT_RT 的内核语义差异 |
-| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | 唤醒延迟工具、参数、限制和最大值解释 |
-| Linux `rt-tests` 项目. [kernel.org](https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/) | B | cyclictest、hwlatdetect 等实现与版本记录 |
-
-## 4. 本项目分析框架
-
-关键任务响应时间可写为：
-
-```text
-R_i = C_i + B_i + I_irq,i + I_sched,i
-      + sum(ceil((R_i + J_h) / T_h) * C_h)
-```
-
-其中 `C_i` 是自身执行时间，`B_i` 是共享资源阻塞，`I_irq,i` 是中断与驱动干扰，`I_sched,i` 是调度器和不可抢占区间干扰，求和项是高优先级任务干扰。该式只用于组织分析；每个项的取值和适用假设必须单独验证。
-
-实测至少覆盖：
-
- 计划释放、就绪、开始和完成时间；
- 唤醒延迟、响应时间、完成抖动、违约率和观测最大值；
- IRQ 数量、处理时间、CPU 亲和性和最长关中断区间；
- 推理提交、DMA 和完成中断与关键任务峰值的时间关联；
- GPIO/CAN/RS485/网络外部回路端到端时延。
-
-## 5. 对照与消融
-
- O0 普通 Linux、O1 PREEMPT_RT、O2 SylixOS 默认、O3 SylixOS 优化、必要时 O4 等预算调优；
- 逐项去除 CPU 隔离、IRQ 亲和性、优先级继承、内存预分配和推理准入；
- 同时报人工智能有效吞吐代价，避免通过饿死推理任务获得低抖动。
-
-## 6. 不应直接推出的结论
-
- cyclictest 测得的是特定路径的唤醒延迟，通常不等于业务任务完整响应时间。
- 实测最大值不是 WCET；零违约不是硬实时证明。
- PREEMPT_RT 和专用 RTOS 的机制差异必须通过等价任务语义比较，不能只比较工具默认输出。
@@ -1,51 +0,0 @@
-# 能耗与热管理参考
-
-## 1. 与本项目的关系
-
-本方向关注满足人工智能和关键实时约束时的能效，而不是脱离任务完成质量的最低功率。功率、温度、频率、有效吞吐和违约必须使用对齐的时间窗口联合分析。
-
-## 2. 核心资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| MLCommons, “MLPerf Inference Power Measurement.” [官方文档](https://docs.mlcommons.org/inference/power/) | A | 外部功率分析仪、PTDaemon、测量窗口和配置 | 设计整机功耗采集链路 |
-| MLCommons, “MLPerf Inference Benchmark Suite.” [官方文档](https://docs.mlcommons.org/inference/index_gh/) | A | Edge/Datacenter 场景、性能与准确率约束 | 对齐负载发生和结果报告方法 |
-| SPEC, “SPECpower_ssj2008.” [官方资料](https://www.spec.org/osg/power_ssj2008/) | A | AC 输入功率—性能联合测量、负载档位 | 借鉴整机边界和多负载点报告 |
-| W. Huang et al., “HotSpot: A Compact Thermal Modeling Methodology for Early-Stage VLSI Design,” IEEE TVLSI, 2006. [DOI](https://doi.org/10.1109/TVLSI.2006.876103) | A | 热 RC 模型、瞬态与稳态温度 | 支撑热动态建模背景，不替代板级传感器实测 |
-| NVIDIA, “DCGM Field Identifiers.” [官方文档](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html) | A | GPU 功率、能量、温度、频率和降频原因 | V100/H100 路线的设备侧归因数据 |
-
-## 3. 统一计算口径
-
-```text
-E_total = integral(P(t), t0, t1)
-E/token = E_total / N_output
-effective_E/token = E_total / N_qualified_output
-tokens/J = N_output / E_total
-throttling_ratio = throttled_time / valid_measurement_time
-```
-
-主结果使用整机输入端测量。设备遥测只作归因；TDP、标称功耗和电源额定值不能替代实测。`N_output=0` 时能效不可计算。
-
-## 4. 建议实验
-
-1. 空闲、prefill、decode 和混合负载分阶段功率曲线；
-2. 25/50/75/100% 负载下的温度—频率—性能耦合；
-3. 不同固定频率/DVFS/功耗上限下的 `E/token` 与 deadline miss；
-4. 冷态、热稳态和 24 h 后的 TTFT/TPOT、吞吐与关键任务尾延迟；
-5. 降频前后同一到达流的有效吞吐变化；
-6. O0～O4 在相同双目标门槛下的能效比较。
-
-每次运行记录环境温度、散热方式、风扇策略、功率计型号、量程、精度和采样率。
-
-## 5. 可形成的论文论点
-
- RTOS 的准入、空闲管理和频率策略可能降低无效执行和失败请求的能耗。
- 更低精度或更高并发可能降低 `J/token`，但热饱和后可能扩大尾延迟和违约率。
- 应寻找满足双目标约束的 Pareto 前沿，而不是独立最小化功率或最大化吞吐。
-
-## 6. 不应直接推出的结论
-
- 芯片遥测功率不能代表整机功率。
- 短时冷态跑分不能代表热稳态或 24 h 性能。
- 更低平均功率不等于更低任务能耗；运行时间延长可能提高总能量。
- 未取得温箱数据时不能宣称覆盖全温域。
@@ -1,66 +0,0 @@
-# 方法论与评估工具链参考
-
-## 1. 与本项目的关系
-
-本方向决定实验结果能否复现、能否公平比较，以及能否从“跑分差异”上升为“RTOS 双目标保障边界”的研究结论。
-
-## 2. 核心资料
-
-| 资料 | 等级 | 可支撑内容 | 本项目使用方式 |
-|---|---|---|---|
-| J. Dean, L. A. Barroso, “The Tail at Scale,” CACM, 2013. [Google Research](https://research.google/pubs/the-tail-at-scale/) | A | 大规模系统尾延迟的来源和重要性 | 支撑 P99/P99.9 而非均值作为核心证据 |
-| V. J. Reddi et al., “MLPerf Inference Benchmark,” 2019. [arXiv](https://arxiv.org/abs/1911.02549) | A/B | 标准负载发生、场景、准确率与性能方法 | 作为 AI 基准方法学参照 |
-| MLCommons, “MLPerf Inference Submission Guide.” [官方文档](https://docs.mlcommons.org/inference/submission/) | A | LoadGen、系统描述、Closed/Open division 和可比性 | 设计外部基准对齐和 manifest |
-| ACM, “Artifact Review and Badging.” [官方政策](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | A | 可用、可运行、可复用与结果复现 | 规划代码、数据和复现包 |
-| Linux Foundation Real-Time Linux, “Cyclictest.” [官方文档](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start) | A/B | RT 延迟测试设计、参数和限制 | 作为 Linux 辅助基线及测量避坑依据 |
-| R. Jain, D.-M. Chiu, W. Hawe, “A Quantitative Measure of Fairness and Discrimination,” DEC TR-301, 1984. [PDF](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf) | A/B | Jain 公平指数 | 多租户相对独占吞吐公平性 |
-
-## 3. 本项目最低方法要求
-
-### 3.1 公平对照
-
-冻结模型修订、tokenizer、量化文件、输入/输出、到达序列、随机种子、硬件、核心数、内存预算、加速器数、功耗策略和散热条件。无法使用同一推理后端时，区分“OS 调度效应”和“整套软件栈效应”。
-
-### 3.2 样本与重复
-
- 普通性能单元至少 5 次独立运行；
- 请求级 P99.9 以至少 10 万有效请求为目标，样本不足则降级为 P99 或标为探索性；
- 1 ms 周期任务记录计划释放数、缺失数和全部违约；
- 长稳运行 24 h，保留完整时间序列；
- 跨运行使用中位数、区间及按运行/时间块 bootstrap。
-
-### 3.3 失败处理
-
-拒绝、超时、OOM、重启、日志中断和测量失败必须保留并分类。只有仪器、程序或配置失效的批次可标为无效，且需保留原文件和原因。
-
-### 3.4 三层证据
-
-```text
-AI 目标负载：TTFT/TPOT/端到端/质量/可用性
-关键保障负载：违约率/P99.9/Max/外部闭环
-系统协同：有效吞吐/E-token/热/公平/恢复/24 h
-```
-
-任何“更优”结论都必须说明另外两层是否仍达标。
-
-## 4. 工具链建议
-
-| 目的 | 工具或方式 | 注意事项 |
-|---|---|---|
-| OS 跟踪 | SylixOS trace、ftrace、perf、事件日志 | 统一事件语义，不直接比较工具自身字段 |
-| RT 辅助测试 | rt-tests/cyclictest、GPIO 打点 | cyclictest 不等于业务端到端响应 |
-| 加速器分析 | CUDA profiler/DCGM、RKNN/RKLLM 日志 | 版本固定；设备事件只作阶段分解 |
-| 外部时序 | 示波器、逻辑分析仪、CAN/RS485 分析仪 | 保存探头、触发、分辨率和空回路基线 |
-| 功率与热 | 外部功率计/PDU、板载温度与频率 | 时间窗口对齐，遥测不替代整机功率 |
-| 分析 | R/Python、bootstrap、CDF/ECDF、时间序列 | 不静默删异常，不把相关样本当独立样本 |
-
-## 5. 推荐数据结构
-
-每次运行保留 `manifest.json`、`requests.csv`、`rt.csv`、`power.csv`、`thermal.csv`、`events.log` 和 `summary.json`。原始数据只读保存，图表和摘要由版本化脚本生成。
-
-## 6. 不应直接推出的结论
-
- 统计显著不等于工程差异重要，应同时报告效应量与阈值。
- 单次最佳结果不能代表配置能力。
- 公开基准与本项目负载语义不同，只能用于方法对齐或外部锚点。
- 未完成的 T5～T1 档位必须标为计划，不能与实测数据连成“连续规律”。
@@ -1,57 +0,0 @@
-# 标准与工程资料参考
-
-## 1. 文档定位
-
-本文件列出论文方向可能涉及但不应与学术论文混为一谈的标准、官方工程文档和安全边界资料。标准是否适用取决于最终行业场景、系统边界和认证目标。
-
-## 2. 功能安全与任务关键系统
-
-| 标准/资料 | 适用范围 | 本项目可能的关系 |
-|---|---|---|
-| IEC 61508, *Functional safety of electrical/electronic/programmable electronic safety-related systems* | 通用功能安全 | 定义安全生命周期、SIL 和证据要求；本项目不应在未认证时宣称合规 |
-| ISO 26262, *Road vehicles — Functional safety* | 道路车辆 | 若落到车载控制与 AI 辅助功能，可用于场景和安全目标分解 |
-| ISO/PAS 8800, *Road vehicles — Safety and artificial intelligence* | 车载 AI 安全 | 用于 AI 输出不确定性、数据和安全论证背景 |
-| DO-178C | 航空机载软件 | 若研究航空部署，可参考软件保证等级和验证独立性 |
-| ARINC 653 | 航空综合模块化系统分区 | 支撑时间/空间分区的相邻工程背景 |
-| IEC 62443 系列 | 工业自动化与控制系统安全 | 涉及联网工业控制时补充网络安全边界 |
-
-正式引用应从 IEC、ISO、RTCA、EUROCAE、SAE 或 ARINC 的标准目录核对版本与访问权限。标准通常受版权保护，本仓库只保存条目和适用性说明，不复制正文。
-
-## 3. 实时通信与时间同步
-
-| 标准/资料 | 作用 | 使用边界 |
-|---|---|---|
-| IEEE 802.1AS | 广义精确时间协议 | 跨设备单向时延需要同步精度证据 |
-| IEEE 802.1Qbv | 时间感知整形 | 可用于 TSN 周期流量窗口规划 |
-| IEEE 802.1Qbu / IEEE 802.3br | 帧抢占 | 分析关键流量受大帧阻塞的边界 |
-| IEEE 1588 | 精确时间协议 | 记录 grandmaster、硬件时间戳和误差 |
-| CAN/CAN FD、RS-485 对应规范 | 工业接口 | 固定波特率、帧长、总线负载和时间戳位置 |
-
-## 4. 操作系统与处理器接口资料
-
- Linux PREEMPT_RT 官方文档：[Real-time preemption](https://docs.kernel.org/core-api/real-time/index.html)。
- POSIX 实时扩展：线程调度、时钟、定时器、内存锁定和优先级协议；需按目标 OS 支持集核对。
- Arm 架构、GIC、SMMU 和缓存一致性官方手册：用于解释中断路由、DMA 和共享内存边界。
- PCIe、IOMMU、NVLink、NCCL 等规范或官方文档：用于多加速器/多节点通信路径。
- SylixOS BSP/API/驱动资料：用于确认优先级、中断、内存、设备复位和追踪接口的实际能力。
-
-## 5. 基准与测量规范
-
-| 资料 | 可借鉴内容 |
-|---|---|
-| [MLPerf Inference](https://docs.mlcommons.org/inference/index_gh/) | 场景、负载发生、准确率约束、系统描述与结果合规 |
-| [MLPerf Power](https://docs.mlcommons.org/inference/power/) | 外部仪器、时间同步、测量窗口与功率记录 |
-| [SPECpower_ssj2008](https://www.spec.org/osg/power_ssj2008/) | 整机 AC 功率、多个负载档位与功效比 |
-| [ACM Artifact Review and Badging](https://www.acm.org/publications/policies/artifact-review-and-badging-current) | 可用、可运行、可复用和结果复现证据 |
-
-## 6. 论文中的合规表述
-
-建议使用：
-
-> 本研究借鉴相关标准中的任务关键性、时间/空间隔离和测量原则，但实验平台与研究原型未经过相应行业认证，因此结果不构成功能安全等级、适航或产品合规声明。
-
-避免使用：
-
- “满足 SIL2/SIL3”——除非完成规定流程并取得正式证据；
- “达到航空级/车规级”——除非硬件、软件、流程和环境均符合对应标准；
- “证明硬实时安全”——除非有完整时序模型、可信 WCET、可调度性证明和覆盖充分的验证证据。
@@ -1,51 +0,0 @@
-# 论文方向参考文件索引
-
-## 1. 目录用途
-
-本目录为 `10-研究框架` 七个研究方向提供可追溯的论文、标准和工程资料入口。它不是完整综述，也不代表文中列出的方案已经在 SylixOS 或本项目硬件上得到验证。
-
-参考资料按以下证据等级使用：
-
-| 等级 | 类型 | 建议用途 |
-|---|---|---|
-| A | 同行评审论文、正式标准、官方内核/硬件文档 | 支撑定义、方法选择和主要论证 |
-| B | arXiv 预印本、官方项目文档、开放源码实现 | 支撑前沿方案、实现路线和复现实验 |
-| C | 厂商白皮书、博客或二手综述 | 仅作背景和线索，不单独支撑核心结论 |
-
-优先引用论文正式页面、DOI、标准组织或厂商官方文档。正式写作前仍需通过学校或机构数据库核对作者、卷期、页码、版本和 BibTeX。
-
-## 2. 文件与研究方向映射
-
-| 文件 | 对应研究文件 | 主要主题 |
-|---|---|---|
-| [01-推理图任务调度参考.md](./01-推理图任务调度参考.md) | `01-推理图任务调度.md` | 经典实时调度、LLM 连续批处理、prefill/decode 调度、SLO |
-| [02-KV-Cache与内存管理参考.md](./02-KV-Cache与内存管理参考.md) | `02-KV-Cache与内存管理.md` | 分页、换出、压缩、淘汰、容量隔离 |
-| [03-加速器协同调度参考.md](./03-加速器协同调度参考.md) | `03-加速器协同调度.md` | CPU/GPU/NPU 协同、流、事件、DMA、共享与切换 |
-| [04-量化与精度感知调度参考.md](./04-量化与精度感知调度参考.md) | `04-量化精度感知调度.md` | PTQ、权重量化、激活量化、KV 量化、精度—时延联合约束 |
-| [05-中断与实时性保障参考.md](./05-中断与实时性保障参考.md) | `05-中断与实时性保障.md` | PREEMPT_RT、优先级继承、响应时间分析、中断线程化、测试 |
-| [06-能耗与热管理参考.md](./06-能耗与热管理参考.md) | `06-能耗与热管理.md` | 整机功耗、E/token、DVFS、温度、降频与热漂移 |
-| [07-方法论与评估工具链参考.md](./07-方法论与评估工具链参考.md) | `07-方法论与评估工具链.md` | MLPerf、尾延迟、统计、可复现性、长稳与公平性 |
-| [08-标准与工程资料参考.md](./08-标准与工程资料参考.md) | 全部方向 | 功能安全、时间敏感网络、硬件接口与工程边界 |
-| [参考文献.md](./参考文献.md) | 论文十章与整个项目 | 连续编号的论文参考文献候选清单与章节映射 |
-
-## 3. 建议引用策略
-
-每项核心主张至少建立“理论基础 + 相邻系统工作 + 本项目实测”三段证据：
-
-```text
-经典理论或标准
-  → LLM/AI 系统领域的相邻工作
-  → 本项目在 O0～O4、T5～T1 条件下的实测与边界
-```
-
-例如，“RTOS 优化提高双目标可保障性”不能只引用 vLLM 或 PREEMPT_RT 文档，而应同时给出实时调度理论、LLM 服务调度工作、对照实验与消融结果。
-
-## 4. 维护规则
-
- 每条新资料需记录标题、作者或组织、年份、正式入口和与本项目的关系。
- 预印本被正式会议或期刊接收后，优先替换为正式版本。
- 厂商文档需记录访问日期和软件/驱动版本。
- 不将论文报告的相对提升直接移植为本项目预期值。
- 不将“平均性能改善”表述为硬实时保证；不将“未观测到违约”表述为理论最坏界。
-
-本目录最后核验日期：**2026-09-21**。
@@ -1,170 +0,0 @@
-# 论文参考文献候选清单
-
-## 1. 文档说明
-
-本文依据仓库根目录的 `最终稿文章规划.md`、`00-项目总览`、`10-研究框架`、`20-实验与规划` 以及现有参考文件，整理拟投实时系统、嵌入式系统或机器学习系统会议论文时可使用的参考文献。
-
-书目格式参照 `GB/T 7714—2015`，英文会议论文保留原始会议名称。在线文档统一记录访问日期 `2026-09-21`。最终投稿时应使用目标会议的 BibTeX/LaTeX 样式重新生成，并再次核对作者、页码、DOI 和版本。
-
-当前项目已经从旧规划中的“四层谱系”调整为 `T5~T1` 五类部署形态与 11 个代表档位。本文献表按当前项目口径组织，但仍可支撑旧版 `最终稿文章规划.md` 的十章结构。
-
-## 2. 章节—参考文献映射
-
-| 论文内容 | 建议优先引用 | 支撑作用 |
-|---|---|---|
-| 第1章 引言 | `[1]~[10]`、`[42]`、`[50]~[53]` | 实时保障基础、任务关键 AI 背景和安全边界 |
-| 第2章 背景与相关工作 | `[1]~[32]` | 经典调度、PREEMPT_RT、LLM 推理服务、KV Cache、加速器和量化 |
-| 第3章 部署形态与硬件谱系 | `[34]~[39]`、`[43]~[47]` | Edge/Datacenter 方法、功率边界、模型与推理运行时 |
-| 第4章 SylixOS 调度框架 | `[1]~[9]`、`[12]~[33]`、`[43]~[47]` | 任务图、内存、异构加速、量化、中断与运行时实现 |
-| 第5章 实验方法学 | `[5]`、`[6]`、`[34]~[42]`、`[48]`、`[49]` | 延迟测试、MLPerf、功率、统计、公平性和可复现性 |
-| 第6章 模型与负载 | `[11]`、`[12]`、`[27]~[33]`、`[43]~[47]` | Transformer、低比特模型、Qwen、llama.cpp、TensorRT-LLM |
-| 第7章 实验结果 | `[34]~[41]` | 指标、功率、尾延迟、温度、公平性和统计解释 |
-| 第8章 深入分析 | `[1]~[33]`、`[37]~[41]` | 根因分析、机制对照与跨层权衡 |
-| 第9章 威胁有效性 | `[7]~[10]`、`[34]~[42]`、`[48]~[53]` | 系统边界、复现性、功能安全与跨设备测量限制 |
-| 第10章 结论与展望 | `[23]`、`[24]`、`[26]`、`[33]`、`[50]~[53]` | 动态调度、精度/资源协同、任务关键 AI 和安全论证 |
-
-## 3. 实时调度、RTOS 与操作系统基础
-
-[1] LIU C L, LAYLAND J W. Scheduling algorithms for multiprogramming in a hard-real-time environment[J]. Journal of the ACM, 1973, 20(1): 46-61. DOI: [10.1145/321738.321743](https://doi.org/10.1145/321738.321743).
-
-[2] SHA L, RAJKUMAR R, LEHOCZKY J P. Priority inheritance protocols: An approach to real-time synchronization[J]. IEEE Transactions on Computers, 1990, 39(9): 1175-1185. DOI: [10.1109/12.57058](https://doi.org/10.1109/12.57058).
-
-[3] AUDSLEY N, BURNS A, RICHARDSON M, et al. Applying new scheduling theory to static priority pre-emptive scheduling[J]. Software Engineering Journal, 1993, 8(5): 284-292. DOI: [10.1049/sej.1993.0034](https://doi.org/10.1049/sej.1993.0034).
-
-[4] TINDELL K, BURNS A, WELLINGS A J. An extendible approach for analyzing fixed priority hard real-time tasks[J]. Real-Time Systems, 1994, 6(2): 133-151. DOI: [10.1007/BF01088593](https://doi.org/10.1007/BF01088593).
-
-[5] LINUX KERNEL COMMUNITY. Theory of operation: Real-time preemption[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/theory.html](https://docs.kernel.org/core-api/real-time/theory.html).
-
-[6] LINUX FOUNDATION REAL-TIME LINUX. Cyclictest: Test design, interpretation and limitations[EB/OL]. [2026-09-21]. [https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start](https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start).
-
-[7] 翼辉信息. SylixOS 概述[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html](https://docs.acoinfo.com/sylixos/app/introduction_to_operating_systems/sylixos_overview.html).
-
-[8] 翼辉信息. SylixOS 发展历程[EB/OL]. [2026-09-21]. [https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html](https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html).
-
-[9] QNX. Priorities and scheduling: QNX Neutrino RTOS[EB/OL]. [2026-09-21]. [https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html](https://qnx.com/developers/docs/7.0.0/com.qnx.doc.neutrino.prog/topic/overview_PRIOR.html).
-
-[10] THE OPEN GROUP. POSIX.1-2024: Realtime functions and general information[S/OL]. 2024[2026-09-21]. [https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html).
-
-## 4. Transformer、LLM 推理调度与服务系统
-
-[11] VASWANI A, SHAZEER N, PARMAR N, et al. Attention is all you need[C]//Advances in Neural Information Processing Systems 30. 2017: 5998-6008. [https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need](https://proceedings.neurips.cc/paper/7181-attention-is-all-you-need).
-
-[12] DAO T, FU D Y, ERMON S, et al. FlashAttention: Fast and memory-efficient exact attention with IO-awareness[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html](https://proceedings.neurips.cc/paper/2022/hash/67d57c32e20fd0a7a302cb81d36e40d5-Abstract-Conference.html).
-
-[13] DAO T. FlashAttention-2: Faster attention with better parallelism and work partitioning[C]//International Conference on Learning Representations. 2024. [https://openreview.net/forum?id=mZn2Xyh9Ec](https://openreview.net/forum?id=mZn2Xyh9Ec).
-
-[14] YU G I, JEONG J S, KIM G W, et al. Orca: A distributed serving system for Transformer-based generative models[C]//16th USENIX Symposium on Operating Systems Design and Implementation. 2022. [https://www.usenix.org/conference/osdi22/presentation/yu](https://www.usenix.org/conference/osdi22/presentation/yu).
-
-[15] KWON W, LI Z, ZHUANG S, et al. Efficient memory management for large language model serving with PagedAttention[C]//Proceedings of the 29th ACM Symposium on Operating Systems Principles. 2023. [https://arxiv.org/abs/2309.06180](https://arxiv.org/abs/2309.06180).
-
-[16] AGRAWAL A, KEDIA N, PANWAR A, et al. Taming throughput-latency tradeoff in LLM inference with Sarathi-Serve[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 117-134. [https://www.usenix.org/conference/osdi24/presentation/agrawal](https://www.usenix.org/conference/osdi24/presentation/agrawal).
-
-[17] ZHONG Y, LIU S, CHEN J, et al. DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 193-210. [https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin](https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin).
-
-[18] SUN B, HUANG Z, ZHAO H, et al. Llumnix: Dynamic scheduling for large language model serving[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 173-191. [https://www.usenix.org/conference/osdi24/presentation/sun-biao](https://www.usenix.org/conference/osdi24/presentation/sun-biao).
-
-[19] GUJARATI A, KARANASOS K, CURINO C, et al. Serving DNNs like Clockwork: Performance predictability from the bottom up[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020. [https://www.usenix.org/conference/osdi20/presentation/gujarati](https://www.usenix.org/conference/osdi20/presentation/gujarati).
-
-[20] SHENG Y, ZHENG L, YUAN B, et al. FlexGen: High-throughput generative inference of large language models with a single GPU[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202. [https://proceedings.mlr.press/v202/sheng23a.html](https://proceedings.mlr.press/v202/sheng23a.html).
-
-[21] ZHANG Z, SHENG Y, ZHOU T, et al. H2O: Heavy-Hitter Oracle for efficient generative inference of large language models[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/6ceefa7b15572587b78ecfcebb2827f8-Abstract.html).
-
-[22] LEE W, LEE J, SEO J, et al. InfiniGen: Efficient generative inference of large language models with dynamic KV cache management[C]//18th USENIX Symposium on Operating Systems Design and Implementation. 2024: 155-172. [https://www.usenix.org/conference/osdi24/presentation/lee](https://www.usenix.org/conference/osdi24/presentation/lee).
-
-[23] PRABHU R, NAYAK A, MOHAN J, et al. vAttention: Dynamic memory management for serving LLMs without PagedAttention[EB/OL]. arXiv:2405.04437, 2024[2026-09-21]. [https://arxiv.org/abs/2405.04437](https://arxiv.org/abs/2405.04437).
-
-[24] BAI Z, ZHANG Z, ZHU Y, et al. PipeSwitch: Fast pipelined context switching for deep learning applications[C]//14th USENIX Symposium on Operating Systems Design and Implementation. 2020: 499-514. [https://www.usenix.org/conference/osdi20/presentation/bai](https://www.usenix.org/conference/osdi20/presentation/bai).
-
-[25] CHOI Y, RHU M. PREMA: A predictive multi-task scheduling algorithm for preemptible neural processing units[C]//2020 IEEE International Symposium on High Performance Computer Architecture. 2020. DOI: [10.1109/HPCA47549.2020.00030](https://doi.org/10.1109/HPCA47549.2020.00030).
-
-[26] NVIDIA. CUDA Programming Guide: Asynchronous execution, streams and events[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html](https://docs.nvidia.com/cuda/cuda-programming-guide/02-basics/asynchronous-execution.html).
-
-## 5. 量化、低比特推理与质量约束
-
-[27] DETTMERS T, LEWIS M, BELKADA Y, et al. LLM.int8(): 8-bit matrix multiplication for Transformers at scale[C]//Advances in Neural Information Processing Systems 35. 2022. [https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html](https://proceedings.neurips.cc/paper_files/paper/2022/hash/c3ba4962c05c49636d4c6206a97e9c8a-Abstract-Conference.html).
-
-[28] FRANTAR E, ASHKBOOS S, HOEFLER T, et al. GPTQ: Accurate post-training quantization for generative pre-trained Transformers[C]//International Conference on Learning Representations. 2023. [https://openreview.net/forum?id=tcbBPnfwxS](https://openreview.net/forum?id=tcbBPnfwxS).
-
-[29] XIAO G, LIN J, SEZNEC M, et al. SmoothQuant: Accurate and efficient post-training quantization for large language models[C]//Proceedings of the 40th International Conference on Machine Learning. PMLR, 2023, 202: 38087-38099. [https://proceedings.mlr.press/v202/xiao23c.html](https://proceedings.mlr.press/v202/xiao23c.html).
-
-[30] LIN J, TANG J, TANG H, et al. AWQ: Activation-aware weight quantization for on-device LLM compression and acceleration[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html).
-
-[31] DETTMERS T, PAGNONI A, HOLTZMAN A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]//Advances in Neural Information Processing Systems 36. 2023. [https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html](https://proceedings.neurips.cc/paper_files/paper/2023/hash/1feb87871436031bdc0f2beaa62a049b-Abstract.html).
-
-[32] LIN Y, TANG H, YANG S, et al. QServe: W4A8KV4 quantization and system co-design for efficient LLM serving[C]//Proceedings of Machine Learning and Systems. 2025, 7. [https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2025/hash/fbe2b2f74a2ece8070d8fb073717bda6-Abstract-Conference.html).
-
-[33] ZHAO Y, LIN C Y, ZHU K, et al. Atom: Low-bit quantization for efficient and accurate LLM serving[C]//Proceedings of Machine Learning and Systems. 2024, 6. [https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html](https://proceedings.mlsys.org/paper_files/paper/2024/hash/5edb57c05c81d04beb716ef1d542fe9e-Abstract-Conference.html).
-
-## 6. 评估、功耗、热管理与可复现性
-
-[34] REDDI V J, CHENG C, KANTER D, et al. MLPerf Inference Benchmark[EB/OL]. arXiv:1911.02549, 2019[2026-09-21]. [https://arxiv.org/abs/1911.02549](https://arxiv.org/abs/1911.02549).
-
-[35] MLCOMMONS. MLPerf Inference Benchmark Suite[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/index_gh/](https://docs.mlcommons.org/inference/index_gh/).
-
-[36] MLCOMMONS. MLPerf Inference power measurement[EB/OL]. [2026-09-21]. [https://docs.mlcommons.org/inference/power/](https://docs.mlcommons.org/inference/power/).
-
-[37] DEAN J, BARROSO L A. The tail at scale[J]. Communications of the ACM, 2013, 56(2): 74-80. [https://research.google/pubs/the-tail-at-scale/](https://research.google/pubs/the-tail-at-scale/).
-
-[38] HUANG W, GHOSH S, VELUSAMY S, et al. HotSpot: A compact thermal modeling methodology for early-stage VLSI design[J]. IEEE Transactions on Very Large Scale Integration Systems, 2006, 14(5): 501-513. DOI: [10.1109/TVLSI.2006.876103](https://doi.org/10.1109/TVLSI.2006.876103).
-
-[39] STANDARD PERFORMANCE EVALUATION CORPORATION. SPECpower_ssj2008[EB/OL]. [2026-09-21]. [https://www.spec.org/osg/power_ssj2008/](https://www.spec.org/osg/power_ssj2008/).
-
-[40] JAIN R, CHIU D M, HAWE W R. A quantitative measure of fairness and discrimination for resource allocation in shared computer systems[R]. DEC Research Report TR-301, 1984. [https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf](https://www.cse.wustl.edu/~jain/papers/ftp/fairness.pdf).
-
-[41] EFRON B, TIBSHIRANI R J. An introduction to the bootstrap[M]. New York: Chapman & Hall/CRC, 1993.
-
-[42] ASSOCIATION FOR COMPUTING MACHINERY. Artifact review and badging policy[EB/OL]. [2026-09-21]. [https://www.acm.org/publications/policies/artifact-review-and-badging-current](https://www.acm.org/publications/policies/artifact-review-and-badging-current).
-
-## 7. 模型、推理框架与工程实现资料
-
-[43] YANG A, YANG B, ZHANG B, et al. Qwen2.5 Technical Report[EB/OL]. arXiv:2412.15115, 2024[2026-09-21]. [https://arxiv.org/abs/2412.15115](https://arxiv.org/abs/2412.15115).
-
-[44] GGERGANOV, GGML-ORG. llama.cpp: LLM inference in C/C++[CP/OL]. [2026-09-21]. [https://github.com/ggml-org/llama.cpp](https://github.com/ggml-org/llama.cpp).
-
-[45] NVIDIA. TensorRT-LLM architecture overview[EB/OL]. [2026-09-21]. [https://nvidia.github.io/TensorRT-LLM/architecture/overview.html](https://nvidia.github.io/TensorRT-LLM/architecture/overview.html).
-
-[46] NVIDIA. NVIDIA Data Center GPU Manager: Field identifiers[EB/OL]. [2026-09-21]. [https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html](https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-api/dcgm-api-field-ids.html).
-
-[47] LINUX KERNEL COMMUNITY. How realtime kernels differ[EB/OL]. [2026-09-21]. [https://docs.kernel.org/core-api/real-time/differences.html](https://docs.kernel.org/core-api/real-time/differences.html).
-
-## 8. 任务关键 AI、功能安全与时间同步标准
-
-[48] ULLRICH L, BUCHHOLZ M, DIETMAYER K, et al. AI safety assurance for automated vehicles: A survey on research, standardization, regulation[J]. IEEE Transactions on Intelligent Vehicles, 2024. DOI: [10.1109/TIV.2024.3496797](https://doi.org/10.1109/TIV.2024.3496797).
-
-[49] IEC. IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems—Parts 1 to 7[S]. 2nd ed. Geneva: International Electrotechnical Commission, 2010. [https://webstore.iec.ch/en/publication/22273](https://webstore.iec.ch/en/publication/22273).
-
-[50] ISO. ISO 26262:2018, Road vehicles—Functional safety[S]. 2nd ed. Geneva: International Organization for Standardization, 2018. [https://www.iso.org/publication/PUB200262.html](https://www.iso.org/publication/PUB200262.html).
-
-[51] ISO. ISO/PAS 8800:2024, Road vehicles—Safety and artificial intelligence[S]. Geneva: International Organization for Standardization, 2024. [https://www.iso.org/standard/83303.html](https://www.iso.org/standard/83303.html).
-
-[52] IEEE. IEEE Std 1588-2019, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems[S]. New York: IEEE, 2019. [https://standards.ieee.org/ieee/1588/6825/](https://standards.ieee.org/ieee/1588/6825/).
-
-[53] RTCA. DO-178C: Software considerations in airborne systems and equipment certification[S]. Washington, D.C.: RTCA, 2011. [https://www.rtca.org/do-178/](https://www.rtca.org/do-178/).
-
-## 9. 使用与取舍建议
-
-### 9.1 核心正文优先保留
-
-受篇幅限制时，建议首先保留 `[1]~[6]`、`[11]`、`[14]~[22]`、`[25]~[30]`、`[34]~[42]`、`[49]~[52]`。它们分别支撑实时理论、LLM 服务、异构调度、量化、实验方法与任务关键边界。
-
-### 9.2 只作工程实现说明
-
-`[7]~[10]`、`[26]`、`[35]`、`[36]`、`[39]`、`[44]~[47]` 属于官方标准、文档或开源实现，适合说明平台能力、API 语义和实验工具，不宜单独用来证明算法创新或相对性能优势。
-
-### 9.3 需要谨慎使用
-
- `[23]`、`[34]`、`[43]` 为预印本或技术报告，投稿前应检查是否已有正式发表版本。
- 功能安全标准只能支撑需求与证据框架；本项目原型未完成对应认证时，不得据此宣称满足 SIL、ASIL 或适航要求。
- SylixOS、QNX、CUDA、TensorRT-LLM 等官方资料描述的是产品或接口能力，实际可用性仍需由本项目准入实验验证。
- 任何外部论文报告的倍数提升都不能移植为本项目预期结果，只能用于选择对照方案和解释机制。
-
-## 10. 待补充文献
-
-正式投稿前还应根据实际实验结果补充：
-
-1. 最终采用的 RKLLM/RKNN SDK、芯片手册和模型转换工具的固定版本文档；
-2. 实际使用的 SylixOS BSP、驱动和追踪工具文档；
-3. 若完成 T1 多节点实验，补充 NCCL、RDMA 和分布式推理的正式文献；
-4. 若完成 MoE 实验，补充专家路由、负载均衡和专家并行文献；
-5. 若论文转投 ISLPED，补充 DVFS、race-to-idle 与嵌入式热管理相关工作；
-6. 若论文面向车载或航空场景，按最终系统边界补充 ISO 26262、ISO/PAS 8800、DO-178C 及行业适用指南。
@@ -1,397 +0,0 @@
-# 核心证据指标说明
-
-## 1. 文档目的
-
-本文依据 [01-研究逻辑说明.md](./01-研究逻辑说明.md) 第 8 节，对后续实验必须覆盖的三层核心证据指标给出统一定义、计算方法、采集要求和报告口径。
-
-本指标体系用于回答一个核心问题：
-
-> **在人工智能目标负载与关键保障负载并存时，RTOS 能否在不牺牲任务质量和系统有效产出的前提下，提高系统的稳定性、可预测性与可保障性；这种提升在什么负载、功耗、温度和部署档位下成立。**
-
-指标分为三层：
-
-1. **人工智能目标负载层**：智能任务是否及时、正确、可用地完成；
-2. **关键保障负载层**：周期控制、联锁和外部闭环是否仍满足实时约束；
-3. **系统协同层**：双目标并存时，系统是否保持有效、节能、公平、稳定且可恢复。
-
-任何单一指标都不能独立支撑系统优越性结论。正式结论必须同时给出三层证据，并说明平台、OS、模型、负载、功耗、温度和运行时长等适用边界。
-
-## 2. 统一测量原则
-
-### 2.1 时间点与时钟
-
-人工智能请求至少记录以下时间点：
-
-| 符号 | 含义 |
-|---|---|
-| `a_i` | 请求计划到达时间 |
-| `s_i` | 请求实际发送时间 |
-| `u_i` | 服务端接收时间，可取得时记录 |
-| `g_i` | 首个有效输出到达时间 |
-| `c_i` | 完整输出到达或任务完成时间 |
-
-周期关键任务至少记录：
-
-| 符号 | 含义 |
-|---|---|
-| `r_i` | 计划释放时间 |
-| `q_i` | 进入就绪态时间，可等价取得时使用 |
-| `b_i` | 实际开始执行时间 |
-| `f_i` | 完成时间 |
-| `T` | 任务周期 |
-| `D` | 相对截止期 |
-
-同一指标必须在同一时钟域内计算，优先使用单调时钟。跨设备测量需在 `manifest` 中记录同步方法、同步误差和时间戳位置；同步误差不足以支持单向时延时，改报往返时延，不将往返时延简单除以二作为单向结果。
-
-### 2.2 统计与报告
-
- 时延和抖动至少报告样本数、`P50/P95/P99/P99.9` 和观测最大值；样本不足以稳定估计 `P99.9` 时，明确标为探索性结果并改以 `P99` 为主。
- 每个普通性能单元至少独立运行 5 次；跨运行报告中位数、区间和置信区间，不只报告最佳一次。
- 最大值只能表述为“指定时长和工况下的观测最大值”，不能写成理论 `WCET`。
- 零违约只能表述为“在 `N` 次计划释放中未观测到违约”，不能据此证明绝对硬实时安全。
- 原始超时、拒绝、OOM、丢样和失败请求必须保留，不能从分母中静默删除。
- OS 对照需冻结硬件、模型与量化版本、输入/输出长度、到达序列、随机种子、CPU/IRQ/频率配置、内存预算、加速器数量、散热条件和测量窗口。
-
-### 2.3 三层联合判定
-
-正式实验单元只有同时满足下列条件，才能记为“通过”：
-
-```text
-人工智能目标负载达标
-AND 关键保障负载达标
-AND 系统协同稳定
-```
-
-若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。
-
-## 3. 人工智能目标负载层
-
-### 3.1 TTFT
-
-`TTFT`（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间：
-
-```text
-TTFT_i = g_i - s_i
-```
-
-该指标包含请求传输、排队、调度和 prefill 阶段。负载发生器还应记录发送滞后 `s_i-a_i`，防止发生器本身饱和导致排队时间被遗漏。
-
-报告要求：
-
- 单位统一为 `ms`；
- 按模型、输入长度、并发度和到达率分别汇总；
- 至少报告 `P50/P95/P99/P99.9/Max`、样本数和超时数；
- 流式接口以客户端收到首个**有效内容 token**为终点，不把连接确认、空片段或仅含元数据的事件作为首 token；
- 非生成式人工智能任务不使用 `TTFT`，改用任务对应的首结果时间，并明确终点语义。
-
-### 3.2 TPOT
-
-`TPOT`（Time Per Output Token）描述首 token 之后的平均生成间隔。对输出 token 数 `n_i > 1` 的请求：
-
-```text
-TPOT_i = (c_i - g_i) / (n_i - 1)
-```
-
-报告要求：
-
- 单位统一为 `ms/token`；
- `n_i <= 1` 的请求记为不可计算，不以 0 填充；
- 请求级 `TPOT` 与逐 token 间隔分布分开报告；
- 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善；
- 按输入长度、输出长度、并发度和到达率分组。
-
-### 3.3 端到端响应时间
-
-端到端响应时间描述从请求实际发出到完整可用结果到达的时间：
-
-```text
-T_e2e,i = c_i - s_i
-```
-
-对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。
-
-除分位数外，还需按业务完成期限 `D_ai` 报告按时完成率：
-
-```text
-on_time_completion_ratio
-= count(success_i AND T_e2e,i <= D_ai) / planned_requests
-```
-
-### 3.4 成功率、任务质量与输出可用性
-
-三个概念必须分开计算：
-
-| 指标 | 定义 | 典型失败 |
-|---|---|---|
-| 请求成功率 | 协议和运行时层面正常完成的请求数 / 计划请求数 | 超时、拒绝、崩溃、OOM、传输失败 |
-| 任务质量 | 输出与冻结的参考答案或数据集指标之间的符合程度 | 精度下降、错误分类、内容偏差 |
-| 输出可用率 | 同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数 | 空输出、截断、格式错误、不可解析或不满足质量门槛 |
-
-计算式：
-
-```text
-success_ratio = successful_requests / planned_requests
-usable_output_ratio = usable_outputs / planned_requests
-```
-
-任务质量应按负载类型选择并预先冻结：
-
- LLM：固定题集得分、精确匹配、规则判分或人工盲评结果；
- 视觉检测：`mAP`、召回率、误检率；
- 分类：准确率、F1 等；
- 语音识别：`WER/CER`；
- 故障诊断：检出率、漏报率、误报率。
-
-量化或调度优化必须同时报告质量变化。仅提高速度但跌破质量门槛的输出不得计入有效结果。
-
-### 3.5 长时间运行稳定性
-
-人工智能负载稳定性用于检查持续运行时的性能和正确性是否退化。至少观测：
-
- 每个时间块的 `TTFT/TPOT/T_e2e` 分位数；
- 请求成功率、输出可用率和错误类型；
- 吞吐、队列长度、内存和 KV Cache 占用；
- 温度、实际频率、进程重启和驱动异常。
-
-建议将 24 h 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率：
-
-```text
-latency_drift = (late_block_metric - early_block_metric)
-                / early_block_metric
-```
-
-报告时需给出完整时间序列，不能仅给 24 h 总平均值。持续内存增长、尾延迟恶化、成功率下降或周期性驱动错误均应作为稳定性退化证据。
-
-## 4. 关键保障负载层
-
-### 4.1 Deadline miss ratio
-
-对第 `i` 次计划释放，若 `f_i > r_i + D`，则发生截止期违约：
-
-```text
-miss_i = 1, if f_i > r_i + D; otherwise 0
-deadline_miss_ratio = sum(miss_i) / planned_releases
-```
-
-要求：
-
- 分母必须是计划释放次数，而不是实际完成次数；
- 未释放、跳过、丢失或未完成的实例必须单独标记，不能直接从分母删除；
- 同时报告违约数、计划释放数、连续违约长度和违约发生时间；
- 按场景、负载强度和 OS 配置分别统计。
-
-### 4.2 P99/P99.9 jitter
-
-本文默认以完成间隔抖动作为关键保障负载的主抖动口径：
-
-```text
-jitter_i = (f_i - f_(i-1)) - T
-```
-
-同时可报告绝对抖动 `abs(jitter_i)`。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。
-
-报告要求：
-
- 有符号抖动报告上下尾，绝对抖动报告 `P99/P99.9/Max`；
- 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件；
- 给出样本量及采样周期；
- 不使用均值或标准差替代尾部分位数。
-
-### 4.3 观测最大响应时间
-
-关键任务响应时间定义为：
-
-```text
-R_i = f_i - r_i
-R_observed_max = max(R_i)
-```
-
-观测最大响应时间需要与截止期 `D` 并列展示，并给出裕量：
-
-```text
-deadline_margin = D - R_observed_max
-```
-
-`deadline_margin < 0` 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。
-
-### 4.4 外部接口响应时间
-
-外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路：
-
-```text
-T_external = t_external_output - t_external_input
-```
-
-采集要求：
-
- 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳；
- 固定波特率、帧长、总线负载、网络拓扑和时间戳位置；
- 报告空回路基线、测量分辨率和仪器误差；
- 报告 `P50/P99/P99.9/Max`、超时和丢帧；
- 内核或应用日志仅作为归因证据，不能替代外部闭环测量。
-
-## 5. 系统协同层
-
-### 5.1 有效吞吐
-
-有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出：
-
-```text
-effective_throughput
-= qualified_output_units / measurement_window
-```
-
-对 LLM，`qualified_output_units` 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。
-
-合格请求至少满足：
-
-```text
-请求成功
-AND TTFT/端到端期限达标
-AND 任务质量达标
-AND 输出可用
-AND 同一窗口内关键保障负载达标
-```
-
-有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。
-
-### 5.2 E/token
-
-在与负载统计完全一致的窗口 `[t0,t1]` 内：
-
-```text
-E_total = integral(P(t), t0, t1)
-E/token = E_total / N_output
-tokens/J = N_output / E_total
-```
-
-其中 `N_output` 为窗口内实际收到的输出 token 数。主结果使用整机输入端实测能耗，包含排队、空闲和失败请求消耗；板载或加速器遥测用于归因，不能替代整机测量。
-
-要求：
-
- 单位为 `J/token`，同时报告平均功率、峰值采样功率和仪器采样率；
- `N_output = 0` 时记为不可计算，不记为 0；
- 同时报有效 `E/token = E_total / N_qualified_output`，以反映失败和不合格输出的成本；
- 混合视觉与 LLM 负载时，不将全部能耗归因于 LLM，应使用独立对照或单列场景总能耗；
- 只在人工智能与关键保障约束均满足的配置之间比较能效。
-
-### 5.3 温度、降频与热漂移
-
-全程同步记录：
-
- 环境温度、芯片/板卡温度；
- CPU、GPU、NPU 和内存相关实际频率；
- 降频事件及其原因；
- 功率、风扇/散热策略；
- 同时间轴上的时延、吞吐和违约。
-
-降频时间比例定义为：
-
-```text
-throttling_ratio = throttled_time / valid_measurement_time
-```
-
-热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化：
-
-```text
-thermal_drift(metric)
-= (hot_steady_metric - early_steady_metric) / early_steady_metric
-```
-
-时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。
-
-### 5.4 多任务公平性
-
-多租户或多模型并发场景使用各任务相对独占性能 `x_i` 计算 Jain 公平指数：
-
-```text
-J = (sum(x_i))^2 / (k * sum(x_i^2))
-```
-
-其中 `k` 为任务数，`x_i` 可取“共享运行时的有效吞吐 / 独占运行时的有效吞吐”。`J` 越接近 1，吞吐分配越均衡。
-
-公平性不能只用一个指数概括，还应报告：
-
- 每个任务或租户的有效吞吐、`TTFT`、端到端时延和成功率；
- 关键任务是否满足各自服务等级；
- 饥饿次数、最长无服务时间和优先级倒置事件；
- 高优先级保障所造成的低优先级代价。
-
-对具有不同优先级和服务等级的任务，“公平”不是平均分配资源，而是在满足保障等级后不存在非预期饥饿。因此 Jain 指数只作为补充证据，不能替代逐任务 SLA 结果。
-
-### 5.5 恢复能力
-
-恢复测试应预先定义故障注入时刻 `t_fault` 和恢复判据。至少覆盖推理进程重启和队列过载；驱动重置、设备掉线或网络故障仅在存在安全、可恢复路径时执行。
-
-建议记录：
-
-| 指标 | 定义 |
-|---|---|
-| 故障检测时间 | 检测到故障的时刻减 `t_fault` |
-| 服务恢复时间 | 恢复到预定成功率和有效吞吐稳定区间的时刻减 `t_fault` |
-| 数据损失 | 故障窗口内丢失、重复或无法确认的请求数 |
-| 实时影响 | 故障窗口内关键任务违约数及最大响应时间 |
-| 重试成功率 | 成功重试请求数 / 发起重试请求数 |
-| 不可恢复故障数 | 需要人工干预、重启系统或丢失测量链路的次数 |
-
-恢复完成必须同时满足人工智能服务恢复和关键保障负载重新达标。仅进程重新启动但吞吐、队列或实时任务仍未恢复，不算恢复完成。
-
-### 5.6 24 h 长稳表现
-
-24 h 长稳采用人工智能目标负载、关键保障负载及必要伴生竞争负载的混合场景。至少连续记录：
-
- 三层核心指标的固定时间块汇总；
- 温度、频率、功率和降频事件；
- 内存、KV Cache、句柄/线程和队列长度；
- OOM、驱动错误、进程重启、接口超时和日志中断；
- 注入故障前后恢复曲线。
-
-长稳通过条件至少包括：
-
-1. 完成连续 24 h 有效测量；
-2. 无不可恢复故障；
-3. 测量与日志链路无中断；
-4. 无持续、不可解释的内存增长；
-5. 人工智能输出与关键保障负载在冻结阈值内；
-6. 故障注入后在冻结时间内恢复。
-
-若发生故障，必须保留原始数据并分析，不得删除故障批次后宣称长稳通过。
-
-## 6. 指标—数据源—实验映射
-
-| 层级 | 指标 | 主要数据源 | 主要实验/场景 |
-|---|---|---|---|
-| 人工智能目标负载 | `TTFT/TPOT`、端到端响应时间 | `requests.csv`、负载发生器、推理日志 | E2/E3/E8，L1～L7 |
-| 人工智能目标负载 | 成功率、质量、输出可用率 | 请求日志、固定题集/数据集、判分程序 | E2/E3/E4/E8 |
-| 人工智能目标负载 | 长时间稳定性 | 分块请求汇总、内存和错误日志 | E8，24 h |
-| 关键保障负载 | 违约率、抖动、最大响应时间 | `rt.csv`、RTOS trace、GPIO 打点 | E1/E3/E7/E8，L0/L2～L7 |
-| 关键保障负载 | 外部接口响应时间 | 示波器、逻辑/总线分析仪、抓包 | E1/E3/E8 |
-| 系统协同 | 有效吞吐 | 请求、质量和 RT 数据联合计算 | E3/E5/E7/E8 |
-| 系统协同 | `E/token` | 外部功率计/PDU、`requests.csv` | E2/E6/E8 |
-| 系统协同 | 温度、降频、热漂移 | `thermal.csv`、频率与功率日志 | E6/E8 |
-| 系统协同 | 多任务公平性 | 各租户请求日志和独占基线 | E5，L6 |
-| 系统协同 | 恢复与 24 h 长稳 | `events.log`、三层时间序列 | E8，L7 |
-
-## 7. 最小数据产物
-
-每次运行至少保存：
-
-| 文件 | 必需内容 |
-|---|---|
-| `manifest.json` | 平台/档位、OS/BSP/驱动、模型校验值、量化、输入、到达序列、CPU/IRQ/频率/内存配置、环境和仪器信息 |
-| `requests.csv` | 请求 ID、计划到达、实际发送、首/末输出、输出数、成功、质量、可用性、超时/拒绝原因 |
-| `rt.csv` | 计划释放、就绪、开始、完成、CPU、违约、丢失/跳过状态 |
-| `power.csv` | 时间戳、功率、电压、电流、仪器来源 |
-| `thermal.csv` | 时间戳、环境/芯片温度、实际频率、降频状态 |
-| `events.log` | OOM、驱动错误、故障注入、重启、网络异常、测量故障 |
-| `summary.json` | 三层指标、样本量、分位数、最大值、区间、阈值和判定结果 |
-
-所有派生指标必须能够从原始记录重新计算。汇总程序不得覆盖原始文件，不得静默剔除异常值。
-
-## 8. 核心证据表述模板
-
-正式报告应采用带边界的联合表述：
-
-> 在 `[平台/档位]`、`[模型与输入输出配置]`、`[到达率与竞争负载]`、`[功耗和温度条件]` 下，`[OS/配置]` 在人工智能目标负载达到 `[TTFT/TPOT/质量/可用率]`、关键保障负载达到 `[违约率/P99.9/观测最大响应]` 的同时，实现 `[有效吞吐和 E/token]`，并在 `[故障与 24 h 长稳结果]` 下保持稳定。相对 `[对照组]` 的改善为 `[效应量及置信区间]`。
-
-不应只写“平均时延更低”“吞吐更高”或“24 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
eaiadmin	feddff6fe4	add leadership analysis for RTOS+LLM+Agent research project 结论：项目框架在问题定义、体系化设计、方法论层面具有明确领先性（预计领先同行3-5年） - 5项强领先：跨层实时性定义、双路线设计、规则兜底、三层指标、四组对照 - 1项领先：五类部署形态体系 - 2项需补强：实证数据、Agent框架集成 - 主要风险：理论框架需快速产出实证数据	2026-09-23 03:22:10 +08:00
eaiadmin	ccf72e32bd	add industry research survey on RTOS+LLM+Agent competitors 包含6个文件： - 总览：7条关键发现摘要 - 国内同行：翼辉SylixOS、华为鸿蒙/LiteOS、端侧AI框架 - 国际同行：FreeRTOS/Zephyr/ThreadX/VxWorks对比、LLM运行时框架、Agent框架、NVIDIA Jetson物理AI - 学术文献：14篇论文/文章完整摘要和链接 - 关键研究空白：7个研究空白及与项目框架的对齐 - 文献索引：40+条文献完整列表	2026-09-23 03:12:03 +08:00
eaiadmin	f18f9f2fd3	reorganize repository into meeting and project framework structure Align the repository with the new collaboration workflow by separating meeting records from project framework materials, so discussion outputs and formal research assets can evolve independently.	2026-09-23 01:35:01 +08:00
eaiadmin	f28cf2314e	reorganize repository into framework-based structure	2026-09-22 15:43:45 +08:00
eaiadmin	7bcd140cdb	update low-power subtopic and evidence framing	2026-09-22 13:46:16 +08:00