Unikernel 曾经很难用。关键词：曾经

# unikernels 很难。关键词：曾经。 来源：https://ghuntley.com/unikernels/ Justin Cormack 曾经参与 MirageOS 和 Unikernel Systems 的开发，他最近注意到了一个我也有同感的现象：人们正在重新发现（或重新认识）unikernels。他正在为自己的 newsletter 做一系列相关访谈，而我是第一个被访谈的对象。他给我发了封邮件，五分钟后我就端着一扎啤酒在酒吧里跟他聊上了。我们深入探讨了 Mirage、Orleans、Haskell、Nix、Cursed 等等。 以下是整理后的内容摘要，底部附有章节链接，方便你直接跳到对话的某个部分。Justin 编辑过的访谈文字稿请见 [Ignore Previous Directions](https://buttondown.com/justincormack/archive/unikernels-in-2026-part-1-geoffrey-huntley/?ref=ghuntley.com)。 > Unikernels 曾经很难。关键词：曾经。现在我们有了 AI。 ## unikernel 是什么，以及它为什么曾经很难 我第一次接触 unikernels 大约是在 2015 年。当时我组建了一个 Haskell 团队，对函数式编程研究得相当深入。有 Haskell 的地方就有 OCaml 程序员，而顺着这条线索你就会找到 [MirageOS](https://mirage.io/?ref=ghuntley.com)。一个很棒的想法。那时我就玩过它。 unikernel 的核心理念是：你的应用**就是**操作系统。没有用户态。如果你需要一个 Web 服务器、DNS 或发邮件的功能，没有任何现成的东西可以 fork 或 spawn。你必须把它们作为库写进你的应用里。 这正是当年的痛点所在。Justin 记得很清楚：他们当年在构建 Mirage 时已经有了 TCP 协议栈和 HTTPS 协议栈，但在存储方面几乎一无所有。他们不得不从 NetBSD 里提取驱动，因为在用户态也能运行它们。那个年代确实很难。 我们这个行业里有太多教条了。Nix 很难。Bazel 很难。Unikernels 很难。是的，它们*曾经*很难。这些难懂的概念如今已经存在于模型权重之中了。你要做的就是用 prompt 引导它们，从认知上去掉"它们很难"这个教条。 ## 操作系统是设计债务 每一个非 unikernel 的应用，都是建立在"存在一个应用层，底下还有一个操作系统层"的假设之上。我们为什么需要操作系统？因为四十年前有一个人类操作员。我用过 IBM 5250、AIX、Solaris 和大型机。多用户操作系统的存在，是因为有一个人坐在它面前，然后我们把应用放在上面。 我认为这是设计债务，而且现在尤其重要。应用会被攻破。在 AI 时代之前就有人被攻破了。有人攻破了用户态应用，拿到了一个 shell。那个 shell 就是一个供数据外泄专用的 VIP 管家服务。 使用 unikernel，攻击面要小得多。如果功能不在应用（也就是操作系统）里，那攻击者就无路可走了。没有下一跳。 Justin 在这里提出了质疑，而且有道理。减少攻击面这件事，人们的理解非常模糊。你可以从 Linux 容器里移除 shell，但几乎每个 Linux 环境中仍然存在某种实质上是解释器的东西。即使没有可写文件系统，你仍然可以执行新程序。内存安全和各种攻击组件仍然需要担心。 都对。但看看我们过去二十六年一直在做的事情。我记忆中最早的格言来自 SunOS 和 cgi-bin 时代——*"不要把编译器放在生产环境"*。然后是构建容器和生产容器。再然后是 Chainguard。我们一直在一点一点地削减攻击面，而不是反其道而行之，从源头确保*根本没有*攻击面。 而这一点恰恰是人们忽略的：如果没有 shell、没有解释器，模型权重中就没有任何东西知道下一步该怎么做。这就把一次"顺手牵羊"式的攻击（随便挑一个你用的框架本周的 RCE 漏洞，你就能拿到 shell，而且模型权重*知道*拿到 shell 后该做什么）变成了一种需要拿到你源代码的定向攻击。 ## 现在你可以直接移植缺失的库 经典的反驳是：你的 unikernel 需要调用 Stripe，但 OCaml 没有 Stripe 库。在 AI 之前，你只能叹口气自己写。现在呢？[运行一个循环](https://ghuntley.com/loop/)，把 Go 的库移植到 OCaml。给，unikernel 里的 Stripe。 Justin 举了一个同样精彩的例子。他一直在为设备（appliance）构建最小化的 Linux OS 镜像，这已经算是半个 unikernel 了，因为只运行一个应用作为 PID 1。他需要创建一个 XFS 文件系统。与其把 xfsprogs 以及它带来的全部依赖拖进来，他和一个 AI agent 一起坐下来，让它用 Rust 重写了 `mkfs.xfs`，输出逐字节完全一致，每个 flag 都正确解析。它逐一逆向了磁盘上的格式，跨不同块大小写了测试。整个过程只花了几个小时。 这之所以可行，是因为原版工具就是一个黄金 oracle（参考实现）。用两种实现生成不同大小的文件系统，然后 diff。把测试也移植过来。自动化整个过程。 移植软件这件事已经变得很简单了。如果你有 oracle，移植就是一个循环。Geoffrey Huntley (https://ghuntley.com/porting/) 存储是另一个大缺口。如今大多数工作负载都是云原生形态的，即使在本地部署也是如此，所以可以采用 [turbopuffer](https://turbopuffer.com/?ref=ghuntley.com) 的方式：以 S3 作为主力的、可无限扩展的存储，加上本地 NVMe 块缓存和 LRU（或你喜欢的任何缓存算法）来处理热点数据。Justin 也是一个狂热的"一切用 S3"的拥趸。只要延迟不是瓶颈，你就能获得支持多用户访问的无限存储，所有东西都可以在它之上构建。 ## Nix 机器测试和 overlays Justin 也在玩 Nix，他很惊讶地发现，第一次让 agent 来原型设计一个 OS 时，它自动把所有测试都构建进了 flake 里。 Nix 这门语言不行。Nixpkgs 很棒。[NixOS 机器测试](https://nixos.org/manual/nixos/stable/?ref=ghuntley.com#sec-nixos-tests)简直是神中之神：你写一个测试，它会启动一组虚拟机，然后验证你的网络规则和应用之间的交互。这是人们不知道的好东西。 而当上游出了问题，或者你的依赖中出现了供应链问题，一个 overlay 就能解决。 这个世界还没有意识到，你真的可以就用一个 Nix overlay 修复一切。修补世界。Geoffrey Huntley。Geoffrey Huntley (https://ghuntley.com/nix/) > 如果你需要 tool-call 一个人类（也就是"尊敬的维护者"），而他可能在度假，或者已经弃坑了，你还得等一天、两天甚至五分钟，那这就不是 AGI。 我们在这里构建的是递归式产品。Agent 需要有能力把世界作为第一方源码来修改，而不是作为第三方的打包二进制。我们要回到 contrib 文件夹和 Unix patch 的年代。 ## 如果你在乎安全，你其实只有两个选择 Justin 问 unikernel 还需要什么才能让人们重新发现它。说实话，就是这个。我们已经培养了两代甚至不知道 unikernel 存在的开发者。 如果你真正关心安全，实际上只有两个选择： 1. 你在把卫星送上太空，那你应该用 [seL4](https://sel4.systems/?ref=ghuntley.com)，一个经过形式化验证的操作系统。（我至今对澳大利亚政府解散那个团队耿耿于怀。） 2. 其他所有人都应该认真考虑 unikernel。别再试图去加固一个本身就可以被攻破的东西。反过来，从另一个方向设计。 另一个经典的批评是，许多早期 unikernel 设计让所有东西都运行在同一个特权级别：你的应用和操作系统在同一个 ring 里。到了 2026 年，如果你想要 ring 隔离，只要一个 prompt 就能搞定。这至少比祈祷你的 systemd cgroup 配置是正确的要安全得多。 想想企业在 Linux 上每次有新东西发布时，要花多少时间修补整个世界。上游现在期望你每周都打内核补丁。我们录制这期访谈的那周，有人攻破了 KVM（本质上就是 Firecracker，我们以为是很好的沙箱化核心原语），并从 Vercel 和其他几家厂商那里拿到了 50,000 美元的赏金。对于一个能 root 掉世界上所有主流云提供商的东西来说，这笔钱实在是太少了。 ## Spaceleans：一个分布式 unikernel 操作系统 大约七个月前，我深入研究了 unikernel，以验证我的心智模型是否正确。我给 Justin 看了我的 Mirage 文件夹，里面装着我需要添加的所有功能。 - unikernel 集群无法对时，所以我从另一种语言移植了一个 NTP 客户端。然后我基于 RADclock 构建了一个 NTP 服务器，借鉴了 [TigerBeetle 处理时间的方式](https://tigerbeetle.com/blog/2021-08-30-three-clocks-are-better-than-one/?ref=ghuntley.com)：不是单一的时钟源，而是多个时钟源，打包为一个库。 - 网络协议栈、DNS、HTTP 客户端和服务端、结构化日志、OpenTelemetry、Anthropic 和 OpenAI 客户端，以及通过 Airwallex 的支付。 - 一个用于处理 HTTP 背压（back pressure）的通用重试库，外加一些 PPX 元编程来好玩。 - 一个在日志边界上的 PII 包装器，确保密钥和个人信息永远不会通过日志子系统泄漏。每个项目都应该有一个。它是可插拔的，用 functor 就行。 然后是那个最疯狂的东西，我以前从未展示给任何人看：**Spaceleans**，把 [Microsoft Orleans](https://learn.microsoft.com/en-us/dotnet/orleans/overview?ref=ghuntley.com) 移植到 OCaml，作为 unikernel 运行。 Orleans 是一个支持事务的分布式 actor 系统。你把多台物理机合并成一个可寻址的堆（heap）。一个 actor 永远存在：`await GetCustomer()`，如果它不在内存中，它会从一个可插拔的存储提供者中被重新水合（rehydrated）。你把 n 层架构折叠成 actor，再也不用关心它是在机器 A、B、C 还是 D 上。运行时把它作为基础设施原语来处理。 所以在某种奇怪的意义上，我用 actor 构建了一个分布式 unikernel 操作系统，上面还加了一个文件系统。Justin 说它像 Erlang，他说得对。我一周之内就做完了全部这些。我可能永远不会发布它，但它证伪了 unikernel 很难这个想法。 ## 采样历史 年纪稍长一点的好处是你能够采样历史，就像经验丰富的 DJ，比如 Carl Cox，在圈子里待得够久，就能从过去的曲目中提取素材并推陈出新。所有这些想法在八十年代就存在了。模型们读过那些论文。它们的训练数据里有 TAPL 和最前沿的类型理论。 > 缺少的是人们做这些疯狂之事的好奇心和野心，以及知道前人的唱片存在可以被采样的认知。 我们怎么让人们尝试这些东西？直接去做就行。如果你有一个涡轮增压兰博基尼外星空间火箭，效率更高、更安全，那恭喜你，你获得了领先优势。做很酷的事情，吸引好奇的新人，指导他们，成长。和以前一样。 与此同时，其他所有人都会忙着用 Chainguard 来加固他们的 Ruby on Rails 应用，用五十个持有 AWS 认证的工程师来管理 AWS，而其实两个人加 Nix 和 Hetzner 就够了。归根结底，还是要算经济账。更强大的工具效率更高，而效率就是王道，尤其是在 AI 压缩利润率的当下。 ## OCaml、Rust、Haskell 和背压 OCaml 的时代又要来了吗？它依然强劲。某家交易公司把它用得非常好。年初我和 Yaron 聊天时，我问他 [OxCaml](https://oxcaml.org/?ref=ghuntley.com) 是否存在是为了让他们的语言扩展进入训练数据、提升整个公司。他给了我一个非常"无可奉报"的微笑。 对 agent 来说，OCaml 简直是美妙的。模块之间的 functor 是美的。`.mli` 文件——用类型化的头文件描述一个模块应该如何工作——对 agent 来说是极其高效上下文。opam 和 Dune 确实好用。Hindley–Milner 类型推断。而且编译速度快。如今我看不出有什么理由还要去用 F#。 Justin 最近主要在写 Rust，agent 们也很擅长 Rust。但编译时间是[背压](https://ghuntley.com/pressure/)的税。LLM 会幻觉，当编译很慢时，每次幻觉的代价都很高，因为每分钟能尝试的次数就变少了。Justin 的 S3 克隆项目大约有一百万行 Rust 代码；四个 agent 同时编译时，它们会争抢磁盘和 CPU。结果花在高速机器上的钱比花在 token 上的还多。 Haskell 的类型系统很棒，模型们也确实掌握得很好。但我在生产环境中跑它总觉得不踏实：空间泄漏（space leak）存在于运行时的状态空间中，只会在生产环境暴露。Justin 指出，Rust 中线性类型的思路就是从试图解决这个问题的 Haskell 论文中发展出来的。还有 Zig 的方法：一次性分配所有内存然后永不释放，这是八九十年代游戏开发者的做法。不过很难说服 agent 在 Rust 里这么做，因为恒定内存程序不在它的训练集中。 我认为依赖类型（dependent types）是下一代语言的赢家。任何能让你在类型系统中编码更多信息的东西都意味着更强的背压。你听到我有一个支持依赖类型的 Rust 工具链 fork 大概也不会惊讶。现在你确实可以直接做到这些事。 ## agent 的语言，以及 Cursed 教会我的事 语言发展的速度一直受限于人类学习新概念的速度。运算符链本质上是为人类准备的语法糖。如果 agent 来写代码，我们可以利用四十年的学术 PL 研究成果，只要你知道如何采样它。 在 Python 2 到 3 之后，业界将"不要做破坏性变更"这条规则固化了下来。Justin 认识一些公司，几百人的团队花了数年时间做迁移。我认为这条规则已经不再成立了。随破坏性变更一起发布一个 skill pack，让 agent 自动迁移就行。 Justin 问现在让一门新语言成功到底要花多少钱。Go 是最后一门公司真金白银投入的语言，而且花了很长时间。这个我能回答。 我让 Claude 循环运行了三个月，它创造了一门叫 **Cursed** 的 GenZ 编程语言。它是唯一一门让你用 sus、slay 和 vibes 编码的编译语言。Geoffrey Huntley。Geoffrey Huntley (https://ghuntley.com/cursed/) Cursed 是用 Sonnet 3.5 和 3.7 构建的，一个刻意模糊的 prompt，加上三个月的循环运行。我从 C 开始（背压不够；agent 把自己的更新搞坏了，我在 Valgrind 里浪费了太多时间），然后是 Rust，然后是 Zig。选 Zig 是个错误；如果我坚持用 Rust，今天就能用了。它花了大约 6,000 美元，而且我做了三遍。对比一下 Go 的成本。 现在是真正让人害怕的部分。如果你正确分配了 context window——一个关于词法结构和语法的查找表——模型就能用一门不在它权重中的语言编程。这是暴力穷举，效率不高，但它确实有效。 想想 T-图（tombstone diagram）。锁定你的语法和词法结构，达到二阶段自托管编译器的程度，发布一个像样的标准库，然后开始下一次训练运行。从那里，你可以以惊人的速度达到一个 Roslyn 风格的自托管编译器，带语言服务。Justin 问微调一个开源模型是否有助于引导这样一门语言。不需要。 这在一个半以前、模型远没有现在强的时候就已经被验证了。只需要有一个编程语言设计者全身心投入好模型，就能震惊世界。 ## 接下来 酒吧快关门时，Justin 问我有什么想法。如果你还没读我最新的那篇文章，去读一下。如果你是管理别人的，现在就为他们创造实验的空间和时间，因为不出六个月，管理层就会要求你把人投入到