# 以 Zephyr 为底座，建一套「中国驱动」的软件系统

> 本文已发布到开源中国：<https://my.oschina.net/u/9765070/blog/19779674>（此为本站备份，便于引用与版本化）。

> 摘要（≤120 字）：Zephyr 是最好的开源嵌入式底座之一，但底座不等于系统。zephyrrtos.cn 工作组的主张是：以 Zephyr 生态为基，把操作系统、系统优化、体系架构、编译器、行业应用、数据加密、开发工具、AI 八个方向的人连成一条链，做一套中国驱动的软件系统——并把已经落地的东西全部开源出来。

---

## 一、先说结论

我们不是要再造一个 RTOS。

我们要做的是：**以 Zephyr 生态为底座，建立一套独立、完整、由中国团队自己驱动的软件系统**——从芯片到行业应用，从编译器到 AI，八个方向上的人共用同一条技术主线、同一套工具、同一份证据。

一个成立不到一个月的民间工作组说这种话，容易显得空。所以我们把话说完整：这篇文章会讲清楚**为什么必须是这条链**、**我们已经在哪些环节落了地**、以及**哪些地方我们明确还没做到**。

## 二、Zephyr 值得当作底座

Zephyr 由 Linux 基金会托管，厂商中立，没有商业绑定与闭源陷阱；现代化设备树、统一设备抽象层、标准化 Kconfig、完整 POSIX 兼容，在工控、车规、消费 IoT、医疗设备等高端场景已经被验证了十年。全球 50+ 企业参与，是少数兼具**开源纯粹性、技术先进性、场景高端性与厂商中立性**的嵌入式底座。

一句话：**它是目前最适合做「高端、高可靠、国产化替代」的技术底座。**

但——底座不等于系统。

## 三、卡点不在「不会用」，而在整条链

很多团队不是不想用 Zephyr，而是撞在四个具体的坎上：

1. **芯片适配**：主线以海外大厂芯片为主，国产 MCU 几乎零适配，企业只能自己啃源码写 BSP；
2. **中文生态**：文档 100% 英文、体系庞杂，设备树 + CMake + west + Kconfig 是一套全新知识体系，学习曲线陡；
3. **社区响应**：核心维护在海外，时区、语言、思维方式都不同，本土定制需求很难传回主线；
4. **产业配套**：培训、咨询、落地案例稀缺，中小企业没有成熟方案可参考。

这四个坎看起来是「生态问题」，实质是同一个结构问题：**操作系统不能单独交付，它只是整条软件链的一段。** 芯片、板级、系统、工具链、应用、安全、AI，任何一段依赖外部，交付就卡在那一段。

所以我们的主张不是「再搞一个国内 RTOS」，而是：**把整条链上的人组织起来。**

## 四、常见质疑问答：那为什么不是 Linux？

每次讲「以 Zephyr 为底座」，总会有人问：**为什么不直接以 Linux 生态为底座？**

先把一个误解说清：**Zephyr 本身就是 Linux 基金会的项目**——同一个治理体系、同样的厂商中立、同样的开源协作方式。我们也没有离开 Linux 生态：沙盒机跑的是 Armbian、工具链与 CI 全在 Linux 上、代码托管也是 Linux 服务。所以这从来不是「Linux vs Zephyr」的路线之争。

真正的问题是：**这条链上，哪一层是中国的空白？** 两者不在同一层，也不能互相替代：

| 维度 | Linux | Zephyr |
|---|---|---|
| 定位 | 通用操作系统（富 OS） | 嵌入式实时操作系统（RTOS） |
| 硬件前提 | 需要 MMU，A 核 / 应用处理器 | 无 MMU 也能跑，M 核 / MCU |
| 资源占用 | MB ～ GB | KB ～ 几百 KB |
| 实时性 | 软实时为主，抖动难压 | 硬实时、确定性调度是设计目标 |
| 功能安全路径 | 成本高、认证面大 | 有明确的工具置信度 / 认证方法论诉求 |
| 国产 MCU 现实 | 上不去（多数没有 MMU） | 主战场 |
| 国内生态厚度 | **很厚**（OpenEuler、麒麟、Deepin、鸿蒙…） | **几乎空白**（适配少、中文资料少、响应远） |

