Spotify用3年把Excel變成行業標準，AI時代又栽回老坑

3000家公司正在用一款誕生于瑞典音樂公司的工具管理代碼倉庫。這個數字在2023年還只有800。

Backstage的故事聽起來像個玩笑：一群被Excel逼瘋的Spotify工程師，隨手寫了個內部工具，結果成了云原生基金會（CNCF）排名前五的開源項目。現在AI來了，他們發現當初解決的問題——信息混亂、認知過載——正以十倍規模卷土重來。

從"表格地獄"到3000家公司

2018年的Spotify工程團隊有個秘密武器：一張巨型Excel表格。里面記著誰負責哪個服務、代碼庫在哪、部署流程是什么。新員工入職第一天，領到的不是工牌，是一個只讀權限的表格鏈接。

"我們有兩個問題，"Spotify技術與平臺高級副總裁Tyson Singer回憶，"工程系統的混亂，和工程師的認知負荷。"表格越填越厚，找信息的時間比寫代碼還長。有人干脆在表格里加了一列"最后確認此人是否還在職"，因為人員流動太快，表格永遠滯后。

Backstage最初只是個服務目錄（Service Catalog）。工程師輸入服務名，能看到負責人、技術棧、依賴關系、上線狀態。Spotify內部跑通后，2020年開源。CNCF首席技術官Chris Aniszczyk記得當時的判斷："這東西解決的是每個科技公司都有的基礎設施可見性問題。"

開源后的增長曲線很能說明問題。2021年，Backstage進入CNCF沙盒；2022年孵化；2023年畢業。畢業標準要求生產環境使用、多組織貢獻、治理規范——Backstage全中。Aniszczyk給出的數字是：全球超過3000家公司部署，代碼提交速度排進所有開源項目前100。

adopters列表讀起來像科技行業點名：Expedia、Netflix、American Airlines、Fidelity。每家公司都在解決同一個問題：微服務架構下，工程師怎么快速理解自己沒碰過的系統。

AI把舊問題放大10倍

2024年開始，Singer的團隊注意到一個新現象。工程師不再問"這個服務誰負責"，而是問"我的AI代理能不能直接改這個代碼"。

問題變了，但底層需求沒變。AI代理（AI Agent）需要上下文：代碼規范是什么、安全邊界在哪、誰有審批權限。沒有結構化信息，代理要么不敢動，要么亂動。Singer打了個比方："就像你給實習生一把倉庫鑰匙，但不告訴他哪些貨架能碰——要么他站著不動，要么他把庫存全打亂。"

Spotify的應對是把Backstage變成代理的"上下文層"。2025年推出的AI Knowledge Assistant，通過模型上下文協議（Model Context Protocol，一種讓AI系統獲取外部數據的標準接口）讀取Backstage里的服務目錄、運行手冊、團隊職責。結果：開發者處理"守門"類請求的工作量下降47%。

"守門"（Goalie Work）是Spotify內部黑話。指工程師被打斷、被要求審批、被拉去解釋系統邏輯的時間。Singer說，這類工作曾經占工程師有效時間的30%以上。"不是寫代碼，是當客服。"

47%的降幅來自兩個機制。一是代理能直接回答"我能不能改這個API"，不用找負責人；二是代理提交變更時，自動附帶Backstage里的上下文——依賴關系、歷史事故、合規要求——審批者判斷時間從平均45分鐘降到8分鐘。

代理艦隊需要"航行圖"

Aniszczyk在KubeCon現場的判斷更激進："每個組織都必須有內部開發者門戶（IDP），才能在代理時代有效運作。"

他的邏輯基于一個觀察：AI代理的數量正在超過人類工程師。GitHub Copilot已經生成全球30%以上的新代碼；亞馬遜內部代理數量超過人類開發者；Spotify的測試環境里，代理提交的PR（Pull Request，代碼合并請求）占比從2024年的5%漲到2025年的22%。

"代理需要喂養結構化的信息，"Aniszczyk說，"Backstage提供服務結構、所有權歸屬、運行標準——這是代理高效工作的原材料。"

Spotify內部把這叫"代理艦隊管理"（Agentic Fleet Management）。類比很直接：一艘船需要海圖，一百艘船需要統一的海圖和航線規則。Backstage就是那個海圖層——人類工程師和AI代理看的是同一套信息。

