铁路：面向Agent的原生云 — Jake Cooper

大家好，欢迎收听 Late in Space 播客。我是 Alessio，Kernel Labs 的创始人，今天和我一起的是 Late in Space 的编辑 Swyx。

对，列车长。呜呜——呜呜——

嗯，我们大概会这么称呼一些人，不过我没有名片。我们还没发展到那个规模。总有一天会有的。之前有人递给我一张 Supermicro 的名片，挺精致的，我当时想，哇，这确实挺正式的。名片要回归了。对，挺酷的，挺时髦的。不过说到列车长这个称呼，我们管一些志愿者版主叫列车长，你懂的。所以这称呼还行。我们内部在琢磨怎么互相称呼，想法不一。有人觉得这太尴尬了，说内部根本不需要什么称呼。也有人觉得，对，我们就想这么叫。但到现在也没定下来。我们有叫"新铁路组"的，有叫"火车迷"的，但都没真正固定下来。

对。还有"铁路人"。

好。Railway 是部署任何东西最简单的方式。你只需打开画布，或者跟 Claude 聊一句，说"部署一个 Postgres 实例"、"部署我的 GitHub 仓库"、"运行这段代码"等等，然后就能直接跑起来了。

哦，谢谢。不过那可不是我做的。他们早就不让我碰任何设计相关的东西了。但我们想做的，不只是让部署变得极其简单，更是让你能随着时间的推移不断演进应用。我们认为，现在大多数工具都是层层堆叠，就像在熵上叠加熵，再叠加熵。比如 Docker、Kube、Ansible 脚本等等。如果我们能帮你把所有软件版本化，并跟踪所有变更，那么你就能轻松克隆环境、分叉到平行宇宙、获取生产数据的副本、获取任何服务的副本、做出变更、验证变更、再合并回去，而无需在预发布环境或其他地方重新复制一切。

这几乎是一种好奇心，想不断深入。一开始我做前端，比如 Wolfram 的 Web Mathematica 移植工作。然后短暂去了 Bloomberg，再到 Uber，接触分布式系统，把跳跳车的系统迁移到基于 Cadence 的分布式系统上。

对。我们还是讲 Railway 的故事吧。这其实是一个持续的过程：我想要某种体验——比如走到一辆自行车前，解锁它，然后毫无摩擦地骑走——然后就需要深入底层去实现它。我和团队做的很多工作，都是为了服务这种体验。我们根本不在乎要深入多少层，哪怕要潜到泳池底，也要把体验捞上来。我觉得这就是我整个职业轨迹的写照。我并没有物理学博士学位，只是读了电子工程与计算机科学。一直以来，我只是在琢磨下一步怎么走。正是这种思路，让我创办了 Railway 来追求那种体验，然后一路深入到裸金属数据中心。比如这周我还在给内核打补丁，就是为了让体验更好。因为我看到了它还能有多大的提升空间。

对，不过不是上游，是我们自己的 Railpack。

对，不，这是真正的内核补丁。但说到底，还是为了获得那种体验，然后想办法实现。任何事都是可以解决的，你只要去解决就行。

嗯，那你会把这个补丁提交到上游吗？还是因为它不适合？

可能吧。我们得先在内部把体验跑通。这跟我们正在为一些 Agent 相关功能构建的存储层有很大关系。所以也许对上游也有用，但对我们内部来说非常关键。

你之前提到了开源，所以我很好奇，你怎么看待从开源起步，然后编码 agent 让你能从它的分支做更多事情？

我觉得这挺有意思的，因为GitHub的原罪就在于它几乎像是一系列断裂的指针。你有一个东西，然后克隆下来，好了，我就失去了整个上游，对吧？怎么让人们能轻松地修改其中非常小的部分呢？你想想Git，它几乎是一种离散的概念：要么我做了改动并合并到上游，要么就没有，对吧？如果改成基于百分比的方式，或者更非确定性一些，会是什么样子？更像是一系列变更流，用户像遍历一样去处理，比如这个功能已经推广了多少百分比，并且一路推广上去，对吧？我们有开源回馈计划，允许你部署那些模板，因为我们几乎想让人们能轻松地随时间对这些碎片进行版本管理。这解决了一个非常大的问题，涉及身份验证、授权、安全性——比如npm有个功能，你可以定义“不要接受任何新包”之类的。理想的状态其实是，你应该逐步推送给那些影响范围最小的用户，然后不断向上推广，对吧？像摩根大通这样的机构，应该排在补丁队列的最后一位，为了我们所有人的利益，对吧？因为我们的钱、生活都依赖这些。如果像Johnny Vibe Coder这样的用户拿到一个有问题的补丁，那也没关系，因为系统里本来就有很多熵，你总得让橡胶碰到路面，必须在不同层次上测试，对吧？所以，这有点偏离我们最初的话题了，但你知道的。

或者每日注册人数，我觉得。

缓慢增长。

哦，是的。一开始基本上就是如何获得前100个用户，不管用什么方法，对吧？所以我们一开始有个网站，支持链接是Discord频道，你直接去那里，我开着通知，有两个显示器。一个显示器我在工作，另一个显示器如果有人进来，我就说“嘿，怎么样？”这种情况非常少见。所以就是努力让最初那100个用户真正回来使用。我觉得在2021年1月到2022年之间，大概中间那段，就是开始。然后你最终会建立一个咨询工厂，因为用户想要各种功能。所以你不得不回到画板前，思考：我到底想在这些基础上构建什么样的产品？有趣的是，VC们喜欢那种一直向上的图表，对吧？但现实中，你其实不想要那样的图表。大多数公司，至少对我们来说，有过扩张期，比如添加功能去测试用例；也有过收缩期，比如我们现有的体验已经很好，怎么让它更好？甚至可能去掉那些不符合我们理想客户画像的功能。怎么做到？在这张图表里，你可以看到很多这样的东西。2022到2023年的爆发是因为我们有了免费层，所有人都来用。

对。

Discord机器人。

而且我觉得有一件事很难教给别人：当你在互联网上构建一个开放产品，任何人都可以注册时，互联网是个可怕的地方，有太多东西——哦，如果我告诉你我的电脑情况。对，我们遇到了——你看到了也试了。然后还有加密货币矿工，各种东西，对吧？所以你经历这些阶段：如何触达尽可能多的人？然后如何精准匹配那些真正重要、真正对这个东西兴奋的用户？我们在内部反复权衡。然后大概有两年的时间，是让业务真正运转起来。免费层时代，每个月亏损大概50万美元。我们银行账户里有2000万美元，但月收入可能只有5万美元，这生意太糟糕了。我不知道为什么有人会投资。但无论如何，你必须经历这个过程：我们有用户喜爱的体验，但业务必须能运转，对吧？我觉得有两种思路。你可以一直把糟糕的生意做下去，保持低利润率；或者你可以回头去把它理顺。对我们来说，我们一直想要一个非常精简的团队，现在只有35个人，非常小。我们有大概300万用户？