**为什么我们选择补 Zephyr 这一段**：

1. **缺口在哪，力气就该在哪。** Linux 侧中国已有多个成熟发行版与强力团队，再去「建一个 Linux 底座」是重复建设、边际贡献极低；Zephyr 侧的国产 MCU 适配、中文生态、本土响应是真空白。
2. **可反哺上游。** Zephyr 上游开放、体量小，小团队甚至个人都能进主线；Linux 内核的体量与门槛高一个量级，民间工作组很难在一年内产生可见的主线贡献。
3. **芯片现实。** 大量国产 MCU 没有 MMU，Linux 装不上去——而这些芯片正是工控、家电、汽车 ECU 的主体。
4. **功能安全诉求。** 车规、工业、医疗要的是「确定性 + 证据链」，这天然落在 RTOS 一侧。配套的合规门禁只为这种交付提供**可复现的证据机制**，并且明确不构成任何功能安全合规声明。

**但「整栈」不等于「只做 RTOS」。** 真实产品是异构共存：A 核跑 Linux（HMI、网关、边缘算力），M 核 / 实时域跑 Zephyr（电机控制、传感器融合、安全监控），两者 AMP 协作。我们的沙盒就是这种形态的实例——RK3588 上 Linux 与 Zephyr guest 的 AMP 实践，构建、部署、回滚、验证都在同一台机器上完成。八个方向里的「操作系统」是吃透 Zephyr 这一端；而「编译器 / 开发工具 / 数据加密 / 行业应用 / AI」是跨两层的，既服务 Linux 侧，也服务 RTOS 侧。

**一句话**：Linux 是已经长出来的那条腿，Zephyr 是还没长出来的那条腿。中国驱动的软件系统要站得住，得先把短板补上；而在 Linux 这条腿上，我们选择的是「用成熟的国内栈」，不是「再造一个」。

## 五、八个方向，一条链

工作组把这条链拆成八个方向，每个方向都有明确的「中国团队必须自己掌握什么」：

| 方向 | 这条链上负责什么 | 必须自己掌握的原因 |
|---|---|---|
| **操作系统** | 内核、调度、电源管理、驱动模型 | 吃透底座才谈得上优化与裁剪，而不是照抄配置 |
| **系统优化** | 启动时间、内存占用、中断延迟、功耗 | 这些数字决定了能不能过行业门槛，且只能在自己的板子上量 |
| **体系架构** | 设备树、抽象层、多核与异构（AMP）、安全分区 | 国产 SoC 的架构差异需要本土建模，不能硬改上游 |
| **编译器** | GCC / LLVM 工具链、链接脚本、尺寸与优化等级 | 工具链是地基：它决定装不装得下、跑得快不快、能不能复现 |
| **行业应用** | 工控、车规、消费 IoT、医疗、电力 | 能力必须映射成行业能验收的交付物：需求、判据、证据、发布记录 |
| **数据加密** | 安全启动、密钥管理、加密库、TEE 与分区隔离 | 安全是行业应用的入场券，不能「后面再加」 |
| **开发工具** | 调试、追踪、CI、评测与「人 + AI + 设备」的协作方式 | 工具不统一，经验就沉淀不下来 |
| **AI** | 智能体答疑、模型路由、让 AI 参与工程流程 | AI 不该停在聊天框，要进流程并留下可复现的证据 |

这八个方向不是八个独立话题：**它们共享同一条链，任一段短板，整条链就交付不出去。** 这就是为什么这些人需要被聚在一起——这也是工作组把自己定义成「**人才纽带**」而不是「又一个社区」的原因。

## 六、已经落地的（不吹，可验证）

我们不把计划写成已交付。到目前为止，下面这些是真的在跑：

