zephyrrtos.cnZEPHYR RTOS 本土生态工作组
有问题随时问智能体:工作组智能体已在智谱清言上线——Zephyr 入门、国内镜像导入、远端沙盒与工具使用,直接对话即可。 打开智能体 →
Linux 基金会 · 厂商中立 · 本土生态倡议

2026-09-11 · 工作组正式成立 · 查看动态与首批发布 →

Zephyr 不缺实力
缺的是一套属于中国的本土生态

Zephyr RTOS 由 Linux 基金会托管,背靠全球 50+ 顶尖企业,在工控、车规、消费 IoT、医疗设备等高端场景 深耕十年,架构先进性、安全性与标准化程度经得起产业验证。
但现实割裂:它在国内长期处于"小众冷门、水土不服"的状态——很多开发者与中小企业想拥抱它, 最后卡在文档晦涩、适配缺失、问题无解、生态脱节,只能退回过更本土化的方案。

这就是 zephyrrtos.cn 工作组存在的理由:倡议成立独立的 Zephyr RTOS 本土开源组织, 补齐本土生态短板,让顶级开源 RTOS 真正落地中国产业。

50+全球顶尖企业共同参与,Linux 基金会托管
10 年工控、车规、消费 IoT、医疗设备等高端场景持续验证
45% / 44%工业控制与消费 IoT 领域的全球份额(行业调研,工作组整理)
≈20%开发者认为 Zephyr 入门难度「有所改善」——中文生态仍是短板

先搞懂:Zephyr 到底强在哪

它不是"又一个普通 RTOS"。FreeRTOS 本质是轻量化内核 + 海外云生态,多数人只用到调度核心; 而 Zephyr 是全栈式、现代化、高安全的嵌入式操作系统解决方案。严格说,两者不在同一个竞争层级。

厂商绝对中立,无绑定风险

托管于 Linux 基金会,不被单一企业掌控,没有商业绑定与闭源陷阱,是纯粹的开源基础设施, 天然适配国产产业自主可控的发展方向。

架构超前,面向高端场景

现代化设备树、统一设备抽象层、标准化 Kconfig 配置体系;内核精简而功能完备, 原生支持安全加密、实时调度与多任务管理,广泛用于工业自动化、智能汽车、医疗设备、智能电网。

兼容性强,Linux 开发者易上手

完整兼容 POSIX 标准;国内知名物联网系统(如小米 Vela / NuttX 体系)的底层实践, 也印证了 Zephyr 作为技术底座的硬核实力。

一句话总结:Zephyr 是目前全球开源 RTOS 里,最适合做高端、高可靠、国产化替代的技术底座。 可它偏偏在国内陷入了「一流技术、末流生态」的尴尬。

扎心真相:Zephyr 在中国的四大「水土不服」

不是国内开发者不想用,而是海外原生生态没有适配中国的开发环境与产业现状—— 所有痛点归根结底,都是「全球化开源体系」与「本土化产业需求」的脱节。

痛点 01

国产芯片适配近乎空白

Zephyr 主线以海外大厂芯片为主,对国内主流 MCU(雅特力、华大、合宙等)几乎零适配。 企业做国产化替代时,只能自己啃源码、写 BSP,耗时耗力、成功率低,多数团队望而却步。

→ 需要:批量维护国产 MCU / 开发板适配仓库,开箱即用
痛点 02

中文生态贫瘠,入门门槛高

官方文档详尽但 100% 英文、体系庞杂、逻辑分散;设备树 + CMake + west + Kconfig 是一套全新知识体系, 学习曲线陡峭。缺少系统中文教程、入门手册与实战案例,仅靠零散博客难以高效掌握。

→ 需要:文档精译、系统化学习路径与实战案例库
痛点 03

社区响应滞后,问题无人解答

核心社区与维护团队在海外,时区、语言、思维体系不同。国内开发者提问常石沉大海或数周后得到模糊回复, 本土定制化需求也很难传递到主线、更难被优先处理。

→ 需要:本土快速响应机制,并把本土方案反向回馈主线
痛点 04

产业配套缺失

国内 Zephyr 相关的技术培训、企业服务、落地案例极度稀缺:中小企业没有成熟方案参考, 团队转型没有培养渠道,项目落地缺少本土技术支持。顶级技术被白白闲置。

→ 需要:培训、咨询、方案适配与落地服务的产业闭环

为什么必须成立「中国 Zephyr RTOS 独立本土组织」

为了国产嵌入式产业的长期上限,也为了高端 IoT、工控、车规领域的自主可控。 现有主流 RTOS 各有短板:FreeRTOS 绑定海外云生态存在供应链风险;部分国产 RTOS 商业化属性偏重、 开源自由度有限。而 Zephyr 是少见的兼具开源纯粹性、技术先进性、场景高端性与厂商中立性的底层底座—— 但再好的技术,脱离本土生态都是空中楼阁。

