当前位置：首页 > news >正文

大模型开发必看：Function Calling、MCP、Skill三者关系深度解析，一篇搞定！

news 2026/7/10 6:54:35

导语：别再把三者当成三个平行方案

Function Calling、MCP、Skill 都和“让大模型干活”有关，但它们解决的不是同一个问题。把它们混在一起，就很容易出现两个误区：要么觉得有了 MCP 就不需要 Function Calling，要么觉得 Skill 只是另一种插件。

更准确的理解是：Function Calling 是最底层的调用语言，MCP 是工具和数据源的标准接入层，Skill 是把经验、流程、脚本和模板封装成可复用能力的工作流层。

可以用一句话记住：Function Calling 像“语言”，MCP 像“工具箱”，Skill 像“操作手册”。语言让模型说清楚要调什么，工具箱让外部能力能被发现和复用，操作手册告诉 Agent 如何一步步完成复杂任务。

一、Function Calling：让模型说清楚“我要调哪个函数”

Function Calling 解决的是最基础的问题：模型本身不会真的查询数据库、发邮件、下单、创建文件，它只能生成文本。Function Calling 的作用，就是让模型用结构化格式告诉宿主程序：我想调用哪个函数、参数是什么。

OpenAI 官方文档把工具调用描述为一个多步流程：先把可用工具交给模型，模型返回工具调用请求，应用侧执行代码，再把工具结果回填给模型，最后模型继续生成回答或继续调用工具。

模型负责判断：这个任务是否需要调用工具。

模型负责生成：函数名和结构化参数。

应用负责执行：真实代码、数据库访问、API 请求。

应用负责兜底：权限、校验、重试、日志和错误处理。

Function Calling 示例

下面这个例子只是定义一个天气查询工具。模型看到用户问“上海明天天气怎么样”时，可能会生成一个 tool_calls，请求调用 get_weather。

{ "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称，例如 Shanghai" } }, "required": [ "city" ] } } }

这里要特别注意：模型输出的只是“调用建议”。真正去访问天气接口、处理异常、控制权限的，仍然是你的业务代码。

二、MCP：把工具变成标准化服务

当项目里只有三五个工具时，直接写 Function Calling 就够了。但当你有几十个工具、多个项目、多个 Agent、多个团队都要接入数据库、GitHub、文件系统、浏览器、内部 API 时，问题就来了：每个项目都要重复写一遍工具定义、鉴权、参数说明和调用适配。

MCP 要解决的就是这个重复接入问题。它把工具、资源和提示模板封装成标准服务，让不同 AI 客户端按统一协议发现和调用。MCP 官方文档把 MCP 定义为连接 AI 应用和外部系统的开放协议，并说明 MCP Server 可以提供 Tools、Resources、Prompts 等能力。

Tools：可执行动作，例如查数据库、调接口、发消息。

Resources：只读上下文，例如文件、数据库 schema、接口文档。

Prompts：可复用提示模板，例如生成日报、总结会议、规划旅行。

MCP Server 示例

下面是一个非常简化的 MCP 工具示例。真实项目里还要加认证、权限、日志和错误处理。

from mcp.server.fastmcp import FastMCP mcp = FastMCP("sales-tools") @mcp.tool() def query_sales(month: str) -> dict: """查询指定月份的销售数据""" return { "month": month, "revenue": 1280000, "top_product": "会员套餐" } if __name__ == "__main__": mcp.run()

有了 MCP，工具不再只是某个应用内部的一段函数，而是一个可以被不同 AI 客户端复用的标准服务。

三、Skill：把“怎么做事”封装成可复用流程

MCP 解决的是“有哪些工具能用”，但它没有告诉 Agent “复杂任务应该按什么顺序做”。比如你给 Agent 一堆工具：数据库查询、Python 执行、图表生成、Word 写入。它能不能稳定产出一份结构清楚的数据分析报告？这就需要 Skill。

Skill 的核心是 SKILL.md。它不仅告诉 Agent 什么时候使用这个技能，还会写清楚执行步骤、注意事项、模板、脚本位置和质量标准。Anthropic 对 Skill 的解释很像“给新员工的入职手册”：把某类任务的经验沉淀下来，让 Agent 在需要时加载。OpenAI Codex Skills 文档也强调了按需加载和渐进式展开，先只放名称和描述，真正需要时再读完整 SKILL.md。

SKILL.md 示例

一个数据分析报告 Skill 可以这样写。它不是告诉模型“调哪个 API”，而是告诉 Agent “这类报告应该怎么做”。

--- name: sales-analysis-report description: 当用户需要分析销售数据、找出下滑原因并生成报告时使用。 --- # 销售分析报告流程 1. 先确认分析范围：时间、产品线、地区、指标口径。 2. 使用数据库工具读取销售数据，不要凭空补数据。 3. 使用 Python 计算环比、同比、异常波动和 Top 产品。 4. 生成趋势图和问题归因表。 5. 按 references/report_template.md 输出最终报告。 ## 质量要求 - 每个结论都要能追溯到数据。 - 不确定的地方要标注“需要进一步确认”。 - 不允许直接编造销售额、增长率或产品排名。

