> ## Content Index
> Fetch the complete content index at: https://www.ai2b.tech/llms.txt
> Use this file to discover other available public pages before exploring further.

# Uber 軟體工廠如何運作？拆解代理架構與五項降本技術
- URL: https://www.ai2b.tech/uber-ai-agent-cost-framework-technology/
- Published: 2026-09-10T08:35:10.000Z
- Updated: 2026-09-10T10:23:54.000Z
- Description: 拆解 Uber 的四層代理架構、成本公式與降本技術，交叉核對 RouteLLM、AWS、Google Cloud、Microsoft Research 的證據，釐清單位成本下降與整體研發效益的差別。
- Author: Gary 
- Tags: AI Agent

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

Uber 在 2026 年 8 月發布的軟體工廠案例，值得企業技術主管注意的地方，是將這些消耗拆成可以量測、比較與改善的工程項目。前篇討論企業擴大 AI 投入的決策，本文進一步回答：它如何建模、技術為何能省錢，以及外部研究能支持到什麼程度。[Uber 原文](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech)

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

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

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

Uber 圖 3 將代理使用分成四層。下表保留其分類，右欄說明對成本分析的用途。[Uber 架構圖與說明](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Four%20Layers%20of%20Agent%20Usage)

| 使用層級                           | 運作方式            | 成本分析的用途                 |
| ------------------------------ | --------------- | ----------------------- |
| Raw Sessions：一般互動工作階段          | 使用者提供上下文與操作引導   | 先掌握每次工作階段的費用，但任務邊界可能不清楚 |
| Sessions with Skills：使用技能的工作階段 | 在本機套用可重用的技能     | 可以比較同類操作的流程差異           |
| General Agents：通用代理            | 在 Uber 雲端執行互動任務 | 執行環境集中，便於統一設定與追蹤        |
| Specialized Agents：專用代理        | 針對特定工作執行，保留人工介入 | 可將成本對應到審查、合併程式碼等明確成果    |

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

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

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

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

**總支出＝使用者數 × 每人工作階段數 × 每階段回合數 × 每回合請求數 × 每請求 token 數 × 每 token 成本。** [Uber 成本公式](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=The%20Cost%20Equation)

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

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

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

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

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

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

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

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

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

Uber 以真實任務建立評測，尋找成本、品質與可靠性之間的 Pareto 有效率配置；uReview 是其程式碼審查案例。[Uber 模型評選方法](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Benchmark-Driven%20Model%20Selection)

> 原文關鍵短句：“cost/completed task, output quality, and model reliability.”
> 
> 意譯：每件完成任務的成本、輸出品質與模型可靠性。

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

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

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

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

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

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

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

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

