Nexu 是一个一键安装的开源 OpenClaw 桌面客户端，让你用 AI 掌控一切——在本地。 GitHub：github.com/nexu-io/nex… ⭐ 觉得有用的话，点个 Star 就是最大的支持。
上篇：Windows 党终于等到了！Nexu v0.1.12 + 免费模型上线
上周我们发布了 Nexu v0.1.12，正式支持 Windows。作为全网首个基于 OpenClaw 的开源桌面客户端，日均处理百亿级 token，Windows 支持是社区呼声最高的功能。
但"支持 Windows"三个字背后，是整条打包流水线的重建。直接看结果：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| ⏱ 打包时间 | 15 min | 4 min |
| 📦 安装时间 | 10 min | 2 min 以内 |
| 🔄 CI 构建 | 手动 | 全自动 |
| 🧩 更新逻辑 | 耦合 | macOS/Windows 彻底解耦 |
我们在这个过程中踩了不少坑，也做了一些不那么常规的技术决策。既然是开源项目，这些经验就不应该藏着。这是实战系列的第一篇，希望能帮到同样在做 Electron 跨平台交付的团队。
electron-builder 哪里不够用
electron-builder 是 Electron 生态最主流的打包工具。大多数项目直接用它从源码到最终安装包一把梭，我们最初也是这么做的。
但在实际跑通 Windows 全流程之后，我们发现默认路径在这几个场景下卡脖子了：
- Nexu 打包后的文件树包含约 3.8 万个文件，默认的 ZIP 压缩方式处理这个规模极慢，安装时逐个解压更是灾难
- 需要在安装器里加入自定义逻辑，比如数据迁移选项、注册表清理
- macOS 和 Windows 的更新语义完全不同，不能用同一套流程
- CI 产物要可复现，不能依赖本地环境
electron-builder 仍然参与生成 win-unpacked（解压后的应用目录），但从这个点之后，我们接管了。
自定义 7z + NSIS
我们最终选择的方案分两步：
第一步：electron-builder 产出 win-unpacked
这一步 electron-builder 仍然发挥作用，生成标准的 Electron 应用目录。
第二步：自定义打包接管
- 用 vendored 的 7-Zip 将 win-unpacked 压缩为
payload.7z - 用 makensis 编译自定义 NSIS 安装器
- 安装器负责解压、写注册表、创建快捷方式、处理卸载逻辑
为什么选 7z？ 面对 3.8 万个文件的 Electron 应用目录，7z 的固实压缩（solid compression）可以把大量小文件当作一个整体压缩，压缩率和解压速度都远优于 ZIP。这也是安装时间从 10 分钟降到 2 分钟以内的关键。
为什么选 NSIS？ 它给了我们对安装流程的完全控制。安装路径、数据迁移、卸载清理——所有行为都能自定义，而不是被框架的默认行为绑架。
顺便提一句，我们把 7-Zip 直接 vendor 进了仓库，这样 CI 和本地构建都不需要额外安装依赖，可复现性直接拉满。
平台驱动分离
这是我们踩的一个大坑：之前 macOS 和 Windows 的更新逻辑挤在同一条路径里，靠 if (platform === 'win32') 硬分叉。
问题是，这两个平台的更新语义从根本上就不同：
- macOS 可以在应用内完成静默更新
- Windows 需要关闭应用 → 运行安装器 → 重启
把它们强行塞进同一套逻辑，只会越改越脆弱，每次修 Windows 的 bug 都有可能连带搞坏 macOS。
所以我们引入了 Update Driver 抽象——三个独立的平台驱动：
- mac-update-driver — in-app 下载安装
- windows-update-driver — 外部下载 + 重定向安装器
- unsupported-update-driver — 其他平台的优雅降级
分开之后，每个平台的更新行为可以独立演进，互不干扰。这个模式如果你也在做跨平台 Electron 应用，强烈建议尽早引入。
运行时定位
还有一个容易忽略的坑：Electron 打包后运行时文件的位置取决于打包配置，但之前的代码用比较松散的方式推断路径。
这意味着一旦构建输出的目录结构稍有变化，运行时就可能找不到了——而且这种问题往往只在打包后才暴露，本地开发完全正常。
我们的解决方案是写了专用的 Windows 运行时定位器，基于 exe 相对路径做显式查找，把构建输出布局、运行时打包布局、运行时查找逻辑三者的契约收紧。
以前是"大概在这个位置"，现在是**"必须在这个位置，找不到就明确报错"**。错了就立刻知道，不会悄悄跑起来然后在用户那里炸。
CI/CD 流水线
之前 Windows 构建基本靠本地手动跑——能不能成功取决于你的机器环境配置得对不对。
这次我们把完整的构建 → 打包 → 签名 → 发布流程搬到了 GitHub Actions：
- nightly / beta / release 三套 workflow 都支持 Windows
- 自动生成
latest-win.json更新清单 - 产物包含安装器、hash、元数据，全程可溯
这是 Windows 从"能用"到**"能持续交付"**的基础。对于开源项目来说，可复现的 CI 流程比什么都重要——任何贡献者都能跑出一样的结果。
下一步
这次改造的核心价值不是炫酷的新功能，而是交付基础设施的升级。打包更可控，更新更稳定，路径更确定。
为了让用户尽早体验到新的打包流程，我们仍有一些实验性质的优化策略在验证中（比如 Windows 用户数据的生命周期迁移），后续打磨完会单独分享。
开源的意义不只是把代码放出来，更是把踩坑的过程也分享出去，让后来者少走弯路。
说到分享，除了 Nexu 本身，我们也在做一个免费开源的 AI Agent 技术知识库——Harness Engineering Guide。
这个项目收录了 AI Agent 领域的架构设计、技术实践、产品横评和前沿论文，目前已有 20+ 篇深度内容，持续更新中。
🌐 网站：harness-guide.com 📦 GitHub：github.com/nexu-io/har…
如果你对 AI Agent 技术有自己的理解和实践，欢迎投稿。提 Issue 或直接 PR，我们会认真 review 每一份贡献。
Nexu 是完全开源的，所有代码都在 GitHub 上：github.com/nexu-io/nex…
如果你也在做 Electron 应用的 Windows 打包，踩过类似的坑，或者有更好的方案——来 GitHub 聊聊，开源社区就是这么玩的。
