The Agent-Native Cloud: 3M Users, 100K Signups/Wk, Data Centers, & Death PRs — Jake Cooper, Railway

如果你还在手写代码，那你就做错了——AI 时代，开发者的核心工作不再是“生成代码”，而是“审查代码”，而基础设施公司必须为此重构整个技术栈。

这期内容适合所有正在用或准备用 AI 辅助编程的开发者、AI 产品经理、以及基础设施创业者。值得花时间看，因为它不是空谈 AI 趋势，而是从一个正在经历爆发式增长的 PaaS 公司创始人视角，讲清楚了“AI 代理时代”对基础设施的底层要求是什么。最值得注意的冲突在于：当所有人都在关注模型能力时，Railway 的创始人 Jay Cooper 却指出，真正的瓶颈在于“计算”和“编排”——你无法在 Kubernetes 上高效运行数千个并行代理，也无法在云上承受那个成本。他选择自建数据中心，把硬件折旧成本在 3 个月内赚回来，这种“反常识”的务实操作，比任何宏大叙事都更有说服力。

这期播客采访了 Railway 的创始人兼“列车长” Jay Cooper。Railway 是一个让开发者“一键部署任何东西”的 PaaS 平台，最近因为 AI 编程代理的爆发而用户量激增（每周新增 10 万用户）。对话从 Jay 的个人经历（从 Bloomberg 到 Uber，再到自建数据中心）切入，深入讨论了：AI 代理时代对基础设施的真正需求是什么、为什么自建硬件比云服务更划算、如何用“循环闭合”思维设计产品、以及为什么“手写代码”已经过时了。整期内容非常务实，没有空谈趋势，全是实操层面的判断。

1. 手写代码的时代结束了，你的工作是审查代码。 Jay 直言：“如果你还在手写代码，你就做错了。”现在的 AI 工具已经足够好，开发者应该把精力放在“审查和调整 AI 生成的代码”，而不是自己从头写。但这不意味着架构设计不重要——恰恰相反，架构模式比以往任何时候都更重要，只是你不需要花时间在“生成”上。

1. AI 代理对基础设施的需求，本质上是“人类需求的 1000 倍速压缩版”。 代理需要版本控制、可观测性、网络、计算、存储——和人类开发者一样，只是速度更快、规模更大。所以，不是需要全新的东西，而是需要“好得多”的东西：比 Kubernetes 更好的编排、比 Envoy 更好的网络、比 Git 更好的版本控制。

1. 自建数据中心的 ROI 远超云服务。 Jay 透露，他们自建硬件的投资回收期只有 3 个月（对比 4 年的折旧周期），而且硬件本身还在升值（因为内存涨价）。这意味着，如果你在云上运行数千个 AI 代理，成本结构会爆炸；而自建硬件能给你巨大的“利润缓冲”，让你可以补贴云上突发流量。

1. “永远不要等待计算，永远只等待智能。” 这是 Railway 内部的设计原则。如果用户或代理在等待计算资源，那就是一个必须被消灭的瓶颈。他们通过自建金属 + 多云突发（burst）的组合，确保计算永远不是瓶颈。

1. CLI 比可视化界面更重要——但只对 AI 代理而言。 人类开发者讨厌有 40 个参数和 600 个标志的 CLI，但 AI 代理喜欢它——因为每个参数都是一个“手柄”，让代理能更精确地控制行为。所以，为代理设计接口时，要尽可能多地暴露“手柄”，然后通过遥测数据找出代理卡住的地方，再添加新的手柄来优化“循环闭合率”。

1. Canvas（可视化界面）的未来是“输出”而非“输入”。 过去，用户通过拖拽画布来配置基础设施；未来，画布的作用是展示 AI 代理做了什么，以及让人类做“批准/拒绝”决策。它还是一个“上下文锚点”，让团队能在同一张图上理解整个系统的状态，避免知识只存在于某个人的脑子里。

1. 融资不是拿钱，而是买“不公平优势”。 Jay 认为，VC 的钱是最贵的钱，所以你应该用它来买“你当前阶段最需要的合作伙伴”——而不是单纯追求估值。从种子轮到 A 轮到 B 轮，他们每次都选择能帮他们解锁下一阶段能力的投资人（比如从产品到运营到企业销售）。

“你永远不应该等待计算，你只应该等待智能。”

这期内容对 AI 从业者（尤其是做 AI 产品、AI 基础设施或 AI 代理的人）有非常直接的启发：

1. “为代理设计接口”是一个被低估的产品方向。 大多数 AI 产品还在模仿人类 UI（聊天框、拖拽画布），但 Jay 指出，AI 代理真正需要的是“高维度的程序化接口”——参数多、标志多、可组合性强。如果你在做 AI 代理工具，不妨想想：你的 API 或 CLI 是否足够“丰富”，让代理能精确控制每一个步骤？还是你只给了它一个“黑盒”？

1. “循环闭合率”是衡量 AI 产品效率的关键指标。 Jay 反复提到“closing the loop”——代理从接收任务到完成任务的过程中，每一步卡住的地方就是瓶颈。通过遥测数据找出这些卡点，然后通过增加接口参数或优化流程来降低卡住率，这比堆模型能力更有效。这其实是一种“产品化”的思维：不是让模型更聪明，而是让系统更少出错。

1. 自建硬件不是“老古董”，而是 AI 时代的成本护城河。 很多 AI 创业公司只关注模型和算法，忽略了计算成本。Jay 的案例表明，如果你能控制硬件层，你的成本结构可以比竞争对手低一个数量级。对于做 AI 推理服务或代理编排的公司来说，这可能是决定生死的关键——尤其是在推理成本还在飙升的当下。

1. “版本控制”是 AI 代理时代最大的未解决问题之一。 Jay 提到 Git 的“原始罪”是它本质上是一堆“断开的指针”——你 fork 了，就失去了上游。在 AI 代理频繁修改代码、配置和基础设施的场景下，我们需要一种更“流式”的版本控制方式，能支持“百分比回滚”和“渐进式发布”。这对做开发者工具或 DevOps 的人来说，是一个明确的创业机会。