MCP与Skills有何区别？AI Agent架构分层详解

一个被问错的问题

"有了 Skills 还需要 MCP 吗？"——这是 AI Agent 架构讨论中被反复提及的问题。但这个问题本身就问错了方向。真正值得追问的是：MCP 和 Skills 分别在 Agent 架构中负责哪一层？

二者并非替代关系，而是分工协作的关系。要理解这一点，需要先回到它们共同的技术根基——Function Call（函数调用）。只有厘清底层逻辑，才能看清 MCP 与 Skills 各自解决的核心问题。

理解这两个概念，还需要一个更大的历史背景：AI Agent 本身是一个正在快速演进的工程范式。早期的 AI 系统以"单轮问答"为主要形态——用户输入一个问题，系统返回一个答案，交互就此结束。2022-2023 年间，随着大语言模型能力的快速提升，研究者和工程师开始探索让模型完成"多步骤、跨系统、自主决策"的复杂任务，AI Agent 这一概念由此从学术讨论走向工程实践。这一转变带来了全新的工程挑战：单轮对话的技术栈无法支撑多步骤自主执行的需求。如何让模型与外部工具稳定交互、如何管理跨步骤的上下文状态、如何将领域知识固化为可复用的执行逻辑——这三个问题，恰好对应了 Function Call、MCP 和 Skills 各自诞生的技术动因。理解这条演进脉络，有助于我们看清每个概念的历史必然性，而不是将其视为凭空冒出的技术名词。

共同的地基：Function Call

Function Call 是模型调用外部工具的桥梁。当你让 AI 查日历、发邮件、搜索数据时，背后走的都是这套机制。模型本身并不能"动手"，它需要通过 Function Call 触发外部系统完成实际动作。

Function Call 最早由 OpenAI 在 2023 年 6 月随 GPT-3.5/GPT-4 API 更新引入，随后成为大语言模型生态中的核心机制。这一时间节点标志着大语言模型从"对话工具"向"行动主体"的关键跃迁——在此之前，模型只能生成文本建议，无法真正触发外部操作；在此之后，模型获得了与外部世界交互的标准化通道。值得注意的是，Function Call 并非凭空出现。在 GPT-3 时代，开发者只能通过精心设计的提示词"诱导"模型输出类 JSON 格式的文本，再用正则表达式解析，这种方式极其脆弱——模型输出稍有变化就会导致解析失败。2023 年的这次更新将工具调用升格为原生能力，模型在推理时会在内部生成结构化调用意图，而非依赖外部字符串匹配，稳定性和准确率大幅提升，这才真正打开了 AI Agent 工程化落地的大门。

其工作原理是：开发者在请求中以结构化 JSON Schema 的形式描述可用函数的名称、参数类型和用途，模型在推理时若判断需要调用外部工具，便输出一段包含函数名和参数的结构化响应，而非普通文本。宿主程序拦截这段响应、执行对应函数、将结果返回给模型，模型再基于结果继续生成最终答案。

这里有一个细节值得深究：模型是如何"学会"在合适的时机生成工具调用而非普通文本的？这背后是专门的微调（Fine-tuning）训练。OpenAI 等厂商在模型训练阶段引入了大量带有工具调用标注的对话样本，让模型学会识别"这类用户意图需要调用外部工具"的模式，并将调用意图序列化为规定格式的结构化输出。这意味着 Function Call 能力并非通用语言模型的自然涌现，而是定向训练的产物——这也解释了为什么不同模型的工具调用能力差异显著，以及为什么专门针对 Agent 场景微调的模型（如专门优化过工具调用能力的 Qwen、DeepSeek^广告 等系列）在实际工程部署中往往比通用模型表现更稳定。对于构建 Agent 系统的工程师而言，这意味着模型选型是影响整个 Agent 系统稳定性的底层变量，而非可以随意替换的组件。

这一"停下来→执行→继续"的循环，背后体现了一个重要的架构设计理念：模型的自然语言推理能力与外部系统的确定性执行能力被刻意解耦。模型负责"判断做什么、用什么参数"，宿主程序负责"真正去做"。这种解耦既规避了让模型直接操作外部系统的安全风险，也让工具的实现细节对模型完全透明，降低了集成复杂度。

