Railway：为AI Agent原生打造的云平台——300万用户、35人团队、自建数据中心的Agent基础设施革命

传统的DevOps信条是"把服务器当牲畜，不当宠物"——没有名字，随时可以杀掉替换。但Jake认为这个观念可能会改变：“只要你有宠物的克隆机，你就可以拥有宠物了。如果你能在每一帧快照所有东西，某个东西被摧毁也无所谓，因为你有一个快照。[1]这背后是Railway正在构建的内容可寻址文件系统——快照整个文件系统，懒加载，按需分页到内存。Agent不是锦上添花，而是基础设施的下一代用户——$200K的

温宇志

536人浏览 · 2026-05-23 08:55:26

温宇志 · 2026-05-23 08:55:26 发布

当AI编程Agent开始自己花钱租服务器部署应用，你需要一个什么样的云平台？Railway给出的答案是：Agent-Native Cloud。

一、一个让Agent自己花钱的平台

先说一个数字：$200,000。

这是Railway平台上AI编程Agent累计消费的金额——不是人类点击部署按钮花的钱，而是自主编程Agent自己调API、自己建服务、自己部署基础设施产生的费用。

在Latent Space最新一期播客中，Railway创始人Jake Cooper透露了更多令人震惊的数据[1]：

300万用户，每周新增10万注册
35人团队支撑全部运营
自建裸机数据中心，3个月回本（vs 租用云服务器）
70%利润率，用于激进云弹性扩容
融资总额1.24亿美元
服务器硬件因内存涨价而增值——硬件价值已超过融资金额

这不是一个普通的PaaS故事。Railway正在从底层重新定义：当Agent成为软件的主要"用户"时，云基础设施应该长什么样？

二、从"Heroku替代品"到"Agent原生云"

起源：让部署的激活能量趋近于零

Railway 2020年成立时，跟AI没有半毛钱关系。Jake Cooper（前Bloomberg、Uber工程师）的想法很简单：

把代码推上去，拿到URL，开始迭代。不需要Dockerfile，不需要K8s清单，不需要Ansible脚本。

这跟Heroku的初心一样，但Jake想要走得更远。

前18个月，Jake在Discord上亲手迎接每一个注册用户——双显示器，一个写代码，一个盯Discord通知。这种"笨功夫"换来了前100个种子用户[1]。

免费层陷阱：月亏50万美元

2022-2023年，Railway开放免费层后迎来爆发式增长——但也引来了Reddit机器人、Discord机器人和加密货币矿工。

“当你在互联网上做一个任何人都可以注册的开放产品时，互联网是一个可怕的地方。”——Jake Cooper

巅峰时期，Railway每月亏损50万美元，账上2000万美元，月收入仅5万。Jake形容这是"一个糟糕的生意，我不知道为什么有人投资"。

之后是两年的"重建业务"期：砍掉免费用户、打磨付费体验、建立可持续的商业模型。

Agent时代的到来

转折发生在2025年底。Jake发现一个趋势：越来越多的部署请求不是来自人类，而是来自AI编程Agent。

“过去6个月，我们深度优先考虑了Agent作为一种构建和部署软件的机制，因为我们相信这条曲线如此陡峭，Agent将成为人们构建和部署软件的主导方式。”——Jake Cooper[1]

他的判断是：从汇编→C→C++→JavaScript→自然语言，下一个10年的主导物种是Agent。即使当前存在"推理墙"或泡沫，长期趋势不可逆转——就像互联网泡沫后，互联网依然改变了世界。

三、为什么Agent需要不同的基础设施？

这是Railway最核心的洞察，也是它与传统云的区别所在。

人类 vs Agent的部署行为对比

维度	人类开发者	AI Agent
部署频率	几小时一次	每秒数十次
反馈需求	看看日志就行	毫秒级反馈循环
资源消费	按需、手动	程序化、批量、自动化
环境管理	staging/production	需要瞬间克隆生产环境
错误处理	人工排查	需要可观测性API+自动回滚
交互方式	GUI + CLI	CLI + API + MCP

用Jake的话说：

