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.

01-会议讨论/20260922_093448-会议主题拆分整理/00-会议主题索引.md

@@ -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`。
+
+这样可以把“研究框架”“平台能力”“具体应用”三类问题拆开处理，不会在同一份会议全文里相互缠绕。

01-会议讨论/20260922_093448-会议主题拆分整理/01-医疗AI导航与嵌入式收缩方向.md

@@ -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 / 基础系统研究的主样例之一。

01-会议讨论/20260922_093448-会议主题拆分整理/02-大模型评测优化平台与本地模型社区.md

@@ -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. 当前结论
+
+这条线的真正价值，不是再做一个“模型体验平台”，而是：
+
+> **把模型、量化、算子、框架和硬件之间原本难解释的运行差异，变成一套可比较、可复现、可交付、可沉淀的证据与服务体系。**
+
+如果继续向前推进，它会自然生长出两个方向：
+
+- 一个是面向内部和合作项目的优化工作台；
+- 一个是面向区域部署、本地模型与算力中心合作的本地模型社区。

01-会议讨论/20260922_093448-会议主题拆分整理/03-RTOS与AI实时控制基础系统课题讨论.md

@@ -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 的实时控制基础系统”这一更高层次主语。**

01-会议讨论/20260922_093448-会议主题拆分整理/04-垂直大模型训练框架与代训服务.md

@@ -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. 当前结论
+
+这条线真正值得保留的，不是“代训”这个商业词本身，而是它背后的方法学判断：
+
+> **垂直大模型的核心不是在通用模型上附加行业语料，而是把角色、目标、制度、动作空间、工作流和边界结构编码进训练与后训练过程。**
+
+如果继续向前推进，它最可能沉淀成两类成果：
+
+- 一类是垂直模型方法论和训练框架；
+- 一类是围绕这一方法论建立起来的咨询、试训和代训服务体系。

01-会议讨论/20260922_093448-会议主题拆分整理/05-法律政务数据治理智能体与XAPP平台.md

@@ -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 平台能力。**
+
+如果继续往前推进，这条线最自然的演化方式是：
+
+- 先做高价值行业应用；
+- 再抽取共性数据治理能力；
+- 最后收口到平台和应用协同的产品结构。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/01-当前研究问题：背景、问题与挑战.md

@@ -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、芯片与资源治理结构承担隔离、边界与整体秩序；
+- 规则层与兜底机制承担异常控制与安全边界。
+
+因此，本框架对应的研究价值在于：为“人工智能进入实时控制系统之后的基础系统问题”建立更准确的问题定义、技术路线和实验组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/02-研究定位与项目边界.md

@@ -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 供应方转向基础系统供应方。
+
+这两套框架可以并行维护，分别服务于不同层次的课题收敛。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/03-总课题与两个子课题的关系.md

@@ -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保持“一总两子”的结构是当前最稳的组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/00-整体研究框架.md

@@ -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. **论文层**：面向实时系统、嵌入式系统和低功耗系统方向的系统化论文与报告。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/01-RTOS直接控制域.md

@@ -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 是关键保障负载的确定性底座，是人工智能进入实时控制系统后仍能维持秩序的直接控制层。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/02-推理运行域.md

@@ -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 的重要性，但明确要求把推理运行域单独提出，是因为：
+
+> **只有先把人工智能目标负载本身的时间结构说清楚，后续系统边界分析才不会落回单因果叙事。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/03-系统协同域.md

@@ -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 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/04-规则兜底与控制闭环.md

@@ -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. 当前结论
+
+> **没有规则兜底与异常切换，人工智能进入实时控制系统就只是“把模型接进来了”；只有闭环建立起来，基础系统课题才真正成立。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/05-研究逻辑说明.md

@@ -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 / 混合结构建立统一对照。
+
+在此基础上，后续可以继续向更细的实验子文档、联合研究方材料和正式交付物展开。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/06-基础设备与算力基础.md

@@ -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 路线的基础系统问题显式暴露出来。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/README.md

@@ -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`、资源隔离和系统协同相关的部分。
+
+这意味着两个子课题虽然分别展开，但不需要各自重复建设方法层。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-子课题定义.md

