MCP、Skills、Tools、Subagents 到底有什么区别？2026 AI Agent 开发栈正在发生什么变化

先给结论：Tools、MCP、Skills、Subagents 不是四个互相替代的产品名，而是 2026 年 Agent 开发栈里四层不同职责。Tools 是模型看见的「可调用函数」契约（名字 + JSON Schema）；MCP 是 Host 与外部工具进程之间的发现与调用协议；Skills 是按需加载的程序性知识包（怎么做事）；Subagents 是带独立上下文、可委派出去的子代理。把它们揉成一个词，调试时就会同时改错层。

这篇按 2026 年 9 月 11 日写。本站已有《MCP 是什么》《Agent JSON 数据流》《JSON Schema 标准合同》。本文只回答：这四层各自管什么、怎么叠、以及 2026 年这套栈正在往哪边收拢。

一张表先分清四层

口语里「给 Agent 加个工具」可能指四件完全不同的事。按下表对号入座：

记一句就够：Tools 是「能调什么」；MCP 是「工具从哪来」；Skills 是「怎么做这件事」；Subagents 是「谁去干、用哪段上下文」。JSON Schema 贯穿 Tools 与 MCP；Skills / Subagents 更多管提示词、策略与会话边界。

Tools：模型面前的调用契约

Tool（或 Function）是大模型侧看到的最小可调用单元。各家名字略有差别——OpenAI 的 Tools / Function Calling、Anthropic 的 Tool Use、Gemini 的 Function Declarations——本质一样：你声明一组工具，模型在回复里返回结构化 tool_calls（或等价字段），Host 执行后再把结果塞回对话。

一份工具定义通常长这样：

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

这里真正约束行为的是 JSON Schema：字段名、类型、required、additionalProperties。模型可以换，Schema 不该随模型飘。本站《Tool Calling 为什么依赖 JSON Schema》把校验纪律写细了；本文只强调：没有 Schema 的「自然语言工具说明」，在 2026 年已经不够当生产契约。

Tools 层的边界很清楚：它不规定工具实现跑在本进程还是远程，也不规定多步任务怎么拆。那些分别是 MCP 和 Skills / Subagents 的事。

MCP：跨进程的工具插座

MCP（Model Context Protocol）解决的是：工具与上下文如何从 Host 进程外被发现和调用。报文是 JSON-RPC 2.0；常见方法包括 tools/list、tools/call，以及 Resources / Prompts 相关方法。Host（Cursor、VS Code、Claude Desktop 等）内部的 MCP Client 连上一台 MCP Server，把 Server 暴露的工具译成模型看得懂的 Tools 数组。

所以正确的叠法是：

1. MCP Server 用 inputSchema（仍是 JSON Schema）描述每个 tool；
2. Host 调 tools/list，翻译成模型的 Tools 声明；
3. 模型发出 tool_calls；
4. Host 再发 tools/call 给 Server，把 result 写回对话。

把 MCP 说成「另一种 Function Calling」是 2025–2026 最常见的误读。Function Calling 在模型 API 边界；MCP 在 Host ↔ Server 边界。当前规范以 2026-07-28 为准：无会话握手，请求自带 _meta。细节见《MCP 完整指南》与《迁移指南》。

什么时候不需要 MCP？单进程、工具写死在 Host 里、不跨应用复用——直接 Tool Calling 就够。什么时候值得上？要跨 IDE / 桌面端复用同一套 Server、要进程隔离、要动态发现工具清单。

Skills：可复用的做事说明书

Skill 不是又一个 tool，而是一段可被 Agent 按需加载的程序性知识：何时启用、按什么步骤做、要检查什么、可以调用哪些工具。工程形态常见为仓库里的 SKILL.md（或等价规则包）：标题、触发条件、步骤清单、禁止事项、相关脚本路径。

和 Tools / MCP 的差别：

2026 年 IDE Agent（含 Cursor 一类产品）把 Skills 做成一等公民：短任务用内置能力；长流程、团队规范、重复运维剧本放进 Skill，避免每次都把整本手册塞进系统提示词。Skill 可以指导 Agent 去调哪些 Tools，也可以规定「先校验 JSON 再提交」这类门禁——但它本身通常不是 JSON-RPC 方法。

落地时容易混的一点：有人把「封装好的 shell 脚本」既叫 Skill 又叫 Tool。分法是——若模型通过 Schema 调一次、拿结构化结果，那是 Tool；若文档告诉 Agent「按这五步做，必要时再调工具」，那是 Skill。

Subagents：独立上下文的委派单元

