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