Fly.io CEO Kurt Mackey 卸任

# 直面变化 来源：https://fly.io/blog/kurt-scott-money-sprites/ 一幅古老的酷炫安妮插画，描绘了某种传送门场景 图片来自 [Annie Ruygt](https://annieruygtillustration.com/) 我们是 Fly.io，一个公有云平台。它既是我们最喜欢将应用部署到互联网的方式，也是我们最喜欢让前沿智能体编程框架安全运行的地方。这篇文章关于我们的公司、未来，以及 Sprites——一种为智能体设计的计算机，你现在就可以[上手体验](https://fly.io/sprites)。 这是一篇复杂的文章。所以我需要你答应我一件事：如果你读完了这段引言，就请把剩下的全部读完。这是信誉问题。 几个月前，Theo Browne 做了一期视频，评价“2026 年托管新应用的最佳位置”（[视频链接](https://www.youtube.com/watch?v=yfxDdQo2cyI)）。Theo 通常会对我们说好话，这次也不例外。但最后他总结说，在他关注的供应商中，我们是那个他最不确定年底还能否存在的。 好吧，操。 Theo 让我们吃了一惊，**因为我们正处于连续几个强劲季度的中间，其中包括公司历史上财务表现最好的几个月**。但这个观点一直在我的脑海里回荡。它狠狠地击中了一根敏感的神经，关乎我们作为一家公司正在做什么以及要走向何方。 老实说，我本该预见到这一点。Fly.io 今年一直在稳步前进，但我有点松懈了，让公司在一场未解决的身份危机中缓缓燃烧。 我马上会再透露一些内情，但不会让你一直疑惑。所以：我们又融了一笔钱。我们正在推出 Sprites 的新迭代版本，并将公司重心放在它们以及它们解决的问题上。而且，我将把 CEO 的接力棒交给 Scott Johnston。 ### 产品-市场契合 我创办 Fly.io 时有两个明确的原则，现在可能已经不再重要了。 第一个原则是，互联网应用在速度快时表现最佳，而这可以通过将应用[部署在靠近用户的地方](https://news.ycombinator.com/item?id=22616857)来实现。我在 Ars Technica 多年的工作中学到了这一点，创办 Fly.io 部分也是为了满足自己的兴趣。这在我们公司的头几年是我们的口号。 第二个原则是，云基础设施过于复杂。开发者需要既拥有 AWS 的灵活性又具备 Heroku 易用性的平台。当我们创办 Fly.io 时，你无法同时获得这两者，而现在，在这里和其他地方都可以了。 你读到这些可能会说，“废话，这些当然重要。”但我得告诉你，它们比你想象的更不重要——原因很明显，也是现在所有人唯一在谈论的：AI 已经彻底改变了软件开发。野狗真的叼走了我们的孩子。 † 在过去的 18 个月里，我每次说这些话，它们就变得更加真实。 我觉得人们还没有完全意识到这一点[†]。我们仍然试图将编码智能体整合到我们的职业中，好像它们只是足够聪明的编译器。但 AI 不同于从发布 C 代码到发布 Ruby 之间的区别。它要重大得多。 大家都忘了，在 Dan Bricklin 发明电子表格之前，世界上每一个“Excel 文档”都是一个计算机程序，由一位计算机程序员构建。短短几年内，每一位商务专业人士都变成了程序员，使用着世界上最重要的编程语言——电子表格公式。AI 就像那样，但规模更大。几乎任何人都可能能够构建几乎任何类型的计算机程序。 现在考虑传统的公有云基础设施。我们将那些按照严格标准、在繁琐的 CI/CD 轨道上构建的固定功能应用，发布给[数百万人的用户群](https://fly.io/blog/the-5-hour-content-delivery-network/)。但一个拥有数百万用户的计算机程序很快会变得像拥有百万读者的电子表格一样。它们存在！但并非主流。 押注于 2020 年的固执公有云设计，就等于押注反对[个性化、自适应的软件](https://sockpuppet.org/blog/2026/05/12/emacsification/)。我认为这不是一个好赌注。即使我这么认为，我也不想下这个注。我想要一个世界，在那里我的朋友和家人可以让计算机完全按照他们的意愿行事，而不必等我为他们构建一切。 ### 智能体想要什么 这就引出了我们的第二个创始原则：严肃的云基础设施对开发者来说太难用了。而且：仍然成立！但这显然更不重要了。 † 实际上，现在拥有精心策划的人类开发者体验和固执的默认设置，可能反而更糟糕。当事情明确时，智能体工作得最好。 大致来说，现在没人读文档了。他们也不会通过试错来学习新的 CLI 并掌握其用法[†]。那是智能体的工作。智能体可以一次性完成 Fly.io 的部署：只需在本地构建一个站点，然后说“让它在 Fly.io 上跑起来”，就能完美运行。但智能体同样可以一次性完成 AWS 的部署。我们这是在干什么？到底发生了什么？ 我去年写过这个，在一篇关于[我们增长最快的客户都是机器人](https://fly.io/blog/fuckin-robots/)的文章里。然后我不再回溯我们已经构建的东西，开始着手弄清楚机器人客户到底想要什么。以下是我总结出来的。 事物 1：编码智能体期望在开发者工作站上运行。 事物 2：即使在你信任的沙盒里，在物理开发笔记本电脑上运行智能体也很烦人，因为当你合上盖子时，笔记本就停止运行了。今年你曾打开 MacBook 上下楼梯吗？手放下了？我猜你家没有楼梯。于是大家最终都把智能体沙盒运行在云上。 事物 3：公有云是不适合运行智能体的恼人地方。我们把服务器分为“宠物”或“牛群”，但对于智能体来说，即使是一头牛也太过投入了。你需要的，我不知道，是一头半一次性牛——一头在你想要的时候恰好出现，停留恰好需要的时间，而且花费不高的牛——这就是为什么类比很难写。 今年早些时候，我们的团队取得了我认为是系统工程乃至整个计算机科学领域的一项突破：我们推出了半一次性牛。我们把它叫做 [Sprites](https://fly.io/blog/design-and-implementation/)。 Sprites 呈现出一个奇怪的形态，这是将它们紧密包裹在我认为机器人所寻找的东西上形成的。你可以快速创建成百上千个，但它们都拥有 100GB 的持久磁盘驱动器。就像云中的一切，它们有按使用计量的计费，但闲置时不计费，并且它们能智能地判断何时空闲。而且你可以在上面托管一个应用，并通过互联网与同事分享。 这些功能的组合构成了一种关于智能体的主张。整个行业痴迷于沙盒。但机器人不想要沙盒。它们想要计算机。这就是我们的半一次性牛：一款为智能体设计的计算机。 ## 你现在就可以创建一个 Sprite 只需要大约一分钟 ✨ [去试试→](https://fly.io/sprites) ### 为智能体设计的计算机 我对 Sprites 的上线效果很满意。但说实话，Sprites 是一个秘密项目。我们甚至没有把它托管在 Fly.io 的主网站上！奇怪的举动。我不是在找借口。我们当时正处于身份危机之中。但现在云开雾散，为智能体设计的计算机将成为我们公司未来的焦点。 † （为了让你明白这话有多真：对整个代码库执行 `git blame`，我的名字出现次数最多） Fly Machines 和我们的平台即服务功能不会消失。但 Sprites 曾经是 Fly.io 内部一个很小的骨干团队的产品[†]，现在不再是了。 通常我们会花几千字深入技术细节，介绍我们如何构建任何新推出的产品。对 Sprites 我们也会这样做。但这篇文章我已经写了不少，还有其他东西要分享。所以现在，我会简短一些。 除了在扩缩和编排方面所做的幕后工作，新 Sprites 引入了两个重要的子系统，它们让我最终认为在我们试图做的事情上达到了“功能完备”。 第一个是 Sprite 块设备（SBD）。最初的 Sprites 存储栈是一个类似地精的装置，我亲自从 JuiceFS 衍生而来，并使用 [Ben Johnson 的 Litestream](https://litestream.io/) 接入我们的系统。听到 Ben 和 Tim Newsham 把整个栈彻底拆除并重建，你应该感到高兴。它更快、更可靠，并且仍然支持即时检查点恢复。 更重要的是，SBD 实现了驱动器分叉：你可以创建一个模板 Sprite，然后高效地克隆数百万次。 Sprites 中另一个重大新东西是连接器（Connectors）。连接器基于我们为[保护核心平台所做的安全工作](https://fly.io/blog/tokenized-tokens/)：它们允许 Sprites 向其他系统发出经过身份验证的请求，而不会给智能体提供任何有用的东西来泄露。连接器具有有趣的安全属性，使用起来也比手动管理账户和 API 密钥愉快得多。 这些是我们最常被要求的功能。这就是为什么在我们专门为智能体公司推出产品后的好几个月里，它们仍然在使用 Fly Machines。所以我足够自信可以下注：除非出现某种外星新技术，对计算机科学造成比 Transformer 模型更奇怪的影响，否则 Sprites 适合我们未来的客户，以及我们现有客户中的很大一部分。这就引出了： ## Fancy Sprite 测试版 想要一个能自我克隆的怪异测试版 Sprite？我可以给你一个脚趾。✨ [注册测试版→](https://fly.io/early-access) ### 我辞职了 这已经酝酿了一段时间，但对于 Fly.io 目前所处的阶段，我认为我作为 CEO 能提取的精华已经大部分被榨干了。所以我将不再担任此职。 在初创公司的头几年，你其实是在运营一个科学项目，一场通过实验来寻找产品-市场契合度的探索。任何在这里工作过的人都可以证明，我们尝试了数十种东西，从非托管 Postgres（**千万别这么做**）到[全球 CDN](https://fly.io/blog/the-5-hour-content-delivery-network/)，再到[用户态 WireGuard](https://fly.io/blog/our-user-mode-wireguard-year/)。在公司架构更深处，我们构建了一个自下而上的工程组织，避开了产品路线图，招募了一个遍布十多个国家的全远程团队。 一些实验取得了回报，其他的则是“学习机会”。在过去的 8 年里，运营这些实验就是我的全部生活。但 Fly.io 不再需要这类科学项目了。 在过去的几个月里，一直追溯到 2025 年，我一直在与 Scott Johnston 讨论如果他来掌舵，Fly.io 会是什么样子。Scott 曾是 Docker 的 CEO，带领公司度过了一段极具挑战性的时期——始于 Docker 自身的企业与开发者身份危机，最终以他们业绩爆发告终。作为 Fly.io 的股东，对于 Fly.io 生命周期的这个阶段，我更喜欢他的剧本而不是我的。作为 Fly.io 的 CEO，我更希望看到他来完成所有这些工作，而不是我自己。我们花了很多时间来敲定这件事，最终董事会和我说服他接受了这份工作。 在这种文章里，这段本应是我告诉你为什么 Scott 非常适合 Fly.io，并回顾他所有过往成就的地方。他确实非常适合，成就也确实辉煌。但你已经知道我要说什么了，那就太无聊了，而且 Scott 想在自我介绍时他会做得很好的。他可不害羞。 与此同时，我会做所有聪明的、被榨干的创始人 CEO 会做的事：转为顾问角色，偶尔空降到产品设计讨论中（我工作中有趣的部分），同时利用我的董事会席位来骚扰 Scott，因为他执行了（对我来说）我工作中无趣的部分，而且比我做得更好。 我确信 Scott 会分析的其中一件事就是我们刚完成的这轮融资。这也是 Theo Browne 在他的视频中提到的另一件事（我没生气，我听起来像生气了吗？）——我们好几年没宣布过融资了。答案是我们融了一大笔钱，不需要更多。我们一直处于*永远*不需要更多的临界点——如果我们坚持原计划，如果 AI 没有导致大地裂开并把我们全部吞没的话。但显然，计划已经变了。 ### 变——化 听着，我知道这会引起什么反应。我本可以写一篇不惹怒任何人的文章，但那样做同时还能值得一读，我不知道该怎么做。 我们在对未来行业走向下一个非常具体且可能两极分化的赌注：几年内，智能体将决定几乎所有软件如何被构建和交付。软件将变得更加个人化，受众更小，也更具灵活性和流动性。 我对这一切感到兴奋。能在这样的变革时期从事这个领域，我有点受宠若惊。但我要是看不到这种转变让领域内其他专业人士多么不适，那我就太麻木了。 到今年年中，我们本可以走两条路之一： - 第一条路：继续把精力投入到我们一直在扩展和优化的东西上——一个由人类设计的、面向固定功能全栈应用的平台。 - 第二条路：聚焦并打磨一款适合智能体驱动的软件近期未来的产品。 初创公司中最危险的五个字是“为什么不能两者都要？”。我们只能选一个做。不能在两个方向上都蹒跚前行。如果失败，那就全力以赴地失败。不过，看来今后只有我的一部分会全力以赴了。 在 Fly.io 这个阶段，领导一个团队、一家公司、一个客户群，真是件棘手的事。我们几个月来一直在推迟关于优先级的重大决策。Theo，你察觉到了。好眼光！我本可以更快、更清晰地做出决定；相反，我推出了 Sprites。Sprites 回答了摆在我们面前的问题。我很高兴我花了时间构建它们，也很高兴我们招募了 Scott 来把它们变成我们的核心业务。