对，对，至少。因为我们每周大概新增10万用户，对吧？所以增长确实很快。但我们一直希望保持一个非常精简的团队。我们不想为了增加人数而增加人数，不想单纯靠堆人来解决问题。我们想构建系统，对吧？在扩张阶段构建系统其实非常困难，因为你通常只是在往系统里不断添加东西，要么是因为用户有需求，要么是因为系统出了问题。所以我们基本上决定，先暂停一下。我们无法继续支持那些我们想要的免费用户。我们想触达尽可能多的人，因为我们相信，软件是一件非常重要的事情——在物理世界里创造东西已经变得非常困难，所以让人们能轻松地在虚拟世界里构建东西，让他们拥有创造的能力，这非常重要。所以我们想触达尽可能多的人。但这条路上有不同的阶段。所以我们不得不暂时关闭免费用户，重新调整业务，确保它整体上能运转。然后，我想你能看到这个构建过程。如果你仔细看2025到2026年之间的图表，会发现一些低谷，要么是夏天，要么是冬天。基本上就是这样，要么人们和家人去度假，要么就是去度假了。

对。

嗯。

对。因为这东西既有点B2C，也有点B2B。所以很多用户平时一直在部署东西，然后就会停下来。所以夏天的时候，我们的激活曲线会变成——现在我们看到很多人在工作日激活，因为我们的商业用户更多了，所以波动会小很多，随着时间的推移，曲线会变得更平滑。

我觉得我们一直把Agentic（智能体化）作为漏斗顶部的事情来优先处理。大概在过去6个月里，我们非常深入地把它作为构建和部署软件的一种机制来优先推进。因为我们从根本上相信，这条曲线非常陡峭，而这就是人们未来构建和部署软件的方式。而且，这基本上跟是不是“.com时代”无关，因为我们现在都已经在互联网上了。所以如果Agent会去部署大量东西，而我们在某个点遇到推理瓶颈，那到时候我们会去解决这些问题。但未来10年，主导物种会是这个——我们从汇编到C到C++到JavaScript，再到现在的语言。你需要能够闭环这个循环。但趋势就是这样。

不，不，不。我的意思是，在.com时代，很多公司因为互联网非常重要而快速崛起。然后你遇到了瓶颈，物理定律、数学不成立等等问题，所有人都回到了现实。但最终，这并不重要，因为互联网对我们的生活影响如此之大，只要你把时间线拉得足够长，你就应该去构建这些东西，因为你能看到它的方向。而这正是我深信Agent领域所处的阶段。我们稍后可以再聊，但你会达到一个点，同时运行成千上万个Agent。第一，推理成本是多少？计算成本是多少？如何让它高效？第二，如何协调所有这些？我们连协调人类都还有问题，甚至没有好的工具。而现在我们开始思考，如何让Agent之间协调？如何让它们安全地进行版本变更？如何让它们在需要时举手请求人工干预？否则，它就会变成一个疯狂的“中断工厂”。

好，好。

我认为原语（primitives）对我们来说非常重要，非常重要。我们需要能够处理网络、计算、存储以及围绕它们的编排。你需要对很多这些东西有控制权。我们聊过很多次，比如我们不怎么用Kube（Kubernetes），因为我们想要更高层次的控制，能够把工作负载放到非常具体的位置。原因就是我们之前聊过的，你必须对这些Agent非常高效，比如内存复用等等，否则你的成本结构会大幅膨胀。另外，能够自己搭建和堆叠服务器、构建自己的裸金属，能解锁一方面的性能，另一方面是成本，让你可以说，那些你想提供的、同时运行1000个Agent的体验，并不会成本高得离谱。因为如果你看现在的token使用量或计算用量，这些东西正在急剧膨胀。随着时间的推移，它们必须变得高效得多。通过构建自己的裸金属，你可以在资产负债表、利润率上获得很多“餐巾纸背面”的优化，让这些体验变得扎实。所以回到之前的观点，我们一直试图每次深入一点，来优化这个体验。这一切都是为了尽可能多的人提供差异化的体验。

对。现在其他每个区域都有两个。新加坡的话，我们会在第三季度增加第二个。

对，我们得去参观一个。

对，我可以搞定Equinix。Equinix。

Equinox。

你可以把数据中心放在蒸汽房里，让它变得又热又潮。但基本上，你只需要去说，嘿，我需要电力，需要一个机笼。然后他们会说，好的，这是费用。接着你租下机笼一段时间，然后得自己往里面放机架、服务器，再连上网络。实际上就是这么回事。

对，其他所有事情都自己处理。

我们自己算过，如果租用云服务，投资回收期大约是3个月。而如果自己买硬件，折旧周期大概是4年。所以，你会看到很多所谓的算力紧张，因为大型云服务商在大量采购设备。我们直接和OEM厂商、零售经销商，以及像Supermicro、戴尔这样的硬件制造商合作，来确保设备能正常运转。但上游供应链也有不少问题。有趣的是，我们上一轮融资时，在部署服务器资金的过程中，甚至到现在，我们筹到的钱其实比银行里的现金加上服务器价值还要少，因为服务器本身增值了——内存价格整体上涨了。所以硬件和这些东西的价值真的很疯狂。尤其是看看那些大型云服务商，他们今年部署了大约800亿美元的资本支出，明年还会更多。这是大规模的基础设施建设。你可以说，这比曼哈顿计划的花费还多。但反过来想，如果每个人都要并行运行几十、几百个agent，那你就应该在这些产品上投入更多。你根本无法想象需要多少算力才能实现那种体验，即使你效率极高、资源共享、一切操作都正确，这还不包括推理。

你们如何规划建设？增长曲线那么陡峭，你们是上线后利用率就达到100%，还是提前多久规划？

我们仍然保留云服务作为突发需求的补充。我们和AWS、GCP等云服务商合作，可以随时租用。一旦我们有了自己的空间或电力，就把云上的负载迁移过来。因为我们最初就是在云上起步，然后建立了一套系统迁移到自己的硬件上。这个过程可以不断重复，我们现在就是这么做的。我们不想陷入算力受限的境地。今年年初，我们确实遇到了算力瓶颈，因为上游供应商无法按我们需要的速度提供配额，硬件交付也慢了。所以我花了一个周末重建了整个网络覆盖层，以便能横跨5个不同的云服务商——Oracle、AWS、我们自己、GCP，还有另一个。现在我们可以做得更多。但当时我们不得不尽量紧凑地打包实例，因为拿不到足够的算力。这导致了一些可靠性问题，不过现在已经过去了。我发过一条推文，想指出这个问题，结果不小心把Supabase的人卷进来了。那条推文说的是，获取算力真的越来越难，而且会越来越难，我们就被这个问题坑了。从因果报应来看，我指出这一点也算公平合理。

考虑到你并不总是有自己的硬件可用，你们如何定价？如果最终不得不使用云服务，你们会给自己加价吗？

因为我们建了自己的硬件数据中心，硬件利润率很高，大约70%。所以如果我们想以合理速度扩张，可以大幅补贴云业务。从运营角度看，这很有趣，因为你有几个不同的杠杆可以调节：硬件带来利润，云突发可以补充，还可以用债务购买服务器。所以这是一个很有意思的运营问题：我们有这么多现金，应该融多少钱？多快能部署出去？只要我们能像扩张算力一样快速扩张收入，同时让用户轻松构建和部署，这个循环越快，运营越高效，业务增长就越接近线性。

