1. 引言随着大语言模型LLM从单纯的对话机器人向能够自主执行任务的 Agent 演进如何让模型安全、高效地与外部世界交互成为了核心课题。在众多技术方案中Function Calling、MCPModel Context Protocol和Skills是三个最常被提及且容易混淆的概念。它们都旨在解决同一个问题让 LLM 能够调用外部工具、获取实时数据或执行特定操作。然而它们在设计哲学、架构层次、使用场景和生态定位上有着本质的区别。本文将深入剖析这三者的定义、工作原理、核心差异以及各自的适用场景帮助你构建清晰的 AI Agent 技术选型认知。2. Function Calling最底层的原生能力2.1 定义与起源Function Calling函数调用并非一个独立的协议或框架而是大语言模型 API 提供的一种原生能力。它最早由 OpenAI 在 2023 年 6 月提出随后被 Google Gemini、Anthropic Claude、百度文心一言、阿里通义千问等主流模型厂商广泛采纳。其核心思想是开发者可以在 API 请求中以 JSON Schema 的形式描述一组可用的函数包括函数名、参数描述、参数类型等。模型在理解用户意图后会判断是否需要调用某个函数并输出一个结构化的 JSON 对象包含要调用的函数名和参数。开发者拿到这个 JSON 后在自己的服务端执行该函数并将结果返回给模型模型再基于结果生成最终的回复。2.2 工作原理定义工具开发者定义一组工具Tools每个工具包含name、description和parametersJSON Schema。发起请求将用户消息和工具定义一起发送给 LLM API。模型决策LLM 分析用户意图如果认为需要调用工具则返回一个tool_calls对象而不是直接生成文本回复。执行工具开发者收到tool_calls后在自己的后端执行对应的函数如查询数据库、调用第三方 API。返回结果将函数执行结果作为新的消息toolrole发送回 LLM。生成回复LLM 结合工具返回的结果生成最终的、对用户友好的自然语言回复。2.3 核心特点标准化JSON Schema 是业界广泛接受的描述格式几乎所有主流模型都支持。低延迟由于是模型原生能力无需额外的中间层或协议转换调用链路最短。灵活性开发者可以定义任意复杂的函数只要能用 JSON Schema 描述其输入输出。局限性函数定义和调用逻辑完全由开发者自行实现缺乏统一的发现、认证和调用规范。每个 Agent 都需要硬编码其可用的工具集。2.4 典型应用构建一个能查询天气、设置提醒、发送邮件的个人助手。让 Agent 能够调用内部 API 查询订单状态或客户信息。实现一个能根据用户指令生成并执行 SQL 查询的数据分析助手。3. MCPModel Context Protocol标准化的工具连接层3.1 定义与起源MCPModel Context Protocol是由 Anthropic 在 2024 年底提出并开源的开放协议。它的目标不是取代 Function Calling而是在其之上构建一个标准化的、去中心化的工具生态。你可以将 MCP 理解为 AI 世界的“USB 协议”。USB 定义了设备如键盘、鼠标、U盘如何与主机电脑通信而 MCP 定义了工具服务器如文件系统、数据库、GitHub API如何与AI 客户端如 Claude Desktop、VS Code 插件、自定义 Agent通信。3.2 工作原理MCP 采用客户端-服务器Client-Server架构MCP Host用户直接交互的 AI 应用如 Claude Desktop、VS Code 中的 AI 插件。MCP Client运行在 Host 内部负责与 MCP Server 建立一对一连接。MCP Server轻量级程序每个 Server 暴露一组特定的工具、资源或提示。例如一个sqlite-server可以暴露query和execute两个工具。交互流程发现DiscoveryMCP Client 连接到 MCP Server 后Server 会发送一个listTools响应告知其所有可用的工具及其 JSON Schema 描述。调用Invocation当 Host 中的 LLM 决定使用某个工具时Client 会向 Server 发送callTool请求Server 执行操作并返回结果。资源访问Resources除了工具MCP 还定义了Resources类似文件系统中的文件用于向 LLM 提供上下文和Prompts预定义的提示模板。3.3 核心特点标准化与互操作性任何遵循 MCP 协议的 Server 都可以被任何 MCP Client 使用。开发者只需编写一次工具 Server就能被整个生态复用。去中心化工具不再需要硬编码在 Agent 代码中。用户或开发者可以自由安装、配置不同的 MCP Server像安装 App 一样扩展 AI 的能力。安全隔离MCP Server 运行在独立的进程中Host 可以通过配置权限如允许访问哪些目录、哪些网络端点来控制 Server 的行为提高了安全性。传输层抽象MCP 支持多种传输方式如 stdio本地进程间通信和 SSEServer-Sent Events用于远程服务器底层通信细节对上层透明。3.4 典型应用Claude Desktop用户可以通过安装 MCP Server让 Claude 直接读取本地文件、操作 SQLite 数据库、与 Figma 或 GitHub 交互。IDE 插件VS Code 中的 AI 编程助手可以通过 MCP Server 访问项目文件、运行终端命令、调用代码分析工具。企业级 Agent 平台公司可以开发统一的 MCP Server 来封装内部微服务 API让不同的 AI Agent 都能通过标准协议调用。4. Skills面向用户的任务封装4.1 定义与起源“Skills” 这个词在不同的平台如 ChatGPT 的 GPTs、字节跳动的 Coze、百度文心智能体平台中有不同的具体实现但其核心思想是一致的将一组指令、知识库和工具调用逻辑打包成一个可复用的、面向特定任务的“技能包”。Skills 是比 Function Calling 和 MCP 更高层次的抽象。它不关心底层是用的 Function Calling 还是 MCP它关心的是如何让非技术用户也能创建和分享一个能完成特定任务的 AI 助手。4.2 工作原理以 OpenAI 的 GPTs 为例配置用户通过自然语言界面告诉 GPT Builder 自己想要创建一个什么样的助手例如“一个能帮我写周报的助手”。指令Instructions系统会生成一组系统提示词定义该 GPT 的行为、语气和限制。知识Knowledge用户可以上传文档、PDF 等文件作为 GPT 的额外知识库。能力Capabilities用户可以选择开启哪些内置能力如网页浏览、DALL·E 绘图、代码解释器。动作Actions这是 Skills 与 Function Calling/MCP 结合的地方。用户可以通过 OpenAPI SchemaSwagger或 MCP 协议为 GPT 配置自定义的外部 API 调用。4.3 核心特点用户友好面向非开发者通过配置而非编码来创建 AI 应用。可复用与分享创建好的 Skill如 GPTs可以发布到商店供其他用户使用。组合性一个 Skill 可以包含多个工具、知识库和复杂的指令逻辑。平台绑定Skills 通常是特定平台如 ChatGPT、Coze的产物跨平台迁移性较差。4.4 典型应用设计助手一个 GPT内置了设计规范文档知识库并能调用 Figma API动作来生成设计稿。代码审查助手一个 GPT能读取 GitHub 仓库的 PR动作并根据团队编码规范知识库给出审查意见。旅行规划师一个 GPT能调用航班、酒店、地图等多个 API动作并根据用户偏好指令生成旅行计划。5. 三者对比一张表看懂核心差异特性Function CallingMCPSkills本质LLM API 的原生能力开放协议 / 标准应用封装 / 产品形态抽象层次底层中间层顶层核心目标让模型能输出结构化函数调用标准化工具与 AI 应用的连接方式让用户能轻松创建和分享 AI 助手使用者开发者开发者 / 平台终端用户 / 开发者工具发现硬编码在代码中运行时动态发现listTools配置时定义生态模型厂商各自为政开放、去中心化、跨平台平台封闭生态安全性由开发者自行实现协议层面支持隔离与权限控制由平台实现复杂度低中高对平台而言典型代表OpenAItool_callsAnthropic MCPOpenAI GPTs, Coze Bot6. 如何选择场景驱动的技术选型6.1 什么时候用 Function Calling你正在构建一个独立的、功能单一的 Agent例如一个只负责查询内部 CRM 系统的聊天机器人。你对延迟和性能有极致要求不希望引入额外的网络开销或协议转换。你的工具集是固定的、有限的不需要动态发现或用户自定义安装。你希望获得最大的模型兼容性因为几乎所有模型都支持 Function Calling。6.2 什么时候用 MCP你正在构建一个通用的 AI 平台或框架希望第三方开发者能轻松为其贡献工具。你的 Agent 需要访问多种异构系统如文件系统、数据库、云服务、SaaS 应用且这些系统可能频繁变化。你重视安全隔离希望将工具运行在沙箱环境中限制其权限。你希望你的工具生态能够跨平台复用一次开发同时支持 Claude Desktop、VS Code 插件、自定义 Web App 等。6.3 什么时候用 Skills你是一个非技术用户希望快速创建一个能完成特定任务的 AI 助手而不想写代码。你是一个平台方希望构建一个 AI 应用商店让用户能发现、安装和使用他人创建的 AI 助手。你需要将复杂的指令、知识库和多个工具组合成一个连贯的、面向特定场景的体验。7. 三者关系不是替代而是互补理解这三者关系的关键在于它们处于不同的抽象层次可以协同工作。MCP 可以基于 Function Calling 实现MCP Client 在调用 LLM 时底层使用的正是 Function Calling 能力。MCP 协议是对 Function Calling 的标准化封装。Skills 可以包含 MCP 或 Function Calling一个 Skill如 GPTs的“Actions”功能既可以配置为传统的 OpenAPI Schema底层是 Function Calling也可以配置为 MCP Server。三者共同构建了 AI Agent 的完整生态Function Calling提供了“让模型理解工具”的基础能力。MCP提供了“让工具可被发现和连接”的标准协议。Skills提供了“让能力可被组合和分享”的产品形态。8. 未来展望MCP 有望成为行业标准随着 Anthropic 的推动和社区的支持MCP 正在被越来越多的工具和平台采纳。它有可能像 LSPLanguage Server Protocol统一代码编辑器生态一样统一 AI Agent 的工具生态。Function Calling 将更加内化模型对 Function Calling 的支持会越来越好例如更精准的参数提取、更复杂的嵌套调用、甚至模型原生支持并行调用多个函数。Skills 将更加智能和自动化未来的 Skills 可能不再需要用户手动配置AI 可以自动分析用户需求动态组合和编排工具甚至自动生成新的工具调用逻辑。9. 总结概念一句话总结Function Calling让 LLM 能“理解”并“请求”调用外部函数的原生 API 能力。MCP标准化 AI 应用与外部工具之间通信的开放协议实现“即插即用”。Skills将指令、知识、工具打包成面向特定任务的、可分享的** AI 应用产品形态**。对于开发者而言理解这三者的区别至关重要。Function Calling 是基础MCP 是生态Skills 是产品。在实际项目中它们往往不是非此即彼的选择而是可以分层组合共同构建出强大、灵活且安全的 AI Agent 系统。