@@ -0,0 +1,26 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向 MCU 的静态智能控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在 MCU 级资源预算下，人工智能能力如何通过静态编排、工具链、代码生成和芯片协同，被纳入可分析、可验证、可部署的实时控制系统。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- 小模型、小算子与控制任务的静态共存；
+- 工具链、部署链路和代码生成能力；
+- 极小内存、极低功耗和快速启动场景；
+- 与芯片厂商和开发套件的协同。
+
+本子课题不把高动态 Linux 生态、复杂虚拟化结构和大规模混合系统作为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第一个子课题，重点对应 `T5` 控制端，也是总课题中最能体现“小型化、低功耗、静态部署”特征的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/01-研究问题与适用场景.md

@@ -0,0 +1,30 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. 小模型与关键控制任务如何静态编排；
+2. 工具链如何把模型部署、资源预算和代码生成联成闭环；
+3. 芯片规格、运行时约束和控制边界如何共同决定系统能力；
+4. 低功耗、小型化和极小内存预算下，系统成立边界在哪里。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 控制器；
+- 轻量控制盒；
+- 小型工业控制节点；
+- 电池供电或功耗严苛设备；
+- 需要毫秒级或更紧周期控制的端侧场景。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `RTOS 直接控制域`
+- `推理运行域`
+- `基础设备与算力基础` 中的 `T5` 部分
+
+但会弱化 `系统协同域` 中面向大 SoC 混合结构的部分。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md

@@ -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 路线的主问题不是“大模型如何跑进去”，而是人工智能能力如何在极端受限条件下，被静态、可分析地纳入实时控制系统。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md

@@ -0,0 +1,28 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- 静态内存预算是否成立；
+- 控制任务截止期是否维持；
+- 小模型推理是否能在固定窗口内完成；
+- 功耗、热状态和启动时间是否满足约束。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. 小模型与控制任务共存实验；
+2. 静态内存池和固定执行窗口实验；
+3. 工具链生成结果与手工部署结果对比；
+4. 低功耗与长稳运行实验。
+
+## 3. 指标重点
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 单次推理时延
+- 峰值内存占用
+- 启动时间
+- `E/inference`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/04-预期成果与论文方向.md

@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向 MCU 的静态智能控制问题定义；
+2. 小模型与控制任务静态编排方法；
+3. 工具链、代码生成与部署检查框架；
+4. 低功耗、小型化场景下的系统边界证据。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- TinyML / Edge AI on MCU
+- 低功耗嵌入式智能系统
+- 静态部署与工具链协同
+- 实时控制中的小模型纳入问题

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/05-合作方式与产业落点.md

@@ -0,0 +1,28 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- MCU / 控制芯片厂商；
+- 开发套件和工具链团队；
+- 小型化控制设备厂商；
+- 对功耗和体积高度敏感的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 芯片与工具链条件梳理；
+2. 静态部署链路共建；
+3. 小规模样机验证；
+4. 工具链与方法沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 开发套件；
+- 芯片协同方案；
+- 小型控制设备智能化升级；
+- 低功耗端侧部署方法。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md

@@ -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)
+
+## 当前特点
+
+本子课题的关键词是：
+
+`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-子课题定义.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 真实工程复杂度的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/01-研究问题与适用场景.md

@@ -0,0 +1,29 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. Linux 与 RTOS 如何在同一 SoC 上分工；
+2. Hypervisor 与 Hybrid 结构如何提升整体可治理性；
+3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析；
+4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 设备端 SoC；
+- 工业边缘节点；
+- 车载或机器人边侧平台；
+- 同时承载控制与 AI 推理的异构系统。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `系统协同域`
+- `规则兜底与控制闭环`
+- `基础设备与算力基础` 中的 `T4/T3` 部分
+
+同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/02-技术路线：Linux-RTOS-Hypervisor-Hybrid.md

@@ -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 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/03-实验设计与验证方法.md

@@ -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`
+- 资源隔离效果
+- 温度、热漂移与恢复时间

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/04-预期成果与论文方向.md