天哪，确实如此。

对，就是以我们的硬件作为抵押。

我们支付的是基准利率加上一些点数，而且随着利率下降可以再融资。条款相当不错。不幸的是，Twitter上的人没有区分细节，他们一听说风险债务就觉得不好。但这不是风险债务，这是数据中心债务。我认为在特定领域有特定的工具，你不能只用一种工具当锤子，比如风险资本就是万能的锤子。你需要去探索，弄清楚怎么用。

对，对，对。我觉得顺便说一句，人们从融资角度对风投的理解完全是错的。

嗯，对。我觉得大多数人想的是，怎么从当时能拿到的最好投资人那里尽可能多地融到钱。我觉得这差不多接近正确。但我认为你应该做的，或者说至少我们尝试去做的，是搞清楚你能用这些股权买到什么样的几乎不公平的优势，因为那是你当时最便宜或者说最昂贵的股权——假设你的公司会越来越好。然后你如何利用这一点去和一位出色的人合作，他能补充你的能力，对吧？比如，A轮——

对，没错。比如，很好。我从来没创办过公司。融资，融钱。他给了很好的建议。我可以随时给他发消息。他回复很快，等等。太棒了，对吧？然后你继续往前走，和Unusual的John和Jordan合作，对吧？他们大概知道你在做产品方面有谱。他们基本不会干涉你，但随时可以提供建议。太棒了，非常好。到了A轮，业务完全是一团乱麻，对吧？因为我们根本不知道如何规模化一家公司，对吧？然后去找Erica合作。而且Jordan现在在Redpoint。所以额外的好处是，我们还能继续和他们合作，对吧？然后现在进入了，比如，从TQ和FPV融资，我们正在进入企业市场，对吧？每一步我们都朝着这个方向走：在这个特定时间点，我们能和谁合作？谁能帮我们解锁下一段旅程？因为猜怎么着？我就是不懂企业销售。我大概能瞄一眼，作为工程师觉得这些是我们大概需要的功能。我们内部也有一些很棒的人会帮忙。但你真正想合作的是那些在董事会层面能说"对，我们意见一致，这显然是我们想做的事"的人。这样我们就能把时间花在如何赢上，而不是争论策略，对吧？

这些挺好的。我是说，它们看起来都差不多，就像机架里的服务器。对，没错。这是我们的机箱。你想看更多机架吗？

对，我们内部有计划。

对。

所以会很有趣。我们今年有几个不同的推广活动和噱头。那些会很好玩。

在我们结束这部分之前，你发过一条关于太空数据中心的推文。

你为什么这么反感？好吧，不是说不建太空数据中心，因为实际上我觉得我的激进观点是，这是可以解决的。我只是没见过有人解决过，对吧？因为你需要——

对，对，嗯，因为，因为我没见过有人证明怎么在真空中散掉那么多热，对吧？这不代表不可能，只是没人——你说什么？

对，对，这说得通。但嗯，我不知道。我是说，总体上可能可行，对吧？但我认为很多人，而且顺便说一句，这大概是你必须做的事，就是他们有点本末倒置了。比如，"哦对，我们要在太空建数据中心。"然后说，"好，但怎么建？"然后说，"嗯，我们有一段时间来搞定它，对吧？"就像《火星救援》里，他们说，"哦，我们怎么拦截Astrofage？"然后说，"哦，好吧。"嗯，就像，"我们怎么做到？"然后说，"嗯，我们会想办法的。我们有那么长时间去搞定它，你知道吧？"

但百分之百，对吧？

对，我知道，对吧？

对。而且我也不知道风投是怎么做的，顺便说一句，因为你怎么知道什么基本上不可能、是骗局，什么可能但听起来完全疯狂，对吧？然后你说，"哦，酷，我们要在太空建数据中心。"这就像抛硬币，你根本不知道是哪种。我猜你大概十年后才会知道。

那是一个周期。

对。

嗯。

对。

智能体与人类的需求有何不同？我认为它们需要版本管理的能力。其实差别并不大，只是在具体实现方式上有些细微差异。智能体需要能够逐步进行变更测试，就像工程师使用功能开关一样。它们为什么不能直接使用功能开关呢？我觉得完全可以。它们需要版本控制，能否用 Git 或别的工具？我认为这个问题目前还没有定论，而且我确实觉得未来会出现 Git 之外的方案来管理这些内容的版本。它们需要可观测性，要能查询某个时间点发生了什么、哪些步骤失败了，以及追踪、日志、指标等。它们还需要网络、计算和存储，要能写入文件、保存文件、迭代文件、快照、文件系统等等。所以我认为我们过去需要的大部分东西，和智能体需要的其实非常一致。分支和分叉这些概念也没有本质区别，只是我们现在的速度比以前快了一千倍。有些东西看起来需要彻底革新，但实际上只是需要比现有方案好得多的版本。你需要编排能力，需要比 Kube 好得多的方案；需要网络，需要比 Envoy 好得多的方案。这样一路往下推，如果工作负载的形态没有太大变化，只是被极度压缩——因为你需要同时处理成千上万的任务——那么哪些假设会改变？比如持续部署（CD）会崩溃，你需要用别的东西来替代它。然后你可以一路往下推，说这部分要改、那部分要改。这种超指数曲线的有趣之处在于，你必须以这样的方式构建系统：随时可以替换掉某些部分，因为新的瓶颈可能会出现。比如你开始非常擅长并行智能体，那就会成为新的瓶颈，进而破坏系统的其他部分。所以我认为这和人类的需求很相似，只是规模要放大一千倍。那么问题来了：在智能体时代，代码审查怎么做？

对，但谁来审查 CVE 之类的问题呢？

没错，更多智能体。然后某个时刻我们就会撞上推理墙。你可以不断用更多智能体去解决那个问题，但我觉得能投入的智能体数量是有限度的。

不过你起步很早，在 CLI 还没流行之前就已经有了。

话说 CLI 什么时候不酷过？

嗯，但你暴露出来的形态有没有变化？

是的，CLI 会变，因为我们的思路是：如何给 Claude、Codex、ChatGPT 或其他模型提供一个“抓手”。CLI 本质上就是一个单一命令，比如执行部署、获取日志等等。对人类来说很烦人的事情，对智能体来说其实并不烦人，反而非常友好。如果我给你一个 CLI，说它有 40 个参数和 600 个标志，你会觉得太疯狂了，根本用不上。但给智能体的话，它会觉得太好了，有这么多抓手可以操作。所以我认为，如果你要通过这种机制为智能体暴露功能，就应该尽可能多地提供抓手，让它们能获取信息、查询额外的动态信息，然后尽快闭环。目前大多数问题其实就是如何尽快闭环。智能体卡在哪里？如何移除那个障碍？这也是遥测非常重要的原因。如果你能从 CLI 中知道智能体卡在哪里，然后说，嘿，有 12% 的人因为某个原因偏离了正常路径，我加一个参数就能降到 2%，那你就大幅提升了很多人闭环的速度。这就是我们思考 CLI 以及仪表盘上每个点的思路。这是一个用户旅程：从听说 Railway，到部署东西，拿到第一个绿色构建，看到端点、日志，然后开始迭代。迭代循环是无限且永久的。用户想部署新东西、新 Postgres 实例、改代码、不断迭代。所以如果你专注于这些迭代循环，找出阻碍闭环尽快完成的因素——我们内部常说，永远不要等待计算，而要等待智能。如果你在等计算，那就说明存在一个需要消除的瓶颈，因为那个瓶颈迟早会变得巨大，以至于其他工作流会涌现出来改变这一切。我们构建了一个非常棒的产品，你可以推送代码然后构建等等。但我从根本上相信，这种推送-拉取循环终将消失。你会达到一个状态：在生产环境中做一个小的变更，就能改变整个基础设施的版本。你与数据库的写时复制版本、所有基础设施一起工作，然后合并进去，瞬间就上线了。这就是循环的圣杯。而推送-拉取-重建这种摩擦点，我们正在从循环中彻底移除。