这一机制是 ReAct（Reasoning + Acting）范式的底层实现基础。ReAct 是 2022 年由谷歌研究团队提出的 Agent 推理范式，核心思想是让模型在推理（Reasoning）和行动（Acting）之间交替迭代——每次行动的结果作为新的观察（Observation）再次输入模型，驱动下一轮推理，形成"思考→行动→观察→再思考"的完整认知循环。Function Call 正是 ReAct 中"Acting"步骤的技术载体，将模型输出的抽象"行动意图"转化为宿主系统可以实际执行的结构化指令。没有 Function Call，ReAct 就只是一套思维框架，无法真正驱动外部世界发生变化。Anthropic、Google 等主流模型厂商均实现了类似机制，尽管命名略有差异（如 Tool Use、Function Calling），但本质架构一致。

Function Call 是整个 Agent 能力体系的最底层协议。无论是 MCP 还是 Skills，都建立在这套机制之上。明白了这个前提，两者的区别就清晰多了。

MCP：把工具调用标准化

MCP 全称 Model Context Protocol（模型上下文协议），本质上是把 Function Call 标准化、协议化的一套规范。

MCP 由 Anthropic 于 2024 年 11 月正式发布并开源，其诞生源于一个真实的工程痛点：随着 AI 工具生态的爆炸式增长，每个工具都需要为不同的 AI 平台单独适配，形成了"M 个模型 × N 个工具 = M×N 个集成"的组合爆炸问题。这个问题在软件工程史上并不陌生——USB 接口的出现解决了外设连接的碎片化，HTTP 协议的统一解决了网络通信的混乱。MCP 试图在 AI 工具生态中扮演同样的角色：通过定义统一的客户端-服务器通信协议（基于 JSON-RPC 2.0），将这个问题降维成"M 个模型 + N 个工具 = M+N 个实现"。

JSON-RPC 2.0 是 MCP 底层通信格式的选择，这一选择本身颇具深意。JSON-RPC 2.0 是一种轻量级远程过程调用协议，相比 gRPC、GraphQL 等方案，它无需预编译 Schema、传输格式人类可读、调试门槛极低，天然契合 AI 工具生态对快速迭代的需求。更重要的是，它与 Function Call 已有的 JSON Schema 体系保持了高度一致性，降低了现有工具迁移到 MCP 的摩擦。开发者无需学习新的数据格式，原有工具定义可以近乎零成本地迁移到 MCP Server 中。这种对开发者体验的刻意照顾，也是 MCP 能在短时间内获得广泛生态支持的重要原因——一个需要陡峭学习曲线的协议标准，往往死于推广期而非技术本身。

MCP 的快速扩张背后，还有一个不能忽视的网络效应机制。标准协议与专有接口的本质区别在于：标准协议存在正反馈循环——接入的模型越多，工具开发者越愿意优先适配 MCP；支持 MCP 的工具越多，AI 平台越愿意内置 MCP 客户端支持。这种双边网络效应一旦形成，协议本身就具备了自我强化的增长动力，后来者很难仅凭技术优势打破既有格局。回顾软件史，HTTP 之所以能成为 Web 时代的统一协议，并非因为它在所有技术指标上都优于竞品，而是因为它在关键时间节点获得了足够多的早期支持者，从而触发了网络效应的飞轮。MCP 在 2024-2025 年间同样经历了这一临界点的突破：Cursor、Claude Desktop 等头部工具的集成，为其带来了大量开发者受众，进而吸引工具厂商批量跟进，形成了正向循环。这也意味着，即便未来出现技术上更优越的替代协议，MCP 的生态壁垒也将使迁移成本远超技术差距本身。

MCP Server 可以暴露三类能力：Tools（可执行的函数）、Resources（可读取的数据源）和 Prompts（预定义的提示模板）。这种三层能力划分的设计，使得 MCP Server 不只是一个"函数执行器"，还能主动提供上下文数据和交互模板，大大拓展了工具的表达能力。值得注意的是，Resources 这一类型让工具从被动响应升级为主动参与——工具服务器可以向模型推送实时数据，而不必等待模型主动发起调用请求，这对需要持续感知环境变化的 Agent 场景尤为关键。截至 2025 年，Cursor、Claude Desktop、Zed 等主流 AI 开发工具已全面支持 MCP，第三方 MCP Server 数量突破数千个，涵盖数据库、浏览器、代码执行、云服务等几乎所有主流场景。

