Railway 創辦人：Pull Request 正在死去，未來屬於 Agent 原生雲端

本文整理自 Latent Space Podcast 2026 年 5 月播出的單集。

---

從「最簡單的部署方式」到 Agent 原生雲端

「我們從組合語言走到 C，走到 C++，走到 JavaScript，現在走到了文字。」Railway 創辦人暨執行長 Jake Cooper 在 Latent Space Podcast 上丟出這句話時，語氣平淡得像在講一個已經發生的事實。

Railway 是一個讓開發者用一句話就能部署應用程式的雲端平台。你可以在它的視覺化畫布上操作，也可以直接對 Claude 說「幫我部署一個 Postgres 資料庫」，幾秒鐘後就能拿到一個運行中的服務。但 Cooper 的野心遠不止於此。他認為整個軟體開發的生命週期正在被 AI 代理人徹底改寫，而 Railway 要成為這個新時代的基礎設施。

這不是空口白話。Railway 目前擁有超過 300 萬名使用者，每週新增約 10 萬人註冊，每月處理超過 1,000 萬次部署。更誇張的是，這一切只靠 35 人的團隊撐起來。2026 年 1 月，Railway 完成了由 TQ Ventures 領投的 1 億美元 B 輪融資，累計募資金額達到 1.24 億美元。而 Heroku 今年 2 月正式停止企業銷售、轉入維護模式，更讓 Railway 站上了一個關鍵的時間點。

自建資料中心的經濟學：三個月回本

多數新創公司把基礎設施外包給 AWS 或 GCP，Cooper 卻選擇了一條更硬核的路：自建裸機資料中心。

他算了一筆帳。Railway 購買伺服器後，相較於租用雲端的成本，回收期大約只要三個月。這些硬體的折舊年限是四年，意味著剩下的三年九個月都是淨利。Railway 在自有金屬上的毛利率約 70%，這讓他們有充裕的空間在需求暴漲時「爆發」到公有雲上，用高毛利補貼短期的雲端租用成本。

這套混合策略讓 Railway 在成長速度和成本控制之間找到了平衡。他們直接與 Supermicro、Dell 等硬體 OEM 合作，在 Equinix 等共置機房中租用機籠，自己填滿伺服器機架。目前 Railway 在全球多個區域都有自己的資料中心，絕大多數流量已經跑在自有金屬上。新加坡的第二座資料中心預計在第三季上線。

但這條路不是沒有代價。今年初，Railway 曾因一家上游雲端供應商無法以足夠的速度提供運算配額，導致平台出現可靠性問題。Cooper 花了一個週末重建了整個網路覆蓋層，讓 Railway 能夠同時橫跨五朵雲（Oracle、AWS、自有金屬、GCP 以及另一家供應商）。這種「運算受限」的痛苦經驗，反而更堅定了他走向自有基礎設施的決心。

在融資策略上，Cooper 的思考也不走傳統路線。他把硬體投資視為「資料中心債務」而非創投資本，用硬體本身作為擔保品取得貸款，利率以 RIME 為基準。「創投資本是你能取得的最貴資金，」Cooper 說，「你應該想清楚用這些股權能買到什麼不公平的優勢，而不是把 VC 當成萬用鐵鎚。」

AI 代理人到底需要什麼？跟人類一樣，但快一千倍

談到 AI 代理人對基礎設施的需求，Cooper 的觀點意外務實。他認為代理人需要的東西跟人類開發者基本相同：版本控制、可觀測性（traces、logs、metrics）、網路、運算和儲存。差別不在種類，而在規模和速度。

「如果我給你一個有 40 個參數和 600 個旗標的 CLI 工具，你永遠不會把它們全用上。但如果我把同樣的 CLI 交給一個代理人，它會說：太棒了，我有 600 個把手可以用來完成任務。」

這個觀察點出了 Agent 時代基礎設施設計的核心轉變。對人類來說，複雜的命令列介面是認知負擔；對代理人來說，每一個旗標都是一個可以操控的「把手」（handle），讓它能查詢動態資訊、做出決策、關閉迴圈。Railway 的策略是盡可能提供更多這樣的把手，讓代理人不需要人類介入就能自主迭代。

Cooper 認為，這也是為什麼 Railway 的 CLI 在 Agent 時代可能比他們引以為傲的視覺化畫布（Canvas）更加重要。畫布原本是人類與基礎設施互動的輸入介面，但在代理人驅動的世界裡，它的角色正在轉變成一個輸出介面：讓人類在需要做決策時，能快速看到系統的當前狀態。

更關鍵的基礎設施需求是「安全的迭代環境」。Cooper 的說法很直白：如果你讓一個 AI SRE（網站可靠性工程師）直接在生產環境中操作，卻沒有提供安全的原語（primitives），比如複製資料庫磁碟區、建立寫入時複製（copy-on-write）版本的能力，它遲早會把你的生產資料庫炸掉。「這不是會不會發生的問題，而是什麼時候發生的問題。」

Pull Request 正在消亡：規格、程式碼、測試的三位一體

這集 Podcast 最精彩的部分，是 Cooper 對軟體開發生命週期（SDLC）即將被翻轉的論述。

Cooper 提出了一個簡潔的框架：未來的軟體開發將圍繞三個支柱運作。你需要一個清晰的規格（spec）來定義系統應該做什麼，你需要程式碼來實現它，你需要測試來驗證它。這三者之間應該能夠自動調和（reconcile）。如果規格和測試吻合但程式碼不對，系統就自動修正程式碼。如果測試和程式碼吻合但規格偏了，系統就回頭調和規格。

