David Crawshaw：为什么我要再造一个云

Tailscale 的联合创始人 David Crawshaw 今天发了一篇长文《I am building a cloud》。背景是 exe.dev 刚完成 A 轮融资，正式的融资公告写得体面、克制，所以他决定写点私人化的东西：为什么他已经在做一家很成功的公司，还要回头再造一个云。

他的结论很直接：我喜欢的就是计算机本身，但今天的云，让我没法享受计算机。

这句话听起来很朴素，但拆开来看，他指出的问题都很具体。

第一，VM 的形状错了。在 exe.dev 上，你买的是 CPU、内存和磁盘，然后在上面跑你想跑的 VM。而在 AWS、GCP、Azure 上，你买的是"实例"——一种把 CPU、内存绑定在一起的抽象。你想在一台物理机上跑十个轻量 VM？不行，你得拿一台大实例，然后用 gVisor 或嵌套虚拟化自己搞隔离，还要自己配反向代理。所有这些额外工作，只是因为云厂商的抽象选错了。

第二，磁盘的速度被白白浪费。云厂商希望你用远程块存储。这在机械硬盘时代是合理的：机械硬盘的随机寻道要 10ms，网络 RTT 1ms，开销只有 10%。但现在大家都用 SSD 了，寻道时间降到 20 微秒。远程存储的开销从 10% 变成了 10 倍。Crawshaw 说，在 EC2 上配 20 万 IOPS 要一套复杂的流程，每月花 1 万美元，而他的 MacBook 有 50 万 IOPS。

第三，网络出口的定价策略。云厂商的网络本身技术没问题，但出口流量费是普通数据中心的 10 倍。这不是技术限制，而是商业策略：确保你建的东西没法便宜地搬走。

第四，PaaS 抽象本质上是权力让渡。你学了一套特定厂商的写法，做到一半发现某个基本操作因为平台抽象的某个隐蔽限制而做不到。你换一家？还得重新学一套。Kubernetes 试图统一这些抽象，但 Crawshaw 说这是在做不可能的事：在错误的底层抽象上建正确的上层抽象，本质上就是在猪身上涂口红。

然后文章转了一个很关键的弯：为什么是现在？

Crawshaw 的回答是：因为有 agent。

Agent 让写代码变得更容易，意味着会有更多的软件。经济学家管这叫 Jevons 悖论：效率提高了，总消耗反而更多。每个开发者会写更多程序，需要更多地方来运行它们。云从"烦人的问题"变成了"真正的大问题"。而且 agent 本身也会在云的糟糕抽象上浪费 token——每一百分之一的上下文窗口花在理解如何扭曲 AWS API 上，就少了一百分之一的上下文窗口用来解决你的实际问题。

嗯，这段话值得单独拎出来。它不是"AI 会改变云"那种空话，而是给出了一个具体的机制：agent 的 token 是有限的，云的抽象越差，agent 越 inefficiency，你得到的结果就越差。这是一个很实在的经济激励。

从工程角度看，这篇文章最有价值的地方，是它把"云的问题"从抱怨变成了可操作的判断。它不是在说"云不好"，而是在说"云的哪些构建块形状错了，为什么错了，怎么改"。VM 应该解绑资源、磁盘应该是本地的、网络出口费应该接近成本——这些都是可以验证的具体主张。

从更大的角度看，这篇文章真正提醒我们的，是另一件更根本的事：当 agent 开始成为主要的代码生产者时，"好用"不再只是开发者体验的问题，而是直接关乎 agent 效率的问题。而今天的大多数云，是为人类开发者设计的，不是为 agent 设计的。

所以今天真正值得记住的，不是"又有人要造一个云"，而是另一句更关键的话：云的抽象越差，agent 的 token 越浪费，你得到的结果就越差。当 agent 成为主要的代码生产者时，"好用"就不再只是体验问题，而是效率问题。