是的。

对。

没错。我觉得 canvas 挺有意思的，因为它本质上只是一个展示随时间变化的机制。但我完全同意你的看法，我们之前主要把它当作输入工具，而未来它的目标更像是一个输出工具。我的意思是，以前你会进入 canvas，做一些修改，看到各种变化，然后你的 agent（代理）或基础设施会随之演变。现在你有一堆 agent，它们能访问 CLI，通常可以直接进去做这些修改。所以 canvas 实际上不再是那种"哦，我怎么进去实现这个"的输入工具，而更像一个输出工具。它基本上就是告诉人类：当前需要哪些信息来做合适的决策，比如批准还是不批准某个控制请求？这才是 canvas 在那种情况下的真实作用。同时，它还需要成为你上下文的锚点，就像暴风雨中的港湾。你得把它想象成层级结构，几乎像一个文件系统，用来到达下一个位置。这就是为什么 canvas 一开始只是一个项目，然后你有一个向下钻取的图表，比如分解到这些服务或某个函数、代码之类的部分。因为你希望不仅能在大脑里，还能在这个 canvas 中呈现整个系统，这样其他人也能获得同样的呈现，从而与你同步思考，快速行动。我认为很多组织，尤其是扩张中的组织，会遇到麻烦，因为所有上下文都只存在于某个人的脑子里。然后就会问："这个微服务怎么工作的？"回答是："我不知道，去问那个人吧。"于是就有了整类产品围绕如何发现上下文而构建。而如果你能有一个非常扎实的层级结构，可以无限嵌套服务、代码、上下文，一直往下嵌套，那么很多这类问题就能被消解。这正是让你能够逐步构建这类结构的关键。我也写过一些关于构建"超结构"（hyperstructures）的东西，比如那些规模大得多的系统。你看金门大桥时会想："我们当年是怎么建成的？"网上有个梗说："我们失去了技术，不知道怎么建了。"某种程度上确实如此，因为当年建造那些东西所需的协调方式已经演变和改变了。随着我们把所有东西都塞进 Slack，我们几乎丢失了建造那种结构的一些技艺。

对，对，道理是一样的。其实无所谓，反正就是消息传递和中断，消息传递和中断，消息传递和中断，对吧？

比 Slack 更好？

当然。我觉得 Slack 很糟糕，顺便说，Discord 也很糟糕。

我们在内部建了一个叫 Central Station 的工具，用来聚合所有用户的上下文。每一条反馈、每一次客户支持、每一件类似的事情，都会被聚合到我们所谓的"集群"（clusters）中。如果有事件正在酝酿或其他情况，我们可以进去判断有多少用户受影响等等。然后我们可以基于此发起一个讨论。我认为这比那些长期运行的频道更有帮助、更准确，因为你不用纠结"该把这条消息放到哪个频道"。如果能动态聚合信息并根据上下文动态路由给正确的人，比如我们知道内部有 4 个人对网络很熟悉，那么看到网络相关问题时，就可以大致定位到那 4 个人。如果问题具体到某个部分，你还可以直接去看提交记录。这不再是内部的手动流程。这就是我们建这个工具的全部原因——如果你去 Station 或 help.railway.com，就能明白。我们想弄清楚如何用巨大的杠杆来规模化地聚合所有这些反馈。

对。

对，对，对。现在我们规模大了 10 倍。

你甚至不需要设定时任务。我们把它暴露成一个可发布订阅（pubsub）的东西。去 railway.com/stats 就行。

那是你的仪表盘，所有这些都是实时指标。也有办法以 JSON 格式获取这些数据，如果你在意的话。

我们会查一下。

对。我们很注重公开构建一切，谈论我们正在做的很多事情。过去我们有过一些问题，我们会说："嘿，我们正在这样修复。"我们的事故报告既收到过表扬也挨过批评，但我们一直在努力改进，就是为了和人们沟通。

对，内部给这个命名的时候，大家都觉得这玩意儿真够呛。你知道，这跟一个上游供应商有关，他们没有按照文档里说的行为来操作，这挺不幸的，毕竟他们自己还写了关于行为应该如何的RFC。但我们还是把这些东西部署出去了，然后Central Station一开始就发现了问题，有几个用户反馈说缓存没有正确失效。所以我们立刻关掉了。但当你把东西推给300万用户这样的大规模用户群时，各种不同的行为问题就会冒出来。尽管我们在测试环境里测试过，也写了测试用例，但不幸的是，我们还是碰到了一个边界情况。后来我们顺便加固了很多系统，现在能把这些做得更好了。但说实话，这确实是个棘手的麻烦。

对。

对，我觉得有负责任的披露机制。我们倾向于宁可过度披露，让你知道出了问题，也不愿让你的供应商对你隐瞒。所以我们更倾向于公开分享这些信息，即使它们只影响一小部分用户。这是我们内部做出的决定。我们有四个价值观，其中之一是诚信。那么，做诚信的事是什么？就是尽可能广泛地通知可能受到影响的人，或者告知他们有问题存在。然后我们直面问题，问自己为什么会发生，未来如何改进，诸如此类。

不是，这是因为我们采用了增量部署和渐进式部署。

完全应该。很多公司也确实是这样做的。比如Meta一般运行着1万个不同版本。回到我们之前说的agent，它们也需要同样的东西。它们需要能模拟流量，需要构建所有这些——我觉得我们在生产环境神圣不可侵犯这件事上搞了太多仪式感，我们需要达到一个状态，让测试不同行为变得非常简单，在一个安全的环境里，这样你就能在安全的环境里犯错。

你提到有人提出来了。你觉得有没有可能让这些事情自动被发现？不一定非得是你的agent，而是客户的agent，你懂我的意思吗？比如缓存验证这种问题，如果你知道要检查，似乎很容易就能发现。

这很难，因为要确定问题，我们几乎需要接入你的可观测性基础设施。这就是为什么我们在平台上几乎要做一个模板循环，以便能渐进式地部署这些东西。比如，我可以先推给Johnny Vibe Coder，或者推一个分片，让你按自己的节奏去消费，然后说，好的，我要更新到这个特定版本。或者花几周时间逐步推送，先推给0.1%的人，再推给1%的人，早期用户，然后一路推下去。这就是我们之前讨论的那种非确定性版本控制。所以，百分之百是这样。我相信大多数事情都应该朝这个方向发展，因为最终大多数公司都会在内部构建这种阶段部署系统。每个公司都在重复造轮子，所以这里有一个巨大的机会来整合开发者的技术栈。

