为什么 AI Agent 开始从“Tool Calling”走向“Skills + Plugins”？2026 Agent 架构变化与 JSON 数据流解析

撑不住的不是调用，是发现面

Tool Calling 仍然是模型选出函数名和 arguments 的那一跳。2026 年没有谁宣布它退役。退役的是一种打包方式：启动时把五十份 inputSchema 全放进 tools[]，再把「先核项目、再谈 billing、周报按财务口径写」整段贴进 system。前十个工具还好；接到第三个业务域，请求本身先变成一份谁也不 diff 的巨型 JSON。模型选错工具，看起来像幻觉，根因常常是发现面太大、说明书被截断。调用 hop 没坏，坏的是你让它同时干发现的活。

窗口只是第一刀。第二刀是变更。财务改了周报段落顺序，你得同时改系统提示、某份内部 wiki、以及三个 IDE 里各自粘贴的规则。没有一份可 diff 的 SKILL.md，这次改动不会进 PR。第三刀是跨客户端：Cursor 的 MCP 方言、Claude Code 的技能目录、Antigravity 的插件布局，三套包装。工具还是那几个，箱子先分叉。痛点不在 tools/call 的信封，在信封外面那层「何时用、和谁一起走」。

所以「走向 Skills + Plugins」不是口号替换。它是把发现和包装从调用请求里拆出去。调用 hop 还在，见 MCP 与 JSON Schema。Agent 循环还在，见 Agent 定义文。今天只看拆出去之后，JSON 怎么流。安装之后客户端手里有什么，见 Plugin Manifest 实战——那是五跳；本文是为什么会出现这五跳。

不是替换：调用层还在，上面多了一层

把 Skills 说成「新一代 Tool Calling」，会在日志里找错层。Skill 没有 tools/call。它是说明书，启动时只注入元数据。模型对上触发词，才读正文和 scripts/。MCP 才是手。Plugin 是目录。三层叠在调用之上，不取代 arguments 这一跳。你在 trace 里仍应看到一次合法的 tools/call；看不到，说明发现层把模型挡住了，而不是调用层被删除了。

渐进披露是 Agent Skills 规范的核心，不是产品形容词。name 最长 64，description 最长 1024，第三人称，写清做什么和何时用。写成内部代号或第一人称口号，发现面为零——工具都在，模型选不中。正文按需加载，是为了不让 runbook 和五十份 Schema 抢同一截窗口。Scripts 仍是 argv，不是 tools/list 里的一等工具。需要稳定 JSON 入参，仍然走 MCP。

Plugin 更薄。它不能内联工具清单，也不能把 SOP 写进 plugin.json 顶层。箱子回答「这组说明书和手在不在」；调用回答「这一跳 arguments 合不合法」。两份都叫 JSON，职责差一层。选型四问见 决策文；安装后五跳见 Manifest 实战。今天只画数据流怎么从扁变厚。

旧数据流：一份巨大的 tools 数组

旧请求长得像一份菜单加一份店规。tools 数组里每项都带完整 inputSchema。system 里塞流程。用户一句话进来，模型在整张菜单上点菜。菜单短，这很快。菜单变成「发票 + 报销 + 权限 + 部署 + 文档检索」，点菜本身先失败：相近工具互相抢，SOP 被截在中间一句「不要把密钥……」之后。故障单上写「模型胡来」，diff 一看是请求体先胡来。

这份 JSON 还有一个隐蔽成本：它是运行时拼出来的，常常不进仓库。下次有人加一个 send_slack，没有 PR 能看出 Schema 膨胀了多少。评审只能翻日志里那次巨大的请求体。没有预算，就没有「该拆发现层了」的信号。扁平架构不是道德错误，是缺少度量的膨胀。

下面是压扁后的旧夹具。真实环境会更长。先让它能 parse，再在 CI 里对 tools.length 和请求体字节设预算——超过预算不是「再加一句提示」，是该把 SOP 和全量 Schema 从启动请求里搬出去。

{
  "era": "flat-tool-calling",
  "system": "Always check the billing project first. Never commit secrets. Write the weekly invoice summary the finance team actually reads.",
  "tools": [
    {
      "name": "query_invoices",
      "inputSchema": {
        "type": "object",
        "required": ["week"],
        "properties": {
          "week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
          "status": { "type": "string", "enum": ["open", "paid", "overdue"] }
        }
      }
    },
    {
      "name": "export_csv",
      "inputSchema": {
        "type": "object",
        "required": ["week"],
        "properties": { "week": { "type": "string" } }
      }
    },
    {
      "name": "send_slack",
      "inputSchema": {
        "type": "object",
        "required": ["channel", "text"],
        "properties": {
          "channel": { "type": "string" },
          "text": { "type": "string" }
        }
      }
    }
  ]
}

新数据流：元数据 → 正文 → 工具合同