四、放到一个故事里就清楚了

假设用户说：“帮我分析最近三个月的销售数据，找出下滑的产品线，并写一份改进建议。”

Skill 先介入：Agent 判断这是“销售分析报告”任务，于是加载对应 SKILL.md，知道要先确认指标、再查数据、再做分析、最后写报告。

MCP 再介入：Agent 通过 MCP Client 连接 sales-db、python-runner、doc-writer 等 MCP Server，发现可用工具。

Function Calling 逐步触发：模型生成 query_sales、run_python、write_report 等工具调用参数，由宿主程序或 MCP Server 真正执行。

最终输出：Agent 按 Skill 里的报告模板，把工具返回的数据、图表和结论整理成完整文档。

五、三者到底怎么选？

不要把这三个概念理解成“只能选一个”。真实工程里经常是一起用：Skill 定流程，MCP 提供工具，Function Calling 触发具体动作。

只需要让模型调用一两个内部函数：直接用 Function Calling。

多个 Agent、多个项目都要复用同一套工具：把工具封装成 MCP Server。

任务有稳定流程、固定模板、质量标准：沉淀成 Skill。

既要标准工具，又要稳定流程：Skill + MCP + Function Calling 一起用。

六、从代码和协议角度再看一遍

可以把三者放到一个执行栈里：Skill 在上层给任务“定路线”，MCP 在中间提供“工具目录”，Function Calling 在底层完成“具体调用”。

这也是为什么 MCP 和 Skill 都离不开 Function Calling。MCP Server 里暴露的工具，最终仍要以模型能理解的工具定义交给模型；Skill 里定义的流程，执行到某一步时也需要调用工具。

七、落地时最容易忽略的安全边界

一旦工具能读数据库、写文件、发邮件、创建工单，就不能只看“模型会不会调用”，还要看“它有没有权限调用、参数是否安全、失败能不能回滚”。

Function Calling 层：参数白名单、必填校验、权限校验、幂等控制。

MCP 层：Server 可信来源、认证授权、工具级权限、调用审计。

Skill 层：触发条件清晰、脚本来源可控、模板版本可追踪。

业务层：高风险操作必须用户确认，例如删除、转账、群发、提交审批。

八、面试回答可以这样说

Function Calling、MCP、Skill 不是三个平行竞争方案，而是 Agent 工程里的三层能力。Function Calling 是最底层，解决模型怎么用结构化参数触发一次函数调用；MCP 在中间，解决外部工具和数据源怎么标准化暴露、发现和复用；Skill 在最上层，解决复杂任务的流程、标准、模板和经验怎么复用。

举个例子，用户要做销售数据分析。Skill 先告诉 Agent 按什么步骤分析；MCP 提供数据库、Python、文档生成等工具；每一步真正执行时，模型通过 Function Calling 生成具体工具调用参数。这样三层分工明确：Skill 管流程，MCP 管工具，Function Calling 管调用。

说真的，这两年看着身边一个个搞Java、C++、前端、数据、架构的开始卷大模型，挺唏嘘的。大家最开始都是写接口、搞Spring Boot、连数据库、配Redis，稳稳当当过日子。

结果GPT、DeepSeek火了之后，整条线上的人都开始有点慌了，大家都在想：“我是不是要学大模型，不然这饭碗还能保多久？”

我先给出最直接的答案：一定要把现有的技术和大模型结合起来，而不是抛弃你们现有技术！掌握AI能力的Java工程师比纯Java岗要吃香的多。

即使现在裁员、降薪、团队解散的比比皆是……但后续的趋势一定是AI应用落地！大模型方向才是实现职业升级、提升薪资待遇的绝佳机遇！

这绝非空谈。数据说话

2025年的最后一个月，脉脉高聘发布了《2025年度人才迁徙报告》，披露了2025年前10个月的招聘市场现状。

AI领域的人才需求呈现出极为迫切的“井喷”态势

2025年前10个月，新发AI岗位量同比增长543%，9月单月同比增幅超11倍。同时，在薪资方面，AI领域也显著领先。其中，月薪排名前20的高薪岗位平均月薪均超过6万元，而这些席位大部分被AI研发岗占据。

与此相对应，市场为AI人才支付了显著的溢价：算法工程师中，专攻AIGC方向的岗位平均薪资较普通算法工程师高出近18%；产品经理岗位中，AI方向的产品经理薪资也领先约20%。

当你意识到“技术+AI”是个人突围的最佳路径时，整个就业市场的数据也印证了同一个事实：AI大模型正成为高薪机会的最大源头。