- **官网 [zephyrrtos.cn](https://zephyrrtos.cn/)**：数据驱动的动态页 + RSS / JSON Feed + 机器可读的站点事实 `info.json`。
- **国内镜像**：一条 `git config` 的 `insteadOf` 重定向，把 `github.com/zephyrproject-rtos` 指向国内 Gitea，`west init / update` 照常用（[导入说明](https://zephyrrtos.cn/import.html)）。
- **远端开发沙盒**：一台 Radxa ROCK 5B+（RK3588，8 核 / 15 GiB，eMMC + 2×NVMe RAID1，Armbian 24.11.2），通过 DSH 插件当作命令行工作区使用——板子放机柜、无键鼠显示器，编译与调试都在板子上跑（[沙盒说明](https://zephyrrtos.cn/sandbox.html)）。
- **四个 DSH 插件**（全部 MIT，安装说明与目录源齐全，见 [插件页](https://zephyrrtos.cn/plugins.html)）：
  - `dsh-ubuntu-sandbox` 0.1.1 —— 把远端主机变成持久 tmux 会话的工作沙盒；
  - `dsh-llm-router` 0.1.1 —— Lead/Worker 模型路由：一轮里 strong 模型规划、其余步骤交给便宜模型；
  - `dsh-compliance` 0.1.1 —— 合规门禁：七个检查 + 生成器 + CI 片段，让每个「已完成」都带可复现的反证；
  - `dsh-handoff` 0.1.0 —— 上下文真的用尽时，换一条干净会话接着干。
- **智能体**：智谱清言上的[工作组智能体](https://www.chatglm.cn/main/gdetail/69992fe43e659c7211733083)，后端跑 18 个工具（构建指引、DTS / Kconfig 分析、架构报告、性能指引、站点问答等）。
- **自建 Gitea**：代码托管、Issue / PR 与适配仓库入口。
- **会员机制**：前 3 个月免费（邮件申请即开通），之后可选正式会员 RMB 200/年，不自动续费——用来覆盖服务器、证书与内容/适配的持续投入（[如何加入](https://zephyrrtos.cn/join.html)）。

## 七、我们坚持的三条纪律

这三条比上面任何工具都重要，因为它们决定了「这套东西能不能被信任」：

1. **只发机制，不发结论。** 合规插件的包里只有校验器、生成器、空模板与 CI 片段，不含任何实测值与记录——你的判据必须由你写进自己的 `spec/`。
2. **跳过不是通过。** 被配置关闭的检查会打印 `SKIP`，并与 `PASS` 分列，明确写出「跳过的检查未被执行」。这条看似琐碎，它防的是「全绿」里混着从未执行的东西。
3. **不把计划写成已交付。** 官网首页把「已落地」和「建设中」分开写；工具页面会把局限单独列一节。我们也确实有没做到的地方——例如「评审与被评审分离」目前由偏差登记承载（单人承担全部角色）、跨仓库工具一致性检查尚未实现、凭据轮换有明确的到期日。

顺便说一个容易被误解的边界：合规门禁借用了 **ISO 26262-8 第 11 章**的工具置信度方法论，但项目自己的硬约束写得很清楚——**不得被解读为「符合 ISO 26262」，不构成任何功能安全合规声明**。说清楚这一点，比含糊地暗示「合规」，对客户更负责。

## 八、怎么参与

- **想一起做**：不管你在操作系统、系统优化、体系架构、编译器、行业应用、数据加密、开发工具还是 AI 方向，公开仓库就是入口。先关注、提问、提 Issue，再决定从哪一段开始贡献。
- **想要会员资源**：邮件 `hakehuang@gmail.com`，主题「申请 zephyrrtos.cn 会员」，提供用户名与邮箱，即可开通 3 个月免费会员。
- **想直接问**：智谱清言上的[工作组智能体](https://www.chatglm.cn/main/gdetail/69992fe43e659c7211733083)——Zephyr 入门、镜像导入、沙盒与工具使用都可以直接问。
- **想买整机**：官方网店有基于 ROCK 5B+ 的沙盒整机与配件。

## 九、最后

中国需要的不是一个「国产 RTOS 的替代品」，而是一套**从芯片到应用都能自己说清楚**的软件系统：系统的每个数字怎么量出来的、每条判据谁写的、每次放宽边界留了什么痕、每次发布带了哪些 open 偏差。

这件事一个人做不完，但一群人用同一条链、同一套工具、同一份证据去做，是可以开始的。

**我们已经在开始的路上。欢迎加入。**

---

*zephyrrtos.cn 工作组 · 2026-10 · 官网：https://zephyrrtos.cn/ · 动态：https://zephyrrtos.cn/news.html*