.title: DoorDash 內部 GenAI 平台架構：從 LLM Gateway 到 Agent Gateway 的演進之路 .slug: doordash-genai-platform-architecture-evolution
背景：從 ChatGPT 熱潮到內部平台需求
2022 年 11 月 ChatGPT 問世後，生成式 AI 迅速從技術話題變成企業實際需求。DoorDash 的 ML 平台團隊在 2023 年 4 月開始評估採用 OpenAI 服務，當時負責簽約的工程主管坦言，面對高昂的授權費用一度感到猶豫，但回頭看那筆金額在今日規模下已顯得微不足道。這個起點促使他們思考一個關鍵問題：在一家大型公司內部，如何讓生成式 AI 不只是少數團隊的實驗，而是能規模化、可問責、真正產生生產力的基礎設施。DoorDash 的 GenAI 平台團隊因此成立，由 Swaroop Chitlur 領導，Siddharth Kodwani 擔任核心工程師，負責打造 LLM 推論、微調、評估與 AI Agent 的底層架構。
核心原則：客戶導向與產品思維
團隊成立初期面對的是一張白紙，沒有既定路線可循。他們先確立了幾項營運原則：第一，客戶導向，專注於團隊與使用情境，不為建置而建置；第二，建置產品而非系統，產品工程師不該自行拼湊不同工作流程，平台必須提供端到端體驗，涵蓋入門引導與技術支援；第三，讓正確的事情變得容易，最佳實務不能只停留在建議層級，而要內建在平台運作方式中。這些原則看似基本，卻在後續多次技術轉向中成為決策依據。
團隊很快發現客戶樣貌與過去截然不同。DoorDash 的 ML 平台團隊原本習慣與機器學習工程師溝通，但在一次對話中，當他們建議對方使用 notebook 進行實驗時，對方反問「什麼是 notebook？」這一刻讓他們意識到，GenAI 的採用者已經從 ML 專業人士擴展到所有工程師，甚至包含非技術人員。這個認知推動了 API-first 與 SDK-first 的產品方向，平台不再以 GPU 存取或 notebook 為核心，而是提供簡單的 API 介面，讓任何團隊都能快速整合。此外，團隊也明確決定聚焦於商業影響，而非打造另一個聊天機器人，他們觀察到產品工程師的需求集中在自動化、推薦與個人化三大類別，自動化有助於降低成本，推薦與個人化則能提升營收。
LLM Gateway：統一入口與成本歸因
在早期階段，市場上的模型供應商快速增加，OpenAI、Anthropic、Gemini 與開源模型相繼出現，產品團隊若自行逐一串接各家 API，會嚴重拖慢開發速度。DoorDash 的解法是建立 LLM Gateway，作為公司內部的統一模型存取層。團隊只需透過一個 API 與一個 SDK，就能切換不同模型供應商，無論是 OpenAI、Azure、Anthropic 或 Bedrock，都能在設定檔中一鍵更換。這項設計在模型迭代頻繁的時期特別有價值，每幾個月就會出現宣稱效能更好的新模型，團隊可以快速實驗評估是否遷移。
LLM Gateway 也解決了可靠性與問責問題。當用量上升，供應商容易出現配額限制，DoorDash 因此在 Gateway 層設計了 fallback 機制，例如 OpenAI 端點失敗時自動轉向 Azure 端點，確保服務不中斷。同時，財務部門開始關注成本分攤，Gateway 導入 workspace 概念，每個團隊有獨立的使用量與預算追蹤，可以精確歸因成本至各部門。Gateway 也具備完整的請求與回應紀錄，工程師能透過 UI 檢視生產環境的模型表現，不必自行建置觀測工具。這套架構在 DoorDash 收購 Wolt、Deliveroo、SevenRooms 等公司後展現了擴充性，新團隊可以快速上線並獲得相同的使用體驗。
從 Vendor-First 到開源模型的轉向
DoorDash 初期採取 vendor-first 策略，優先採用外部供應商服務以加速產品上市。這個策略在模型供應上運作良好，但在評估（evals）工具上遭遇挫折。團隊原本導入第三方評估平台，卻發現各產品團隊有獨特的自訂追蹤與人工標註需求，例如需要在圖片上標註特定區域作為 ground truth。供應商產品雖然品質不錯，但靈活性不足，團隊甚至將其當作 OTel trace store 使用，自行在之上建構工作流程，形成次佳解。DoorDash 因此調整策略：平台擁有工作流程表層，但底層實作可以採用供應商或自建，若供應商可行就擴大使用，若不可行就吸收經驗自行開發。
模型供應方面也出現類似壓力。Gemini 模型有為期一年的生命週期，每年都必須強制遷移到新版本，對於平台團隊而言，要推動數百個使用案例遷移，卻無法提供明確的商業效益論述，是沉重的負擔。同時，DoorDash 的內部需求量龐大，供應商配額經常不足，成本也隨規模急劇上升。幸好 LLM Gateway 的設計初衷就是可攜性，模型切換成本極低，產品團隊只需變更設定即可改用新模型。平台團隊因此加速投入開源模型策略，選擇 Modal 作為 Python-first GPU 雲端平台，搭配 vLLM、SGLang 等開源推論引擎，以及 Hugging Face TRL、Unsloth、Axolotl 等微調工具。2025 年下半年開始投資後，採用率大幅成長，團隊從前沿商業模型切換到 Qwen3、Qwen3 Embeddings 等開源模型後，部分場景準確度提升，成本下降達 20 倍，年化節省金額已達數百萬美元。
Agent Gateway：從 MCP 到代理協定的演進
2024 年初，Agent 應用開始在 DoorDash 內部萌芽，真正引爆採用的是 MCP（Model Context Protocol）的出現。MCP 可以理解為 Agent 與外部工具之間的標準化溝通協定，類似資料的展示層，讓 Agent 能存取 Slack、GitHub、Jira 等內部服務。DoorDash 的 Agent Gateway 從 MCP 出發，借鏡 LLM Gateway 的成功經驗，提供統一的授權政策、工具層級存取控制、身分驗證與觀測性。MCP server 作者不需自行處理使用者認證或權限管理，只需宣告授權政策，Agent Gateway 會代為驗證使用者與服務身分，並執行速率限制。
團隊很快意識到 Agent 的世界不只是 MCP，還涉及更複雜的代理體驗。Agent Gateway 因此走向協定無關的設計，除了 MCP 之外也支援 AG-UI 協定，並正在評估 A2A 協定。AG-UI 讓 UI 可以直接透過 Gateway 與 Agent 進行串流互動，A2A 則讓 Agent 之間能互相溝通。截至演講時間，Agent Gateway 已上線超過 50 個 MCP server，每日工具呼叫次數達 30 萬次。身分與授權是 Agent 時代最棘手的問題之一：使用者允許 Agent 代表自己執行操作，但該授予多少權限？內部 Agent 與個人筆電上的 Claude Code 或 Codex 應有不同的權限邊界。Agent Gateway 的控制平面讓使用者可以檢視所有可用 Agent 與工具組合，並自行決定哪些 Agent 能存取哪些工具。
影響與限制：數據與未解問題
DoorDash 的 GenAI 平台目前已有超過 5,000 名內部用戶，每天新增 45 人，其中 40% 是非工程師，來自法務、銷售、營運與策略部門。這個數字說明了平台 API-first 策略的成功，但也帶出教育訓練的挑戰。非技術用戶不見得理解 eval、skill 或 MCP 等概念，DoorDash 的對策是與開發者平台團隊合作，提供 Agent skills marketplace，讓用戶安裝外掛後，Claude Code 或 Cursor 就能直接與內部系統互動，降低使用門檻。
評估（evals）仍是尚未完全解決的問題。DoorDash 正在建置內部評估平台，協助團隊建立基於程式碼的確定性評判器與 LLM-as-a-judge 機制，但如何讓產品團隊從 trace 中獲得訊號而非雜訊，仍需逐步引導。團隊的實務路徑是先解決追蹤問題，讓團隊可視化 Agent 的運作樹，理解瓶頸在於 LLM、工具或外部搜尋，再協助定義產品指標並轉化為評估器。人工標註 UI 也是重要環節，例如餐廳推薦場景中，人類需要檢視推薦結果並標註品質，DoorDash 提供了客製化標註介面，取代過去在 Google Sheets 中逐格檢視的笨拙流程。
平台團隊也坦言仍有未解的技術難題。Agent 的長時間執行與串流連線穩定性仍在探索階段，目前 Agent Gateway 在協定層面是無狀態的，session 管理與對話歷史由產品團隊自行負責；當 pod 終止時如何重建連線，尚未有標準答案。此外，安全與治理雖然是平台的核心責任，但目前 guardrails 採取 opt-in 模式，由產品團隊自行決定是否啟用，DoorDash 認為這是公司政策層面的議題，而非平台可以單方面強制執行。整體而言，DoorDash 的經驗說明了生成式 AI 平台的成功關鍵不在於追求最新技術，而在於建立可攜性、可觀測性與問責機制，並在快速變動的產業環境中持續調整策略。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。