Railway创始人：35 人团队如何服务300万用户丨Latent Space
Railway创始人：35 人团队如何服务300万用户丨Latent Space
Railway创始人：35 人团队如何服务300万用户丨Latent Space Railway创始人：35 人团队如何服务300万用户丨Latent Space Modified May 24 🔗 原文链接： https://mp.weixin.qq.com/s/DHjZ4IF ... 原创 Capihom Capihom 晚点再听LaterCast2026年5月23日 22:21 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "如果你还在手写代码，方法已经错了。" "架构模式现在比任何时候都重要。" "未来十年，Agent 会成为构建和部署软件的主导方式。" Railway 做的是开发者部署平台：你可以在画布里，或直接对 Claude 说，部署一个 Postgres、部署一个 GitHub 仓库、运行一段代码。听起来像 PaaS 的老故事，但 Jake 讲的重点已经变了：当 Agent 开始替人写代码、部署服务、并行改系统，云平台要处理的就不再只是“把服务跑起来”，还包括成本、隔离、回滚、权限、环境复制和人机协作。如果你负责工程效率、AI 产品或内部平台，这期对话比一次产品介绍更有参考价值，它讲的是下一代软件生产线会压到哪里。 手写代码正在变成低杠杆动作 节目开头，Jake 先把工程师的工作方式改写了一遍。他说，如果你已经知道代码该怎么写，就应该让 Agent 去生成，然后反复对齐到“像你写的一样”。人的时间不该耗在敲出那些自己已经会写的代码上。 工程师的价值会更多转向判断、审查、架构取舍和系统边界。 他强调，架构模式没有过时，反而因为生成速度变快而更重要。以前写错一段函数，影响范围有限；现在一个 Agent 可以顺手改依赖、改部署脚本、改数据库迁移，审查者必须看得见整条链路。 "如果你还在手写代码，方法已经错了。你应该审查写出来的代码，让它不断接近你会写出的样子。" 这对团队管理的影响很直接。以前一个任务要拆给几个人，现在可能先交给几个 Agent 跑出多个版本，再由人判断哪个方向能合进主线。写代码的人少了，能看懂系统的人反而更稀缺。产品经理和技术负责人也要学会看 AI 产物的风险：权限有没有越界，依赖有没有乱加，数据路径有没有被改坏。代码评审会从“看这一段写得好不好”，变成“看这个改动能不能进入现有系统”。 部署平台要能复制整个工作现场 Railway 对自己的定义很短：最容易把任何东西发布出去的方式。Jake 举的例子也很具体：你到画布里，或者对 Claude 说，部署 Postgres、部署 GitHub 仓库、运行一段代码，系统就应该把服务拉起来。 但 Railway 真正在做的，是让应用在不同环境之间被复制、验证、合并。 他说，今天很多工具把 Docker、Kubernetes、Ansible 一层层叠上去，熵也一层层增加。团队越想省心，越会把更多脚本、配置和人工约定压在一起，最后每次发布都像在拆一团打结的线。 "如果我们能替你版本化所有软件，记录每一次变化，就能让克隆环境、拿到生产数据副本、验证改动、再合回去变得很简单。" 这也是 Agent 需要的底座。一个 Agent 改代码，另一个 Agent 改数据库 schema，第三个 Agent 跑迁移脚本，如果每次都要人手工搭 staging，速度会立刻被打回原形。Railway 想把“复制一个可运行的平行宇宙”变成常规动作，工程团队就能在更小风险里试错。更重要的是，试错不再只停留在本地机器，而是带着真实服务、真实配置和近似生产的数据一起跑。发布前的验证，也就从“能编译”推进到“能在完整环境里活下来”。 35 人团队不靠堆人接增长 Railway 的增长曲线很陡，但 Jake 反复提到一件事：他们仍然只有 35 人。节目里主持人问到用户规模时，现场出现了一个很有意思的修正：他说“300 万”，旁边人补了一句“200 万”，但下一句是每周新增约 10 万用户。这个数字组合比“高速增长”更有信息量。 Railway 选择用系统吃掉复杂度，用产品和基础设施接住每个新问题。 当用户不断涌入，支持、计费、滥用治理、部署稳定性都会同时增加压力，单纯加客服和运维只能把成本一起抬上去。 "我们一直想保持一个很精干的团队。我们不想只是为了人数而加人，也不想把人丢到问题上。我们想建系统。" Railway 早期也踩过免费层的坑。Jake 说，2022 到 2023 年的增长里，免费用户带来了很多使用量，也带来了机器人、挖矿、支持压力和很差的商业账。那段时间他们每月亏掉大约 50 万美元，账户里有 2000 万美元，月收入大约 5 万美元。后来他们收缩免费层，重新把业务跑通，再继续扩张。再往前看，最早 100 个用户靠的是 Discord 支持链接：有人进来，Jake 就在另一块屏幕上马上回复。增长从手工接待开始，最后必须回到系统化。 Agent 会把云成本问题提前引爆 过去半年，Railway 把 Agentic 作为构建和部署软件的重要入口。Jake 的判断很硬：未来十年，软件开发会从汇编、C、C++、JavaScript，继续走到“用语言表达逻辑”。当一个团队同时跑几百、几千个 Agent，云平台要回答的问题会变得朴素又残酷：推理成本多少，计算成本多少，内存能不能复用，Agent 之间怎么协调，什么时候需要人介入。AI demo 里的一次成功部署很轻松，生产系统里的持续并发会把账单、队列、日志和权限全部推到台前。 "你会走到某个点，同时运行成千上万个 Agent。推理成本、计算成本、协调方式，都会变成问题。" 他还用了一个很生动的说法：如果 Agent 不知道什么时候举手找人，就会变成疯狂的 interrupt factory。很多公司现在只看见“AI 帮我多写代码”，还没看见“AI 同时改很多地方以后，谁来调度这些改动”。未来的云平台要像运行时系统，也要像项目管理系统，还要像权限系统。否则人会被通知、冲突、失败任务和安全审批淹没，AI 提速反而制造新的等待队列。 他们绕开 Kubernetes，是为了拿回控制权 Railway 在底层选择上很激进。Jake 说，他们需要同时控制网络、计算、存储和编排，所以没有按常规路线使用 Kubernetes。原因很清楚：Agent 工作负载需要被放到非常具体的位置，内存复用和执行效率会直接影响成本结构。 当软件生成速度提升一千倍，基础设施里的每个小浪费都会被放大。 一个人写代码时，几十秒冷启动还能忍；上千个 Agent 同时跑任务时，调度、缓存、网络跳转都会变成利润表里的数字。 "我们不用 Kubernetes，是因为我们想要更高阶的控制，能把工作负载放到非常具体的位置。" 这也解释了 Railway 为什么去做自有金属服务器。Jake 说，租用云资源相比自建硬件，回本周期大约只有 3 个月。节目里还提到他们在新加坡等区域有自己的数据中心，并且大部分流量已经跑在自有裸金属上。AI 公司如果长期吃高并发计算，只靠公有云账单，很容易把毛利交出去。硬件采购、电力、机柜、网络这些听起来笨重的东西，会重新变成产品体验的一部分。 版本控制要从代码扩展到环境 谈到开源和 Agent，Jake 把 GitHub 说成“一串断掉的指针”。一个项目被 clone 之后，上游关系就变弱了；一次改动要么合并，要么停在分叉里。Agent 大量修改软件以后，这套离散模型会变得笨重。Railway 想象的是另一种状态：改动像一条流，可以按百分比逐步滚动到用户身上，影响面最小的人先试，影响面最大的人最后试。对企业客户来说，软件更新不再只是 pull request 审核，还会变成持续的风险排序。 "理想状态是，把改动先推给影响范围最小的用户，然后一路向上滚动。JP Morgan 应该是补丁线上的最后一个。" 这就是为什么老工具会重新变重要。Feature flag、灰度、影子流量、blast radius，在大公司里早就存在；Agent 让小团队也需要这些能力。Jake 说，软件开发生命周期会被压缩一千倍，然后又长出更多环节。谁能把这些环节产品化，谁就能吃到下一代工程团队的预算。节目里还提到，大公司过去为了规模被迫建设的发布系统，会被更小的 AI 团队重新需要，因为他们也要在更高速度下控制影响范围。 Dockerfile 的仪式感会被快照削弱 节目后半段，Jake 抛出一个更底层的设想：如果你能在每一帧给系统做快照，就不用把生产环境当成一只脆弱的宠物。他甚至说，可以重新拥有“宠物”，前提是你有克隆机器。Dockerfile、Ansible 脚本、密封的 DevOps 流水线，很多时候是在限制变化；而 Agent 时代需要的是更轻的复制、更快的回滚、更细的状态管理。尤其当 Agent 直接在运行环境里尝试修复问题时，文件系统、服务状态和网络连接都需要被一起保存。 "如果你能把每一帧都快照下来，整个文件系统都可以懒加载，很多仪式就不再需要。" 这听起来像科幻，但 Railway 已经把问题推到内核、TCP/IP、存储层。Jake 说，只要体验需要，他们就会继续往下钻。对开发者而言，这条路径的意义很现实：未来部署一个 Agent 生成的改动，可能更像合并一个可验证的运行现场，而不只是合并几行代码。代码 diff 只能告诉你文本变了哪里，环境快照能告诉你服务、文件系统、状态和依赖一起变成了什么样。 AI 公司最后都会碰到算力边界 主持人最后问，既然 Cloudflare 都能变成 GPU provider，Railway 会不会也走过去。Jake 的回答很克制：现在不做 GPU，但未来大概率会做，因为完全垂直整合以后，总有一天需要 flops。他还提到 Anthropic 正在进入更多区域，比如 Figma 相关工作流，AI 公司边界移动得很快。 在 Agent 成为默认工作方式之后，谁掌握计算、存储、部署和体验闭环，谁的战略空间就会变大。 "现在我们不会做 GPU，但未来百分之百会做。因为到某个点，你会需要 flops。" 这期最值得带走的判断，是 AI 应用公司和基础设施公司的边界正在互相靠近。做应用的人会更关心成本曲线、状态复制和权限隔离；做基础设施的人会更关心 Agent 如何理解产品语义。Railway 的案例说明，一个 35 人团队想服务数百万用户，核心动作是把复杂度提前沉进系统。以后每个 AI 产品团队都要问自己：哪些问题靠 prompt 能解决，哪些问题必须靠运行时、数据层和部署层一起解决。 写在最后 如果你的团队已经开始用 Claude、Cursor 或 Codex 写代码，下一步别只看生成速度。更该检查环境能否复制、改动能否灰度、成本能否承受、出错时谁来接管。Agent 会把很多人从敲代码里放出来，也会逼团队补上过去偷懒省掉的工程系统。先把这些问题列清楚，再去追求更快的生成速度，团队会走得更稳，也更能承受下一轮增长期。 内容来源："Railway’s AI Transition: 35 People, 3M Users, $200K+ Spend, & Cloud for Agents—Jake Cooper, Railway"丨Latent Space（嘉宾：Jake Cooper） 原视频：https://www.youtube.com/watch?v=LzCUYNP5UTI No access c46f9c65dde541faaf5885166b1541cd 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣ https://mp.weixin.qq.com/s/DHjZ4IF ... 🔗 原文链接： https://mp.weixin.qq.com/s/DHjZ4IF ... https://mp.weixin.qq.com/s/DHjZ4IF ... 原创 Capihom Capihom 晚点再听LaterCast2026年5月23日 22:21 北京 我们每天为你更新硅谷最新的 AI 创业与科技播客总结，让你与前沿保持同频。 全文约 3900 字，如果你现在没有时间，试试转成播客稍后再听 "如果你还在手写代码，方法已经错了。" "架构模式现在比任何时候都重要。" "未来十年，Agent 会成为构建和部署软件的主导方式。" Railway 做的是开发者部署平台：你可以在画布里，或直接对 Claude 说，部署一个 Postgres、部署一个 GitHub 仓库、运行一段代码。听起来像 PaaS 的老故事，但 Jake 讲的重点已经变了：当 Agent 开始替人写代码、部署服务、并行改系统，云平台要处理的就不再只是“把服务跑起来”，还包括成本、隔离、回滚、权限、环境复制和人机协作。如果你负责工程效率、AI 产品或内部平台，这期对话比一次产品介绍更有参考价值，它讲的是下一代软件生产线会压到哪里。 手写代码正在变成低杠杆动作 节目开头，Jake 先把工程师的工作方式改写了一遍。他说，如果你已经知道代码该怎么写，就应该让 Agent 去生成，然后反复对齐到“像你写的一样”。人的时间不该耗在敲出那些自己已经会写的代码上。 工程师的价值会更多转向判断、审查、架构取舍和系统边界。 他强调，架构模式没有过时，反而因为生成速度变快而更重要。以前写错一段函数，影响范围有限；现在一个 Agent 可以顺手改依赖、改部署脚本、改数据库迁移，审查者必须看得见整条链路。 "如果你还在手写代码，方法已经错了。你应该审查写出来的代码，让它不断接近你会写出的样子。" 这对团队管理的影响很直接。以前一个任务要拆给几个人，现在可能先交给几个 Agent 跑出多个版本，再由人判断哪个方向能合进主线。写代码的人少了，能看懂系统的人反而更稀缺。产品经理和技术负责人也要学会看 AI 产物的风险：权限有没有越界，依赖有没有乱加，数据路径有没有被改坏。代码评审会从“看这一段写得好不好”，变成“看这个改动能不能进入现有系统”。 部署平台要能复制整个工作现场 Railway 对自己的定义很短：最容易把任何东西发布出去的方式。Jake 举的例子也很具体：你到画布里，或者对 Claude 说，部署 Postgres、部署 GitHub 仓库、运行一段代码，系统就应该把服务拉起来。 但 Railway 真正在做的，是让应用在不同环境之间被复制、验证、合并。 他说，今天很多工具把 Docker、Kubernetes、Ansible 一层层叠上去，熵也一层层增加。团队越想省心，越会把更多脚本、配置和人工约定压在一起，最后每次发布都像在拆一团打结的线。 "如果我们能替你版本化所有软件，记录每一次变化，就能让克隆环境、拿到生产数据副本、验证改动、再合回去变得很简单。" 这也是 Agent 需要的底座。一个 Agent 改代码，另一个 Agent 改数据库 schema，第三个 Agent 跑迁移脚本，如果每次都要人手工搭 staging，速度会立刻被打回原形。Railway 想把“复制一个可运行的平行宇宙”变成常规动作，工程团队就能在更小风险里试错。更重要的是，试错不再只停留在本地机器，而是带着真实服务、真实配置和近似生产的数据一起跑。发布前的验证，也就从“能编译”推进到“能在完整环境里活下来”。 35 人团队不靠堆人接增长 Railway 的增长曲线很陡，但 Jake 反复提到一件事：他们仍然只有 35 人。节目里主持人问到用户规模时，现场出现了一个很有意思的修正：他说“300 万”，旁边人补了一句“200 万”，但下一句是每周新增约 10 万用户。这个数字组合比“高速增长”更有信息量。 Railway 选择用系统吃掉复杂度，用产品和基础设施接住每个新问题。 当用户不断涌入，支持、计费、滥用治理、部署稳定性都会同时增加压力，单纯加客服和运维只能把成本一起抬上去。 "我们一直想保持一个很精干的团队。我们不想只是为了人数而加人，也不想把人丢到问题上。我们想建系统。" Railway 早期也踩过免费层的坑。Jake 说，2022 到 2023 年的增长里，免费用户带来了很多使用量，也带来了机器人、挖矿、支持压力和很差的商业账。那段时间他们每月亏掉大约 50 万美元，账户里有 2000 万美元，月收入大约 5 万美元。后来他们收缩免费层，重新把业务跑通，再继续扩张。再往前看，最早 100 个用户靠的是 Discord 支持链接：有人进来，Jake 就在另一块屏幕上马上回复。增长从手工接待开始，最后必须回到系统化。 Agent 会把云成本问题提前引爆 过去半年，Railway 把 Agentic 作为构建和部署软件的重要入口。Jake 的判断很硬：未来十年，软件开发会从汇编、C、C++、JavaScript，继续走到“用语言表达逻辑”。当一个团队同时跑几百、几千个 Agent，云平台要回答的问题会变得朴素又残酷：推理成本多少，计算成本多少，内存能不能复用，Agent 之间怎么协调，什么时候需要人介入。AI demo 里的一次成功部署很轻松，生产系统里的持续并发会把账单、队列、日志和权限全部推到台前。 "你会走到某个点，同时运行成千上万个 Agent。推理成本、计算成本、协调方式，都会变成问题。" 他还用了一个很生动的说法：如果 Agent 不知道什么时候举手找人，就会变成疯狂的 interrupt factory。很多公司现在只看见“AI 帮我多写代码”，还没看见“AI 同时改很多地方以后，谁来调度这些改动”。未来的云平台要像运行时系统，也要像项目管理系统，还要像权限系统。否则人会被通知、冲突、失败任务和安全审批淹没，AI 提速反而制造新的等待队列。 他们绕开 Kubernetes，是为了拿回控制权 Railway 在底层选择上很激进。Jake 说，他们需要同时控制网络、计算、存储和编排，所以没有按常规路线使用 Kubernetes。原因很清楚：Agent 工作负载需要被放到非常具体的位置，内存复用和执行效率会直接影响成本结构。 当软件生成速度提升一千倍，基础设施里的每个小浪费都会被放大。 一个人写代码时，几十秒冷启动还能忍；上千个 Agent 同时跑任务时，调度、缓存、网络跳转都会变成利润表里的数字。 "我们不用 Kubernetes，是因为我们想要更高阶的控制，能把工作负载放到非常具体的位置。" 这也解释了 Railway 为什么去做自有金属服务器。Jake 说，租用云资源相比自建硬件，回本周期大约只有 3 个月。节目里还提到他们在新加坡等区域有自己的数据中心，并且大部分流量已经跑在自有裸金属上。AI 公司如果长期吃高并发计算，只靠公有云账单，很容易把毛利交出去。硬件采购、电力、机柜、网络这些听起来笨重的东西，会重新变成产品体验的一部分。 版本控制要从代码扩展到环境 谈到开源和 Agent，Jake 把 GitHub 说成“一串断掉的指针”。一个项目被 clone 之后，上游关系就变弱了；一次改动要么合并，要么停在分叉里。Agent 大量修改软件以后，这套离散模型会变得笨重。Railway 想象的是另一种状态：改动像一条流，可以按百分比逐步滚动到用户身上，影响面最小的人先试，影响面最大的人最后试。对企业客户来说，软件更新不再只是 pull request 审核，还会变成持续的风险排序。 "理想状态是，把改动先推给影响范围最小的用户，然后一路向上滚动。JP Morgan 应该是补丁线上的最后一个。" 这就是为什么老工具会重新变重要。Feature flag、灰度、影子流量、blast radius，在大公司里早就存在；Agent 让小团队也需要这些能力。Jake 说，软件开发生命周期会被压缩一千倍，然后又长出更多环节。谁能把这些环节产品化，谁就能吃到下一代工程团队的预算。节目里还提到，大公司过去为了规模被迫建设的发布系统，会被更小的 AI 团队重新需要，因为他们也要在更高速度下控制影响范围。 Dockerfile 的仪式感会被快照削弱 节目后半段，Jake 抛出一个更底层的设想：如果你能在每一帧给系统做快照，就不用把生产环境当成一只脆弱的宠物。他甚至说，可以重新拥有“宠物”，前提是你有克隆机器。Dockerfile、Ansible 脚本、密封的 DevOps 流水线，很多时候是在限制变化；而 Agent 时代需要的是更轻的复制、更快的回滚、更细的状态管理。尤其当 Agent 直接在运行环境里尝试修复问题时，文件系统、服务状态和网络连接都需要被一起保存。 "如果你能把每一帧都快照下来，整个文件系统都可以懒加载，很多仪式就不再需要。" 这听起来像科幻，但 Railway 已经把问题推到内核、TCP/IP、存储层。Jake 说，只要体验需要，他们就会继续往下钻。对开发者而言，这条路径的意义很现实：未来部署一个 Agent 生成的改动，可能更像合并一个可验证的运行现场，而不只是合并几行代码。代码 diff 只能告诉你文本变了哪里，环境快照能告诉你服务、文件系统、状态和依赖一起变成了什么样。 AI 公司最后都会碰到算力边界 主持人最后问，既然 Cloudflare 都能变成 GPU provider，Railway 会不会也走过去。Jake 的回答很克制：现在不做 GPU，但未来大概率会做，因为完全垂直整合以后，总有一天需要 flops。他还提到 Anthropic 正在进入更多区域，比如 Figma 相关工作流，AI 公司边界移动得很快。 在 Agent 成为默认工作方式之后，谁掌握计算、存储、部署和体验闭环，谁的战略空间就会变大。 "现在我们不会做 GPU，但未来百分之百会做。因为到某个点，你会需要 flops。" 这期最值得带走的判断，是 AI 应用公司和基础设施公司的边界正在互相靠近。做应用的人会更关心成本曲线、状态复制和权限隔离；做基础设施的人会更关心 Agent 如何理解产品语义。Railway 的案例说明，一个 35 人团队想服务数百万用户，核心动作是把复杂度提前沉进系统。以后每个 AI 产品团队都要问自己：哪些问题靠 prompt 能解决，哪些问题必须靠运行时、数据层和部署层一起解决。 写在最后 如果你的团队已经开始用 Claude、Cursor 或 Codex 写代码，下一步别只看生成速度。更该检查环境能否复制、改动能否灰度、成本能否承受、出错时谁来接管。Agent 会把很多人从敲代码里放出来，也会逼团队补上过去偷懒省掉的工程系统。先把这些问题列清楚，再去追求更快的生成速度，团队会走得更稳，也更能承受下一轮增长期。 内容来源："Railway’s AI Transition: 35 People, 3M Users, $200K+ Spend, & Cloud for Agents—Jake Cooper, Railway"丨Latent Space（嘉宾：Jake Cooper） 原视频：https://www.youtube.com/watch?v=LzCUYNP5UTI No access c46f9c65dde541faaf5885166b1541cd 00:00 No access c46f9c65dde541faaf5885166b1541cd 00:00 如果你喜欢深度好文，试试用小程序将不方便立刻阅读的文章转成播客，用「听」的方式，稍后阅读，不再错过好文章⇣ ⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