當科技公司紛紛投入大型語言模型與 AI Coding Agent，Spotify 選擇了不同的切入點。它沒有推出另一個用來生成程式碼的模型，而是發表全新桌面應用程式 Xirp，試圖解決開發者同時使用多個 AI Agent 後逐漸浮現的管理問題。這款產品目前支援 Claude Code、OpenAI Codex 與 Gemini CLI，可將不同專案、終端機、Agent Session 與 Git 工作流程集中到同一個介面，產品定位更接近一座 AI 程式開發指揮中心。
當 Coding Agent 增加，新的問題不再只是模型能力
過去討論 AI 程式開發工具時，焦點大多放在模型能不能理解大型專案、寫出的程式碼是否正確，以及完成任務的速度夠不夠快。然而，當開發者開始同時使用 Codex、Claude Code 與 Gemini CLI，甚至讓多個 Agent 分別處理功能開發、錯誤修正、測試與 Code Review，問題便不再只是「哪個模型比較厲害」。
不同 Agent 可能分散在多個終端機視窗，分別操作不同專案與 Git Branch；有些正在執行工作，有些等待使用者授權，有些則已經完成任務。當工作階段增加，開發者需要花費更多時間確認每個 Agent 的狀態，也必須避免它們同時修改相同檔案而造成衝突。Xirp 瞄準的正是這個逐漸成形的管理需求。
根據 Spotify 官方文件，Xirp 是一款用來執行及管理 AI Coding Agent 的 macOS 桌面應用程式。它不會取代既有的 Coding Agent，也不會自行提供模型。開發者仍須分別安裝並登入 Claude Code、Codex 或 Gemini CLI，模型選擇、帳號方案、推理設定、操作權限與 Sandbox 行為，也繼續由各工具的原生設定負責。
換句話說，Spotify 並沒有加入模型競賽，而是選擇站在這些模型的上層，提供一套統一的工作介面。當開發者更換 Agent 時，可以保留相同的專案管理方式；當同時啟動多個 Agent 時，也不必再依賴大量彼此分散的終端機視窗。
從管理 Session 開始，建立多 Agent 平行開發流程
為了讓多個 Agent 可以同時工作，Xirp 將每次 AI 開發任務視為一個持續運作的 Session。開發者可以在同一個專案建立多個 Session，也能跨不同專案使用不同 Agent。即使關閉 Xirp 再重新開啟，原本的 Session 仍會保留，不必重新建立終端機環境或從頭啟動工作。
Xirp 也會顯示每個 Session 目前是執行中、閒置、等待輸入，還是已經結束。開發者可以透過 Grid View，在同一個畫面監看多個即時終端機；背景中的 Agent 需要回應或權限確認時，系統也能發出通知。這些功能並不會直接提升模型寫程式的能力，卻能減少開發者在多個視窗之間反覆切換及確認進度的時間。
不過，單純把多個 Agent 放在同一個畫面，仍無法解決它們同時修改程式碼所造成的衝突。因此，Xirp 進一步將 Git Worktree 納入主要工作流程，讓每個任務都能擁有獨立的 Branch 與工作目錄。
開發者可以讓一個 Agent 開發新功能，另一個 Agent 修正錯誤，再由第三個 Agent 檢查程式碼。由於不同任務位於各自的 Worktree，它們不必同時在主要 Checkout 中修改檔案，完成後再透過既有的 Git 與 Pull Request 流程進行檢查及合併。Xirp Session 文件也顯示，使用者可以直接在工作階段中瀏覽檔案、檢查 Git 變更、切換 Agent、分叉對話，或開啟使用相同 Worktree 的 Shell。
從 Session 狀態管理到 Git Worktree 隔離，Xirp 所建立的是一套完整的多 Agent 平行開發流程。這也說明 Spotify 推出這項產品的重點並不是再增加一個 AI 助手，而是處理多個 AI 助手開始共同工作後產生的協調問題。
從個人開發工具延伸到企業知識平台
如果只使用 Xirp 本身，開發者已經可以管理本機專案、Agent Session、Git Worktree、檔案、Rules、Skills 與 Pull Request 狀態，不必另外連接 Spotify Portal。這讓 Xirp 可以先以桌面工具的形式進入個人開發者與小型團隊的日常工作，再視需求向企業級功能延伸。
當企業將 Xirp 連接至 Spotify Portal 後，產品的定位就不再只是 Session 管理工具。Portal 可以提供 Software Catalog、Workspace 文件、系統負責人、技術紀錄、資源與過去的工作階段，Agent 則可透過 MCP 在需要時讀取這些組織脈絡。Spotify 對 Xirp 與 Portal 的說明指出，從 Portal Workspace 啟動的 Session 可以先取得專案背景，再根據 Software Catalog 找到對應的 Repository。
這項整合想處理的是企業導入 AI Agent 後更深一層的問題。即使模型可以閱讀程式碼，它也未必知道某項架構為何如此設計、哪個團隊負責特定服務、過去做過哪些技術決策，以及前一個 Agent 曾經嘗試過什麼。如果這些背景資訊沒有被保存，每次啟動新 Session 或更換模型，團隊都必須重新解釋一次。
因此，Xirp 官網將 Living Documentation 列為重要特色，主張開發過程產生的知識可以被整理、保存，再提供給未來的工程師與 Agent 使用。這使 Xirp 與 Portal 的組合不只管理「現在有哪些 Agent 正在工作」，也開始嘗試累積「這些 Agent 在工作過程中學到了什麼」。
不過，官網呈現的是較完整的產品願景，目前 Beta 版本尚未完全自動化。依照現行官方文件，與 Portal Workspace 關聯的 Session Transcript 仍須由使用者手動上傳，尚未支援自動同步。因此，現階段的 Living Documentation 比較接近由團隊主動保存工作紀錄，再逐步建立可供未來 Agent 使用的共同知識庫。
產品仍在 Beta，資料分享也有明確界線
Xirp 目前只支援 macOS，官網分別提供 Apple Silicon 與 Intel Mac 的下載版本；Windows 與 Linux 使用者則必須先加入候補名單。使用者也至少需要準備一組 Claude Code、Codex 或 Gemini CLI 帳號，本機若要使用完整的 Git、Worktree 與 Pull Request 功能，仍須安裝對應的開發工具。Xirp 下載頁面目前已開放 Mac 版本下載，Spotify Portal 則另外提供免費試用。
由於 Xirp 的主要工作都發生在本機，將專案加入應用程式並不會自動把程式碼上傳至 Spotify Portal。只有當使用者主動上傳 Session Transcript 時，相關紀錄才會進入 Portal Workspace，並提供給具備權限的團隊成員及未來的 Agent 使用。
這個上傳流程也伴隨需要注意的資料安全問題。Session Transcript 可能包含完整對話、工具呼叫、檔案變更、程式碼片段、檔案路徑，以及 Agent 在工作過程中處理過的其他資訊。Spotify 在 Xirp 官方 FAQ 中明確表示，系統不會在上傳前自動移除憑證、個人資料或敏感內容，因此使用者必須先自行檢查，避免將 API Key、客戶資料或受限制的原始碼一併分享。
除了資料分享仍須人工把關，Xirp 目前也尚未支援 Windows、Linux、自動上傳 Transcript 與自動處理 Monorepo 等功能。Xirp Changelog將它定位為持續快速調整的 Beta 產品，介面、支援範圍與整合方式都可能隨後續版本改變。
Spotify 搶占的不是模型，而是 Agent 管理層
Xirp 現階段仍有不少限制，但它透露出 Spotify 對 AI 程式開發市場的判斷：當模型能力逐漸普及，企業與開發者面對的下一個問題，將是如何同時管理多個 Agent、避免程式碼互相衝突，並把每次開發產生的知識保存下來。
對個人開發者而言，Xirp 是一套將 Codex、Claude Code、Gemini CLI 與 Git Worktree 集中管理的桌面工具；對企業而言，它則是 Spotify Portal 連接 AI 開發流程的入口。前者解決多個 Session 難以掌握的問題，後者則試圖讓組織文件、系統脈絡與 Agent 工作紀錄形成可以重複利用的知識。
Spotify 沒有再做一個新的 Coding Agent，而是選擇打造管理 Coding Agent 的產品。這個切入點未必像推出新模型那麼引人注目，卻可能更接近企業真正導入 AI 開發工具時必須面對的問題：當 AI Agent 從一名助手變成一組可以平行工作的數位開發者，誰來管理它們，以及它們完成工作後留下的知識要如何被團隊繼續使用。
