> ## 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.

# CTO 該何時加碼 AI Agent？從 Uber 案例看五個投資決策
- URL: https://www.ai2b.tech/uber-software-factory-ai-agent-cost/
- Published: 2026-09-09T10:25:22.000Z
- Updated: 2026-09-10T10:21:51.000Z
- Description: 從 Uber 軟體工廠案例，拆解 CTO 擴大 AI Agent 投入前的五個決策：成果成本、模型評測、流程改善、平台投資與擴張門檻，附 90 天試點決策表。
- Author: Gary 
- Tags: AI Agent, 企業 AI, AI 成本管理

AI 開發工具的使用率上升，下季預算卻不一定該跟著增加。對 CTO 與工程主管而言，真正需要回答的是：多花一筆錢，能否帶來更多合格交付？還是把時間與成本轉移到審查、返工和平台維運？

Uber 於 2026 年 8 月 27 日發布的軟體工廠案例，提供了觀察 AI Agent 成本的切入點。AI2B 的編輯判斷是：**先建立成果與完整成本的對照，再決定要增加工具預算、改善流程，或投資共用平台。**

本文適合已導入 AI 開發工具、正在評估擴大投入的 CTO 與工程主管。關鍵原文短句與中文意譯直接列於相關段落，完整來源集中於文末；企業適用條件、試算與決策表均為 AI2B 編輯分析。

## Uber 的 AI 成本下降，數字代表什麼？

Uber 表示，2026 年 2 月至 8 月，代理工具週活躍使用者增至 7 倍、每週請求增至 9.4 倍，AI 總支出自 4 月起相對穩定。固定同一模型比較，每千次請求成本較高峰下降近 34%，每個工作階段成本較 6 月高峰下降 52%。這些是內部觀測，不能解讀為整體研發成本或人力減半。（資料來源：Uber Engineering，2026 年 8 月 27 日；原圖見下。）

[![Uber 原文圖表：2026 年 2 月至 8 月的週活躍使用者、代理請求與費用趨勢](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9kZGExMDZkMy0wNDM5LTQyN2ItYjc4MC1jMzk5ZGM4NWM3YzgucG5n)](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9kZGExMDZkMy0wNDM5LTQyN2ItYjc4MC1jMzk5ZGM4NWM3YzgucG5n?ref=ai2b.tech)

*圖 1｜週活躍使用者、代理請求與費用趨勢。來源：Uber Engineering，原文 Figure 1。 [開啟大圖](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9kZGExMDZkMy0wNDM5LTQyN2ItYjc4MC1jMzk5ZGM4NWM3YzgucG5n?ref=ai2b.tech)*

[![Uber 原文圖表：固定模型下，每千次請求與每個工作階段的成本變化](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9iMjVkMTc1Zi04MjFiLTRiYTYtYTE0OS0xNGU1Yzk1YTI1Y2IucG5n)](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9iMjVkMTc1Zi04MjFiLTRiYTYtYTE0OS0xNGU1Yzk1YTI1Y2IucG5n?ref=ai2b.tech)