必要性 01

打通软硬件国产化闭环

牵头统筹国内芯片厂商与开发者社区,批量完成国产主流 MCU、开发板的 BSP 适配, 同步维护本土化适配仓库,让工程师真正开箱即用。

必要性 02

搭建完整中文生态

把陡峭的学习曲线拉平:在校学生、初级工程师、中小企业团队都能低成本上手顶级 RTOS 技术。

必要性 03

建立本土快速响应

承接国内企业的技术问题、bug 反馈与功能需求,快速迭代;同时把国内优质适配与优化反哺全球主线, 让中国开发者从「生态使用者」变成「生态共建者」。

必要性 04

凝聚产业力量

把芯片厂商、终端企业、高校科研团队与个人开发者从「各自为战」整合起来, 形成统一的技术规范、适配标准与落地体系,减少重复造轮子。

必要性 05

筑牢自主可控底座

在工控、车联网、医疗物联网等关键领域,掌握核心适配、优化与定制能力, 摆脱对海外生态的被动依赖。

成立本土独立 Zephyr RTOS 组织,不是另起炉灶,而是扎根全球开源、服务中国产业。

不谈空泛理念,只讲落地价值

工作组未来聚焦五个务实方向:

01

硬件适配

批量维护国产 MCU、开发板适配仓库,持续更新迭代,覆盖国内主流硬件方案。

02

内容建设

官方文档中文精译、入门实战教程、视频课程、行业案例库持续更新。

03

社区运营

中文问答社区、月度技术分享、年度开发者沙龙、开源贡献激励计划。

04

产业赋能

为中小企业提供技术咨询、方案适配与问题排查服务,降低落地成本。

05

产学研联动

联合高校开设 Zephyr 实训课程,培养本土高端嵌入式人才梯队。

工具与标准

生态不是口号,要落在能复用的工具上。工作组把工程协作方式固定下来:一条标准工具链,加上持续发布的工具。

标准工具

DSH · DeepSeek Harness

工作组标准工程协作工具:插件化架构、本地优先、可直接操作终端 / 文件 / 远端主机, 用来把「人 + AI + 真实设备」的开发流程固定下来,而不停留在聊天窗口。

  • 不被单一厂商流程绑死,工具 / 技能 / 面板均可按需扩展
  • 可自建、可离线,数据留在本地与自有服务器
  • 插件与目录源可自行发布,内部工具能沉淀为公共能力
选择理由 →
首个工具

dsh-ubuntu-sandbox 0.1.1

把远程 Ubuntu / Debian 主机变成像本地命令行一样的「工作沙盒」:默认 tmux 持久会话 加远程读写能力,适合远程编译、板端调试与文件同步。

  • 会话状态跨调用与断线保持;与 dsh-ssh 共享主机库
  • 已在 aarch64(Armbian)与 x86_64(Ubuntu 22.04)实机验证
  • MIT 许可,npm 公开包 + 已收录进工作组目录源
npm → · 安装与更新教程 → · 目录源 → · 发布说明 →
模型路由

dsh-llm-router 0.1.1

Lead/Worker 模型路由做成 harness 的一等公民:在 ctx.llm 上注册一条虚拟提供方路由, 再加一个可观察、可拦截、可替换的 ctx.llmRouter 服务——一轮里 lead 规划、其余步骤交给 worker。

  • 路由即注册表里的一条路由:模型选择器、会话日志、压缩都无需改动
  • 决策可观察(事件)可拦截(waterfall)可替换(策略 / 路由器 / 适配器)
  • MIT 许可,npm 公开包 + 独立工作组目录源
npm → · 发布与安装 → · 目录源 → · 发布说明 →

资源

工作组自建入口,以及值得长期跟踪的官方与社区资源。

一起把本土生态做起来

如果你是用 Zephyr 做产品、做适配、做研究的嵌入式开发者、物联网从业者、开源爱好者或高校团队, 欢迎一起参与——不需要任何审批,公开仓库就是入口。

会员

加入会员:前 3 个月免费

发邮件到 hakehuang@gmail.com,提供用户名邮箱, 即可开通 3 个月免费会员,使用 zephyrrtos.cn 的资源;3 个月后可选开通正式会员(年费 RMB 200),不自动续费。

查看如何加入 →

1 · 关注与提问

在自建 Gitea 上注册账号、关注适配仓库;遇到问题直接开 Issue,本土解答不再石沉大海。

2 · 贡献适配与内容

国产 MCU 板级适配、驱动移植、中文文档、示例工程、踩坑记录,都欢迎用 Pull Request 贡献。

3 · 共建与反哺

把经过验证的本土方案与优化回馈全球主线,让中国开发者成为生态共建者。

问智能体 Zephyr 问题问答 · 直接问智能体