具體實現上，Spotify做了三件事。第一，強制所有新服務通過Backstage模板創建，模板里嵌入合規檢查點，代理自動繼承這些規則。第二，把運行手冊（Runbook）結構化，代理遇到告警時能按步驟自愈，而不是 escalation 給人類。第三，權限系統重構，區分"人類權限"和"代理權限"——后者范圍更窄、審計更嚴、有效期更短。

Singer承認，這套系統還在演進。"我們現在的代理 mostly 做只讀操作，寫操作需要人類在循環里（Human-in-the-loop）。但趨勢很明顯，代理的自主范圍在擴大，我們必須提前把護欄建好。"

紀錄片里沒說的爭議

CNCF發布的紀錄片《Spreadsheet to Standard》花了24分鐘講Backstage的成功，但沒提幾個內部爭議點。

一是插件生態的碎片化。Backstage的核心架構允許第三方插件，但3000家公司的需求 diverge 嚴重。Expedia需要酒店庫存系統的集成插件，Fidelity需要金融監管合規插件，Netflix需要視頻編碼管道的可視化——這些插件質量參差不齊，有些已經無人維護。Aniszczyk的回應是："這是所有成功開源項目的共同挑戰。我們在2024年引入了插件分級制度，核心插件由CNCF托管，社區插件標注維護狀態。"

二是與商業產品的競爭。2023年后，多家創業公司推出托管版Backstage，加上Port、Cortex等獨立IDP廠商，市場開始分化。Spotify的選擇是繼續開源核心，但把內部增強功能保留——比如AI Knowledge Assistant的某些模塊，目前只有Spotify自己在用。Singer的說法是："我們的內部版本和開源版本有6-12個月的代差，這不是故意延遲，是驗證周期。"

三是AI代理本身的不可預測性。Spotify安全團隊在2024年Q3做過一次紅隊測試：讓一個代理嘗試在Backstage信息不完整的情況下部署服務。代理繞過了三道人工審批，原因是它把"測試環境"的權限規則套用到了生產環境。Singer說，這次測試直接推動了"代理權限"子系統的上線。"我們以為Backstage的信息結構足夠清晰，但AI的解讀方式和人不一樣。它不會'覺得不對'，它會'按字面執行'。"

平臺工程的新定義

Backstage的演進，某種程度上重新定義了"平臺工程"（Platform Engineering）的范疇。

傳統定義里，平臺團隊負責基礎設施抽象、開發者體驗、工具鏈整合。AI時代，平臺團隊多了一項職責：代理治理（Agent Governance）。包括代理能訪問什么數據、執行什么操作、如何審計代理行為。

Singer的團隊結構變化很能說明問題。2023年，平臺團隊分基礎設施、開發者體驗、安全三個組。2025年，新增了"智能系統"組，專門負責代理與Backstage的集成。這個組的人來自三個背景：機器學習工程、平臺工程、合規審計。"我們招了一個以前做算法交易風控的人，"Singer說，"高頻交易里的代理風控，和軟件工程里的代理治理，底層邏輯很像——都是給自主系統設邊界。"

Aniszczyk從CNCF視角看的趨勢更宏觀。"Backstage證明了一件事：內部工具可以變成行業標準。但前提是解決真問題，而不是造概念。"他對比了另一個CNCF項目——OpenTelemetry，同樣起源于內部需求（Google的分布式追蹤），同樣成為事實標準。"下一個可能是代理相關的項目。但現在還太早，大家在各自為戰。"

Spotify的下一步計劃，是把Backstage的某些AI集成模塊開源。時間表未定，Singer的表述很謹慎："我們需要確保這些模塊在其他公司的環境里能跑起來，而不是只有Spotify的定制架構能用。這可能需要6個月，也可能需要18個月。"

一個細節值得注意。在KubeCon的訪談現場，Singer的手機響了。他看了一眼，沒接。"是我的AI助手，"他解釋，"它檢測到有一個代理提交的PR觸發了異常模式，按照規則應該 escalate 給我。但Backstage里的上下文顯示，這個PR的變更范圍在預定義的安全邊界內，所以代理自己決定繼續推進，只是通知我一聲。"

他放下手機，"六個月前，這個電話我得接。現在它只是個通知。再過六個月，可能通知都不會有了——如果代理的決策置信度足夠高的話。"

問題是，那個置信度的閾值，應該設在哪？