MCP 被宣判死亡的那週，Uber 正在用它管理數千個 AI agent

MCP、CLI、skills、AGENTS.md，都是讓 AI agent 取得正確資訊的方式，但適用場景完全不同。本文從 Uber 企業案例與 Vercel 基準測試拆解三者差異，幫你搞清楚該用哪個。 ⭐ 文章深度讀：整理了三個判斷題，讓你在一分鐘內找到適合自己場景的工具 → https://heymaibao.com/mcp-not-dead-uber-ai-agent/ ⚡ 章節重點 開場：MCP 被宣判死亡，但 Uber 不這樣想 00:00 你以為 MCP 死了？先看看當初的邏輯 00:45 Uber 的啟示：企業規模讓所有規則都變了 02:39 Skills 的盲點：那 44% 的情況讓你吃虧 04:02 三個問題選對工具，不被口水戰帶偏 06:16 📝 懶人包 ∙ MCP 的核心護城河是企業規模的集中式基礎設施。Uber 的 MCP gateway 讓任何 ProtoBuf 或 HTTP 端點用一個簡單的 config 設定就能包成 MCP server，而 auth (身份驗證)、telemetry (遙測數據)、logging (日誌記錄) 全部在一個閘道統一處理，服務數千位工程師與數千個 AI agent。 ∙ Skills 有一個你可能不知道的隱藏問題：觸發率只有 56%。Vercel 的基準測試發現，即使把 skill 準備好放在那裡，agent 也只有 56% 的機率會主動選用它，另外 44% 直接忽略。而且 skill 文件是靜態的，工具 API 更新後不會自動同步。 ∙ CLI、skills、MCP、AGENTS.md 沒有輸贏，只有適用場景。對訓練資料豐富的工具 (比如 GitHub CLI 的 gh 指令) 直接跑 CLI 最有效率；需要企業集中管理的場景用 MCP；想給 agent 補充文件上下文用 skills 或 AGENTS.md (每次對話自動注入的 agent 規則文件)。 ∙ 我的觀察：這場「MCP 已死」的辯論本身，揭露的是我們設計 AI 工作流程時的一個盲點，也就是我們常常把「個人開發者的最小可行做法」當成「所有場景的最佳解」，忽略了規模問題。 📚 參考資料 or is it? → https://youtu.be/X-QCpoi0zF4