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 文。