CTO 該何時加碼 AI Agent？從 Uber 案例看五個投資決策
從 Uber 軟體工廠案例，拆解 CTO 擴大 AI Agent 投入前的五個決策：成果成本、模型評測、流程改善、平台投資與擴張門檻，附 90 天試點決策表。
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 日；原圖見下。）
圖 1｜週活躍使用者、代理請求與費用趨勢。來源：Uber Engineering，原文 Figure 1。 開啟大圖
圖 2｜固定模型下的單位成本變化；工作階段資料自五月底開始。來源：Uber Engineering，原文 Figure 2。 開啟大圖
讀這兩張圖時，要區分使用規模、技術單位成本與業務成果。一次工作階段可能完成任務，也可能失敗；每件工作的難度也不同。即使每次請求變便宜，仍需要驗收資料，才能判斷每件合格成果是否更划算。
以下五個決策，把案例轉成企業預算會議可以追問的問題。
決策一：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 呈現各項目如何共同構成總支出。
圖 3｜總費用的六項乘數。來源：Uber Engineering，原文 Figure 4。 開啟大圖
這個拆法有助於定位費用增加的原因。實際帳務仍應依模型、輸入輸出與快取等計價類別分項加總，不能用單一 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 的平台嗎？
本刊建議先借用量測與驗收方法，從高頻流程驗證需求。當共用需求、工作量與維運能力都足以支持投資，再決定平台範圍。
完整來源
以下連結供閱讀完整文件；相關重點已摘錄於內文，不需跳轉查找。