Uber 軟體工廠如何運作？拆解代理架構與五項降本技術

AI Agent 的成本，很容易被理解成「用了哪個模型、每百萬 token 多少錢」。但一個代理完成任務之前，可能反覆找文件、等待工具回應、重讀對話，最後還要有人處理錯誤。模型牌價只解釋其中一部分。

Uber 在 2026 年 8 月發布的軟體工廠案例，值得企業技術主管注意的地方，是將這些消耗拆成可以量測、比較與改善的工程項目。前篇討論企業擴大 AI 投入的決策，本文進一步回答：它如何建模、技術為何能省錢，以及外部研究能支持到什麼程度。Uber 原文

本文的判斷是：Uber 的方法可理解為一套以任務成果為目標的成本工程框架。學術研究與雲端業者資料支持其中多項機制；公開資訊目前最能證明的是技術單位成本改善，尚不足以算出整體研發投資報酬率。

建模框架：將代理分層，再把成本連回成果

這篇案例所描述的「建模」，核心是使用情境、成本與品質的關係。原文沒有將它定義成某個新訓練出的神經網路，也沒有交代一套可直接安裝的通用開發框架。

Uber 圖 3 將代理使用分成四層。下表保留其分類，右欄說明對成本分析的用途。Uber 架構圖與說明

分層的分析價值，在於讓比較單位更清楚。如果一次對話同時混合除錯、寫文件和查資料，「每次對話變便宜」很難解讀。把程式碼審查獨立成任務，就能追問：在相同難度下，每次審查花多少錢、找出多少問題，又產生多少誤報？

因此，專用代理的優勢來自任務邊界、可重複評測與集中管理。把工作搬上雲端本身，並不會自動產生這些效益；仍需要可驗收的輸出與成本紀錄。

成本公式：找出錢花在哪一段

Uber 將總支出拆成六個乘數：

總支出＝使用者數 × 每人工作階段數 × 每階段回合數 × 每回合請求數 × 每請求 token 數 × 每 token 成本。 Uber 成本公式

這個公式可以用來回答不同問題：費用增加是更多人使用、每人做更多工作，還是代理為了同一件事多繞了幾圈？如果支出主要來自重複輸入資料，換模型之外，還有上下文與工具流程可以改善。

從數學上看，若所有數字取自同一期間、同一組紀錄，且平均值使用相鄰總量的比值，這是一個會逐項約掉的帳務恆等式。例如「總工作階段數／總使用者數」與前項相乘，就回到總工作階段數。它本身不需要訓練，也沒有證明哪個因素造成成本變化。

兩個實作細節尤其重要。第一，不能直接將不同團隊各自平均後的數字相乘，否則工作量權重可能不一致。第二，輸入、輸出、快取寫入和快取讀取價格不同；末項應使用實際加權成本，或直接按模型與計價類別逐筆加總。

以下是本刊建議的實作口徑：

模型費用＝Σ〔未快取輸入費＋快取寫入費＋快取讀取費＋輸出費〕。

再將工具、執行環境、審查、失敗重試及平台維運納入，才能算：

每件合格成果成本＝該類任務的完整成本／驗收合格件數。

例如兩種配置都執行 100 件同類工作：A 花 100 元、成功 50 件；B 花 120 元、成功 80 件。A 每次嘗試較便宜，但每件成功成果為 2 元，B 為 1.5 元。這是說明衡量方式的假設示例，不是 Uber 數據。

模型選擇：用品質與成本共同決定

Uber 以真實任務建立評測，尋找成本、品質與可靠性之間的 Pareto 有效率配置；uReview 是其程式碼審查案例。Uber 模型評選方法

原文關鍵短句：“cost/completed task, output quality, and model reliability.”

意譯：每件完成任務的成本、輸出品質與模型可靠性。

Pareto 的意思是，若另一個配置成本更低、品質與可靠性都不差，原配置就缺乏選用理由。但當高品質配置也更貴時，仍需要企業設定可接受的品質門檻；不存在脫離任務需求的唯一最佳模型。

本刊建議把選擇問題寫成：在品質、成功率與延遲達標的配置中，選擇每件合格成果成本最低者。「配置」應涵蓋模型、提示、工具、上下文和推理設定，因為這些因素會共同改變結果。

這種共同評估有直接的學術支持。Princeton 研究者的《AI Agents That Matter》指出，只追求準確率容易獎勵昂貴而複雜的代理，主張同時最佳化成本與準確率，並保留適當的測試資料，避免代理只對評測題有效。論文與研究摘要

這是對方法的支持，不能據此聲稱 Uber 採用了該論文的演算法。