“AI Agent不会像人类开发者那样与基础设施交互。人类可能部署一个服务、监控几个小时、调整设置、然后离开。Agent会连续发射数十次部署，需要近乎即时的反馈循环，并以机器速度将基础设施视为可程序化消费的东西。”[2]

这意味着：

冷启动必须极快——Agent不会等几分钟让容器启动
延迟必须可预测——Agent的反馈循环对延迟敏感
定价模型要适合机器消费——按秒计费，不用不花钱
环境克隆必须瞬间完成——Agent需要频繁fork生产环境做测试
CLI和API优先——Agent不用GUI

四、自建裸机数据中心：3个月回本的经济学

Railway最激进的决定是自建数据中心（Railway Metal），而不是继续租用AWS/GCP。

为什么自建？

Jake算了一笔账：

“如果我们租用云服务器，我们转向裸机的回本期大约是3个月。这太疯狂了。那是4年折旧的硬件。”

更戏剧性的是硬件增值：

“当我们部署最后一轮融资的资本购买服务器后，从那时到现在，我们筹集的资金金额已经低于银行存款加服务器价值的总和，因为服务器随着内存价格上涨而增值了。”

数据中心怎么建的？

Railway选择的是Cage Colocation（笼子托管）模式[3]：

找场地：在Equinix等数据中心租一个笼子（四面墙+安全门+空地）
电力：最关键资源，按kW/月固定付费，双路冗余供电
网络：每个地区至少2家一级ISP，获取完整互联网路由表，优化每个IP前缀的最佳路径
服务器：与Supermicro、Dell等OEM直接合作，追求功率密度（单位功耗下的算力密度）
PDU：可远程控制和计量每个插座的智能配电单元

整个建设周期：5个月从启动到第一批服务器上线，再3个月才敢让用户使用。

五云弹性架构

自建不意味着完全脱离公有云。Railway实现了Metal + GCP + AWS + Oracle + 其他云的五云互联架构：

                    ┌─────────────┐
                    │   Edge      │
                    │   Proxies   │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
     ┌────────┴──┐  ┌─────┴─────┐  ┌───┴────────┐
     │ Railway   │  │   AWS     │  │    GCP     │
     │  Metal    │  │ (Burst)   │  │  (Burst)   │
     └───────────┘  └───────────┘  └────────────┘
         ↑ HA光纤互联 ↑

日常流量：走Railway Metal（成本最低、延迟最优）
突发流量：自动Cloud Burst到AWS/GCP（弹性扩容）
资源释放：Metal容量就绪后，自动压缩公有云工作负载

Jake甚至在一个周末重写了整个网络覆盖层，只为了能跨五个云调度工作负载——因为某个上游提供商无法按需给足配额。

5月19日GCP宕机事件：一次痛苦的教训

2026年5月19日，GCP错误地暂停了Railway的生产账户，导致全平台8小时宕机[4]。

关键教训：虽然Metal和AWS上的工作负载本身仍在运行，但边缘代理的路由表依赖GCP上的控制平面API刷新。当缓存过期后，所有区域的工作负载都变得不可达。

Railway的修复方案：

去除控制平面对GCP的硬依赖，实现真正的mesh网络
将HA数据库分片扩展到AWS和Metal
从数据面的热路径中移除GCP，仅作为二级/故障转移

这个事件恰恰证明了Jake的论点：你必须控制自己的基础设施。

五、Agent-First的工程设计

Railway为Agent做了哪些专门的工程优化？

1. CLI优先 + MCP集成

Railway为Agent提供了四种交互方式[5]：

# 一键安装Agent支持
bash <(curl -fsSL cli.new) --agents -y

# 或已有CLI的用户
railway setup agent

Railway CLI：适合依赖本地状态的操作（当前目录部署、SSH、本地链接）

Local MCP Server：通过CLI运行，适合Agent在已登录机器上的操作

Remote MCP：托管在 mcp.railway.com，浏览器OAuth，无需本地CLI

Agent Skills：教AI编程Agent如何操作Railway的技能包，支持Claude Code、Cursor、Codex等

各编辑器快速接入：

# Claude Code
claude mcp add railway --transport http https://mcp.railway.com

# Cursor（添加到 .cursor/mcp.json）
{
  "mcpServers": {
    "railway": {
      "url": "https://mcp.railway.com"
    }
  }
}

