AI Agent Skills vs MCP vs Plugins：2026 開發者到底應該使用哪一種？從工具發現到 JSON Schema 完整解析

問錯了：它們不在同一層，不能互斥

評審裏最常見的誤判，是把三張卡片攤在桌上投一票。Skill 不暴露 tools/list，也不接收 tools/call。它是目錄加 SKILL.md：啓動時只把 name 與 description 放進上下文（大約一百個 token），正文和 scripts/、references/ 按需再讀。沒有 JSON-RPC，沒有握手，也沒有一份「技能入參 Schema」在線上跑。MCP 正好相反：對面是進程或 HTTP 端點，參數必須是能校驗的 JSON。Plugin 兩樣都不做，只規定目錄和兩份閉集 Manifest。把 Plugin 當成「更強的 MCP」，等於把紙箱當成發動機。

發現也不是同一條路。Skill 的發現面是描述字符串：寫得像「做什麼 + 何時用」，模型才選得中；寫得像內部代號，技能等於沒裝。MCP 的發現面是 tools/list 返回的工具名加 inputSchema。Plugin 的發現面是根上的 plugin.json，然後按固定位置找 skills/ 和 mcp.json。三條路可以疊：客戶端先看見箱子，再看見技能元數據，再連上 MCP 拿到工具清單。疊了不等於可以互相替代。缺手的時候再寫一份更長的 Skill，只會讓模型用已有 shell 去「假裝」有 API——那是在賭幻覺，不是在做集成。

橫向委託也不在這三張卡片裏。另一個 Agent 怎麼被發現、怎麼接 Task，是 A2A Agent Card 的事，見 A2A vs MCP。今天只決定：這個倉庫要不要說明書、要不要手、說明書和手要不要鎖在同一個可移植目錄。先分層，再談選型。

四個問題走完決策樹

把選擇題收成四問，按順序答，不要跳。第一，模型是不是必須碰到倉庫外的活系統——數據庫、官方文檔檢索、計費 API、gcloud？要，你至少需要 MCP（或已有的原生工具，比如本機 gh）。不要，先別爲「看起來專業」起一個空 Server。第二，你是不是要固化「先核項目、再談 billing、密鑰不準進 git」這類流程，而且希望換會話還在？要，寫 Skill。只靠系統提示貼一段，下次窗口一擠就丟。

第三，第一問和第二問是不是必須一起分發？查發票的 MCP 離開寫週報的 Skill 就會被亂用；寫週報的 Skill 離開 MCP 就只能在假數據上演示。必須一起走，才考慮 Plugin。第四，你是不是要送給兩個以上的客戶端——Cursor、Claude Code、Antigravity、Codex？只服務一個 IDE、且它已有原生 MCP / Skills 安裝，用原生配置更短。Google 在 Developers Blog 裏把這點寫死了：Plugin 值錢的時候，是組件屬於同一目標、並且需要一起旅行。

下面是一份可進倉庫的決策記錄。它不是規範字段，是你們評審留下的 JSON 夾具：四問的答案、選擇、以及打算裝進箱子的組件名。先讓它能 parse，再在 CI 裏斷言 choice 與四問不互相打架——mustTravelTogether 爲 false 卻選了 plugin，就是過早裝箱。

{
  "task": "weekly-invoice-summary",
  "needRuntimeTools": true,
  "needReusableBrief": true,
  "mustTravelTogether": true,
  "clients": ["cursor", "claude-code", "antigravity"],
  "choice": "plugin",
  "components": [
    "skill:write-weekly-summary",
    "mcp:invoice-tools"
  ]
}

只用 Skill：發現靠 description，沒有 tools/call

Skill 贏在三件事：零握手、按需加載、人能 diff。啓動時客戶端只注入元數據；模型對上 description 裏的觸發詞，纔讀正文。所以描述必須同時寫「做什麼」和「何時用」，第三人稱、帶關鍵詞，長度有上限（name 64，description 1024）。寫成內部代號或第一人稱口號，發現面等於零。規範原文在 Agent Skills；Plugins 只規定它出現在 skills/<name>/SKILL.md，不改 frontmatter。

Skill 也可以帶 scripts/。那不是新的 MCP 工具，是「請用已有 shell 跑這個腳本」。適合本機已有的 CLI：gh、gcloud、你們的 lint.sh。腳本把確定性計算留在進程外，只把摘要寫回上下文，這比把整本 runbook 糊進提示更省窗口。它仍然不是傳輸層：沒有 OAuth 發現，沒有 inputSchema，參數對不對靠模型和腳本自己的 argv 校驗。需要穩定的 JSON 入參、需要遠程鑑權，就不要假裝腳本等於 MCP。

只寫 Skill 的典型場景：輸出格式（PR 正文、事故報告）、本機 CLI 工作流、領域護欄（「先讀這份 checklist」）。反例：把「查詢生產庫」寫成 Skill，讓模型拼 SQL 再塞給通用 shell。那是在用說明書冒充手。發現階段你也核不到參數形狀——因爲根本沒有 Schema 可校驗。

只用 MCP：發現靠 tools/list，合同是 inputSchema

MCP 贏在三件 Skill 給不了的東西：活連接、結構化入參、失敗邊界。客戶端連上 Server，tools/list 給出工具名和 inputSchema，模型填 arguments，運行時 tools/call。參數能不能過，是 JSON Schema 的事，不是「模型看起來很有信心」的事。鑑權、配額、傳輸版本，走 MCP 自己的規範；2026-07-28 無狀態版可以掛在普通 HTTP 負載均衡後面，見站內 Remote MCP 文。Skill 做不到其中任何一層。

