AI Agent 如何改善企業工作流？Uber 公開用 3,600 個 Skills 建立 SOP 的實戰經驗

AI Agent 到底要怎麼真正融入一家大型公司的工作流程？Uber 最新公開的內部數據，提供了一個相當具體的案例。

Uber Engineering 表示，目前 AI 工具已經進入公司軟體開發生命週期（SDLC）的各個階段，超過 70% 的 Pull Request（PR）可歸因於本地或雲端 Agent；員工更已經建立超過 3,600 個 Agent Skills，每天執行超過 3 萬次 Agent Skill。

更重要的是，Uber 的 AI Agent 已經不只是工程師主動打開 Coding Assistant，叫 AI 幫忙寫幾行程式。

愈來愈多工作甚至不是由人類主動發起，而是由 Managed Agents 自動接手。

人類工程師則逐漸轉向最後 Review，以及 Agent 無法處理時的 Escalation。

Uber 將這套願景稱為 Software Factory（軟體工廠）。

從「工程師使用 AI」變成「AI 自己收到工作」

Uber 認為，真正重要的轉變是從 Interactive Developer Workflow，逐步走向 Fully Managed Agents。

傳統 AI Coding 的使用方式仍然以人為中心：工程師遇到問題後打開 Claude、GPT 或其他 Coding Agent，輸入需求，再等待 AI 執行。

Managed Agent 則不同。

例如 CI Pipeline 出現錯誤後，不一定需要等待工程師發現問題、複製 Error Message 再詢問 AI，而可以直接由 Agent 接收到失敗事件，自動取得相關 Context、分析問題並嘗試修復，最後產生修改結果交給人類確認。

Code Review 也是如此。

Uber 已經建立名為 uReview 的 AI Code Review 系統，處理公司的 Pull Requests。

為了確認 AI 是否真的能抓出問題，Uber 使用真實發生過 Bug 的 PR 建立 Benchmark，並依 Easy、Medium、Hard 分級，再評估模型的 Precision、Recall、F1、延遲與錯誤率。

這代表 AI Code Review 不再只是工程師偶爾詢問模型「這段 Code 有沒有問題」，而是直接成為軟體開發流程中的一個固定環節。

一個 Agent 不必包辦全部工作：主 Agent 管理，Subagent 執行

Uber 內部的 AI 工作模式也開始從「一個 AI 完成一切」轉向 Multi-Agent。

隨著新一代模型的 Agent Orchestration 能力提升，Uber 發現愈來愈多 Session 會主動建立 Subagents。

其分工方式很像一個小型團隊：

主要 Agent 負責理解目標、拆解工作與驗收結果；Subagents 則分頭執行已經定義清楚的任務。

由於 Subagent 接收到的工作通常已經有明確輸入與範圍，因此不一定需要使用最強的 Frontier Model。

Uber 因此預設讓 Subagents 使用較弱、成本更低的模型，再由主要模型負責較複雜的推理與品質判斷。

這讓 AI Agent 的角色開始更接近「管理者＋執行團隊」，而不是單純的一個聊天機器人。

UBER AI Agent 融入工作遇到什麼問題

但當 AI Agent 真正進入企業工作環境後，Uber 發現一個很現實的問題：

Agent 大量時間其實不是花在寫程式，而是在找資料。

Uber 擁有數億行程式碼與數千張資料表，資訊散落在服務、Pull Requests、Incident Logs、Architecture Documents、Deployment Records 與不同 Dataset。

如果 Agent 缺乏公司內部 Context，它可能不斷搜尋程式碼、呼叫工具、建立 Subagents，最後甚至得到錯誤答案。

因此 Uber 建立了一套 AI Context Graph。

這張企業知識網路整合超過 30 個內部系統，目前包含約 2,400 萬個 Nodes、8,000 萬條 Edges，涵蓋服務、工程團隊、事故紀錄、PR、架構文件、部署、Dataset 與歷史資料表使用紀錄等資訊，並允許 Agent 使用自然語言查詢。

Uber 曾把同一個問題交給相同模型測試。

有 Context Graph 的 Agent 根據歷史紀錄，找到一張超過 50 名分析師實際使用的正確資料表，只花 38 秒完成任務。

沒有 Context Graph 的 Agent 則花了 20 分鐘檢查 Service Code、建立兩個 Subagents、遭遇三次錯誤，最後還錯誤判斷這份 Dataset 無法查詢。

超過 1,000 個 MCP Server，Uber 讓 Agent 自己找工具

除了「知道資料在哪」，Agent 還必須知道「該用什麼工具」。

Uber 內部已經有超過 1,000 個 MCP Servers，連接大量內部服務與第三方 SaaS。

但如果一次把所有工具說明全部塞給模型，反而會產生問題。

Uber 發現，安裝超過 100 個 Tools 時，光是預先載入 Tool Schema，就可能占掉約 5 萬至 7 萬 Token。

因此 Uber 改變方法：不要求 Agent 一開始就「知道所有工具」，而是讓 Agent 在需要時透過 CLI 與 Tool Search 找出適合的工具，再動態載入。

這就像新進員工不需要第一天背下公司所有內部系統的操作手冊，而是需要知道：遇到某種問題時，去哪裡找到正確工具。

Agent 還能自己寫程式操作公司的工具

Uber 進一步採用 Code Mode，讓 Agent 不只是一次呼叫一個 Tool，而能寫一段 Python Script，把多個操作串起來。

例如查詢公司 Data Warehouse 時，傳統 Agent 可能需要送出 SQL → 等待 → 查詢狀態 → 再等待 → 再查詢 → 取得結果。

每一步都需要模型介入。

改用 Code Mode 後，Agent 可以直接產生 Python Loop，讓程式自行完成等待與 Polling，最後只把真正有用的結果交回模型。

Uber 的測試顯示，即使只是執行 5 個相同 SQL Query，這種方式也能降低超過 50% Token 使用量；大量批次工作的節省幅度更可以超過 90%。

Uber 已經替最常使用的 MCP Servers 建立超過 25 個 Code-mode Skills，將這些企業內常見操作直接包裝成 Agent 可以重複使用的工作能力。

3,600 個 Skills，讓企業知識逐漸變成「AI 可以執行的 SOP」

這也是 Uber 已建立超過 3,600 個 Agent Skills 特別值得注意的地方。

企業過去的知識往往存在 Documentation、SOP，或者乾脆存在資深員工腦中；但 Agent Skill 的概念，是進一步把「遇到這種工作應該怎麼做」包裝成 AI 可以直接執行的能力。

Uber甚至準備進一步建立 Continuous Skill Improvement。

未來 Agent 執行 Skill 過程中遇到的問題（papercuts）可以被自動記錄，再利用這些 Execution Traces 產生 Skill 更新。