有一个很形象的比喻：以前每家餐厅的点餐方式各不相同，有的扫码，有的喊服务员，有的用纸质菜单。MCP 就像统一推行的"扫码点餐标准"——不管走进哪家餐厅，模型都能用同一种方式点单。

MCP 解决的核心问题是工具生态的互操作性。只需定义好一个 MCP Server，任何兼容的 AI 系统都能接入，实现"可插拔、可替换"。这大大降低了工具集成成本，也让工具生态得以快速扩张。

换句话说，MCP 回答的是模型"能干什么"的问题——相当于给模型装上了一双双带标准接口的"手"。

Skills：告诉模型"怎么干"

Skills 则是完全不同的概念。它不是协议，而是结构化的提示词文档——可以把它理解成"完成某类任务的最佳实践"，被固化成一份可复用的执行手册。

Skills 的概念在不同 AI Agent 框架中有不同的具体实现形式，但核心思想一脉相承——将隐性的任务执行经验显式化、结构化、可复用化。在微软的 Semantic Kernel 框架中，Skills（后改名为 Plugins）是封装了提示词模板和执行逻辑的功能单元；在 Coze、Dify 等 Agent 构建平台中，类似概念以"工作流"或"自定义指令块"形式呈现。

从提示词工程的角度看，Skills 本质上是三类核心技术的综合应用：Few-shot Prompting（少样本提示）通过2-5个具体示例帮助模型快速对齐期望的输出格式与风格，让模型无需大量微调即可理解目标任务的"标准答案长什么样"；Chain-of-Thought（思维链）通过显式的步骤分解引导模型逐步推理而非直接跳到结论，这一技术在2022年由谷歌研究团队发表的论文中被系统证明可以显著提升复杂任务的准确率；Structured Output（结构化输出）则通过 JSON Schema 或 XML 标签约束输出格式，确保结果可被下游系统稳定解析，避免了自由文本输出在工程集成中的不确定性。三者叠加，使 Skills 既能约束模型的"思维路径"，又能规范模型的"输出形态"，形成端到端的任务执行规范。这种组合之所以有效，在于它同时解决了 AI 输出的两个核心工程问题：语义对齐（模型是否理解我们真正想要什么）和格式稳定性（模型的输出是否可被系统可靠消费）。

值得深入理解的是，这三种技术解决的是不同维度的问题，因此相互补充而非重叠。Few-shot Prompting 解决的是示例层面的语义锚定——通过具体案例消除自然语言描述的歧义，让模型理解"好的输出"在这个特定任务中具体长什么样，这在处理高度领域化的业务任务时尤为重要，因为领域术语和业务规则往往难以用纯文字描述清楚，但一个具体示例可以瞬间消歧。Chain-of-Thought 解决的是推理路径的可控性——对于需要多步骤判断的复杂任务，直接要求输出结论往往导致模型"跳步"而产生错误，而显式的步骤分解迫使模型在每个推理节点上进行局部验证，错误在中间步骤就会暴露，而非积累到最终输出时才被发现。Structured Output 解决的是下游消费的确定性——即便前两种技术确保了语义和推理的正确性，如果输出格式在不同调用之间存在随机波动，系统集成仍然是噩梦。三种技术的协同，使 Skills 形成了从"理解任务"到"正确推理"再到"稳定输出"的完整质量保障链条。这也解释了为什么仅靠调整提示词中的某一个维度往往效果有限，而系统性地应用这三类技术才能构建出生产级可用的 Skills。

这种"固化最佳实践"的思路，与软件工程中的设计模式（Design Patterns）高度同构：就像设计模式把解决特定问题的编程经验沉淀为可复用的模板，Skills 则把解决特定业务问题的 AI 执行经验沉淀为可复用的提示结构。两者的核心价值都在于：让经验不随人员变动而流失，让成功的解法可以被无损复制。

举个例子，一个"生成短视频脚本"的 Skills 通常会定义：

• 什么时候触发这个 Skills
• 执行步骤的先后顺序
• 输出内容的格式要求
• 边界情况的处理方式
• 具体的参考示例

