Uber Context Graph：AI Agent 真正缺的不是更多技能，而是可查詢的組織關係圖
Uber Context Graph 與 Software Factory 的 Agent grounding／成本工程；2026-09-09 新增 400K compaction、長 TTL cache、CLI 取代 MCP schema 預載、code-mode 與 managed fleet。
Context Graph解決的不是工具選擇，而是關係缺失
大型組織的Agent通常不是不知道有哪些工具，而是不知道「資料與責任如何相連」。服務清冊、團隊歸屬、事故紀錄、PR、設計文件、部署、資料集及歷史查詢分散在不同系統；Agent若逐一呼叫工具拼答案，會增加token、延遲與錯誤路徑。Context Graph把這些物件正規化成節點與邊，讓Agent能沿著關係找到真正相關的上下文。
Service、Team、Engineer、Repository、Incident、Pull Request、Design Doc、Deployment、Dataset、API Endpoint、Feature Flag等可識別實體。
誰擁有哪個服務、哪次部署造成事故、PR修改了什麼、API依賴哪些服務、資料表被哪些工作與分析師使用。
Agent不必在30多個系統中盲目探索，而能用自然語言取得經過關係約束的候選答案，再回到原始系統驗證。
官方案例：38秒與20分鐘的差距
Uber以「找出正確資料表」作為對照。接上Context Graph的Agent利用歷史使用紀錄，找到一張被50多位分析師使用的特定資料表，38秒完成回答；沒有Graph grounding的Agent花了20分鐘檢查服務程式碼、啟動2個subagents、發生3次錯誤，最後仍錯誤判定資料不可查詢。這個案例顯示Context Graph同時降低requests per turn、探索成本與錯誤率。
| 面向 | 沒有Context Graph | 有Context Graph |
|---|---|---|
| 探索方式 | 逐系統搜尋、反覆呼叫工具 | 先沿已知關係縮小範圍 |
| 責任歸屬 | 從文件或聊天猜owner | Team／Engineer／Service關係可查 |
| 事故調查 | 人工拼接部署、告警與程式變更 | 沿Incident→Deployment→Code Change回溯 |
| 資料選擇 | 只看名稱或schema猜測 | 加入歷史使用者、查詢及血緣關係 |
| Agent成本 | 更多turns、subagents與長上下文 | 更少探索turns，答案較快收斂 |
中小型團隊不需要先做2,400萬節點
可先建立Minimum Viable Context Graph。第一階段只收最會影響Agent判斷的關係：服務→owner、服務→repository、服務→部署環境、事故→服務、事故→修正PR、資料表→owner、runbook→服務。第二階段再加入文件、工單、客戶、權限與歷史成功操作。重點是每個節點有穩定ID、每條邊有來源與更新時間，且Agent能回到原始證據，而不是一次把所有文件做embedding。