AI Coding 正快速走出「工程師偶爾叫模型幫忙寫程式」的階段。Uber Engineering 在〈Running a Software Factory Efficiently at Uber Scale〉中，描述的已經是一套可大規模運作的 AI Software Factory：模型負責推理，代理負責拆解與執行，工具與企業知識提供上下文，最後再用成本與品質指標持續校正整個系統。
從 AI Coding 走向 Software Factory
Uber 公布的規模，說明 AI 已經進入日常工程流程：
- 超過 70% 的 Pull Request 可歸因於本機或雲端 Agent。
- 內部累積超過 3,600 個 Agent Skills。
- 每天執行超過 30,000 次 Agent Skill。
- 2026 年 2 月到 8 月，Agent 每週活躍使用者成長 7 倍，請求量成長 9.4 倍。
- 在使用量大幅增加的同時，AI 總支出自 4 月後相對穩定。
- 固定同一模型比較，每千次請求成本下降約 34%，每個 Session 成本下降 52%。
真正值得注意的地方，不只是使用量，而是 Uber 沒有把「節省成本」理解成限制工程師使用 AI。它的目標是增加有效使用，同時降低每次工作的浪費。
AI 支出 = 使用者數 × 每人 Session 數 × 每個 Session 的 Turn 數 × 每個 Turn 的 Request 數 × 每個 Request 的 Token 數 × 每 Token 價格
企業應鼓勵更多使用者、更多高價值 Session，同時降低不必要的 Turn、Request、Context 與昂貴模型使用。這也是 Agent FinOps 與傳統 API 成本管理最大的不同。
模型分工：主代理負責判斷，子代理負責執行
如果所有工作都交給最強、最貴的模型，規模一上來，成本必然失控。Uber 的做法是把主代理與子代理的職責拆開：
- 主代理：規劃、拆解任務、評估結果與品質驗收。
- 子代理：搜尋、寫程式、執行測試、查詢資料等範圍明確的工作。
- 模型路由器：依工作難度、品質需求、延遲與成本，選擇合適模型。
這套設計的關鍵不是「弱模型取代強模型」，而是讓每個模型處理適合自己的工作。Uber 也不只比較模型榜單，而是針對真實 workload 建立 benchmark，評估 Accuracy、F1、Latency、Timeout、Reliability 與 Cost，找出品質與成本都合理的 Pareto Model。
同樣的思路也適用於 reasoning effort。檔案搜尋、格式轉換、簡單查詢和小幅程式修改，通常不需要最高推理強度；架構決策、複雜除錯與高風險變更，才值得使用更強模型與更高 reasoning。預設採 Medium，再依任務升降，是更可控的企業策略。
上下文管理：更大的 Context Window 不等於更有效率
Agent 的成本很容易被上下文放大。一段對話會逐步累積 system prompt、程式碼、工具輸出、MCP schema、log 與舊結果，而這些內容可能在每次請求中重複傳送。
Uber 即使使用支援 100 萬 token context 的模型，也會在約 40 萬 token 時自動壓縮。理由很務實：可容納更多資訊，不代表應該無限制攜帶更多資訊。
Prompt Cache 也必須配合真實工作節奏。工程師送出任務後，可能過 10 到 30 分鐘才繼續對話；若 cache 五分鐘就失效，下一次互動便要重新傳送大量 context。Uber 因此把互動式 workflow 的 cache TTL 拉長到一小時，而生命週期短的子代理仍使用較短 TTL。
這裡可以歸納出三個原則：
- 設定 context budget，不要把視窗上限當成目標。
- 依工作型態設定 compaction 時機。
- 讓 cache TTL 對齊人與 Agent 的實際互動間隔。
MCP、CLI 與 Code Mode：不要讓模型處理機械式工作
MCP 能讓 Agent 連接企業工具，但大量工具 schema 也會擠占上下文。Uber 擁有超過 1,000 個 MCP servers；若一次載入上百個工具，初始 prompt 可能光 schema 就增加約 5 萬到 7 萬 token。
Uber 的方向是透過 Tool Search 動態尋找能力，再以 CLI 投影需要的 MCP 工具。Agent 不必一開始知道所有 schema，只在需要時載入需要的命令。
Code Mode 進一步把輪詢、分頁、格式轉換與資料彙整交給程式。傳統流程可能讓模型反覆送出 SQL、查詢狀態、取得結果，再把每一步加入 context；Code Mode 則讓模型先生成一段程式，由程式完成 submit、poll、fetch 與 summarize，最後只把必要結果交回模型。
Uber 公布的 SQL 測試顯示，簡單查詢可節省約 55% 到 71% token；面對寬表時，token 使用量甚至能從 140 萬級降到約 900。
能由 deterministic workflow 完成的事情，就交給程式；模型應負責理解、規劃、判斷與例外處理。
Context Graph：讓 Agent 找到正確的企業知識
大型企業的另一個瓶頸，是 Agent 不知道資料在哪裡。Uber 面對數億行程式碼、數千張資料表與超過 30 個內部系統，建立了包含約 2,400 萬個節點、8,000 萬條邊、86 種節點類型與 117 種關係類型的 AI Context Graph。
這張圖把 Service、Team、Incident、Pull Request、Architecture Document、Deployment、Dataset 與 Table Usage 等資訊連結起來，讓 Agent 不必每次都從零開始搜尋。
在 Uber 的案例中，相同 prompt 與相同模型，有 Context Graph 時約 38 秒得到正確答案；沒有 Context Graph 時耗時 20 分 09 秒，啟動兩個子代理、遇到三次錯誤，最後仍回答錯誤。
Agent Capability = Model + Context + Tools + Skills + Workflow + Evaluation
模型只是其中一個元件。企業真正能累積的護城河，是高品質上下文、可靠工具、可重用技能、治理流程與持續評估。
企業導入 Agent 的五個落地原則
- 不要把每個任務都交給最強模型。建立 model routing，依 workload 選擇成本與品質最合適的模型。
- 不要把每個工具都塞進 context。使用 Tool Search 與動態載入。
- 不要讓模型逐步執行 deterministic work。將輪詢、批次處理與資料轉換交給 Code Mode。
- 不要讓 Agent 在企業資料中盲目搜尋。建立 Context Layer 或 Context Graph。
- 不要只監控 API 帳單。同時觀察 cost per session、cost per task、cost per PR、cache hit rate、成功率與實際商業成果。
最終成熟度不應用「用了多少 token」衡量，而應看每個 merged PR、每次 code review、每個 alert triage 或每個完成任務的單位成本與品質。
結語
Uber 的 AI Software Factory 說明，企業 Agent 平台的核心不只是選一個更強的模型。真正的系統能力來自模型分工、上下文工程、工具治理、程式化執行、知識圖譜、可觀測性與成本管理。
當企業把這些元件組合起來，AI 才能從零散的個人工具，變成穩定、可擴展、可衡量的生產系統。
參考資料：Uber Engineering—Running a Software Factory Efficiently at Uber Scale