Skills 关注的是任务的完整执行流程，是一套业务编排逻辑，回答的是模型"怎么干"的问题。

一个容易混淆的细节

很多人会追问：MCP 工具里也有 Description，也在告诉模型什么时候用这个工具，这不就是 Skills 的触发条件吗？

答案是：在工具选择这一层，两种逻辑确实是同构的。MCP 的 Description 和 Skills 的触发描述，在"决定是否调用某个能力"这件事上作用相似。

但 Skills 的作用域要大得多。它不只是说"用我"，还定义了：

• 调用工具之后下一步做什么
• 需要调用哪几个工具
• 这些工具的执行顺序
• 最终的输出格式

一个 Skills 可以编排多个 MCP 工具。 如果说 MCP 是一个个独立的零件，Skills 就是把这些零件组装起来的"装配图"。这一点与软件工程中"接口"和"业务逻辑层"的关系高度类似：接口定义了"能做什么"，业务逻辑层决定了"按什么顺序、在什么条件下做"。值得补充的是，这种编排不仅限于顺序执行——Skills 还可以描述条件分支（"如果搜索结果为空，则改用另一个数据源"）、循环迭代（"重复精炼输出直到满足质量要求"）和并行调用（"同时查询多个工具再汇总结果"）。这些编排模式并非仅仅是提示词技巧，它们对应着真实的业务需求场景：条件分支处理异常情况和降级策略，循环迭代实现自我纠错和质量提升，并行调用则在需要聚合多源信息时大幅缩短整体延迟。从系统可靠性角度看，Skills 中的条件分支尤为重要——它使 Agent 能够在单个工具调用失败时优雅降级，而非整体崩溃，这是生产级 Agent 系统与玩具级演示系统的核心区别之一。

这使得 Skills 本质上是一种轻量级的业务流程定义语言，其表达能力远超单一的工具描述。从这个角度看，Skills 与工作流引擎（Workflow Engine）中的流程定义文件（如 BPMN 文档）在概念上同构——前者用自然语言和提示结构描述业务流程，后者用 XML 标准描述业务流程，本质上都是"将人类意图翻译为系统可执行指令序列"的形式化表达。

分层视角：看懂二者的定位

理解 MCP 和 Skills 最清晰的方式，是把它们放到 Agent 的分层架构中来看。将 AI Agent 拆解为"协议层-能力层-策略层"的分层思维，与软件架构领域长期实践的**关注点分离（Separation of Concerns）**原则高度一致。

关注点分离是软件工程的核心原则之一，最早由计算机科学先驱 Edsger Dijkstra 于 1974 年明确提出。其核心思想是将系统按不同的关注维度划分为相对独立的模块，每个模块只处理自己的问题域，通过标准接口与其他模块交互。OSI 网络七层模型将通信协议拆分为物理层、传输层、应用层等相互独立的层次；MVC 框架将 UI 系统拆分为模型、视图、控制器；微服务架构将单体应用按业务边界拆分为独立服务——每一次成功的分层，都带来了更好的可维护性、可测试性和可扩展性。值得注意的是，这些历史案例有一个共同规律：分层设计的真正价值，往往不在于第一个系统，而在于第一百个系统。当只有一个工具、一个 Agent 时，分层显得繁琐；当工具数量增长到数十个、Agent 数量增长到数百个时，没有分层的系统会因维护成本指数级增长而崩溃，而有分层的系统仍然保持线性可控。这正是为什么在 AI Agent 工程化仍处于早期阶段时，就值得认真对待这套分层架构。

将这一成熟原则迁移到 Agent 架构中，带来的工程价值同样显著：平台工程师可以专注于维护 MCP Server（能力层），确保工具的稳定性、安全性和性能；业务专家专注于编写 Skills（策略层），将领域知识和业务逻辑沉淀为可复用资产；双方通过标准接口协作，互不依赖，大幅降低了构建复杂 Agent 系统的协作摩擦。这种分工模式，与现代软件工程中"平台团队"和"业务团队"的职责划分高度吻合，意味着 AI Agent 的工程化管理正在向成熟软件工程实践靠拢。

