AI Agent（AI 代理）用得越多，企業的下一道難題也開始從怎麼導入，轉向怎麼控制成本。Uber 今年就碰上這個問題。《Fortune》5 月報導，Uber 前 4 個月便用完原先編列一整年的 AI coding 工具預算。但幾個月後，情況出現明顯反差。
Uber 近期公布，今年 2 月至 8 月，公司內每週 Agent 請求量成長 9.4 倍、活躍使用者增加 7 倍，超過 70% 的程式碼合併請求（pull request，PR）已有 Agent 參與，但整體 AI 支出自 4 月起維持穩定。若固定使用相同模型比較，每 1,000 次模型請求成本較高點下降近 34%，每個工作階段（session）成本也較 6 月高點降低 52%。
也就是說，Uber 沒有靠減少 Agent 使用來控制帳單。從前 4 個月燒完全年預算，到 Agent 使用規模持續擴張、支出卻不再同步暴增，Uber 到底改了什麼？
Uber 先把一筆 Agent 帳單拆開，從使用者、session、互動輪次，到模型請求數、每次請求使用的 token 與 token 單價逐項檢視。在具體做法上，Uber 不打算壓低使用者與 session 數，因為這正代表 AI 採用增加，因此把成本最佳化集中在 4 個面向：
第一個方向：降低每個 token 成本，不必每個工作都用最強模型
第一個面向處理的是每個 token 的價格（Price / Token）。Agent 開始自行拆解任務、啟動其他代理後，一項工作背後可能同時呼叫多個模型。如果所有步驟都預設使用能力最強、價格最高的前沿模型，成本也會隨任務數快速放大。
Uber 因此不只比較模型報價，而是用真實工作建立基準測試（benchmark），同時衡量完成任務的成本、品質與可靠度，再找出適合不同工作的模型。由於模型能力與價格快速變化，這套 benchmark 也會持續更新。
多 Agent 工作則進一步分工。主代理（main agent）負責理解問題、拆解任務與檢查結果，需要較完整的推理能力；子代理（subagent）接到的通常是範圍與目標已經明確的小任務，因此 Uber 預設讓 subagent 使用能力較低、成本也較低的模型，需要時才升級。當 Agent 越來越常自行啟動多個 subagent，這種分工能避免高價模型被用在不需要的地方。
第二個方向：減少每次請求的 token，別讓模型背著多餘資訊
第二個面向是減少每次模型請求使用的 token（Tokens / Request）。Agent 執行的工作越複雜、互動輪次越多，每次模型請求都可能重新帶入先前對話、程式碼、工具資訊與執行結果；多餘的上下文（context）不只計費一次，後續多輪請求還可能反覆帶著它。
Uber 因此同時調整 context、推理強度、提示詞快取（prompt cache）與工具載入方式。例如，即使部分模型支援 100 萬 token 的 context，Uber 仍預設在約 40 萬 token 時進行壓縮，也調整 prompt cache 保存時間，降低重新載入既有內容的成本。
MCP 工具也可能成為隱形負擔。Uber 的 MCP Gateway 串接超過 1,000 個 MCP server，但若一次安裝超過 100 個工具，光工具的結構定義（schema）就可能在使用者提問前先占掉約 5 萬至 7 萬 token，後續還會跟著 context 重複送出。Uber 因此改成透過工具搜尋，需要哪個工具時才載入，而不是一開始全部塞給模型。
即使需要呼叫工具，也不是每一步都需要 LLM 判斷。Uber 導入 code-mode，讓模型先產生一段 Python 程式，把 SQL 查詢、確認執行狀態與取得結果等固定流程一次完成，最後只把結果送回模型。
Uber 實測幾項簡單 SQL 工作，token 用量可降低 55% 至 71%；大量批次工作則能把原本多次模型互動整合成一次程式執行，token 減幅超過 90%。核心思路是，能交給一般程式確定完成的流程，就不需要讓模型在每一步重新判斷。
第三個方向：減少每輪模型請求，別讓 Agent 一直繞路找答案
第三個面向處理的是每輪互動需要多少次模型請求（Requests / Turn）。Uber 發現，Agent 很多請求其實花在找資料。該公司內部有數億行程式碼與數千張資料表，如果 Agent 不知道程式、服務、文件與資料彼此的關係，就可能反覆搜尋、呼叫工具，甚至啟動其他 Agent，讓模型請求一路增加。
Uber 因此建立 AI Context Graph，把服務、工程團隊、事故紀錄、PR、架構文件、部署與資料集等 30 多個內部系統串起來，讓 Agent 更快找到與問題相關的企業 context。
Uber 用相同模型與問題測試，有 AI Context Graph 輔助的 Agent 在 38 秒內找到正確資料；沒有相關 context 的 Agent 則花超過 20 分鐘，另外啟動 2 個 subagent、遭遇 3 次錯誤，最後仍答錯。讓 Agent 一開始取得更準確的 context，不只改善回答品質，也能減少搜尋、重試與模型呼叫。
方向四：技術之外，還要讓工程師知道錢花在哪裡
Uber 也直接在開發工具中顯示目前 session 的即時成本，以及跨不同 Agent 工具的總支出。他們沒有直接設定硬性上限，而是在使用量達預期支出的 50%、80% 與 100% 時透過 Slack 提醒；若要提高額度，則需再經主管核准。
Uber 另外建立 Session 層級的成本儀表板（Session Analysis Dashboard），辨識 16 類常見浪費並提供改善方式，例如簡單任務使用過強模型、MCP 回傳內容持續留在 context 中重複計費，或 prompt cache 過期後重新載入完整內容。
下一步，Uber 還準備把成本衡量拉到實際成果，例如每個合併 PR、每次程式碼審查、每個告警處理需要多少 AI 支出，並同步檢查品質。
Uber 的案例顯示，當 Agent 使用規模持續擴大，成本管理也開始從模型單價，深入到完成一項工作究竟需要多少 token 與模型請求。
科技的變化總是快得驚人，而我們每天的工作，就是從龐雜的趨勢中理出觀點、提煉出決策者真正需要的洞察。如果你也對 AI 發展充滿熱情，《TechOrange 科技報橘》正在徵內容編輯！
👉了解職缺內容
【推薦閱讀】
◆ 數萬家餐廳怎麼導入 AI？KFC 母公司從統一資料、微調小模型到算 ROI
＊本文開放合作夥伴轉載，資料來源：Uber、《AXIOS》、《Fortune》1、《Fortune》2，首圖來源：Unsplash
