动态

dsh-llm-router 0.1.1 已发布（2026-09-20）。它把 Lead/Worker 路由做成 harness 的一等公民：插件在 ctx.llm 上注册一条虚拟提供方路由（默认 lead-worker），并提供 cordis 服务 ctx.llmRouter。模型路由因此不再是躲在外部二进制或旁路代理里的决策——它就是每个模型调用都要经过的同一张注册表里的一条路由：可观察、可拦截、可替换。

0.1.1 修掉的是与 dsh-ubuntu-sandbox 0.1.0 同源的安装阻断（schemastery ^3.18.2 在公共源不存在 → notarget），依赖范围改为 ^3.18.0；同时新增 check-installable / verify-installed 两步「打包 → 真实解析依赖装进临时 profile → 以 bundle 启动」的发布前校验，让这类不可安装的版本不再有机会发出去。

配套上线新页面 dsh-llm-router 发布与安装：三种安装方式（社区市场 / dsh plugin / 手工 patch 行）、配置字段表、虚拟模型与策略规则、推理强度为什么归路由所有、观察 / 拦截 / 替换三种改路由方式，以及「成本与边界」——prompt cache、故障转移绝不拼接答案、重试仍归 dsh-llm-retry、决策不进持久会话日志。

• 轮次成本形状：一次 lead 调用做规划，其余步骤交给 worker；便宜路由持续失败时再升级回 lead（升级自限，成功即清零）
• 虚拟模型：auto / lead / worker / worker:<id>——模型选择器、会话日志、压缩、会话标题都无需改动
• 无配置时休眠：既没有 lead 也没有 workers 时只打一行日志、不挂载任何东西；但「写了一半」的路由会明确报错
• 目录源已在线：https://zephyrrtos.cn/dsh-llm-router/catalog-source.json，市场里条目名为 Lead/Worker Model Router

安装前请先读插件安装与更新教程里的两个通用坑：dsh plugin 只装依赖、不写挂载清单（要确认 dsh.profile.bundles 含包名），以及 pnpm 10/11 的 store 版本冲突（ERR_PNPM_UNEXPECTED_STORE）。

0.1.1 修掉了一个会让插件根本装不上的问题：0.1.0 声明依赖 schemastery ^3.18.2，而公共 npm 源里最新只有 3.18.0，于是 npm/pnpm install 与 DSH 社区市场的安装都会以 notarget 失败——之前只在「把插件目录手工拷进 profile」的场景下被掩盖了。现在依赖范围改为 ^3.18.0，安装恢复正常；0.1.0 已在 npm 上标记废弃（deprecated）并指向 0.1.1，请使用 ≥0.1.1。

同时新增教程页 dsh-ubuntu-sandbox 安装与更新：三种安装方式（DSH 社区市场 / dsh plugin 命令行 / 手工离线）、更新与回滚、装完的验证清单，以及安装期最常见的报错处置。

• 前置：DSH ≥ 0.1.2-rc.1；远端主机装 tmux；主机写进 ~/.dsh/dsh-ssh.json（与 dsh-ssh 共用）
• 一条命令：dsh plugin --profile desktop add @hakehuang/dsh-ubuntu-sandbox@0.1.1，然后重启 DSH
• 装完必查：profile 的 dsh.profile.bundles 是否含包名——dsh plugin 只装依赖、不写挂载清单，缺了不会报错、只是工具不出现
• 验证：dsh --profile desktop --dump-config 里出现 id: ubuntu-sandbox，且工具列表出现 sb_cwd / sb_session / sb_exec / sb_ls / sb_read / sb_write

排查提示：如果安装报 ERR_PNPM_UNEXPECTED_STORE，那是 profile 的 node_modules 由 pnpm 10 建立、而 DSH 强制使用自带的 pnpm 11 造成的。完全退出 DSH 后在 profile 目录执行一次 DSH 自带的 pnpm install 迁移 store 即可根治；不想迁移就用与现有 store 匹配的 pnpm 手工安装。两种做法都写在教程页里。

除了邮件与 Gitea，我们把智能体支持接进了站点的几个入口：在智谱清言上的工作组智能体，可以直接问 Zephyr 入门、镜像导入（west / insteadOf 重定向）、远端沙盒接入与工具使用的日常问题。

• 首页——资源区「智能体支持（智谱清言）」入口，参与区也加了「向智能体提问」按钮；
• 加入页——新增「支持渠道」板块（邮件 / 智能体 / Gitea），并补了一条 FAQ「遇到技术问题去哪里问」；
• 沙盒页——相关链接新增「支持与答疑」，覆盖接入、采购与预装咨询；
• 分工建议——日常答疑找智能体，需要留痕跟进的开 Issue，账号与合作事宜走邮件。