你应该提供一个免费层，比如模型提供商给你免费token，如果你让他们使用数据的话。我们会给你免费算力，如果你是最先推出的分片，并且让我们接入你的可观测性。

对。顺便说一句，我们确实这么做了。这就是为什么我们之前提到，影响到了3000人左右。我们从影响较小的人开始，比如平台上的大公司，他们应该是最后收到这些部署的，这样他们就能拥有一个深度稳定的平台版本。

我有三个服务，所以我肯定是最先被部署的。你随时可以炸掉我的东西。我还有一个问题，现在有很多SRE agent公司，可观测性领域的人也想要有agent来修复你的上游问题。你们有自己的agent，在Canvas里可以聊天。你怎么看待这种局面？

这基本上就是堆叠熵的问题，对吧？我认为如果你没有让迭代在生产环境中安全进行的基本构件，事情就会变得非常非常困难。所以，如果你是一个可观测性提供商，你说“哦，这是针对这个错误的修复”，假设其中80%可能确实没问题，它们会合理、有意义等等。但剩下的20%是那种复杂的长尾问题，最终要推出这些变更时，如果你只是让人说“哦，这个看起来不错”，然后直接盖章通过，就有可能出现问题或事故。我认为这就是为什么拥有那种分叉环境非常重要，人们也有预发布环境等等。但它总是会偏离生产环境，对吧？所以你需要那些基本构件、工作流程和体验，就像我们脑海中内置的、作为平台第一方功能的东西，这样你可以在任何时间点、对任何服务进行分叉。这样你几乎可以——我觉得可以把画布想象成一张透明纸，而代理就像一个小家伙，你把它推上去，它应该能弹出在画布上，然后说“哦，好的，我需要复制那个服务，这样我才能测试这两件事”，这就是我作为代理的假设。然后它进去做这些操作，看起来一切正常。理想情况下，我得到一个生产环境的只读副本，任何PII（个人身份信息）之类的东西在我们自动克隆数据库、或使用写时复制版本、或从中读取时，都会被标记为需要转换，然后它做出那些变更，并验证是否真的有效？尽可能接近生产环境。因为最终你必须接近到那个程度，否则就会出现大量偏差，比如“我改了这东西”，然后系统就失控了，变得非常不稳定。我认为这就是很多公司在本地用Docker、生产用Kube、其他东西用特定方案构建的大型系统所面临的问题。所有这些复杂性最终会拖慢开发者的速度。是的，但它会达到一个规模上非常不稳定的点，让人们难以迭代和做出变更。所以我们想大幅压缩这些东西，直接说“尽可能接近生产环境”，那就是我们想要的状态。

哦，是的。嗯，我其实——

是的，我转变了。但我实际上仍然不相信AI SRE，因为我认为你需要那些基本构件来确保安全。如果你只是把一个AI SRE放到你的生产基础设施上，而没有像复制卷、确保一切正常这样的安全基本构件，它就会炸掉你的生产数据库。这不是会不会的问题，而是什么时候会炸掉的问题。我坚信要让这类循环整体上安全。我觉得自己直到2023年都算是个深度AI怀疑者，然后2024年我开始觉得“好吧，也许我能让这东西大致做到”。2025年，我觉得“好了，现在我能掌控它了”。然后整个圣诞假期，大家都回来之后，突然发现“天哪，几乎不可能掌控它了”。

对。

打开Claude。

但它已经到了一个点，几乎很难用错它，而不是用对它。你知道，就像《复仇者联盟》里那个场景，幻视说“它平衡得惊人”，当他拿起雷神之锤时，你会觉得“该死，这东西就像自我平衡一样，从那个角度看运行得很好”。所以，是的，我现在深信它将成为主导物种。就像汇编、C、C++、JavaScript、文字一样，对吧？

对，感觉是个大跳跃，也确实如此。而且我认为，你并不是要放弃基于CPU的离散逻辑，直接转向模糊逻辑。你需要两者兼备。所以你的技能应该调用代码或应用程序，或者某种静态结构。你可以用这些技能来提炼出几乎像流程一样的东西，或者代码应该如何运作。我逐渐形成这个论点，即你基本上需要三个要素：一个清晰的系统定义规范、代码，以及测试。当你把这个论点说出来时，任何做过一段时间工程的人都会说“废话，当然是这样”。这就像RFC（请求评议）、测试和代码。但它们都很重要，而且必须真正结合在一起，以便相互强化。比如“规范和测试匹配，但代码不匹配，让我去协调一下”，然后“好了，现在测试和规范匹配了，让我去协调另一件事”。你可以这样循环推进，基本上就是说“这是模糊的，而这两个要么是离散的（测试），要么是稍微模糊、稍微离散的（代码）”。这就是你的迭代循环。我认为这也是为什么很多人突然说“软件工厂”、“我想写这个文档”、“如何协调所有这些其他东西”的原因，但如果你不去实际实施，这有点像架构天文学。不过我确实认为，大多数事情最终都会走向这种循环。

哦，好的。

不错。

是啊，这太疯狂了。我们有一个循环，我大概搭起来了：你把 Railway CLI 放在一个运行在 Railway 之上的东西上，对吧？基本上，你以当前环境的身份完成认证，然后可以对它做任何修改。接着你只需调用 Railway deploy，它就会自我部署，对吧？就像，哦，我需要启动这个环境的一个实例。我已经在这个环境里了。太好了，我现在能访问一个 Postgres 实例了，对吧？这就是我们想在很多 agent 式、近乎自我复制的基础设施上实现的方向——这就是你的循环，你在生产环境中迭代，这就是你的循环，对吧？你会不断做一些改动，要么成功，然后你合并进去，说，不错，很好，把它推送到上游；要么失败，你就直接丢弃它，等等。对吧？你怎么才能让这些可丢弃的副本启动起来尽可能简单、运行成本极低呢？我觉得那种“我有一个 AWS 实例，我要搞 4 个 vCPU 和 16 GB 内存”的时代快要被彻底摧毁了，对吧？因为如果你为 agent 或其他东西这样做，你现在需要 1000 台那样的机器，对吧？成本高得离谱，相比之下，我们花了很多时间研究如何去做这些部署，随便你怎么叫它。Cloudflare 有 isolates，大家都叫 sandbox，不管那个部署的原子单元叫什么，只用付你实际使用的资源。瞬间启动，尽快闭环，对吧？因为如果系统可以自我复制，并且能安全地做到这一点，说，这是我的环境，我在做这些改动，等等，它就能回来说，嘿，这样看起来对吗？这是根据这个 prompt 得出的基础设施新状态。我觉得我已经解决了这个问题，对吧？然后你可以回到 agent 那里说，实际上，看起来有点不一样。它再跑一次循环。然后你说，不错，很好。

没有，我是说，每天都在变好，我在 X 或 Twitter 或随便你怎么叫的平台上。你可以随时骂我体验不够好，因为有很多东西应该做得更好。

没有，我觉得就像你提到的，它介于两者之间，对吧？就是能够运行有状态、长时间运行的东西，你想叫它 workflow、execution 或别的什么都行。对。

