Uber 超過 70％ PR 可歸因於 AI Agent：Software Factory 如何控制成本與品質？
Uber 超過 70％ PR 可歸因於 AI Agent，使用量成長時仍降低單位成本。本文拆解 Software Factory 的評測、context 與成本方法。
AI coding 工具最初只是幫工程師補程式、解釋錯誤。到了 Uber，它已經進入程式碼審查、自動測試失敗修復、bug 排查、維護，以及從任務執行到提交 PR 的完整流程。
Uber Engineering 在 2026 年 8 月公布，超過 70％ 的 pull requests（PR，也就是提交給團隊檢查與合併的程式變更）可歸因於本機或雲端 Agent。工程師已建立超過 3,600 個 Agent skills，每天執行超過 30,000 次。
但這不代表 70％ 的程式碼都由 AI 自動完成，也不代表工程師只要下 Prompt 就能交付。Uber 原文使用的是「attributed to agents」，範圍可能包含 Agent 參與開發、修改或處理流程的 PR，最後仍有人工 review 與必要的升級處理。
比 70％ 這個比例更值得研究的，是 Uber 如何在使用量快速增加時，避免 AI 成本跟著失控。我的結論是，Uber 已經把 AI coding 從單一工具，推進成一條需要評測、計價、監控與持續改善的軟體生產線。
Uber 的 Software Factory 是什麼？
Software Factory 直譯是「軟體工廠」。放在 Uber 的情境中，它並非獨立產品，而是一套管理 AI Agent 開發工作的工程系統。
有些 Agent 直接與工程師互動，有些則由系統自動啟動，處理 code review、修復 CI 失敗、驗證畫面、分類 on-call 警示、除錯與例行維護。CI 是程式提交後自動執行測試與檢查的流程。當檢查失敗時，Agent 可以先找出原因並嘗試修正，再交由人員確認。
Uber 表示，2026 年 2 月至 8 月，全公司使用各類 Agent 產品的每週活躍使用者成長 7 倍，每週 Agent 請求量成長 9.4 倍。總 AI 支出自 4 月起則相對穩定。在固定同一個模型的比較下，每 1,000 次模型請求成本較高峰降低近 34％，每次 session 成本也較 6 月高峰降低 52％。
這些是 Uber 內部環境的結果，不能直接套用到每家公司。codebase 規模、工作種類、模型合約與 Agent 流程不同，節省幅度也會不同。不過，它至少證明一件事：Agent 使用量增加，不必然等於成本等比例增加，前提是團隊能看見成本到底花在哪裡。
Uber 工程團隊在 AI Engineer 2026 分享 Agentic SDLC 與 Software Factory。影片來源：AI Engineer 官方 YouTube 頻道，並由 Uber Engineering 原文直接引用。
控制 AI Agent 成本，不能只看每個 token 多便宜
Token 是模型處理文字與程式碼時使用的計費單位。很多團隊談 AI 成本，只比較不同模型每百萬 token 的價格，但 Uber 把總支出拆成六個相乘的變數：
總支出＝使用者數 × 每人 session 數 × 每個 session 的 turn 數 × 每個 turn 的 request 數 × 每個 request 的 token 數 × 每 token 價格
Session 可以理解成一次完整工作階段，turn 是使用者或 Agent 推進任務的一輪，request 則是實際送給模型的一次請求。
這個公式的重點，是把「大家用得更多」和「每次工作變得更浪費」分開。使用者與 session 增加，通常代表採用率上升，不該一開始就壓低。真正需要優化的，是 Agent 是否反覆嘗試、每輪是否呼叫太多次模型、每次是否攜帶過量 context，以及任務是否交給價格過高的模型。
更重要的是，成本不能只用 token 衡量。Uber 也追蹤每個合併 PR、每次 code review、每個警示處理的成本，同時觀察變更被撤回的比例、F1 與 MTTR。F1 是綜合衡量找得準不準、漏得多不多的指標。MTTR 則是事件平均修復時間。
換句話說，一個模型即使單價較低，只要經常答錯、需要重跑或增加人工修改，最後的每項成果成本仍可能更高。對產品團隊來說，這比單純要求「每次少用 20％ token」更接近真正的投資報酬（ROI）。
第一個槓桿：依工作選模型，不讓最強模型包辦全部任務
Uber 不用單一模型處理所有 Agent 工作，而是為不同任務建立真實 benchmark。Benchmark 是一套固定測試，用來比較模型在同類工作上的品質、成本、速度與穩定性。
以 AI code review 工具 uReview 為例，Uber 從真實 PR 整理已知 bug，再依難度分類，同時測量找到多少正確問題、漏掉多少 bug、F1、每次 review 成本、延遲、執行逾時與無效提醒。團隊會選擇位在 Pareto frontier 的方案，也就是在目前候選中，沒有另一個模型能同時做到更便宜又更好。
這也延伸到多 Agent 分工。主要模型負責拆解任務與驗收，範圍明確的子任務則預設交給成本較低的模型，必要時仍可人工覆寫。
我認為這是 Uber 方法中最容易被中小團隊採用的一項。你不需要先做自動路由平台，只要挑一項每週重複出現的任務，用 10～20 個真實案例比較成功率、人工修正時間與單次成本，就能判斷較便宜的模型是否真的夠用。
第二個槓桿：減少 Agent 每一輪都要重新攜帶的 context
Context 是模型在當下能看到的對話、程式碼、工具說明與參考資料。問題不只是 context 越長越貴，還包括無關資訊會稀釋真正重要的規則。
Uber 提到，當環境安裝超過 100 個 MCP 工具時，預先載入所有工具 schema，可能在 session 一開始增加約 50K～70K token。MCP 全名是 Model Context Protocol，可以讓 AI 用共同格式連接資料與工具。Schema 則是每個工具的功能與參數說明。
Uber 沒有停用 MCP，而是把超過 1,000 個內部與第三方 MCP 服務放在統一 gateway 後方，需要時再透過 CLI 或 tool search 找出工具。CLI 是用指令呼叫功能的介面，tool search 則讓 Agent 先搜尋工具目錄，只載入當前任務需要的項目。
另一個做法是 code-mode。若一個資料查詢需要送出請求、輪詢狀態、再取得結果，傳統流程可能讓模型參與每一步，所有中間回應也會留在 context。改由程式在背景完成輪詢，只把最後摘要交回模型，就能同時減少模型回合與重複資料。
這裡的產品原則很直接：不要因為 Agent「可能會用到」，就把所有工具、文件與歷史紀錄在啟動時全部塞進去。先提供工具目錄與最小必要背景，再依任務載入完整內容，通常更省錢，也更容易維護。
第三個槓桿：先解決 Agent 找不到公司知識的問題
Agent 浪費成本的常見原因，往往是它不知道正確資料放在哪裡，而非缺少寫程式的能力。它會搜尋更多檔案、啟動更多子 Agent、重試更多工具，context 也在過程中持續膨脹。
Uber 為此建立 AI Context Graph，把服務、團隊、事件紀錄、PR、架構文件、部署與資料表等資訊連成可查詢的知識網路。官方公布的規模是 2,400 萬個節點、8,000 萬條關係，資料來自超過 30 個內部系統。
在 Uber 展示的同一題測試中，有圖譜支援的 Agent 用 38 秒找到正確資料表。沒有圖譜時，同一模型花了約 20 分鐘、啟動 2 個子 Agent、遇到 3 次錯誤，最後仍得到錯誤結論。
這是 Uber 自己挑選並公布的內部案例，不是第三方 benchmark，不能推論每項任務都會有相同差距。但它揭露的瓶頸很真實：當 Agent 不知道公司內部的「正確答案通常在哪裡」，增加模型能力只會讓它更有能力四處搜尋。
小團隊也不需要一開始建立數千萬節點的知識圖譜。先整理每項服務的負責人、常用資料表、正式 API 文件、部署位置與故障處理手冊，並提供穩定的搜尋入口，就已經能處理最常見的 context 缺口。API 是讓不同軟體依固定規格交換資料或呼叫功能的介面。
第四個槓桿：讓工程師即時看到成本，而不是月底才收到帳單
Uber 把當前 session 與各工具的成本直接顯示在開發環境狀態列，並在使用量達到預期額度的 50％、80％ 與 100％ 時發出提醒。團隊沒有對每個工具設死上限，而是提供共用額度、調升流程與成本分析。
Uber 的 session dashboard 還會檢查 16 類浪費模式，例如簡單任務使用過強模型、過大的工具回應長期留在 context、提示詞快取過期後重新載入，以及使用者尚未輸入要求前就先載入大量全域規則。提示詞快取是暫存重複 context、避免每一輪都按完整價格處理的機制。
這種做法比直接限制使用更成熟。若工程師只知道「這個月超支」，很難判斷該少用 Agent，還是該修正模型路由、工具回傳與 context 設計。把成本放到 session 與成果層級，才能找到真正可以改善的地方。
一般產品與工程團隊怎麼做？先從一項任務建立 MVP
Uber 的完整 Software Factory 包含 benchmark、model routing、MCP gateway、context graph 與成本 dashboard。對多數團隊來說，一次複製整套只會先增加平台維護成本。
更實際的 MVP 可以分成四步：
- 選一項高頻且容易驗收的任務，例如 PR review、測試失敗分類或 API 文件更新。
- 記錄目前的完成時間、成功率、人工修正時間、模型費用與錯誤類型。
- 只改一個槓桿，例如模型、context、工具載入方式或知識來源，再用同一批案例重跑。
- 以每個通過驗收的成果比較前後差異，而不是只看 token 或執行次數。
如果第一輪就同時導入多 Agent、知識圖譜與自動模型路由，成果變好或變差時都很難找出原因。先把一條工作流量清楚，再逐步擴充，速度通常更快，長期也更容易維護。
安全界線也不能因為自動化而消失。Agent 可以先處理低風險、可回復、容易驗證的工作。正式環境寫入、權限變更與重要資料刪除，仍應保留明確核准、最小權限與操作紀錄。
Uber 案例真正代表什麼？
Uber 的案例不能解讀成「工程師已被 AI 取代」。它反映的是另一個變化：軟體開發正在從個人使用 AI 助手，進入組織管理 Agent 工作負載的階段。
我的判斷是中性偏多。Software Factory 的方向值得採用，因為它要求每個 Agent 都有可衡量的成果、品質與成本，而不是只用使用人數或生成程式碼量證明成功。不過，Uber 的節省數字依賴自家 codebase、工具與內部知識，其他團隊不應把 34％ 或 52％ 當成導入保證。
真正會推翻這個正面判斷的，是 Agent 雖然消耗更少 token，卻增加更多人工 review、維護、安全與錯誤修復成本。因此，「用了多少 AI」只能算使用指標。每一個通過驗收的成果究竟花了多少總成本，才是團隊最該追蹤的結果。
若要開始，先挑一項每週至少重複數次的工作，建立 10～20 個真實案例。當同一套流程能穩定提高成功率、縮短交付時間，而且沒有把成本轉移給人工 review，才值得擴充成更完整的 Agent 平台。
Uber AI Agent 常見問題
Uber 有 70％ 的程式碼都是 AI 寫的嗎？
不能這樣解讀。Uber 的原文是超過 70％ PR「可歸因於」本機或雲端 Agent，代表 Agent 參與了相關變更或流程，不等於 70％ 程式碼完全由 AI 獨立生成。官方也明確提到人工 review 與必要時的升級處理。
Software Factory 是 Uber 對外販售的產品嗎？
不是。這是 Uber 用來描述內部 AI 軟體開發系統與管理方法的概念，包含 Agent、評測、模型選擇、工具、context、成本與品質監控。
控制 AI Agent 成本，只要改用較便宜的模型嗎？
不夠。便宜模型若需要更多重試或人工修正，最後的成果成本可能更高。Uber 同時優化模型選擇、每次請求的 token、每輪請求數、工具載入、知識來源與成本可視性。
小團隊需要先做 MCP gateway 或知識圖譜嗎？
通常不需要。先選一項高頻任務，建立成功率、人工時間與費用基準，再處理最明顯的瓶頸。只有在工具 schema 或內部知識查找已經成為主要成本時，才值得投入 gateway 或圖譜。
如何判斷 AI coding Agent 真的有 ROI？
用每個通過驗收的成果衡量，例如每個合併 PR、每次有效 review 或每個修復事件的總成本。模型費用、人工修正時間、錯誤率、revert 與維護成本都要一起計算。
