「Unikernels were hard. Key word: were. Now we have AI.」
2026 年 10 月，Geoffrey Huntley 在技术对谈中给出了这句断言。桌对面的 Justin Cormack 是 MirageOS 的早期核心作者。十年前为了在虚拟机上裸跑，团队只能从 NetBSD 抽取驱动。这些代码全靠手工移植到用户态运行。
Unikernel 是一种单地址空间架构：应用程序本身就是操作系统。镜像里没有独立进程划分，也没有可供交互的 Shell。开发者想收发网络包或解析域名，不能依赖外部环境。所有底层驱动和协议栈必须直接编译进镜像。
过去十年间，陡峭的工具链与匮乏的生态让这项技术长期坐冷板凳。如今大模型抹平了编写专用库的门槛。但开发门槛的降低，并没有替它解决架构固有的安全争议。
图：把 unikernel 描绘为一枚精简数字核心的概念插画。来源：ghuntley.com
模型权重替开发者扛下了手写驱动门槛
在 Huntley 眼里，行业长期被一长串技术教条困住。Nix 很难，Bazel 很难，Unikernel 也很难。这些难点本质上只是实现细节构筑的知识壁垒。
模型权重吸收了类型理论与历史论文。过去需要耗费数月编写的底层脚手架，如今只隔着几条提示词。资深工程师不再需要逐行搬运 C 语言驱动代码。
Huntley 用一周时间做出了 Spaceleans 原型。他将微软 Orleans 分布式系统移植到 OCaml 环境，做成了 Unikernel 镜像。系统把多台物理机合并为一个可寻址堆，actor 实例随时可以从存储中唤醒。
为了跑通原型，他必须补齐一整套运行时底座。借助代码生成，他在 7 天内写完了网络栈、DNS 服务与 HTTP 客户端。随后他又补上了 NTP 时钟同步、大模型客户端以及分布式追踪。这种原本需要团队人力的底层工作，被个人开发者在几天内装配完成。
生态匮乏的问题在代码生成面前失去了杀伤力。过去反对 Unikernel 的理由是缺少第三方 SDK，比如 OCaml 没有成熟的支付接口。启动自动化代码循环后，模型能在几小时内把 Go 库重写为 OCaml 模块。
几个小时内用 Rust 仿造专用工具链
Cormack 自己的工程实践也出现了类似路径。他在构建单应用 Linux 镜像时追求体积精简。传统方案为了格式化磁盘，必须把庞大的 xfsprogs 塞进镜像。这仅仅是为了运行其中一条命令。
他选择让模型用 Rust 重写一个专用的 mkfs.xfs 工具。原生工具直接充当黄金基准（golden oracle）。模型生成的代码与原生输出逐字节比对，并在多种块大小下跑通测试。整个工具的参数解释与磁盘结构写入，只花了几小时。
这种工作流改变了专用系统工具的生产方式。过去裁剪底层工具意味着沉重负担。团队只能被迫接受臃肿的用户空间。代码生成与基准比对，把工具定制成本压到了近乎可忽略的区间。
云原生基础设施的演进，进一步降低了本地文件系统的实现要求。类似 turbopuffer 的现代架构直接把对象存储当成主持久层。本地 NVMe 盘只负责块缓存与淘汰逻辑。持久化交给云端之后，本地不再需要日志型文件系统。系统依赖对象存储就能支撑大规模状态。
图：「Unikernels in 2026」对谈视频封面。来源：YouTube / Geoffrey Huntley 频道
剥离操作系统外壳并不等于消除攻击面
门槛降低之后，围绕安全价值的争议反而更加尖锐。Huntley 认为多用户操作系统是终端时代的陈旧包袱。专用程序根本不需要多余的操作界面。没有 Shell 和系统解释器，入侵者拿不到外泄跳板。批量扫描攻击因此失去目标。
但 Cormack 对此当场表达了保留态度。他直言社区对「削减攻击面」的理解长期停留在模糊口号上。在容器里删掉 Shell 并不困难，但业务运行环境依然自带等价的解释能力。即使关闭磁盘写入，内存破坏与 ROP 链依然能劫持程序执行流。
Huntley 也承认早期设计把应用和内核放在同一个特权环，但他认为这在 2026 年只是「一个 prompt 的距离」就能补上 ring 隔离的程度，而且再怎么论资排辈，也比祈祷自己的 systemd cgroup 配置写对了更安全。Cormack 在这一点上没有继续推进，他关心的是攻击面这个概念被含糊地当成口号使用。
即使是底层虚拟化沙箱，也存在被突破的现实风险。对谈录制当周，研究人员靠 KVM 逃逸漏洞从云厂商拿到 5 万美元赏金。这类漏洞足以动摇多租户托管的隔离基石。追求极高安全需要转向 seL4 这类系统。盲目寄望于单镜像只会转移安全风险。
本地编译延迟正在反噬模型推理效率
编程语言的选择直接影响了自动化开发效率。Huntley 偏好 OCaml 语言。清晰的接口提供了紧凑上下文，编译器几秒就能完成类型校验。
Cormack 在 Rust 生态中则遇到了明显的阻力。Rust 的严格类型系统很适合推演，但庞大的构建开销拖慢了迭代节奏。模型探索底层实现时难免出现幻觉。漫长的构建等待大幅推高了试错成本。
在百万行代码的项目中，编译甚至耗尽了机器资源。四个模型代理并发编译 Rust 代码，瞬间打满了磁盘与 CPU 负载。在高速服务器上，等待编译的时间开销甚至超过了生成 token 的花费。
这种工程现实颠倒了传统的开发逻辑。人工编码习惯用慢编译换取运行期可靠性。在模型主导的试错流中，编译延迟成了制约系统迭代的核心瓶颈。
工程摩擦消失后暴露出纯粹架构抉择
单地址空间设想并未过时。模型消化了类型理论与历史论文，能快速填补工程空白。驱动和网络栈的代码生成，大幅缩短了搭建专用系统的周期。
但工程摩擦的消退，并没有改写体系结构的基本法则。剥离脚手架之后，摆在开发者面前的是 Unikernel 的真实底色。它依然是一个缺乏特权环隔离、对内存安全高度敏感的单进程沙盒。
AI 抹平的是入场券的造价。开发者不用再为手写驱动发愁，但必须直面单特权环带来的系统风险。要不要抛弃操作系统的调试生态，始终是需要权衡的工程抉择。
参考链接：
- Ignore Previous Directions: Unikernels in 2026 (Justin Cormack)
- Geoffrey Huntley: Unikernels were hard. Key word: were.
- Spaceleans 项目设计纪要与 MirageOS 回顾
