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