SRE 視角解讀：Uber Software Factory 如何治理 AI Agent 時代的 Token 成本

AI coding agent 在過去兩年間，從輔助工具演變為軟體開發生命週期中的主要生產力來源，也讓 AI 支出從可預測的授權費用，轉變為隨用量複合成長的變動成本。Token 計費模式沒有天然的用量上限——工程師平行執行多個 agent、對整個 codebase 進行重構、或把重複性作業自動化，都會讓消耗量隨活躍度倍增。這個轉變，正把「AI 支出治理」推成一個新的工程管理課題。

Uber Engineering 在 2026 年 8 月發布的〈Running a Software Factory Efficiently at Uber Scale〉，公開了該公司如何在用量快速擴張的同時壓低單位成本。根據該文披露，從 2 月到 8 月中，全公司 agentic 功能的週活躍用戶成長 7 倍，agent 請求量成長 9。4 倍;若把模型版本固定下來比較，每千次請求的成本從高峰下降約 34%，每個 session 的成本從 6 月高峰下降 52%。

若拉開一層來看，這套框架並不是全新的方法論，而是把 SRE 領域行之有年的容量規劃與 error budget 治理，搬進了 AI agent 這個新的資源類型。過去容量規劃談的是運算資源與流量成長的關係，error budget 談的是可用性與變更速度的平衡;Uber 這篇文章處理的問題結構完全相同，只是把「運算資源」換成了「token」、把「可用性」換成了「單位成本」。理解這層對應關係，有助於判斷哪些做法是換皮的舊經驗，哪些才是 AI agent 帶來的新變數。以下先整理該文揭露的治理框架，再回頭對照這層關係。

分層治理模型:掌控力隨專用程度遞增

該文將公司內的 agent 使用場景分為四層，由最泛用到最受管理。層級愈高、愈受管理，團隊對成本、輸出品質與模型選擇的掌控力也愈強。互動式的個人 coding session 屬於最泛用的一層，routing 與模型選擇多半由工程師臨時決定;相對地，把工作交給「受管理的 agent」(例如自動 code review、CI 失敗自我修復、on-call alert 分診)，則讓平台方能統一決定模型版本與執行環境。該文將此描述為核心策略轉向——從優化個別終端 session，轉向優化一支專門化的 managed agent 艦隊。

成本方程式:六個變數，三個可控

Uber 把單一 agent session 的總花費拆解成六個相乘的變數。文中說明，前兩個變數對應「使用者規模與參與度」，是公司希望持續成長、不會刻意壓縮的部分;中間三個變數則對應 agent 在工程師實際請求之外額外產生的工作量，是該文所稱優化的主要著力點:

• Price / Token——每個 token 的計費單價
• Tokens / Request——每次請求所需的 token 數量
• Requests / Turn——完成一個任務所需的來回輪數

前者由供應商定價決定，後兩者取決於使用方自身的工程實踐，也是該文後半段著墨最多的部分。

模型選型:以 Benchmark 取代直覺

Uber 描述其模型選型流程分為四步:用真實歷史任務建立 benchmark、在同一介面下對多個模型跑分、挑選 Pareto 最優的組合、並隨模型迭代持續調整。以其內部程式碼審查工具 uReview 為例，該文表示透過切換模型，在維持甚至提升準確度(F1)的同時大幅降低每次審查的成本。文中同時提到，subagent 預設採用比主模型更弱、更便宜的模型執行定義明確的子任務，由主模型負責任務分解與結果評估——該文形容這是目前影響力最大、且隨多代理協作能力提升而持續放大的一項槓桿。

Context 管理:三個具體參數

該文列出三個直接影響「每次請求 token 量」的設定:context 累積達 400K token 時自動觸發壓縮，即使模型本身支援到 1M context window;reasoning effort 預設調整為中等，理由是輸出 token(含內部推理 token)的計費通常是輸入 token 的數倍;prompt cache 的 TTL 依工程師實際的中斷習慣調整——原文提到，由於工程師常在對話中閒置超過 5 分鐘才回來，Uber 已把預設從 5 分鐘 TTL 改為 1 小時，理由是短 TTL 頻繁失效反而導致 context 被迫全額重建。相對地，生命週期短、任務單一的 subagent 仍維持 5 分鐘 TTL。

Grounding 對照案例

該文舉出一組對比實驗:同一個 prompt，分別在有無內部知識圖譜(AI Context Graph)grounding 的情況下執行。有 grounding 的 agent 在 38 秒內完成查詢並給出正確答案;沒有 grounding 的 agent 則耗費 20 分鐘、額外呼叫兩個 subagent、撞了三次錯誤，最終仍給出錯誤結論。Uber 將此歸因於其自建的知識圖譜——涵蓋 2400 萬節點、8000 萬邊、整合逾 30 個內部系統——讓 agent 得以用自然語言查詢公司內部脈絡。這部分的可轉移性相對有限，多數團隊不具備投入同等規模知識圖譜的資源，但「先建立結構化內部索引、再放行 agent 自由搜尋」的原則仍具參考意義。

MCP 工具的 Schema 開銷

該文指出，標準 MCP 架構會將所有工具的 schema 直接載入每個 session，不論該次任務是否會用到。以 Uber 內部超過百項工具為例，這帶來約 5 到 7 萬 token 的起手開銷，且會在每輪對話中重複計費;第三方 SaaS 的 MCP server 開銷更明顯，單一服務即可能佔用兩萬多 token 的 schema。