国内直连 github.com/zephyrproject-rtos/* 经常慢到 west update 跑不完。我们把这条路径固化成一份可直接照做的说明：zephyrrtos.cn 项目导入。

• 核心只有一条配置——git config --global url."https://www.zephyrrtos.cn:3000/zephyrrtos_china/".insteadOf "https://github.com/zephyrproject-rtos/"，之后 west init / west update / 手动 clone 全部走镜像，无需改动工程文件；
• 从零搭建步骤——Ubuntu 依赖、Python venv、west 安装、重定向、west init/update、SDK 获取（zephyr_sdk）与首次编译；
• 已有工程切换与还原——单仓库改远端、仅当前目录生效、一键取消重定向，都给了命令；
• 排错与凭据建议——401/403、仍走 GitHub、模块缺失、update 中断的处理；强调凭据不要写进脚本或 URL。

镜像组织 zephyrrtos_china 需要账号访问——先在 如何加入 申请账号并在账号里配置公钥或访问令牌。页面上同时提供两个可直接下载的脚本：zephyr_redirect.sh（3 行，只做重定向）与 zephyr_cn_setup.sh（依赖 + venv + west + init/update 一键完成，不含任何凭据）。

zephyrrtos.cn 官方网店现已开通。我们把这个远端开发沙盒的整机与配件放上了货架——需要一台能远程开发的 ARM64 机器，可以直接下单，不用自己攒。

• 开发沙盒整机——基于 Radxa ROCK 5B+（RK3588，8 核 / 16GB 级内存），出厂为「通用型人工智能个人代码数据中心」形态：定制散热、定制电源、定制外壳、双 128GB NVMe 组 RAID1；
• 固件与软件预置——Armbian 系统、Samba 共享、SSH、Gitea 本地代码托管、RAID1 文件系统等按需启用；
• 拿到就能远程开发——配合 dsh-ubuntu-sandbox 与 DSH，把板子接进主机库即可当远端开发机使用（见平台说明）。

购买前想先了解平台规格、实测配置与接入方式，可以看 远端开发沙盒（ROCK 5B+）；企业或高校批量采购、需要预装与配置服务，直接在邮件里说明需求即可。

zephyrrtos.cn 会员现已开通申请。发一封邮件即可开始：提供你的用户名与邮箱，我们为你开通 3 个月免费会员，用来使用 zephyrrtos.cn 的资源。

• 怎么申请——发邮件到 hakehuang@gmail.com，主题写「申请 zephyrrtos.cn 会员」，正文提供用户名与邮箱；
• 免费期——3 个月，从我们回信确认开通之日算起；
• 到期之后——可自行选择是否开通正式会员（年费 RMB 200），到期前会提醒一次，不自动扣费、不强制。

会员可用于自建协作平台（Gitea）、工作组工具与插件、中文资料与国产芯片适配仓库等 zephyrrtos.cn 资源；其中正在建设与规划中的部分，会员可优先获取与参与。

企业、高校团队同样可以加入——在申请邮件里说明团队情况与用途即可。

工作组自建的基础设施同日就绪，全部运行在自己的服务器上：

• 官网：zephyrrtos.cn（HTTPS，证书自动续期）；
• 代码托管：zephyrrtos.cn:3000（自建 Gitea，Issue / PR 全部公开）；
• DSH 插件目录源：/dsh-ubuntu-sandbox/catalog-source.json——符合 DSH 社区市场 v1 契约，可被任何用户添加；
• 工具发布链路：npm 公开包 + 目录源收录 + CI（Gitea Actions）自动发布。

工作组发布第一个工具 dsh-ubuntu-sandbox：把一台远程 Ubuntu / Debian 主机变成像本地命令行一样的「工作沙盒」，用于远程编译、烧写辅助、板端调试与文件同步。

• 远程执行 bash，默认 tmux 持久会话：cd / export / 后台任务跨调用保持，断线重连不丢；
• 远程文件能力：目录列表、读、写（自动建父目录），与本地工具同款退出码 / 超时标记；
• 与 @linxin666/dsh-ssh 共享主机库 ~/.dsh/dsh-ssh.json，支持密钥 / 密码 / agent 认证；
• 已在 aarch64（Armbian）与 x86_64（Ubuntu 22.04）实机验证：会话保持、读写回环、断连续用；
• MIT 许可；npm 公开包，同时收录进工作组自建目录源，可在 DSH 社区市场一键安装。

安装：dsh plugin --profile <profile> add @hakehuang/dsh-ubuntu-sandbox

工作组确定把 DSH（DeepSeek Harness）作为标准工程协作工具，用于把「人 + AI + 真实设备」的开发流程固定下来。

选择它的理由：

• 可扩展——插件化架构，工具、技能、面板都能按工作组需要扩展，不被单一厂商流程绑死；
• 本地优先——可自建、可离线、数据留在本地与自有服务器，符合自主可控要求；
• 贴近真实工程——直接操作终端、文件与远端主机，而不是停留在聊天窗口；
• 可协作——插件与目录源可自行发布，工作组能把内部工具沉淀成公共能力。

后续工作组的适配脚本、板级辅助工具、文档工作流，都会以 DSH 插件 / 技能的形式发布，并通过自建目录源统一收录。

今天，zephyrrtos.cn 工作组正式成立，并公开发出倡议：成立独立的 Zephyr RTOS 本土开源组织，补齐本土生态短板，让顶级开源 RTOS 真正落地中国产业。

我们的出发点是四个已经被反复验证的现实问题：

• 国产芯片适配近乎空白——缺少批量维护的国产 MCU / 开发板 BSP 与适配仓库；
• 中文生态贫瘠——文档全英文、体系庞杂，设备树 / CMake / west / Kconfig 学习曲线陡峭；
• 社区响应滞后——本土问题难以进入主线，定制化需求得不到优先处理；
• 产业配套缺失——培训、企业服务与落地案例稀缺，技术被闲置。

工作组的定位很明确：不是另起炉灶，而是扎根全球开源、服务中国产业——做国产芯片适配、中文内容建设、本土快速响应与产业赋能，并把经过验证的本土方案反向回馈上游主线。