这种分层架构还带来了一个常被忽视的优势：可测试性的大幅提升。在没有分层的 Agent 系统中，测试往往只能进行端到端的黑盒测试——输入一个用户请求，观察最终输出是否符合预期，但当出现问题时，很难定位是工具调用错误、推理逻辑错误还是输出格式错误。分层架构使得每一层都可以独立测试：MCP Server 可以用标准的 API 测试方法进行功能和性能验证，完全不依赖模型；Skills 可以在固定工具集合的前提下，针对不同输入场景进行提示词效果评估；Function Call 层的稳定性则可以通过模型基准测试独立衡量。这种分层可测试性，是 Agent 系统从"能用"走向"可靠"的关键工程基础设施，也是区分实验性项目与生产级部署的重要判断维度。

底层协议层：Function Call

模型调用外部系统的桥梁，是一切能力的技术基础。

能力层：MCP

标准化工具接口，解决"能干什么"的问题。让工具具备互操作性，可被任何兼容系统接入。

策略层：Skills

业务编排逻辑，解决"怎么干"的问题。把多个能力按合理顺序和规则组织起来，驱动完整任务落地。

一句话总结二者的关系：

缺了 MCP，模型没有"手"；缺了 Skills，模型有"手"却不知道怎么用。

什么时候用 MCP，什么时候用 Skills？

回到最初那个问题，答案已经很明确：MCP 和 Skills 不是二选一，而是各司其职。

当你要接入新的外部能力（如数据库、API、第三方服务）时，需要的是 MCP——将这个能力标准化，让模型可以调用。

当你要固化一套任务执行流程（如内容创作、数据分析、多步骤自动化）时，需要的是 Skills——把"怎么做"沉淀成可复用的执行手册。

真正强大的 AI Agent，是让 Skills 在策略层负责编排，调用 MCP 在能力层提供的标准化工具，最终由 Function Call 在底层完成实际执行。三层协同，才能构建出既有"手"、又懂"怎么用手"的智能体。

核心要点

• Function Call 是底层协议，是模型与外部世界交互的最基础机制，由 OpenAI 于 2023 年首创并迅速成为行业标准。其核心设计理念是将模型的推理能力与外部系统的执行能力解耦，让模型专注于"判断"，让宿主程序专注于"执行"。它将此前脆弱的"提示词诱导+正则解析"方案升格为原生结构化调用能力，同时也是 ReAct 范式中"Acting"步骤的技术载体，将模型的推理意图转化为可被系统执行的结构化指令。值得注意的是，Function Call 能力依赖专门的微调训练而非通用语言能力的自然涌现，这使得模型选型成为影响整个 Agent 系统稳定性的底层变量。
• MCP 是能力层标准，解决工具互操作性问题，将"M×N 集成"降维为"M+N 实现"，让任何工具一次接入、处处可用。基于 JSON-RPC 2.0 的轻量级通信设计，兼顾了协议的标准化与开发者的低迁移成本，使其与现有工具生态的摩擦降到最低。其三层能力划分（Tools/Resources/Prompts）使工具从被动响应升级为主动参与，显著扩展了工具的表达能力。MCP 在 2024-2025 年间触发了双边网络效应的飞轮，形成了难以被后来者轻易打破的生态壁垒。
• Skills 是策略层逻辑，综合运用 Few-shot Prompting、Chain-of-Thought 和 Structured Output 三类提示工程技术，分别解决"示例层面的语义锚定"、"推理路径的可控性"和"下游消费的确定性"三个相互独立又互补的工程问题，形成从"理解任务"到"正确推理"再到"稳定输出"的完整质量保障链条。一个 Skills 可编排多个 MCP 工具，支持顺序、条件分支、循环和并行等多种编排模式，其中条件分支使 Agent 能够优雅降级而非整体崩溃，是区分生产级系统与玩具级演示的关键能力。
• 三者不是竞争替代关系，而是从底层到上层、从通用到具体的分层协作关系，与软件工程中 Dijkstra 提出的关注点分离原则高度一致，共同构成现代 AI Agent 的完整架构。这种分层设计除了在规模化场景中维护成本线性可控的优势外，还带来了关键的可测试性提升——每一层均可独立验证，这是 Agent 系统从"能用"走向"可靠"的工程基础。