Uber 描述的因應方向有二:一是透過 CLI 讓模型動態解析並呼叫工具，取代將 schema 常駐於 context 之中;二是提供 tool search，讓模型依需求搜尋工具目錄、按需載入。需要說明的是，原文只揭露這兩個方向的效果與動機，並未公開 Gateway 本身的路由與認證架構如何實作——這部分若要進一步還原技術細節，需另行參照 MCP 協定的公開規格與現有開源實作，不在本文討論範圍之內。

可見度優先於硬性上限

值得留意的是，Uber 在文中呈現的治理機制並非依賴嚴格的用量上限，而是著重即時可見度:介面上有 live 花費計數器，顯示當前 session 與跨工具的總花費;花費達到預期的 50%、80%、100% 時分級推播提醒，而非直接中止任務;另有一套 session 分析儀表板，自動掃描 session 紀錄，標記出 16 類常見的浪費模式，包括將簡單任務交由昂貴模型執行、對話中殘留未清除的大型 MCP 回應反覆計費、閒置過久導致 cache 失效被迫重建，以及在使用者輸入前就已載入十萬 token 的系統提示詞與工具定義。這套設計讓工程師得以自行評估任務的成本效益，而非完全仰賴平台方事後稽核。

與傳統 SRE 治理的對照

把這套框架攤開，幾乎每個機制都能在傳統 SRE 治理裡找到對應版本。50%、80%、100% 的分級推播提醒，對應的正是 error budget 燒錢速率告警(burn rate alerting)的邏輯——差別只在於燒的不是可用性額度，而是花費額度;session 分析儀表板自動標記 16 類浪費模式，功能上等同於一份 SLO 違規儀表板，只是把「延遲」「錯誤率」換成了「模型選型錯誤」「context 膨脹」;而四層 agent 分工模型，從個人自行管理的互動式 session，收斂到平台方統一治理的 managed agent 艦隊，本質上就是 Platform Engineering 一貫的黃金路徑(golden path)邏輯——先開放自由試驗，再把驗證過的模式收斂成受控的自助服務。

這個對照的意義，不在於證明 Uber「什麼都懂 SRE」，而在於說明:當一個組織的 AI agent 用量規模夠大，治理問題最終都會回到同一組老問題——如何量測、如何設定門檻、如何在不犧牲敏捷性的前提下收斂風險。這也是本部落格先前在〈SRE 不是專案:價值、評估與治理〉一文中談過的核心主張:治理不是一次性的專案，而是持續的量測與調整循環。

小結:可轉移性取決於規模與既有投資

Uber 這篇文章呈現的框架，核心主張是把 AI 支出治理視為工程問題處理——透過分層管理、成本方程式拆解、以及可見度機制，在用量大幅成長的同時壓低單位成本。其中，模型選型的 benchmark 方法論、context 參數調整、以及即時可見度機制，對多數團隊具備一定的參考價值;但知識圖譜規模、內部 MCP Gateway 架構等基礎設施投資，則明顯受限於 Uber 自身的規模與資源，難以直接複製。評估此類案例時，通常需要區分「方法論層次的啟發」與「基礎設施層次的複製」。

原文對 MCP Gateway 的架構細節揭露有限，後續會另外整理 MCP 協定的公開資料，針對這部分做更深入的技術拆解。這個對照關係，也是本部落格規劃中「token 預算作為 FinOps guardrail」系列文章的出發點:當 token 成為一種需要被治理的資源，傳統 SRE 的容量規劃與 error budget 工具箱，能夠直接套用多少、又有哪些地方需要重新設計，會是下一篇系列文章要處理的問題。

參考來源:Uber Engineering，〈Running a Software Factory Efficiently at Uber Scale〉，2026 年 8 月 27 日。原文連結

常見問題 FAQ

這套 Token 成本治理框架，跟傳統 SRE 治理有什麼關係?

從機制設計看，兩者高度同構:分級推播提醒對應 error budget 燒錢速率告警，浪費模式儀表板對應 SLO 違規儀表板，分層治理模型對應 Platform Engineering 的黃金路徑收斂邏輯。差異主要在於治理的資源類型，從「可用性與運算資源」換成了「token 與模型選擇」。

Uber 的 subagent 預設模型策略具體是什麼?

根據該文，主模型負責任務分解與結果評估，定義明確的子任務則轉包給較便宜、較弱的模型執行，並保留手動覆寫的彈性。Uber 將此列為目前影響力最大的成本槓桿之一。

Prompt cache 的 TTL 設定，Uber 是根據什麼調整的?

該文說明，由於工程師常在對話中閒置超過 5 分鐘才回來，原本的 5 分鐘 TTL 會頻繁失效、迫使 context 全額重建，因此改為 1 小時;生命週期短、任務單一的 subagent 則維持 5 分鐘 TTL。

MCP 工具過多會如何影響 token 用量?

該文指出，標準 MCP 架構會把所有工具的 schema 預先載入 context，百餘項工具即可能帶來 5 到 7 萬 token 的起手開銷，且每輪對話重複計費。Uber 的因應方向是改用 CLI 動態呼叫工具，以及提供 tool search 按需載入。

這套治理框架是否適用於所有規模的團隊?

並非全部可直接複製。模型選型的 benchmark 方法論、context 參數調整、即時可見度機制較具跨團隊參考價值;但大型知識圖譜與內部 MCP Gateway 這類基礎設施投資，明顯受限於 Uber 自身的規模與資源。