AWS 則將相關做法產品化。其 Amazon Bedrock Intelligent Prompt Routing 頁面宣稱，在適用情境下可降低最多 30% 成本而不犧牲準確率。這是供應商的產品效益宣稱，並非跨企業的平均實測結果。[AWS 成本最佳化說明](https://aws.amazon.com/bedrock/cost-optimization/?ref=ai2b.tech)

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

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

多回合任務往往重複包含相同文件與歷史。Prompt Caching 重用這部分輸入的計算結果，降低再次處理的成本；它與直接回傳舊答案的「答案快取」不同。Google Cloud 的說明明確提到重用先前請求的 KV 狀態。[Google Cloud 技術說明](https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-context-caching?ref=ai2b.tech)

Uber 的案例依互動節奏選擇快取存活時間：主互動工作階段使用較長 TTL，短任務子代理使用較短 TTL。[Uber 快取策略](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Prompt%20Caching%20Strategy)

以 Anthropic 文件中仍採用的標準倍率為例，5 分鐘寫入是一般輸入價的 1.25 倍，1 小時寫入為 2 倍，命中讀取為 0.1 倍；實際倍率須核對模型，文件也列有例外。[Anthropic 計價文件](https://platform.claude.com/docs/en/build-with-claude/prompt-caching?ref=ai2b.tech#pricing)

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

| 策略     | 前綴費用計算               | 合計    |
| ------ | -------------------- | ----- |
| 不用快取   | 5 次一般輸入              | 5B    |
| 5 分鐘快取 | 每次都已過期，重新寫入          | 6.25B |
| 1 小時快取 | 首次寫入 2B，後續 4 次各 0.1B | 2.4B  |

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

Google Cloud 也公布，適用 Gemini 模型的快取輸入費用減少 90%，但顯式快取另有儲存時間費。這支持重用輸入可降低費用，也提醒企業：這項減免作用在符合條件的快取 token，不是整張帳單。[Google Cloud 費用說明](https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-context-caching?ref=ai2b.tech#:~:text=Cost%20implications%20for%20implicit%20and%20explicit%20caching)

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

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

Uber 採用工具搜尋與 CLI 動態解析，減少預載工具定義。[Uber 工具存取方法](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Executing%20MCP%20Tools%20via%20the%20Shell)

Anthropic 的 Tool Search 實作同樣採取按需發現與載入。其內部 MCP 評測中，Opus 4.5 的準確率由 79.5% 提高至 88.1%。這說明在該測試條件下，減少同時提供的工具不僅能控制上下文，也可能改善選用工具的品質。[Anthropic 工具搜尋評測](https://www.anthropic.com/engineering/advanced-tool-use?ref=ai2b.tech#:~:text=79.5%25)

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

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

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

Uber 將這類操作合併到程式執行；其前三項小結果 SQL 測試，token 用量分別下降 55%、58%、71%。這些是特定查詢路徑的測量。[Uber Code-mode 測試](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Code-Mode)

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

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

Anthropic 的 Programmatic Tool Calling 也有同方向結果：其複雜研究任務平均由 43,588 降至 27,297 tokens，約減少 37%。原文將效果連到中間結果不再逐一進入模型上下文。[Anthropic 程式化工具呼叫數據](https://www.anthropic.com/engineering/advanced-tool-use?ref=ai2b.tech#:~:text=43%2C588)

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

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

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

Uber 的 AI Context Graph 整合內部關係資料。其展示的一個問題，使用圖譜後在 38 秒內正確完成；未使用圖譜的路徑花了約 20 分鐘仍答錯。這是一個對照案例。[Uber 上下文案例](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Context%20Engineering)

Microsoft Research 的 GraphRAG 提供相關研究證據：在新聞與 podcast 資料集的全局問答評測中，社群摘要相對一般向量 RAG，在完整性與多樣性上的勝率約為 70%–80%；以最高層摘要作答時，查詢 token 約為分層原文摘要基準的 2%–3%。評判使用 LLM judge，這些數字不是程式開發任務的正確率。[Microsoft GraphRAG 評測](https://www.microsoft.com/en-us/research/blog/graphrag-new-tool-for-complex-data-discovery-now-on-github/?ref=ai2b.tech#:~:text=Evaluation%20and%20results)

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

另一項相關研究《Lost in the Middle》發現，在其測試模型與任務中，關鍵資訊位於長上下文中間時，表現可能下降。它支持「更多上下文不一定帶來更好結果」的判斷，不能用來證明任何 2026 年模型的最佳上下文上限。[TACL 論文](https://aclanthology.org/2024.tacl-1.9/?ref=ai2b.tech)

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

Uber 還將互動工具的上下文自動壓縮門檻設為 400K tokens，推理強度預設為 Medium，並提供即時費用與工作階段分析。[Uber 設定與量測](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Automatic%20compaction)

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

此外，原文仍將擴大動態模型路由列為後續工作。因此，已落實的任務評測與選模，應與持續開發的逐請求動態路由區分。[Uber 後續規劃](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=What%E2%80%99s%20Next%3F)

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

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

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

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

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

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

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

Uber 公布的主要結果如下。這些是其內部觀測，應連同比較基準閱讀。[Uber 採用與成本結果](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=Introduction)

| 指標        | 公布結果                  | 正確的解讀範圍               |
| --------- | --------------------- | --------------------- |
| 週活躍使用者    | 2026 年 2 月至 8 月增至 7 倍 | 採用規模擴大                |
| 每週代理請求    | 同期增至 9.4 倍            | 請求量擴大，不等於交付量同步增加      |
| AI 總支出    | 自 4 月起相對穩定            | 不代表整段期間總支出下降          |
| 每千次模型請求成本 | 固定同一模型，較高峰下降近 34%     | 技術單位成本改善              |
| 每個工作階段成本  | 固定同一模型，較 6 月高峰下降 52%  | 工作階段變便宜，不等於每件合格成果同比下降 |

品質方面，Uber 也表示 uReview 換模後，F1 提高且每次審查成本下降；這提供單一任務的品質與成本改善證據，仍不足以代表所有代理工作。[Uber uReview 結果](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech#:~:text=switching%20models%20improved%20our%20F1)

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

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

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

---

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

延伸閱讀：[前篇：CTO 該何時加碼 AI Agent？從 Uber 案例看五個投資決策](https://www.ai2b.tech/uber-software-factory-ai-agent-cost/)。