爲什麼 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 文；要不要裝箱讀決策文。