对。

App Runner。

我忘了那一堆名字了。嗯，对。我觉得这大概就是所有东西的方向——这也是我们过去 6 年一直在做这个的原因——我们就是相信，你需要访问一台计算机，你想要一个能跑 Linux 的盒子，对吧？这样你就能部署你想部署的东西。其他东西会改变你能构建的“表面积”。对我们来说，我们一直认为，不，用户需要一台计算机，他们需要能够部署任何他们真正想要的东西。对。这就是为什么我们花了很长时间专注于那些原语，比如网络、计算和存储。对。因为如果我们能给你这些东西，并让你能无限期地运行它们，对，这就是我们相信的大方向。所以我认为你现在看到的是，整个 Twitter 上要么没 nuance，要么大家都在说服务器，对吧？是服务器。其实不是，它总是介于两者之间，你知道，总是某种融合：我想长时间运行，但我不想静态地预配资源，或者为我不用的东西付费。这从一开始就是我们的论点：只为你用的东西付费，无限期运行。它基本上就是完整的 Linux。

对，没错。

对。

是啊，就是有太多人跟你说，你在这上面跑东西，你们这家公司，太疯狂了，随便一个你知道的名字都在跑这个，然后你来找我们。对，我们想把很多东西迁移走之类的。我说，哦，好吧，酷。但确实挺疯狂的。

顺便说一句，这对智能体旅程的下一阶段也非常重要。比如你希望一个智能体执行某个特定任务，然后你希望它要么完成要么未完成，接着再进入下一个任务，对吧？你需要一种方式来进入并管理这些工作流，而且需要能够动态地管理它们。对我来说，Temporal 在理论上一直非常非常棒。当你让它按你想要的方式在生产环境中运行时，它也确实非常非常出色。只是它要求你在脑海中把整个旅程建模出来。如果你没有完整的旅程图，就可能把自己置于一个困境中，比如重放整个工作流的状态会导致非确定性问题。

没错，就是这样。嗯，所以这非常容易。我大概会这样描述：它就像一台喷气发动机，对吧？如果你知道如何操作它，知道如何运行它，以及所有那些东西，那没问题。但你不能把它交给那些试图构建复杂东西、但脑子里没有完整状态的人，对吧？所以如果你有一个大型工作流——比如我们在它上面运行整个部署管道——那就是一个相当复杂的工作流，对吧？有预提交钩子、信号、队列，还有各种其他东西。我们在 Uber 也遇到了同样的问题：当你试图表达这个大型工作流时，就像你提到的，一路往下走，它变得越来越复杂，状态机里的状态也越来越多，你不得不把状态机映射回工作流。

对，没错。

对。所以在 Uber 我们建了一个系统来处理状态机、测试状态机以及其他所有东西。我们在这里也开始构建一些类似的东西，因为它已经发展得非常庞大了，对吧。但这就像是一种……我不想说爱恨交织的关系，因为那太宽泛了。就是当它运行得非常好的时候，它真的超级棒。但然后你会遇到这样的情况：某个没有接触过系统、或者没有完整上下文的人，往系统里放了一些东西，导致某些状态失效、引发非确定性问题，或者产生大量活动之类的。然后你就得跟踪几乎底层的 SRE 旋钮，比如“哦，我们在这个东西里的活动槽数量是多少”，对吧？但实际上这些应该随着内存、vCPU 等资源自动扩展，对吧？所以最终它变得有点难以扩展。

对，对。

我想我们会构建自己的工作流引擎。我们内部已经有几个了，我们一直在开发。

我觉得你仍然不应该用 vibe coding 来做。你还是需要运行 Jepsen 测试之类的东西。

不是。

对，是的，这非常可行。所以我觉得工作流相关的东西非常有趣。有几家很酷的公司，比如 ReState 在这方面做了一些不错的东西。

我们内部有 JavaScript，或者说 TypeScript，还有 Rust 和 Go。就这三种语言，对吧？对，我们不再加别的了。其实也不对，我们还有一点 C，因为我们写 BPF 代码和它的钩子之类的东西。所以，嗯，但这些是主要的。这是给 sidecar 容器用的吗？不是。这是给网络栈以及卷和类似东西用的。嗯，对。但我们大量使用 TypeScript，因为它驱动了仪表盘，不过我们打算把很多工作流相关的东西从仪表盘栈迁移到基础设施栈。我们最近刚这么做。

对。

嗯，对。我们构建了一个引擎，可以根据你的源代码确定依赖关系，这非常酷。它叫 Railpack。我们构建了第一个版本叫 Nixpacks，基于 Nix。然后我们迁移了。

对。

我不知道。我们当时对它非常兴奋，但它有很多不同的痛点。因为如果你想想，它就是一个特定时间点上的版本源代码栈，或者说版本二进制栈。所以如果你想要版本 X 和版本 Y，最终会膨胀很多包空间，对吧？这会让镜像体积变大，变得非常困难。

理论上是的。嗯，但最终会发生的是，如果你有足够大的用户群和足够分散的机器，你就会遇到 Meta 发布的一篇论文里提到的问题，XFAAS，那是他们内部的某种无服务器系统。它会变得非常难以大规模处理，除非你拆分成特定的运行时，基本上是这样。嗯，我们不想那么做，对吧？因为我们希望真正允许你部署任何东西，这是我们最初用 Nix 时的想法。但我们后来转向了一些有趣的东西，我想我们稍后可以聊聊，我们构建了用于内容寻址文件系统的东西，以便能够从任何点懒加载任何内容，然后分页到内存中。

对，会很有趣。整个未来非常光明。太疯狂了，会非常劲爆。

对。还有你的云服务使用情况，你在推上说这个月要花30万美元。

嗯，我觉得我们大概——

这到底是怎么回事？

我觉得我们花了20万。

你们只有35个人，肯定不是每个人都月花1万美元。分布情况是怎样的？

我大概有25个普通用户，然后还有一些重度用户，往下递减。我不知道。我们过完寒假回来，我基本上就是说，如果你还在手写代码，那你就是在做错事，对吧？现在的工具已经足够好了，你可以非常非常快地推进。是的，确实有各种问题和痛点，但你应该去审查你写的代码，而不是自己动手写。所有的架构模式、那些东西，你又不是要直接扔掉。实际上，它们现在比以往任何时候都更重要，但你就不该花时间去生成那些你自己会写的代码。如果你知道怎么写，就让代理去写，然后调整到看起来像你自己写的一样。对。而且我觉得，人们误解了我推动大家用代理的倾向，以为是因为我们增长很快、现实中有一些波折。其实这两者不一定相关。但我觉得人们真的应该明白，这些工具已经足够好，能让你极其快速地构建比以前大得多的东西，对吧？就像我们之前说的，怎么在太空中冷却数据中心？其实我也不知道，对吧？但现在做软件，你可以直接想：我怎么从零构建块存储？怎么去做这些事？我有想法，因为我有经验，我读过所有这些论文。让我去把它们实现出来，建一个包含几千个测试的大型测试台，对吧？因为现在写测试是免费的，去验证这个系统能不能建起来。我觉得，如果你不用这些AI系统来加速你的路线图，去搞清楚怎么把现有系统过渡到未来，那你就在错过当前正在发生的大事，对吧？因为你可以随便搭个模板，在旁边免费验证它。

