安装慢往往不是包太大，是小文件太多

初衷文之后，桌面端要从「我自己能跑」走到「别人装得上」。

我更在乎的不是下载按钮画在哪，而是打包规则本身：

包怎么尽量小？Windows 安装为什么拖成泥？这两件事经常被混成一句「优化安装包」。实际不是一回事。

慢的经常是文件个数，不是总大小

本机 Agent 带着一整棵 runtime：会话、工具、委托都在那一层。依赖是真·node_modules。

Electron 默认会把渲染层打进 app.asar。runtime 不行。它用 ELECTRON_RUN_AS_NODE=1 起子进程，没有 asar 虚拟文件系统，依赖必须落在真实路径上。

于是慢点就暴露了：松散的 resources/runtime/node_modules 里是上万小文件。NSIS 逐条写出时极慢；DMG / zip 拷贝也慢。你盯安装包 MB 数，以为还行；用户盯进度条，已经等疯了。

对策很土，但有效：物化之后，立刻打成单个 node_modules.tgz，再删掉松散树。安装器只处理一个文件；展开交给系统 tar。Windows 在 NSIS 的 customInstall 里解；mac 没有安装脚本，首次启动再解一次，大约十几秒，之后跳过。

.tgz 本身已是 gzip。还得告诉 NSIS 别再压一遍，否则白费 CPU，安装也不更快。

打包规则写成流水线，不靠临场发挥

afterPack 里顺序是死的：

1. prune：砍文档、sourcemap、@types、常见 changelog / readme。只删确定用不到的；不删业务依赖，也不误伤包内部叫 doc 的目录。
2. materialize：把构建机上的绝对路径 symlink 改成包内相对链接，保留「一份 .pnpm 实体」。逃逸出包的链接直接报错，不静默出坏包。
3. pack tgz：打归档，删松散树。

为什么不把整棵 node_modules 写进 extraResources？electron-builder 会按忽略规则跳过它。所以 package.json 只带 dist 和 package.json，依赖在 afterPack 注入。

这三条合在一起，才叫「打包规则」。少一步，要么体积炸，要么装到别人机器起不来，要么安装器卡在小文件上。

mac 保体积，Windows 保能解开

同一份依赖，打 tgz 时 follow 必须按平台分叉。

mac：follow=false，保留相对 symlink。dmg 大概在 160MB 量级。我踩过坑：darwin 误开 follow，链接被解成多份实体，dmg 胀到 216MB+。体积回归时，先查是不是跟错了平台开关。

Windows：follow=true，必须解成实体文件。Windows 自带的 tar 要求创建 symlink 时目标已经存在；归档里顶层链接常常先于 .pnpm 实体出现，会大片 Cannot create symlink。setup 会更大，但 NSIS 仍然只解压一个 tgz，安装速度还能保住。

两边目标不一样：mac 优先「一份依赖」；win 优先「解得开」。用同一套 follow，两边都会倒霉。

我实际在优化什么

下载页、Windows 构建链、版本提到 0.1.1，同日都做了。那是入口。

这篇文章想记清楚的是入口后面的判断：

• 包要小：先 prune，再靠相对链接别复制多份。
• 安装要快：别让安装器面对上万小文件，打成单个 tgz。
• 规则要分平台：mac 禁 follow，win 必须 follow；注释和测试里都写死了回归信号。

同日产品侧还有委托舰队与取消。协作体验和安装体验是两件事；装不上，前面都白做。

签名、杀软、不同 Windows 版本差异后面还会冒。当前这套先把「体积」和「小文件拖垮安装」这两条红线钉住。

想试用：https://agentup.me/download。