新轨迹按需变厚。启动：上下文里只有技能元数据（和 Plugin 身份，如果装了箱子）。匹配：才读 SKILL.md 正文。需要手：才把 tools/list 的 inputSchema 放进这一轮。调用：arguments 仍然走原来的 Schema 校验。窗口里同时出现的，从「全量菜单 + 全量店规」变成「一张索引 + 当前这一本」。token 账从启动一次性支付，改成按匹配支付。

注意 tools[] 没有消失，它后移了。后移的代价是多一次握手、多一次匹配失败的可能。description 写得差，模型到不了第三跳，用户会说「装了 Plugin 也不会」。那是发现面的 bug，不是 Tool Calling 回归。反过来，轨迹里已经有 inputSchema 却仍把整本 runbook 灌进 system，是新架构的回潮——窗口账会重新失控。

下面是同一任务的新夹具。它不是规范文件，是评审用的轨迹。和旧请求并排 diff：你会看到 SOP 从 system 搬到了 skills[].description，Schema 从启动搬到了 afterMatch.tools。调用层的 query_invoices 合同应保持同一份 canonical Schema，不要为了「新架构」另写一套字段。

{
  "era": "skills-plus-plugins",
  "startup": {
    "plugin": "invoice-ops",
    "skills": [
      {
        "name": "write-weekly-summary",
        "description": "Turn invoice query results into the weekly summary finance reads. Use when the user asks for a week-end report.",
        "loaded": "metadata"
      }
    ]
  },
  "afterMatch": {
    "skillBodyLoaded": true,
    "tools": [
      {
        "name": "query_invoices",
        "source": "mcp:invoice-tools",
        "inputSchema": {
          "type": "object",
          "required": ["week"],
          "properties": {
            "week": { "type": "string", "pattern": "^[0-9]{4}-W[0-9]{2}$" },
            "status": { "type": "string", "enum": ["open", "paid", "overdue"] }
          }
        }
      }
    ]
  }
}

为什么还要 Plugin：说明书和手必须一起旅行

只把 SOP 收成 Skill、只把 API 收成 MCP，已经能瘦请求。跨两个客户端时，目录布局和 MCP 方言又开始分叉。Plugin 值钱的时刻，是说明书和手必须一起旅行。Google Cloud Developer Plugin 把 gcloud 护栏技能和 Developer Knowledge MCP 打成一包，原因在此，不是因为 Tool Calling 不够用。箱子不执行任何工具；它只保证换 Antigravity、Claude Code、Cursor，发现路径不分叉。

单客户端、单 Server，继续用原生 MCP 配置。为「架构先进」先做 Plugin，只是多一份 Manifest。决策文的第三、第四问仍适用。架构变迁不是「全体升级到 Plugin」，是「调用层保持稳定，发现层和包装层按痛点往上加」。没有第二台客户端、说明书和手也不互相依赖，停在 Skill 或原生 MCP，就是正确的 2026 架构。

和 A2A 再划界。另一个 Agent 怎么被发现，是 Agent Card，不是把对方塞进 tools[]。扁平 Tool Calling 的另一种膨胀，是把远程 Agent 当成一个函数。那会撑破 arguments 的形状。横向委托不在今天的数据流里；今天只处理「这一个 Agent 如何少带菜单、多带索引」。

两份夹具并排 diff

评审夹具至少三份：上面的旧请求、新轨迹、一次真实 query_invoices 的 arguments。前两份对「膨胀从哪一层拆走」负责。第三份证明调用层没被改写——inputSchema 仍是那份 canonical。有人把 Plugin 的 name 抄进工具 arguments，或把 inputSchema 抄进 plugin.json，diff 一眼就能看见。

再加两份负例：新轨迹里 skills 为空，却声称 era 是 skills-plus-plugins；旧请求 tools.length 超预算，却没有拆分记录。前者抓「口号换了、发现面没换」。后者抓「还在用加长提示硬撑」。密钥不要出现在任何一份进仓库的夹具里。

浏览器里即可完成：JSON 格式化看旧请求与新轨迹能否 parse；JSON Schema 校验核 inputSchema 与 arguments；JSON Diff并排旧 system / tools 和新的 skills / afterMatch；数据不离开本机。延伸阅读：MCP 与 JSON Schema、选型决策、以及 Manifest 五跳。

相关文章：AI Agent 是什么、MCP 与 JSON Schema、Skills vs MCP vs Plugins、Plugin Manifest 实战。

常见问题 FAQ

总结与下一步

2026 年说「从 Tool Calling 走向 Skills + Plugins」，可以收成一句：调用 hop 留下，发现和包装从一次巨大的请求里拆出去。模型仍然点菜；菜单不再在开席时全上桌。

落地顺序：给旧请求的 tools.length 和字节设预算；把 SOP 收成 description；全量 Schema 后移到匹配之后；跨客户端再补 plugin.json。用 JSONVue 把旧请求和新轨迹并排。循环定义读 Agent 文；arguments 读 MCP 文；要不要装箱读决策文。