那要花到每月300万美元的路径是什么？是受限于创意和客户能接受的东西吗？

我觉得对大多数公司来说，目前其实是受限于部署。这也是为什么我们看到大量用户——不只是用户，还有公司，比如财富50强之类的——都在问：怎么让我们的开发者更快地推进？我觉得你很可能先碰到CFO的阻力，而不是这些技术限制，因为他们看到花在token上的钱会吓一跳。我记得好像是Uber的CTO说过，我们一年的token预算全花光了。所以推理成本必须降下来，但现阶段推理本身也是受限的。所以你会经历一个价格发现的过程，看什么样的成本对组织来说合理。最终你会得到一个类似F1车手的概念：如果你有一个人非常擅长这些事，那给他配一辆300万美元的车是合理的；但如果你不擅长，那就不值得。我们会挑出几个人，说：你开F1车，往这个方向走，看看行不行，先做个原型。所以我们做了几件事，大大加速了路线图——本来以为要几年才能发布的东西，现在可能几个月就能发了。因为我们验证了它可行，甚至不用增量构建，可以直接跳步骤，朝着我们的愿景前进。我觉得这就是我们现在的状态。

对，我觉得很多人意识到路线图不一定带来商业影响。所以他们会说，跑这些token太贵了。但如果你的路线图本来就是为了在建成后赚更多钱，那你就应该像对待销售一样，为它设定token定价。如果你知道花10亿美元销售能带来20亿美元收入，你就会花。

完全正确。我觉得最天真的衡量方式就是看最终投入生产的token比例。

对。

如果你能衡量出这个级别的impact，因为那些token进了生产，那很棒。但我觉得举证责任会越来越重。我们内部也能看到这一点，比如有越来越多的pull request还没合并。你就会想，怎么把它弄进生产？所以关键还是多快能构建和部署软件。这很令人兴奋，因为我们整个团队都在做这个。

你们部署软件。

我们构建和部署软件，对吧？是的。

还有什么在改变？我觉得——

AISRE，那些工具……AISRE是那种遥不可及的目标。要做一个AI SRE需要什么？

嗯，哪个工具？

哦，Central Station？Central Station。对，对。我们现在给模板维护者用，他们可以部署和维护模板，并获得反馈。我们会逐步开放这些东西。

对，对。我不想说我们在内部已经解决了，但它已经变得非常好用，我们现在能很快看到Bing的那些事故。

对。嗯，所以到某个时候，那些东西要么是别人去构建，要么是我们自己去构建，但我们一直只做为自己量身定制的东西。如果合理，并且有办法让它对用户有用、能变现，或者确保那个循环从成本中心变成利润中心，那我们当然愿意在某个时候去做。对吧。嗯，不过，没错，port 确实在消亡。

我们内部自己建了一个特性开关引擎，到某个时候我们会把它推出来。

嗯。

嗯。所以像那样，你知道，那会挺好的。对吧。

嗯，因为，因为我们得先做 beta 测试。我们其实非常、非常、非常在意这些东西的质量。有很多东西我们在内部用过，然后做到某个程度——但它没能完整走完整个流程，因为它失败了，对吧？它可能对一个服务管用，但对多个服务就不行了，对吧？所以我们得为多个服务重新构建这些东西才能让它工作，对吧？而且我们很清楚，如果我们发布这个东西，我们就得一遍又一遍地重做。有些事值得去做，但很多其实也差不多，它们只是帮我们规划路线图：好吧，为了让我们真正把它做得更简单一点，我们可以先做其中几件事，然后再达到那个体验，对吧？我们不想通过说"哦对，这个能用，但只对这个服务管用"来稀释体验，对吧？除非它是一个非常、非常核心的计划，比如，你知道，在接下来的几个月里，我们会推出一些东西，先是单个服务能用，然后多个服务能用，再然后跨环境多个服务都能用，对吧？但你必须非常、非常慎重地对待这些事。否则你最终会搞出一堆破碎、不连贯的体验，最终带来巨大的支持负担。因为人们会问：这个功能怎么用？那个东西怎么弄？对吧？嗯，所以这有点像之前说的：你扩大公司规模来获取那些功能，然后你几乎要压缩它，把那些东西打磨平滑。这样体验才会真的非常出色。就像我们之前在走廊里聊的，你说"哦天哪，这好多了"，而我心里想"唉，我们内部觉得这部分真的很烂"。嗯，你知道，我们得让它显著、显著地变好。

对。100%。

有 Flagger，还有另一个。

Facebook 有 Gatekeeper。对。它们真的很重要。

对。

对。

就是这样，而且它超级重要，对吧？因为如果你假设软件开发生命周期会100%改变，那它之所以改变，是因为我们试图比现在快1000倍、并发高1000倍地做事。对吧。所以这就是路由。对。所以在大规模下什么变得重要，你知道，在我甚至开始做 Railway 之前，我其实就构建过一个特性开关产品，还试着去卖给别人。好吧。因为我觉得，哦，这就像 LaunchDarkly 的简化版之类的，对吧？然后我遇到了这种情况：任何小到能采用你技术的公司，根本不在乎特性开关，对吧？而任何大到真正需要特性开关的公司，又需要那么大的规模，以至于你得把整个现有基础设施都建好。所以我最后放弃了。但这就是旧瓶装新酒，因为现在公司都想飞快地推进。但你不能就这么"YOLO"地把 vibe-coded 的东西直接扔进生产环境。你得说：嘿，这是我的影响范围，这是我的影响，这是我的什么什么。我想对这部分用户做影子测试，对吧？特性开关，对吧？你最终会需要那些大公司为了维护自身结构而不得不去构建的工具。一切都会被压缩1000倍，这样每个人都能做那些事，每个人都能非常快地构建那些结构。对吧。而这正是我们现在所处的阶段：你在压缩软件开发生命周期，然后我们又会把它扩展，加入更多新东西，你知道吧？

对。

对，对，没错。嗯，我其实，我其实觉得这也许是个激进观点，但我认为这其实会改变。我觉得，是的，你可以走向"宠物"模式，只要你——这会是跳跃式的——只要你有一个宠物的克隆机。对，对。如果你能在每一帧都做快照，那么就算那个东西被摧毁了也没关系，因为你还有它的快照，对吧？我们现在构建的所有东西，本质上都是为了阻挡任何变化或改动，就像密封的 DevOps 流水线一样。比如，好吧，你得写一个 Dockerfile，因为我只需要这些特定的实例，只取文件系统的这一部分，等等。对吧。如果你直接拥有整个文件系统呢？如果你直接做快照呢？如果你懒加载整个文件系统呢？对吧。那你就能完全绕过这个问题。你不需要那些仪式性的东西，比如 Dockerfile 或者 Ansible 脚本或者所有其他东西，你只需要在那个循环上迭代，然后做快照。就像：这个循环对吗？这个时间点这个对吗？好，行。现在我要把它合并到生产环境。就像合并文件系统一样。

为什么不呢？那会很有趣。

是啊，确实挺意外的。对我来说一直都很意外，因为这就是我们在做的事情。因为这些东西太明显了。