單客戶端、單 Server，優先用該客戶端的原生 MCP 配置，而不是先做 Plugin。mcp.json 是 Agent Plugins 的可移植寫法，字段不必等於 Cursor 或 Gemini CLI 的方言；客戶端負責映射。你若只有一個 IDE，映射層是多餘的。等第二臺客戶端出現，再把同一份連接信息收成根上的 mcp.json，並補 plugin.json——哪怕暫時沒有 skills/。空的技能目錄不是錯誤；規範說缺位置就跳過。

發現鏈在這裏是短的：連上 → tools/list → 按 inputSchema 填參。不要把 OpenAPI 整文件丟給 MCP Client 當工具清單，也不要把 Plugin Manifest 的字段抄進 inputSchema。包裝合同回答「箱子在不在」；工具合同回答「這一跳 arguments 合不合法」。兩份都叫 JSON Schema，職責差一層。下面是「只發 MCP、暫不裝箱」時仍可先寫好的可移植片段——等你決定裝箱，它原樣放進插件根。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "invoice-tools": {
      "type": "stdio",
      "command": "./bin/invoice-mcp",
      "args": ["--data", "${PLUGIN_DATA}/invoices"],
      "cwd": "${PLUGIN_ROOT}"
    }
  }
}

何時裝箱：多組件、多客戶端才值得 Plugin

Plugin 只在決策樹第三、第四問同時亮燈時值錢。典型組合：查數的 MCP + 把結果寫成人類週報的 Skill；或 Google 那套——gcloud 護欄技能 + Developer Knowledge MCP。兩者離開彼此都會被誤用：只有手，模型亂寫週報；只有說明書，模型沒有接地的文檔檢索。裝箱之後，換 Antigravity、Claude Code、Codex，目錄佈局不用分叉。plugin.json 閉集，mcp.json 單獨放，密鑰仍走環境變量，不寫進 headers。

過早裝箱的代價是多一份要維護的 Manifest，以及評審時「我們有 Plugin 了」的幻覺。箱子不會讓 Skill 變成工具，也不會讓 MCP 獲得說明書。獨立組件獨立失敗：mcp.json 裏一條 server 起不來，技能還在；某一份 SKILL.md frontmatter 寫錯，其他技能和 MCP 繼續加載。這是規範，不是產品口號。如果你的 CI 把「多一個未知頂層字段」當成整包拒絕，你比客戶端更嚴，要自己知道。

和 A2A 再劃一次界。Plugin 解決「這個 Agent 如何獲得一組技能和工具」。另一個團隊的發票 Agent 怎麼被發現，是 Agent Card，不是把對方塞進你的 mcp.json 當一個 tool。多輪澄清和異步回調會撐破函數調用的形狀。選型順序可以寫成一句：先手、再說明書、最後纔是箱子。 沒有手卻先做 Plugin，等於先訂紙箱再決定賣什麼。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin",
  "version": "1.0.0",
  "description": "Invoice MCP plus the weekly-summary skill, shipped together"
}

三份 Schema、三種發現，用 JSONVue 覈對

把合同按 hop 攤開。第一份：plugin.schema.json，回答箱子能不能被發現，$schema 釘在 https://agent-plugins.org/schemas/1.0.0/plugin.schema.json。第二份：mcp.schema.json，回答 Server 怎麼連，type 必須顯式。第三份：每個工具的 inputSchema，回答 arguments 過不過。Skill 的 frontmatter 是 YAML，不是這三份裏的任何一份；不要用 JSON Schema 去「校驗」整本 SKILL.md。發現階段核第一、第二份；調用階段核第三份。

評審夾具至少五份：上面的決策記錄、一份合法 plugin.json、一份故意多頂層字段的 Manifest、一份可移植 mcp.json、一次真實 tools/call 的 arguments。決策記錄用來抓「四問與 choice 打架」。Manifest 用來抓包裝合同。arguments 用來抓工具合同。Google 的 Developer Knowledge 用 API Key，那是客戶端運行時的事；倉庫裏校驗的 mcp.json 不應含密鑰。

瀏覽器裏即可完成：JSON 格式化看決策記錄與兩份 Manifest 能否 parse；JSON Schema 校驗核 $schema、name、mcpServers 與 inputSchema；JSON Diff對比「可移植 mcp.json」和某個客戶端導出的原生配置；數據不離開本機。延伸閱讀：MCP 與 JSON Schema、Plugins 總覽、以及 A2A 與 MCP 的分工。

相關文章：Google Agent Plugins 2026、MCP 與 JSON Schema、MCP 是什麼、A2A vs MCP。

常見問題 FAQ

總結與下一步

2026 年在 Skills、MCP、Plugins 之間做選擇，可以收成一句：先問要不要手、要不要說明書、兩者是否必須一起走、要不要送給多家客戶端。不是三選一，是按層疊加。

落地順序：四問寫成決策記錄 JSON；該出手時先寫 inputSchema；該出說明書時先寫 description；兩問都亮且要跨客戶端，再補 plugin.json。用 JSONVue 核三份合同。箱子長什麼樣讀 Plugins 總覽；線協議讀 MCP 文；跨 Agent 讀 A2A 文。