*圖 2｜固定模型下的單位成本變化；工作階段資料自五月底開始。來源：Uber Engineering，原文 Figure 2。 [開啟大圖](https://cn-geo1.uber.com/image-proc/resize/udam/format%3Dauto/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9iMjVkMTc1Zi04MjFiLTRiYTYtYTE0OS0xNGU1Yzk1YTI1Y2IucG5n?ref=ai2b.tech)*

讀這兩張圖時，要區分使用規模、技術單位成本與業務成果。一次工作階段可能完成任務，也可能失敗；每件工作的難度也不同。即使每次請求變便宜，仍需要驗收資料，才能判斷每件合格成果是否更划算。

以下五個決策，把案例轉成企業預算會議可以追問的問題。

## 決策一：AI ROI 要用什麼成果衡量？

FinOps Foundation 的單位經濟框架區分資源效率與業務成果：前者看資源如何使用，後者把費用連到可辨識的產出。

> **FinOps 原文摘錄｜把支出連到價值**
> 
> “Unit Economics brings together what an organization spends on technology and the value that technology spending creates.”
> 
> 中文意譯：單位經濟將組織的技術支出，與這些支出創造的價值連結起來。

**本刊建議，先選一類可比較的工作，以「每件驗收合格成果的總成本」作為擴張指標之一。** 例如同一服務的測試補齊任務，先固定驗收條件，再比較不同流程；不要把文件整理和跨系統故障修復混在同一個平均數裡。

成本分子應包含該類工作的成功與失敗嘗試，以及模型、工具、執行環境、人工審查、返工和合理分攤的維運費。既有流程與 AI 流程都要計入直接執行工時，並採相同口徑，避免只對其中一方多算成本。

**誰負責：** 工程主管定義合格成果，財務確認工時與平台費用的計入方式。若兩者尚未對齊，應先補基準資料，再討論擴大採購。

### 一個假設試算：技術帳單增加，仍可能值得投入

以下為兩種 AI 輔助流程的月度示例，並非 Uber 數據。假設同類任務、驗收標準與工時估值一致，人工費已涵蓋直接執行、審查和返工。

| 成本與成果      | 流程 A       | 流程 B       |
| ---------- | ---------- | ---------- |
| AI、工具與執行環境 | NT$30,000  | NT$45,000  |
| 人工執行、審查與返工 | NT$70,000  | NT$35,000  |
| 分攤平台維運     | NT$20,000  | NT$20,000  |
| 總成本        | NT$120,000 | NT$100,000 |
| 驗收合格成果     | 200 件      | 250 件      |
| 每件合格成果成本   | NT$600     | NT$400     |

流程 B 的單位成本較低，但若實際只能用掉 100 件成果、固定投入又降不下來，擴張理由就會改變。工時釋出也要追蹤去向：增加交付、縮短積壓，或減少實際支出，應分開報告，避免重複認列效益。

## 決策二：先換模型，還是先建立任務評測？

Uber 以真實工作建立評測；程式碼審查代理 uReview 同時比較品質、每次審查成本與延遲等指標。

> **Uber 原文摘錄｜模型評選標準**
> 
> “cost/completed task, output quality, and model reliability.”
> 
> 中文意譯：每件已完成任務的成本、輸出品質，以及模型可靠性。

對企業的啟示是，模型採購應有一份自己的驗收題。以程式碼審查為例，候選工具除了找出已知問題，也要記錄誤報數量與人工確認時間。便宜模型若讓主管花更多時間排除錯誤建議，省下的模型費可能不夠支付增加的工時。

**適用條件：** 團隊有重複工作、可回放的案例，以及能判斷對錯的人。樣本應涵蓋常見任務、困難任務與失敗案例，保留未參與調整的驗證資料。

**投入與取捨：** 整理樣本和人工評分都有成本。中型企業可以從單一流程開始；尚未形成穩定工作量時，不宜為每個模型都維護龐大的評測系統。

**預算會議要問：** 新配置在相同驗收條件下，是否降低完整成本？模型或設定更新後，誰負責重測與決定回退？

## 決策三：成本高，是任務難，還是流程做了太多無效工作？

Uber 將支出拆成使用者、工作階段、回合、請求、token 與單價的乘積；實作包含按需載入工具、批次處理工具往返，以及依工作模式調整快取。

> **Uber 原文摘錄｜成本公式**
> 
> “six terms that multiply.”
> 
> 中文意譯：六個互相相乘的項目。圖 3 呈現各項目如何共同構成總支出。

[![Uber 原文圖表：使用者、工作階段、回合、請求、token 與單價組成的成本公式](https://cn-geo1.uber.com/image-proc/crop/smartcrop/udam/format%3Dauto/width%3D2280/height%3D654/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9jYWY5MWU3ZC0wODVkLTQwMTQtOTE4Zi1hZmVmN2Y3YjI5OWIucG5n)](https://cn-geo1.uber.com/image-proc/crop/smartcrop/udam/format%3Dauto/width%3D2280/height%3D654/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9jYWY5MWU3ZC0wODVkLTQwMTQtOTE4Zi1hZmVmN2Y3YjI5OWIucG5n?ref=ai2b.tech)

*圖 3｜總費用的六項乘數。來源：Uber Engineering，原文 Figure 4。 [開啟大圖](https://cn-geo1.uber.com/image-proc/crop/smartcrop/udam/format%3Dauto/width%3D2280/height%3D654/srcb64%3DaHR0cHM6Ly90Yi1zdGF0aWMudWJlci5jb20vcHJvZC91ZGFtLWFzc2V0cy9jYWY5MWU3ZC0wODVkLTQwMTQtOTE4Zi1hZmVmN2Y3YjI5OWIucG5n?ref=ai2b.tech)*

這個拆法有助於定位費用增加的原因。實際帳務仍應依模型、輸入輸出與快取等計價類別分項加總，不能用單一 token 牌價估算全部工作。

**本刊建議先抽查高成本工作階段，再選改善項目：**

| 觀察到的現象            | 可先做的改善                | 必須驗證的代價           |
| ----------------- | --------------------- | ----------------- |
| 每次任務都帶入大量用不到的工具說明 | 縮小預設工具集合，按需提供         | 工具發現是否變慢、選錯率是否上升  |
| 不斷查詢同一工作是否完成      | 用可稽核的程式處理固定輪詢，只回傳必要結果 | 失敗是否仍能被發現，結果是否可追溯 |
| 反覆尋找同一份文件或系統負責人   | 維護高頻任務的資料索引與責任人       | 資料過期後誰更新，存取權限是否正確 |
| 長對話重複帶入舊資料        | 比較摘要、快取與重新開始的配置       | 是否遺失必要脈絡，導致額外返工   |

這些改善適合有重複軌跡、能量測前後差異的流程。若每次任務都高度客製，建立自動化機制的維護成本可能高於節省額。縮短上下文也要保留驗收測試，避免把必要資訊當成浪費刪掉。

**預算會議要問：** 現在最值得花錢解決的是模型能力、資料品質，還是重複操作？請用工作紀錄回答，而不是只看帳單最大的供應商。

## 決策四：什麼時候值得自建 AI Agent 共用平台？

Uber 的策略包含將更多工作移向可集中管理的代理，以掌握模型、執行環境與支出。

> **Uber 原文摘錄｜流程轉型方向**
> 
> “from interactive developer workflows to fully managed agents.”
> 
> 中文意譯：從開發者互動操作的工作流程，轉向全受管的代理。

對中型企業而言，可以先把「軟體工廠」理解為一套可重複交付的流程：需求進來後，有明確的執行、測試、驗收與人工接手機制。是否需要自建平台，取決於共用需求與工作量。

**本刊建議，當多個團隊反覆維護同樣的連接器、權限、評測與成本紀錄時，再比較共用平台的效益。** 若只有一個低頻流程，現有工具加上清楚的作業規範，可能已足以驗證需求。

建置估算應包含初期串接、後續維運、版本變更、權限管理、故障處理與遷移成本。集中管理也意味著故障可能影響多個團隊，需要指定維運責任與人工接手方式。

### 用損益平衡檢查平台投資

以下為編輯假設：共用平台初期投入 NT$240,000，以 12 個月攤提，每月增加 NT$20,000；另外每月維運 NT$20,000。若經驗證，每件合格成果可減少 NT$200 的其他成本，則每月需要 **200 件，才能打平新增的 NT$40,000 固定成本**。

這項試算假設節省額可實現、工作量足夠，且未計入利息或稅務。若需求不足或節省主要是尚未利用的工時，應改以產能效益評估。採攤提口徑的損益平衡，也不等於現金回收期。

**預算會議要問：** 未來工作量能支撐這筆固定投入嗎？若預估工作量少一半，投資案是否仍成立？

## 決策五：什麼證據足以支持擴大 AI 投入？

DORA 的交付指標同時關注速度與穩定性，包括變更前置時間、部署頻率、失敗部署恢復時間、變更失敗率與部署返工率。比較時應考慮同一應用或服務的脈絡。

> **DORA 原文摘錄｜指標需要脈絡**
> 
> “Context matters. Apply the metrics in the context of the application or service your team is delivering.”
> 
> 中文意譯：脈絡很重要。應在團隊所交付的應用或服務脈絡中，使用這些指標。

本刊建議將試點結果分成三個決策：**擴大、修正後重測、停止該配置。** 先約定成本、品質與觀察期間，再執行；不要看到成果後才改成功標準。

擴大的依據應是同類工作完整成本改善、品質達標，而且有足夠需求吸收產能。若費用降低但審查排隊變長，應先修流程。若反覆出現無法接受的品質問題，則停止該配置並回到既有流程。

成本或品質門檻由企業依現況設定，Uber 的降幅不能直接變成其他公司的驗收承諾。

## 可帶進預算會議的 90 天 AI Agent 試點決策表

以下是本刊提供的規劃模板，以「同一服務的測試補齊」為例。時程依任務頻率調整；工作量太少時，應延長觀察，避免用少數成功案例推估全年效益。

| 階段              | 負責人與交付物                          | 進入下一階段的條件                     |
| --------------- | -------------------------------- | ----------------------------- |
| 第 1–30 天：建立基準   | 工程主管選定範圍；測試負責人定義驗收；財務確認成本口徑      | 有現行流程的成本與交期紀錄、代表性樣本、預算上限及品質門檻 |
| 第 31–60 天：比較配置  | 試點負責人記錄模型版本、成功與失敗任務、人工工時；審查者核對品質 | 相同樣本與驗收條件下有可比較結果，失敗與接手成本均納入   |
| 第 61–90 天：做擴張決策 | CTO 檢視單位成本、品質、需求量與新增維運投入         | 擴大有實際需求且品質達標的配置；其餘修正重測或停止     |

**會議前請補齊五個欄位：** 試點負責人、每件合格成果的現況成本、可接受的品質門檻、累計投入上限、下一次決策日期。

以測試補齊為例，驗收不能只有「測試檔已產生」，還應由團隊定義應覆蓋的行為、執行結果與人工審查要求。觀察期間也要涵蓋足以暴露返工的後續使用，才不會把今天的快速交付變成下週的維護負擔。

下一次 AI 預算會議，可要求每個試點帶來一件合格成果、一份包含失敗嘗試的成本紀錄，以及一個擴大後的需求估算。這三份材料，能讓增購工具或建置平台的理由變得可檢驗。

## 常見問題：企業評估 AI 開發工具時該注意什麼？

### AI 使用率提高，就代表 ROI 變好嗎？

使用率反映採用情況；ROI 還需要投入與成果的證據。本刊建議把每件合格成果成本、交付時間與品質一起看，並區分可用產能和已實現的支出減少。

### 一定要換成便宜模型，才能控制 AI 成本嗎？

先找出成本來源。若費用主要來自重複查找、無效往返或人工返工，優先改善這些步驟可能更有價值；是否換模型，應由自己的任務評測決定。

### 中型企業應該照搬 Uber 的平台嗎？

本刊建議先借用量測與驗收方法，從高頻流程驗證需求。當共用需求、工作量與維運能力都足以支持投資，再決定平台範圍。

## 完整來源

以下連結供閱讀完整文件；相關重點已摘錄於內文，不需跳轉查找。

- [Uber Engineering：Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/?ref=ai2b.tech)（2026 年 8 月 27 日）
- [FinOps Foundation：Unit Economics](https://www.finops.org/framework/capabilities/unit-economics/?ref=ai2b.tech)
- [DORA：Software delivery performance metrics](https://dora.dev/guides/dora-metrics/?ref=ai2b.tech)