我不知道。对，就是这样。你会想，Meta 有那么多写 eBPF 代码的人，他们在用这些做点什么。但你需要那种东西来解决这些问题，对吧？就像之前说的，不管需要什么，不管要深入到什么程度去解决这些问题，哪怕一直下探到内核的 TCP/IP 协议栈，我们都会去搞清楚。是不是有什么地方需要我们去修改，才能让它符合我们对未来宇宙的心智模型？对，百分之百，我们会去做。我们会一直往下走。这超级有趣。真的特别有意思。我甚至得强迫自己从那些有趣的问题中抽身出来，才能确保公司能以可行的方式规模化。有太多不同又有趣的问题了，比如如何把客户的信息通过支持团队传递给内部构建产品的人？或者如何进行安全的迭代？如何把上下文从仪表盘传递给用户？如何一路下钻到基础设施层？如何管理编排？这就像一个真正的实时操作系统，而不是一个反馈控制系统，对吧？真的太有意思了。

没有，我只是——对，我总体上做了很多不同的事情，对吧？

对。

对。

好吧，我想问，这里面有具体的问题吗？对，问题是这到底是怎么回事？

嗯，我的意思是，尽量睡够8小时，你知道——

没有平衡。你只能去思考所有这些事情，并对它们都充满热情。无论是痴迷于从市场推广的角度人们如何看待你的产品，还是痴迷于如果我在内核层面做这个改动，就能让用户的 SSH 连接永不中断。因为那就是我想要的。我想要一个世界，在那里我可以去快照所有这些东西，而且看起来就像你在 VM 上迭代一样。我觉得你必须对栈的每一层都充满热情。这对我来说反而更容易。有些人只对旅程或公司的某一部分充满热情。而我认为，当你把这些问题切分得很清楚时，就能实现几乎完美的协同。所以，在电梯里我提到，你有一个技术型的人，还有一个客户型的人。如果你能把那些界限划分得非常清楚，并且非常明确你自己或你的公司要负责的领域，以及你将在哪里运作，那你就会过得很顺利。如果你不能把这些事情搞清楚——这就是为什么我说两个联合创始人是最糟糕的数字，因为没有人能打破平局。你会说，我不同意这个，我不同意那个。那你怎么解决呢？

对，没错，对吧？

听着，这很难。无论你怎么切分，都很难。找人帮忙很难，自己做也很难。大体上说，运营事情就是很难。但它也很有回报，很有趣。

我喜欢写很多东西。我经常因为我的 Twitter 惹麻烦。我觉得这里面有个模式。

你跟谁惹麻烦？

Twitter 上的人。

哦，好吧。

你知道，我之前聊过这个，我说，嘿，如果你周末还在工作，那你的规划基本就乱套了，对吧？我对此也反复思考过。因为我觉得现在这个时期其实比较特殊，多工作一些反而合理，对吧？因为目标在我心里很明确。所以如果你有清晰的愿景，知道自己要往哪走，那你就该更努力一点，把愿景落实，去执行那些事。但如果你只是觉得“我们大概该往这个方向走”，自己也不完全确定，想再理清思路，那我觉得你需要做的就是断开连接，认真对待你的周末。你需要写下来：你现在在哪，你想做什么，你想去哪，你想解决什么问题，然后好好思考这些事，对吧？所以，写作很重要，坐下来——我不太喜欢“冥想”这种词，但不管用什么方式，只要能让你进入思维清晰的状态，那在你踏上这种旅程时，说“我们现在在这，我们需要到那去”，或者“我们在这，我觉得大概需要到那个空间才能让事情运转”，这种状态就非常非常重要。然后，断开连接，和你爱的人待在一起，然后在工作日全力以赴——我一般周一到周五从日出干到日落，全情投入。然后周六断开连接，周日下午再回来工作，做我的周计划和其他事情。这对我来说效果很好。但另一个大胆的观点是：大多数建议都是拿来消化然后扔掉的。如果它有用，它会自己回来，对吧？如果它有用，你会随着时间通过经验或其他方式慢慢学会。但你说到了标准的YC建议之类的。我们这个社会把失败的成本搞得非常高，这让人们很难偏离常规路径，对吧？

你还有什么其他“软书”想聊聊吗？比如那些你没发推文惹麻烦、想提前透露给世界的东西？

没有，我觉得Agent相关的东西真的很疯狂。它将成为人们做几乎所有事情的主流方式，对吧？前提是我们当然能搞定所需的推理量。但在未来十年里，你会看到人们在思考方式上的根本转变，甚至包括如何把脑子里的逻辑写出来。

对。我觉得如果我们不成为GPU提供商，会有很多坏处。我认为，你几乎更多是由你不做的事来定义的，而不是你做的事，因为对一堆事情说“是”太容易了。我觉得这会非常有趣。Anthropic是一家很棒的公司，非常出色。他们正在进入各种不同的领域，比如他们现在在做的Figma那种东西。是的，作为记录。他们还有云业务。

是啊。所以现在事情发展得非常快。但没错，这就会是人们做事的方式。好了。

对，专注，专注。永远别说永远。我可以明确告诉你，我们现在不会做GPU，但未来某个时间点我们100%会做。这不是我在泄露路线图，因为我们没有计划去做GPU。这只是说，到了某个时候你需要算力，对吧？如果你完全垂直整合，想让人们非常轻松地迭代、构建和部署东西，你就需要接触到这个核心的基础逻辑。嗯，是的。

哦，到了某个时候我们100%会用自己的数据中心。

对。现在，我们裸金属数据中心里运行的东西，绝大部分都是我们自己的。

好了。

对。

嗯。

对。我之前不知道这个转变的程度这么大。是的，完全没想到。

然后我们增长得太快了，以至于我们不得不基本上退回去，缩减规模。

带我们回顾一下。

是啊。

抱歉，Google Cloud。

对，挺有意思的。在Datadog的仪表盘上，它到了100%，然后又掉回到90%多之类的。

对。

这确实很难，对吧？你知道，我们要解决很多不同的问题，来确保平台极其可靠。但当你决定从零开始构建一个云平台，而不是复制超大规模云厂商的做法时，你就必须在许多新领域开疆拓土。我们非常刻意地基于大量论文阅读，从零开始发明自己的基础设施，几乎相当于向自己承诺不会抄袭别人的作业。因为我们觉得，如果抄袭别人，我们就输了——最终只会变成他们的翻版。所以你必须有一个核心论点：为什么这个业务要在当下存在？对我们来说，关键在于，目前在任何超大规模云厂商上部署生产环境的激活成本都太高了。我们认为这应该是瞬间完成的，你的想法和最终能与朋友分享的现实之间不应该有任何摩擦。这就是我们在每一层栈上努力构建的方向。如果需要深入到能源层面，我们迟早也会去做。这对我们来说非常重要，因为我们要让人们能够使用这些工具，而目前这些工具不仅对普通公民开发者（现在流行"氛围编码"）有门槛，实际上有多层门槛：公民开发者、前端开发者、后端开发者、DevOps 人员——所有这些层级都需要消失，让人们能够像这样直接交付。

谢谢。感谢你邀请我。非常愉快。