EAC-Desktop三层架构完全解析Tauri原生壳、Node sidecar与dsh内核如何分工协作【免费下载链接】EAC-DesktopEmbracing All Creation (Desktop) — Dedicated to the Harmonious Coexistence of Hundreds of DSH Plugins / 揽尽万象桌面版 —— 致力于让数百个DSH插件和谐共存项目地址: https://gitcode.com/gh_mirrors/de/EAC-DesktopEAC-DesktopEmbracing All Creation揽尽万象是一个致力于让数百个 DSH 插件和谐共存的开源桌面工作台。它最独特的地方正是这篇文章要拆开的三层架构**Tauri 原生壳L1**负责窗口与桌面集成**Node sidecarL2**负责运行编排与插件治理**dsh 内核L3**负责 Agent 执行与 Web 界面——三层各司其职、互不越界。本文将带你完整看懂这个分工设计不需要你具备 Rust 或 Node.js 经验只要对桌面应用是怎么跑起来的感兴趣就能读懂。为什么桌面应用要做三层架构一个常见的困惑是桌面应用用一个框架比如 Electron 或 Tauri从头包到尾不就行了吗EAC-Desktop 的设计者给出的答案是桌面能力和 AI 内核的演进速度完全不同。窗口、托盘、单实例锁这些桌面集成需求变化很慢但 Agent 内核、插件生态的变化极快。如果把两者焊死在一个进程里任何一层出问题都会连累全局——典型症状就是一个插件崩溃整个应用白屏。因此 EAC-Desktop 用一份架构决策记录ADR明确划定了三条永不混淆的边界层次一句话职责技术实现L1 桌面集成层窗口 / 托盘 / 单实例 / 退出策略RustTauri可替换L2 业务服务层进程编排 / 环境初始化 / 插件治理Node.js sidecar壳无关L3 内核层Agent 执行 / 对话 / 工具 / Web UI官方 dsh 内核零修改完整的设计背景可以阅读 0002-壳层边界声明与分层架构.md。这份文档里有一句关键结论原壳层中约 60% 是与桌面框架零耦合的 Node 业务逻辑只有约 35% 是真·桌面集成——前者原封不动搬进了 L2 sidecar后者才用 Rust 重写。这正是三层的由来。L1 层Tauri 原生壳——只管像桌面应用L1 是用户双击安装包后第一个接触到的部分。它的职责被刻意收窄到极小窗口、托盘、单实例、退出策略和原生集成代码入口是 main.rs。从启动序列能看出 L1 的角色定位main.rs 头部注释写得很直白拉起 sidecar 子进程建立 stdio JSON-RPC 通道并绑定本地回环端口主窗口先显示加载页即起即见不用干等内核启动通过boot.start让 sidecar 去拉起 dsh 内核内核就绪后主窗口导航到真实 Web UI内核异常则显示恢复页。可以看到Rust 壳从头到尾没有碰任何业务逻辑。它像一个总机接线员来自页面的请求属于窗口控制的最小化、拖拽标题栏就地拦截处理属于业务编排的一律转发给 sidecar。这种壳层不承包业务的纪律是 L1 层最值得学习的点——它保证了未来想换壳比如换别的原生框架L2、L3 一行代码都不用动。L2 层Node sidecar——三层中技术含量最高的大脑如果说 L1 是脸面L2 就是大脑。server.ts 是 sidecar 的入口它启动后按严格顺序挂载一组桌面服务模块lib/desktop/ 目录environment环境隔离→ platform平台适配→ profile配置档案 → runtime-patches运行时补丁→ guard-box插件保护 → companion-sync配套插件同步→ plugin-ops插件启停 → boot-server内核进程编排L2 承担了三件脏活累活环境初始化。读取用户配置、准备插件目录之前必须先建立隔离的运行环境下一节详述进程编排。由 boot-server.ts 启动 dsh 内核进程监听服务就绪内核挂掉时走恢复链而不是静默失败插件治理。guard-box.ts 提供插件快照、体检与回滚入口plugin-ops.ts 管理启停让数百个插件不至于演变成一场灾难。L2 还有一个关键设计它是壳无关的。同一份 Node 代码既能被旧 Electron 壳驱动也能被新 Tauri 壳驱动——sidecar 只认 stdio JSON-RPC 协议帧不关心外面是谁。L3 层dsh 内核——绝对不动区与真正的 AI 能力L3 是官方deepseek-ai/dsh内核加 Cordis 插件树负责 Agent 执行、对话、工具调用和整个 Web 界面。它被称为绝对不动区壳层对内核一行代码都不修改扩展能力一律通过插件契约host/client 注入点接入。你在界面上看到的一切智能——会话列表、模型选择、文件变更、权限确认——都是 L3 的 Web UI 渲染出来的。L1 的窗口只是它的一副屏幕边框。这也是为什么插件生态能长到几百个规模插件挂在内核的插件树上崩溃治理由 L2 的保护中心兜底而内核本身始终保持干净。三层如何通信两条通道各司其职三层之间的对话走两条互相独立的通道这是很多架构文章里容易忽略的细节通道连接协议用途stdio JSON-RPCRust 壳 ↔ Node sidecar行分隔 JSON 帧业务方法调用boot.*、profile.*、files.*回环 WebSocketWeb 页面 ↔ Rust 壳 ↔ sidecarWS JSON-RPC页面桥window.dshDesktop窗口控制、boot 事件两条通道的纪律都是stdout 只走协议帧一切日志走 stderr见 server.ts 的注释。协议与诊断分离意味着日志打多了也不会把通信协议冲花这是长连接服务稳定性的基本功。页面侧的桥实现见 bridge.ts它对内核页面暴露的接口面经过严格收敛——只保留官方契约加窗口控制壳层自造的扩展面全部剥除。隐藏的地基DPX 环境隔离层三层之外还有一个贯穿全局的地基DPX 环境隔离environment.ts dsh-dpx。问题背景是如果 EAC 直接复用系统里旧的.dsh目录老版本的插件和依赖会被新内核继续读取实测后果是插件加载失败和白屏。EAC 的解法很干脆——每个发布通道beta / rc拥有独立的数据根目录内核、插件、缓存全部装在自己的沙箱里互不污染。更关键的是它的失败策略fail closed。环境初始化失败时 sidecar 会直接退场并记录错误走恢复链绝不悄悄回退到宿主旧目录——因为在错误的数据根里假装成功才是最难排查的故障来源。设计细节见 0004-EAC安装环境隔离.md。总结一张表看懂 EAC-Desktop 三层分工问题谁来回答入口文件窗口为什么能最小化/拖动L1 Rust 壳拦截win.*方法main.rs内核进程怎么启动、挂了怎么恢复L2 sidecar 进程编排boot-server.ts插件太多怎么治理L2 保护中心快照/体检/回滚guard-box.ts数据会不会被旧版本污染DPX 通道隔离fail closedenvironment.ts对话、工具执行、插件能力在哪L3 dsh 内核零修改package.json这套架构给普通用户带来的实际好处是内核可以激进迭代而不影响桌面体验桌面集成可以按平台优化而不触碰 AI 内核插件装多了也有保护中心兜底。三层边界看似增加了工程复杂度实际上是把复杂性关进了明确的笼子里——这正是 EAC-Desktop 能让数百个 DSH 插件和谐共存的根本原因。【免费下载链接】EAC-DesktopEmbracing All Creation (Desktop) — Dedicated to the Harmonious Coexistence of Hundreds of DSH Plugins / 揽尽万象桌面版 —— 致力于让数百个DSH插件和谐共存项目地址: https://gitcode.com/gh_mirrors/de/EAC-Desktop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考