五項降本技術，各自省下什麼？

1. 依任務選模型，讓算力配置有依據

對企業而言，可以先為不同任務指定模型，再評估是否需要對每次請求動態選模。前者容易追蹤；後者還要驗證路由器是否選對，以及額外延遲是否值得。

RouteLLM 提供了動態選模的研究證據。它利用偏好資料訓練路由器，選擇較強或較弱模型。論文 v4 的 Table 6 顯示，在 MT Bench 的一個設定下，可保留 GPT-4 約 95% 的評測分數，估算成本約為全用 GPT-4 的 1／3.66，換算約低 72.7%。這使用論文當時的價格與短提示、單回合假設；其他測試集的效益不同，不能當成所有任務的降幅。RouteLLM，2025 年修訂版

AWS 則將相關做法產品化。其 Amazon Bedrock Intelligent Prompt Routing 頁面宣稱，在適用情境下可降低最多 30% 成本而不犧牲準確率。這是供應商的產品效益宣稱，並非跨企業的平均實測結果。AWS 成本最佳化說明

這兩份資料支持「模型選擇可以成為可量測的最佳化問題」。但 RouteLLM 的分數保留率不等於品質完全不變，單次問答路由也不等於能直接處理長時間、多步驟的程式開發任務。

2. Prompt Caching：重用相同前綴的計算

多回合任務往往重複包含相同文件與歷史。Prompt Caching 重用這部分輸入的計算結果，降低再次處理的成本；它與直接回傳舊答案的「答案快取」不同。Google Cloud 的說明明確提到重用先前請求的 KV 狀態。Google Cloud 技術說明

Uber 的案例依互動節奏選擇快取存活時間：主互動工作階段使用較長 TTL，短任務子代理使用較短 TTL。Uber 快取策略

以 Anthropic 文件中仍採用的標準倍率為例，5 分鐘寫入是一般輸入價的 1.25 倍，1 小時寫入為 2 倍，命中讀取為 0.1 倍；實際倍率須核對模型，文件也列有例外。Anthropic 計價文件

以下試算只計算一段完全相同、符合快取條件的前綴。假設一般讀取費為 B，在第 0、10、20、30、40 分鐘各使用一次，忽略新增內容與輸出費：

在此假設下，1 小時策略比 5 分鐘策略低 61.6%，比不用快取低 52%。若五次請求在很短時間內完成，5 分鐘策略只需 1.65B，反而更便宜。要最佳化的是命中與重建的實際費用，不能只追求更長 TTL。

Google Cloud 也公布，適用 Gemini 模型的快取輸入費用減少 90%，但顯式快取另有儲存時間費。這支持重用輸入可降低費用，也提醒企業：這項減免作用在符合條件的快取 token，不是整張帳單。Google Cloud 費用說明

3. 工具按需載入：縮小每次推理的負擔

工具定義包含用途、參數與格式。若任務只需要查一個資料表，卻預先帶入大量其他系統的說明，這些內容就會占用上下文。

Uber 採用工具搜尋與 CLI 動態解析，減少預載工具定義。Uber 工具存取方法

Anthropic 的 Tool Search 實作同樣採取按需發現與載入。其內部 MCP 評測中，Opus 4.5 的準確率由 79.5% 提高至 88.1%。這說明在該測試條件下，減少同時提供的工具不僅能控制上下文，也可能改善選用工具的品質。Anthropic 工具搜尋評測

需要辨別的是，節省來自提供資訊的方式，而不是單純把介面名稱從 MCP 改成 CLI。若 CLI 仍一次輸出所有說明或大量原始結果，模型依然要處理它們。工具數很少時，多一道搜尋還可能增加等待時間。

4. Code-mode：讓程式處理輪詢與資料整理

查詢資料庫常包含提交工作、等待完成、取回資料與整理結果。這些步驟若每次都回到模型，就會產生多輪推理與更多上下文。

Uber 將這類操作合併到程式執行；其前三項小結果 SQL 測試，token 用量分別下降 55%、58%、71%。這些是特定查詢路徑的測量。Uber Code-mode 測試

可以用下面的流程理解其作用：

模型決定要查什麼 → 程式提交、輪詢、檢查錯誤及整理 → 模型讀取必要結果並解釋。

Anthropic 的 Programmatic Tool Calling 也有同方向結果：其複雜研究任務平均由 43,588 降至 27,297 tokens，約減少 37%。原文將效果連到中間結果不再逐一進入模型上下文。Anthropic 程式化工具呼叫數據