2. railway agent：终端里的AI运维

# 交互式对话
railway agent

# 一句话搞定
railway agent -p "add a Postgres database and set DATABASE_URL on the API service"

# 排查部署失败
railway agent -p "help me figure out why my backend service is crashing on deploy"

# 查看资源使用
railway agent -p "show me memory and CPU for my services"

# JSON输出，方便接入自动化
railway agent -p "list my services and their status" --json | jq '.toolCalls'

# 继续上次的对话
railway agent --thread-id <thread-id>

3. AI Agent异步Worker架构

Railway官方提供了Agent部署的推荐架构[6]：

┌─────────┐     ┌───────┐     ┌──────────┐
│  API    │────▶│ Redis │────▶│  Worker  │
│ Service │     │ Queue │     │ Service  │
└────┬────┘     └───────┘     └─────┬────┘
     │                              │
     │        ┌──────────┐         │
     └───────▶│ Postgres │◀────────┘
              │  (State) │
              └──────────┘

API Service：接收请求、入队任务、返回状态
Worker Service：出队任务、运行Agent循环（调用LLM→解析响应→执行工具→重复）
Postgres：存储对话状态、工具输出、任务状态
Redis：API与Worker之间的任务队列

部署步骤：

# 1. 创建项目+数据库
# 在Railway Dashboard: + New → Database → PostgreSQL
# + New → Database → Redis

# 2. 部署API服务
railway link
railway up

# 3. 设置环境变量
railway variables set DATABASE_URL=${{Postgres.DATABASE_URL}}
railway variables set REDIS_URL=${{Redis.REDIS_URL}}
railway variables set OPENAI_API_KEY=sk-...

# 4. 部署Worker服务（同一仓库，不同启动命令）
railway service new
railway variables set START_COMMAND="npm run worker"
railway up

Worker核心循环伪代码：

while True:
    task = redis.blpop("agent:queue")
    state = postgres.load(task.conversation_id)
    
    for step in range(MAX_STEPS):
        response = llm.chat(state.messages, tools=agent_tools)
        
        if response.has_tool_calls:
            results = execute_tools(response.tool_calls)
            state.append(role="tool", content=results)
        else:
            # Agent完成
            postgres.save(task.id, result=response.content)
            redis.ack(task)
            break
    
    postgres.update_status(task.id, step=step)

注意：Railway HTTP请求最长15分钟。超过此时间的Agent任务需要实现SSE客户端重连机制。

4. Feature Flag + 渐进式发布

Jake在Uber时期就深度体验了Feature Flag的文化。他认为Agent时代更需要这套工具：

“如果软件开发生命周期要改变，因为我们做事的速度快了1000倍、并发量多了1000倍，那么在规模化时什么变得重要？你不能把vibe coding的东西直接YOLO上生产。你需要说：这是我的爆炸半径、我的影响范围，我想对这些用户做影子流量。这就是Feature Flag。”[1]

5. 生产环境Fork：瞬间克隆

传统DevOps需要维护staging环境。Railway的想法是：直接克隆生产环境。

“如果我们能版本化你的所有软件并跟踪所有变更，那么克隆环境、fork到一个平行宇宙、获取生产数据副本、获取任何服务副本、做变更、验证、然后合并回来——这一切都可以变得轻而易举。”——Jake Cooper

底层技术是内容可寻址文件系统（Content-Addressable Filesystem），可以懒加载任意时间点的快照并分页到内存。不需要Dockerfile的仪式感，不需要Ansible脚本的复杂性。

6. Railpack：自动依赖检测引擎

Railpack是Railway自研的构建引擎，替代了基于Nix的第一版Nixpacks：

Nixpacks：基于Nix构建，理论上可以部署任何东西，但版本化的二进制文件会膨胀镜像
Railpack：基于源码自动检测依赖，配合内容可寻址文件系统，实现懒加载

Jake评价Nix：

“我们对Nix很兴奋，但它有痛点。把它想象成特定时间切片的版本化二进制文件堆栈。如果你需要版本X和版本Y，包空间就会膨胀，镜像爆炸，实际工作负载难以管理。”[1]