Subagent 是父 Agent 委派出去的子会话：通常有独立上下文窗口、更窄的系统提示词、更受限的工具集，完成后把摘要交回父会话。它解决的不是「多一个函数」，而是「上下文污染」和「并行探索」。

典型用途：

• 隔离检索：让子代理去翻仓库、读日志，父会话只收结论，不吞进整份噪音。
• 并行分工：前端改动、测试、文案翻译同时跑，互不抢同一段上下文。
• 角色收窄：安全审查、代码探索、CI 诊断用不同提示词与工具白名单。

实现上，Subagent 常常对父 Agent 暴露成一种特殊 Tool（例如 Task / spawn_agent）：参数是任务描述与类型，返回是子代理的最终答复。这不意味着 Subagent = Tool。Tool 是调用面；Subagent 是另一个带状态的推理循环。

和 Skills 的边界：Skill 告诉「怎么做」；Subagent 决定「另开一个会话去做」。一个 Skill 可以规定「复杂排查必须启动 CI 诊断 Subagent」；Subagent 内部再加载自己的 Skills 与 Tools。

四层怎么叠在一起

一次真实任务里，四层经常同时出现。以「写博客并部署」为例（示意，不是本站真实内部协议）：

1. 父 Agent 加载 Skill：「博客发布检查清单」——校验正文、多语言、sitemap、IndexNow。
2. 父 Agent 调用 Subagent 去探索仓库里的历史文章模板，避免把几十个 HTML 塞进主上下文。
3. 主会话通过 Tools（读写文件、跑 shell）改前端；若工具来自外部进程，则经 MCP 发现与调用。
4. 每一步涉及结构化参数时，仍用 JSON Schema 卡住字段——尤其是会离开本机的那一跳。

数据流可以压成一行：

User → Host/父 Agent
      → Skills（选流程）
      → Subagents（可选委派）
      → Tools 声明（给模型）
      → 可选 MCP Client ↔ MCP Server
      → 执行结果写回对话

调试口诀：模型乱调工具 → 先查 Tools / Schema；工具进程连不上 → 查 MCP；步骤经常漏项 → 补 Skill；上下文爆了或互相污染 → 拆 Subagent。

2026 Agent 开发栈在变什么

和 2024「把函数塞进 prompt」相比，2026 年的变化可以收成五条：

另一条主线是结构化输出与工具参数合流：模型回复业务 JSON、工具 arguments、MCP inputSchema，三处都在用同一套 Schema 纪律。本站《结构化输出是什么》《OpenAI vs Gemini 对比》写的就是这条线。

产品侧，IDE Agent 不再只是「聊天 + 补全」：默认栈里同时有工具调用、MCP 连接器、Skills 目录、可派生子代理。对开发者的含义是——你交付的不再只是一个 API，而是可被发现的工具（MCP/Tools）+ 可被遵循的流程（Skills）+ 必要时可被委派的角色（Subagents）。

现在该怎么选、怎么写

• 先写 Schema，再暴露工具。additionalProperties: false、required 写全；用本站校验工具在浏览器里对样例 arguments 做语法与结构检查。
• 工具要跨应用复用，再包 MCP Server。单脚本、单 Host 内嵌实现，不必强行上 MCP。
• 团队重复流程写成 Skill。发布、迁移、排障、安全审查——步骤稳定的，不要每次靠「记得提醒模型」。
• 上下文一长就拆 Subagent。探索型、只读型、高噪音任务优先委派；父会话只留决策与最终补丁。
• 不要用 Skill 代替 Schema，也不要用 Subagent 代替 MCP。前者是流程，后者是契约与传输；混用会导致「文档里写了校验、线上却从不跑」。

本地检查 JSON 时，把 inputSchema、模型返回的 arguments、MCP tools/call 结果样例存成文件，用 JSON 校验 与 JSON Diff 对照。数据不离开浏览器——和端侧优先的隐私思路一致。

常见问题 FAQ

总结

Tools 定义模型能调什么；MCP 定义工具如何从外部进程被发现与调用；Skills 定义怎么按规范把事做完；Subagents 定义如何隔离上下文并委派。2026 年的 Agent 开发栈，正从「一个聊天框 + 一堆临时函数」收拢成这四层加一条 JSON Schema 契约带。

选型时由内向外加，不要一次上齐。先把 Schema 与 Tools 做对，再按复用、流程、上下文三个压力点决定 MCP、Skills、Subagents。动手前用本地 JSON 工具把样例跑通——模型可以换，字段名和 required 不该变。