這類改寫保留模型對語意的判斷，把規則明確的迴圈與資料處理交給程式。實作時應保留查詢識別碼、錯誤與必要證據，讓摘要可追溯；否則表面省下 token，可能增加後續除錯成本。

5. 結構化上下文：降低搜尋與重新探索

企業資訊不只有文字內容，還有「誰維護哪個服務」「哪個資料表被哪些查詢使用」等關係。若每次任務都要重新從文件與程式碼推測關係，就可能花費大量探索步驟。

Uber 的 AI Context Graph 整合內部關係資料。其展示的一個問題，使用圖譜後在 38 秒內正確完成；未使用圖譜的路徑花了約 20 分鐘仍答錯。這是一個對照案例。Uber 上下文案例

Microsoft Research 的 GraphRAG 提供相關研究證據：在新聞與 podcast 資料集的全局問答評測中，社群摘要相對一般向量 RAG，在完整性與多樣性上的勝率約為 70%–80%；以最高層摘要作答時，查詢 token 約為分層原文摘要基準的 2%–3%。評判使用 LLM judge，這些數字不是程式開發任務的正確率。Microsoft GraphRAG 評測

Microsoft 的研究支持先整理關係、再提供相關資訊的方向，但不能據此認定 Uber 採用 Microsoft GraphRAG。 兩者資料來源、查詢任務與實作可以不同；查詢階段省下的 token，也要和建立、更新索引的成本一起評估。

另一項相關研究《Lost in the Middle》發現，在其測試模型與任務中，關鍵資訊位於長上下文中間時，表現可能下降。它支持「更多上下文不一定帶來更好結果」的判斷，不能用來證明任何 2026 年模型的最佳上下文上限。TACL 論文

配套：預設設定與成本回饋

Uber 還將互動工具的上下文自動壓縮門檻設為 400K tokens，推理強度預設為 Medium，並提供即時費用與工作階段分析。Uber 設定與量測

這些設定分別控制重複輸入、推理輸出與發現浪費所需的時間。400K 和 Medium 是案例中的工程選擇，不能視為研究證明的通用最佳值；壓縮也可能丟失資訊，必須檢查後續重查與返工。

此外，原文仍將擴大動態模型路由列為後續工作。因此，已落實的任務評測與選模，應與持續開發的逐請求動態路由區分。Uber 後續規劃

支持這套框架的證據，強到什麼程度？

把上述資料合在一起，可以得到三種不同層次的支持。

學術方法支持：《AI Agents That Matter》支持成本與品質共同評估；RouteLLM 證明路由器能在特定基準下改善成本與品質取捨。這些研究有實驗設定，移植到企業仍須重新評測。

供應商機制與測試支持： AWS、Google Cloud 和 Anthropic 的資料證明，模型路由、快取、按需載入與程式化工具呼叫，都有實際產品或測試依據。但折扣、上限宣稱、內部測試平均值，代表的證據強度不同。

企業營運觀察： Uber 公開的趨勢顯示，多項改善導入期間，單位成本下降。要再回答「到底哪項技術貢獻最多」，需要各項配置的獨立比較；公開文章沒有提供足以完成這種因果歸因的實驗資料。

因此，不能把 AWS 的 30%、快取的 90%、Anthropic 的 37% 與 Uber 的降幅相加。它們來自不同資料、不同分母，也可能節省同一批消耗。

最後的結果：使用擴大，技術單位成本降低

Uber 公布的主要結果如下。這些是其內部觀測，應連同比較基準閱讀。Uber 採用與成本結果

品質方面，Uber 也表示 uReview 換模後，F1 提高且每次審查成本下降；這提供單一任務的品質與成本改善證據，仍不足以代表所有代理工作。Uber uReview 結果

固定模型能減少模型更換帶來的干擾，但任務組合、難度與使用者行為仍可能變動。要驗證整體效益，還需要同類任務的成功率、人工審查與返工時間，以及平台投入等資料。

對企業而言，最有用的起點，是選一種高頻、可驗收的任務，記錄成功與失敗嘗試的完整成本；再從軌跡找出最大消耗，逐項比較模型、快取、工具載入或上下文配置。

每次改動都應回答同一個問題：在品質達標的前提下，是否用更少的完整成本，交付了一件可用成果？ 這會比直接照搬 Uber 的參數或降幅，更接近這套框架的實際價值。

查核日期：2026 年 9 月 9 日。文中的成本試算、實作口徑與企業適用性判斷為 AI2B 編輯分析；引述的研究與供應商結果保留各自的比較條件。

延伸閱讀：前篇：CTO 該何時加碼 AI Agent？從 Uber 案例看五個投資決策。