@@ -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 协同结构与实时边界

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/05-合作方式与产业落点.md

@@ -0,0 +1,29 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- SoC / 板级平台厂商；
+- Hypervisor / mixed-criticality 基础软件团队；
+- 工业边缘和机器人设备团队；
+- 同时承载 AI 与控制任务的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 平台条件与资源结构梳理；
+2. Linux / RTOS / Hypervisor 分工设计；
+3. 板级实验与隔离验证；
+4. 规则兜底和闭环安全验证；
+5. 系统协同证据沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 边侧 SoC 参考架构；
+- 混合基础系统方案；
+- Hypervisor 协同部署方法；
+- 设备端 AI + 控制一体化平台路线。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md

@@ -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`、`统一内存`、`资源隔离`、`系统协同`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/01-统一实验设计与验证骨架.md

@@ -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的实验设计，不再围绕“单系统性能竞赛”组织，而是围绕“人工智能进入实时控制系统后的整体边界是否成立”来组织。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/02-总课题论文写作规划.md

@@ -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 任务下是否更优”，而是回答“人工智能进入实时控制系统后，基础系统如何共同维持边界”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/03-两个子课题的共同问题.md

@@ -0,0 +1,26 @@
+# 两个子课题的共同问题
+
+## 1. 共同主语
+
+两个子课题共同服务于同一个总课题主语：
+
+> **面向 AI 的实时控制基础系统。**
+
+## 2. 共同方法层
+
+两个子课题共同依赖：
+
+- 三层边界；
+- 三类系统负载；
+- `T5~T1` 验证矩阵；
+- 统一评价框架；
+- 对照逻辑与规则兜底思想。
+
+## 3. 共同科学问题
+
+二者都需要回答：
+
+- AI 目标负载如何进入控制系统；
+- 关键保障负载如何继续保持边界；
+- 系统边界由哪些机制共同构成；
+- 实时性问题如何避免单因果叙事。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/04-两个子课题的差异边界.md

@@ -0,0 +1,32 @@
+# 两个子课题的差异边界
+
+## 1. 子课题A的主边界
+
+子课题A的主边界在于：
+
+- 极小资源预算；
+- 静态部署；
+- 低功耗与小型化；
+- 工具链和芯片协同；
+- 小模型与控制任务的静态共存。
+
+## 2. 子课题B的主边界
+
+子课题B的主边界在于：
+
+- Linux / RTOS 分工；
+- Hypervisor 与 Hybrid；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与异常切换；
+- 混合系统中的整体确定性。
+
+## 3. 为什么不能混写
+
+两个子课题对应的是两类不同的问题结构，因此：
+
+- 评价重点不同；
+- 工程条件不同；
+- 合作对象不同；
+- 论文表达重点不同。
+
+这就是框架2内部需要采用“一总两子”结构的原因。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/05-总课题申报与论文组织建议.md

@@ -0,0 +1,24 @@
+# 总课题申报与论文组织建议
+
+## 1. 申报组织建议
+
+当前更适合按以下方式组织：
+
+- 以总课题名义对外表述；
+- 在内部和申报材料中并列写出两个子课题；
+- 共享方法层放在总论部分；
+- 两个子课题分别作为技术主线展开。
+
+## 2. 论文组织建议
+
+论文层面建议采用：
+
+1. 总问题定义；
+2. 共享理论与方法层；
+3. 子课题A；
+4. 子课题B；
+5. 共同问题、差异边界与总体结论。
+
+## 3. 当前结论
+
+在当前阶段，最稳的组织方式不是把两个子课题拆成两个独立框架，而是在框架2内部保持“一总两子”的结构，并用共享方法层与综合收敛层保证主线统一。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/README.md

@@ -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)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/README.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既保持统一主语，又避免两个子课题的价值被主干目录湮灭。

02-项目框架/README.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”的内部子课题结构；
+- 后续可在两套框架之间持续比较，最后再确定正式主课题版本。