六、“PR正在消亡”：Agent时代的软件开发生命周期

Jake有一个大胆的论点：Pull Request正在走向消亡。

传统SDLC

写代码 → Git Commit → 开PR → 代码审查 → CI通过 → 合并 → 部署 → 监控

Agent时代的SDLC

描述需求 → Agent生成代码 → Feature Flag灰度 → 影子流量验证 → 渐进式全量 → 监控

关键区别：

代码审查的意义在变：当你能瞬间克隆整个生产环境做测试时，人工审查每行代码的效率远不如让Agent在fork的环境里自动验证
Feature Flag成为必需品：Agent生成代码的速度是人的1000倍，你需要精确控制爆炸半径
PR变成Prompt Request：描述你要什么，Agent帮你实现并安全发布

“最终进入生产环境的token占比——这是一个衡量ROI的朴素方法。如果你能量化影响，因为那些token最终进入了生产环境，那就太棒了。但举证责任会越来越高。”——Jake Cooper[1]

"牲畜还是宠物"的重新定义

传统的DevOps信条是"把服务器当牲畜，不当宠物"——没有名字，随时可以杀掉替换。但Jake认为这个观念可能会改变：

“只要你有宠物的克隆机，你就可以拥有宠物了。如果你能在每一帧快照所有东西，某个东西被摧毁也无所谓，因为你有一个快照。”[1]

这背后是Railway正在构建的内容可寻址文件系统——快照整个文件系统，懒加载，按需分页到内存。

七、Solo Founder的生存法则

Jake是罕见的成功Solo Founder。他的一些思考：

关于作息

“我尽量保证8小时睡眠。周一到周五从日出到日落全力以赴。周六完全断联。周日下午回来写作、规划下周。”

关于合伙创始人

“两个联合创始人是最差的数量，因为没有打破僵局的方法。你们意见不合，怎么解决？”

关于建议

“大多数建议应该被消化然后扔出窗外。如果真的有用，它会通过经验自己回来的。我们社会把失败变得太昂贵了，让人不敢偏离既定路径。”

关于写作

“写作很重要。我不喜欢’冥想’这个词，但任何能让你进入心智清明状态的东西——当你需要说’我们在这里，需要到那里’——都很重要。”

八、对中国开发者的启示

1. Agent-First的基础设施是蓝海

Railway证明了Agent不会用传统云的方式消费基础设施。国内无论是阿里云、腾讯云还是各种Serverless平台，目前都在为人类开发者设计。Agent需要的是：

毫秒级冷启动
程序化的环境克隆
API/CLI/MCP原生集成
按秒计费+按需弹性

这是一个全新的市场机会。

2. 自建数据中心的经济学

Railway用实践证明：在内存价格持续上涨的趋势下，自建裸机数据中心的3个月回本期远比租用云服务器划算。尤其是对AI推理场景，内存是刚性需求。

3. CLI + MCP是Agent集成的标准解法

Railway同时提供CLI、Local MCP、Remote MCP三种接入方式，覆盖了终端用户、编辑器集成和无本地环境三种场景。这个设计思路值得国内基础设施团队借鉴。

4. 35人团队支撑300万用户的秘密

不是堆人头，而是建系统。Jake反复强调：

“我们不想为了增加人手而增加人手，也不想用人力去堆问题。我们想建系统。”

这意味着Agent时代的团队效率可以指数级提升——前提是你愿意在系统建设上投入。

九、实战：5分钟在Railway上部署一个AI Agent

# 1. 安装CLI并配置Agent支持
bash <(curl -fsSL cli.new) --agents -y

# 2. 登录
railway login

# 3. 初始化项目
railway init

# 4. 让Agent帮你部署（MCP方式）
# 在Claude Code中：
claude mcp add railway --transport http https://mcp.railway.com

# 然后直接对话：
# "帮我部署一个Python FastAPI应用，需要PostgreSQL数据库和Redis队列"

# 5. 或使用CLI手动部署
railway link
railway add --database postgres
railway add --database redis
railway variables set OPENAI_API_KEY=sk-...
railway up

# 6. 查看状态
railway agent -p "show me the status of all my services"