乍聽之下，這不就是 RFC（徵求意見書）、程式碼和測試嗎？工程師早就熟悉這三個概念了。但 Cooper 強調，關鍵在於讓這三者真正整合在一起，而不是分散在不同的工具和流程中。當代理人可以在這個三角形中自動迭代時，傳統的 Pull Request 就變成了一個多餘的摩擦點。

「在代理人的時代，你不一定需要人類逐行審查程式碼中的 CVE 漏洞，如果你有代理人能做這件事的話。」Cooper 說。但他也清楚，你不能把更多的代理人無限制地堆到問題上。他承認這條路最終會碰到推論成本的天花板。

這套思維的實際應用，就是 Railway 正在打造的「複製機器」（cloning machine）概念。想像你能在任何時間點，把生產環境中的任何服務瞬間複製一份，包括檔案系統和資料庫的快照。代理人在這個副本中做實驗、測試假設，如果結果正確就合併回生產環境；如果不對就直接丟棄。Cooper 認為，一旦這個迴圈夠快、夠安全，傳統的推送、拉取、重建流程就會徹底消失。

「如果你能懶載入整個檔案系統呢？那你就不需要 Dockerfile 的儀式感了。不需要 Ansible 腳本，不需要那些層層疊疊的東西。你直接在那個迴圈中迭代，然後快照它。」

從 Heroku 接棒：不只是「新版 Heroku」

今年 2 月，Salesforce 宣布 Heroku 停止接受新的企業合約，並將開發資源轉入「維護工程模式」。對許多開發者來說，Heroku 是他們學會部署的第一個平台。Cooper 自己也是其中之一。「我在 Heroku 上學會了寫程式，」他說，「它是基礎性的存在。」

但 Cooper 很明確地表示，Railway 的目標不是成為「新版 Heroku」。「我們想成為人們建構和部署軟體的方式，最終成為人們透過軟體獲利的方式。」

他把 Heroku 的衰落歸因於一個簡單的邏輯：雲端運算平台不是 Salesforce 的核心業務。當一家公司被收購後成為母公司的旁支，無論團隊多有才華，資源分配、內部對齊、使命感都會逐漸被稀釋。Cooper 引用了 Meta 早期的經驗，指出在資源充裕時，企業反而容易失去焦點。

有趣的是，Cooper 也用「專注」來解釋 Railway 為什麼目前不做 GPU 供應。「你更應該被你不做的事情來定義，而不是你做的事情。」他坦言 Railway 未來一定會提供 GPU，因為完全垂直整合的邏輯最終會把他們帶到那裡，但現在的優先順序是把網路、運算和儲存這三個核心原語做到極致。

35 人團隊的槓桿祕密

Railway 用 35 人服務 300 萬名使用者的祕訣，除了自動化之外，還有一個他們自建的內部工具叫做 Central Station。這個系統會彙整所有使用者的回饋、客服紀錄和事件資訊，把它們聚類成「叢集」。當一個事件正在醞釀時，系統能自動判斷有多少使用者受影響，並根據內部脈絡把問題路由到最適合處理的團隊成員。

這取代了傳統的 Slack 頻道式溝通。Cooper 對 Slack（和 Discord）的批評很直接：它們本質上就是「訊息傳遞加上中斷」的無限循環。當你的組織靠這種方式運作，協調成本會隨規模急劇上升。Central Station 試圖用結構化的脈絡路由取代這種「該把訊息放在哪個頻道」的困境。

Cooper 透露，Railway 每月在 AI 程式碼工具上的花費已達 30 萬美元。他自己一個人就貢獻了約 2.5 萬美元。他對團隊的要求很明確：「如果你還在用手寫程式碼，你的做法就錯了。」但他也強調，這不代表架構思維和工程判斷力變得不重要。正好相反，這些能力現在比任何時候都更關鍵。差別在於，你應該花時間審查程式碼，而不是花時間生成程式碼。

我的觀察：基礎設施決定了 Agent 時代的天花板

Cooper 在這場訪談中反覆強調一個原則：「你永遠不該等待運算資源，你應該等待的是智慧。」這句話道出了 Agent 時代一個容易被忽略的核心瓶頸。

目前多數關於 AI 代理人的討論都聚焦在模型能力和提示工程上，但 Railway 的故事提醒我們，如果底層的基礎設施跟不上，再聰明的代理人也只能在瓶頸中空轉。當你想讓一千個代理人同時在各自的沙盒中迭代程式碼、測試假設、部署服務，你需要的不只是更大的 GPU 叢集，而是一整套重新設計的原語：瞬間複製的環境、寫入時複製的資料庫、內容可定址的檔案系統、以毫秒計的部署速度。

Cooper 用六年時間從零建起的這套系統，恰好在 Agent 浪潮來臨時準備就緒，這確實有幾分「回溯性顯而易見」（retroactively obvious）的味道。但換個角度看，這也是為什麼 Railway 能在 Vercel、Cloudflare、Render 等一眾競爭者中佔據獨特位置：它不只是在應用層做優化，而是從核心堆疊的最底層開始重建。

真正的考驗在接下來十二個月。Railway 的 B 輪資金能否讓自建資料中心的規模跟上使用者成長的速度？Central Station 式的內部工具能否對外產品化？他們承諾的「複製機器」能否從願景變成開發者每天使用的功能？這些問題的答案，將決定 Railway 是否真的能從「新版 Heroku」的標籤中掙脫出來，成為 Agent 原生雲端的定義者。