这段时间后台和社群里问得最多的问题就是Skill、MCP、Function Calling 到底是什么关系很多人一上来就把这三个词划等号觉得都是“让 AI 做点什么”的东西。其实这三个概念的层级完全不同放在一起比就像把菜谱、水龙头和通燃气管道放在一起比较它们有关联但根本不是一回事。这篇文章我打算用实战视角把它们彻底拆开。不绕理论先讲清楚每个概念解决什么问题再讲怎么在真实项目里组合使用最后把我踩过的坑和排查思路一并整理出来。适合正在做 AI 应用、Agent、智能体或者被 Codex、Trae、Claude Code 这一波工具搞晕的朋友参考。1. 概念拆解Skill、MCP、Function Calling 分别在解决什么问题1.1 Function Calling模型侧的输出约定Function Calling 本质上不是“AI 调用函数”而是“大模型按照约定输出一段结构化的函数调用指令”。你给模型传入一份工具清单每个工具描述自己的名字、功能、参数结构。模型读完用户的提问之后在需要的时候不直接回答结果而是返回一个类似{name: get_weather, arguments: {city: 北京}}的结构。真正执行函数的是你自己的代码执行完把结果塞回给模型模型再组织语言回答。所以它是模型 API 层的一种能力是模型和开发者之间的调用契约。我在实际开发里最直观的感受是Function Calling 把“让模型决定要不要调用工具”这件事标准化了。以前大家搞 ReAct 提示词让模型输出Action: xxx Action Input: xxx然后再写正则去解析简直痛苦。现在模型直接输出结构化 JSON错误率低得多。这里有个容易误解的点模型并不“会”执行函数它只是“会”提出调用请求。真正执行函数、访问数据库、操作文件、调用外部 API都是你自己的代码在做。这个边界一定要先立住否则后面理解 MCP 会有困难。1.2 MCP应用与工具之间的标准化接口MCP 的全称是 Model Context Protocol是 Anthropic 在 2024 年提出的开放协议。它解决的是“AI 应用怎么和外部工具、数据源连接”这件事。在没有 MCP 之前每接一个工具就要写一套自定义集成接 GitHub 要写 GitHub 集成接数据库要写数据库驱动接设计稿要写 Figma API 封装。每个 AI 应用都要重复造轮子而且不同应用之间还不通用。MCP 做的事情就是把这些工具的接口统一成一套标准工具方把能力包成 MCP ServerAI 应用通过 MCP Host 去连双方用一套固定的协议通信。技术结构上是三部分MCP Host 是运行 AI 应用的主程序比如 Claude Desktop、Codex、Trae 这类工具MCP Server 是暴露工具、资源、提示词的独立服务可以跑在本机也可以跑在远程服务器MCP Client 维护与 Server 的连接负责握手和路由。MCP 不只是“工具调用”。它定义了 Tools、Resources、Prompts 三类原语。Tools 是可执行操作Resources 是上下文数据Prompts 是可复用的提示词模板。也就是说它连“数据和提示”这种非执行类的东西也能一并接入。拿前端开发举例Figma MCP 能把设计稿的节点信息、颜色、尺寸、切图资源暴露给 AI 工具。你告诉 Claude 或 Trae 去看某个设计稿AI 不用靠截图猜布局而是直接读结构化的设计数据。这在做设计稿转代码时简直是质变。1.3 Skill任务执行的“技能包”Skill 是三者里最容易被误解的一个因为它至今没有一个像 MCP 那样全球统一的标准。不同产品对 Skill 的实现也有差异但行业里基本共识是Skill 是一组可复用的“任务执行资产”包含说明文档、工作流步骤、示例、模板有时还带校验脚本。如果说 Function Calling 是“模型怎么调用工具”那 Skill 就是“Agent 怎么把一件事做对”。它回答的是方法论问题接到一个任务后先做什么、再做什么、参考什么规范、输出什么格式、有哪些必须避开的坑。比如你经常让 AI 做前端页面评审就可以写一个 code-review Skill。里面规定先检查组件边界再检查状态管理再检查样式一致性和可访问性最后按固定模板输出评分和修改建议。以后每次让 Agent 做评审它就会自动按照这套流程执行而不是每次临场发挥。现在 Claude Code、Codex、Trae 这类工具都对 Skill 有不同程度的内置支持。典型的实现方式是在项目里挂一个skills目录里面每个子目录是一个技能核心是一个带 YAML 元数据的 Markdown 文件。元数据里写明技能名称、描述、触发条件Agent 会在对话开始时扫描这些技能根据用户意图决定要不要加载。Skill 可以包含动态能力但它的底层仍然是提示词、示例和步骤的结构化封装不能脱离模型和工具独立运行。它更像一份“战场手册”指导 Agent 在具体场景下怎么调度自己的工具链。2. 三者核心区别层级、粒度与调用链路的差异2.1 一句话说清边界我用一句话概括三者的关系Function Calling 是模型开口说话时用的语法MCP 是 AI 应用与工具之间连接用的插头标准Skill 是 Agent 把活儿干漂亮用的工作手册。这个类比虽然简单但能直接建立正确的心智模型。语法不对模型就说不出“我要调用这个函数”这句话插头不对即使模型说了也够不到对应工具手册不对就算工具齐了也容易把事情做乱。换句话说Function Calling 发生在模型推理的输出端MCP 发生在应用和工具的连接层Skill 发生在任务编排和决策层。它们不在同一个平面上所以不存在谁替代谁的问题。2.2 抽象层级模型能力、协议、编排方法从技术角度看Function Calling 是模型能力的大小。模型有没有经过工具调用训练、能不能准确输出结构化参数这是模型侧的问题。你换一个模型同样的工具定义调用准确率可能差很多。MCP 是一个协议标准。它不关心模型聪明不聪明只关心双方能不能按规范通信。MCP Server 可以同时被 Claude Desktop、Codex、Trae 等多个 Host 连接工具方只需要实现一次协议。Skill 是一种工程组织方式。它不属于模型 API也不属于协议层而归属于应用层。谁来维护技能库、技能怎么版本化、Agent 在什么时机加载技能都是应用设计者自己定义的事情。这三层里只有 Function Calling 是 Agent 技术栈中“模型原生能力”的部分。MCP 和 Skill 都是这个能力之上的工程化封装。2.3 调用链路里各管一段把它们放进同一条调用链路看会更清晰。用户输入请求后Agent 先拿到这个输入结合当前会话上下文做意图判断。这时候 Skill 就可能介入根据用户的描述Agent 判断要不要加载某个技能包。加载后Skill 里的步骤指引会影响 Agent 接下来的策略。接着 Agent 需要调用工具。工具如果来自 MCP Server就通过 MCP 协议把工具列表暴露出来转成模型能懂的 Function Calling schema。模型根据 schema 输出 tool_callsHost 拿到后执行再把结果返回给模型。整个过程里Skill 决定了走哪条流程MCP 决定了能借用哪些外部能力Function Calling 决定了模型如何表达调用意图。三者协同才构成一个完整的 Agent 任务闭环。很多初学者只看局部看不到这条链路。比如他们在 Function Calling 里手动接了一个工具就问“还需要 MCP 吗”其实你手动对接的行为就是自带私有协议对接MCP 只是把这段路标准化了让更多工具更容易接进来。2.4 核心差异对照表维度Function CallingMCPSkill所属层级模型 API 能力工具连接协议应用编排层核心问题模型如何表达调用意图应用如何连接工具Agent 如何把任务做对作用对象模型输出应用与工具之间的通信Agent 的流程与策略标准化程度各模型厂商接口有差异开放协议跨应用通用无统一标准产品实现各异典型实现OpenAI tool calling、Anthropic tool useMCP SDK、MCP ServerSKILL.md、技能目录、提示词包可替换性换成别的模型可能不兼容Host 换掉也能复用同一套 Server换到别的工具可能需要迁移这张表基本就是我在项目里做技术选型时的判断依据。遇到问题先定位层级是模型选得不对还是工具没接通还是流程没定义好。定位错了解决方案自然错。2.5 选型逻辑什么时候用哪个先判断需求。如果你只做一个简单的中台服务比如让用户问天气、查库存只需要在模型 API 里声明几个函数用 Function Calling 就足够了完全不需要引入 MCP更不需要搞复杂的 Skill。如果你要做一个通用 AI 助手或接入大量外部工具比如让 AI 既能查代码库又能操作浏览器还要连设计稿那 MCP 是更合适的方案。它让你不用一个个写私有集成工具生态里现成的 Server 也越来越多。如果你的 Agent 需要做复杂任务比如代码评审、数据分析报告、设计稿转前端代码这些任务有固定流程、有输出模板、有常见错误点那就必须上 Skill。因为它能把团队经验固化下来让每一次执行都有稳定的水平线。三者不是互斥关系。实际项目里它们往往是叠着用的用 Skill 定义流程用 MCP 连接工具用 Function Calling 完成底层调用。3. 实操解析三者在真实项目里怎么落地3.1 先用 Function Calling 把一个函数接进 Agent我拿一个最典型的最小示例说明。假设你要让模型帮忙查天气但模型自己没有实时天气数据只能调用你的接口。工具定义大概长这样import json from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: get_weather, description: 查询指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名比如北京 }, date: { type: string, description: 日期格式YYYY-MM-DD } }, required: [city, date] } } } ] messages [{role: user, content: 北京明天天气怎么样}] resp client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools )请求发出去后模型如果决定调用工具会返回tool_calls字段里面是结构化的调用请求。然后你要在代码里处理这个结果找到对应的函数执行再把执行结果作为新的消息回传给模型# 取出模型返回的调用请求 tool_call resp.choices[0].message.tool_calls[0] name tool_call.function.name args json.loads(tool_call.function.arguments) # 执行你的真实函数 result get_weather(args[city], args[date]) # 把结果回传给模型让它组织最终回答 messages.append(resp.choices[0].message) messages.append({ role: tool, tool_call_id: tool_call.id, content: result }) final_resp client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools ) print(final_resp.choices[0].message.content)这里的执行权在你自己手里。模型只是提出调用请求真正接管系统的是你的代码。不要指望模型替你执行任何代码它没有那个能力。关于 Function Calling我有几个实际心得工具描述写得越具体模型选工具的准确率越高。不要只写“查询天气”要写“查询指定城市在指定日期的天气情况返回天气现象、温度、风力”。参数名和枚举值要与业务语义一致。别用什么a、b这种缩写模型对语义理解非常依赖命名。每个函数的职责要单一。一个工具只做一件事参数控制在三到五个超过这个数模型出错率会明显上升。3.2 再用 MCP 把一批工具统一暴露出来如果你要接很多工具Function Calling 的手动维护成本会指数级上升。这时候 MCP 就派上用场了。假设你想让 AI 工具直接读你电脑上的某个目录。传统做法是写一个函数然后在 Function Calling 里手动声明。用 MCP 的话直接跑一个现成的文件系统 Server 就行。以 Claude Code、Trae、Codex 这类工具为例它们通常都支持通过配置文件维护 MCP Server 列表。配置格式大概是这样的{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/yourname/projects/demo ] } } }这段配置的意思是用npx启动一个 MCP Server这个 Server 暴露了/Users/yourname/projects/demo目录的读写能力。AI 应用启动时会按配置把 Server 拉起来通过本地标准输入输出来通信。在 Trae 这类 IDE 里一般在设置里能找到 MCP 管理入口图形化界面添加后它本质上维护的还是这个 JSON。Codex 和 Claude Code 里也是类似思路只是配置文件位置和命令略有差异。如果你做前端Figma MCP 值得重点关注。它可以把页面节点、图层结构、样式 token 以结构化数据的方式提供给 AI。配置时需要先拿到 Figma API Token把 Token 配到 Server 的环境变量里{ mcpServers: { figma: { command: npx, args: [-y, figma-developer-mcp], env: { FIGMA_API_KEY: 你的访问令牌 } } } }配置完成后你在对话里说“打开 Figma 里叫 xxx 的设计稿帮我提取它的配色方案”Agent 就能通过 MCP 直接读取设计稿数据而不是靠截图瞎猜。中文设计协作工具里蓝湖也有类似 MCP 能力。如果你团队用的是蓝湖配置思路一致先拿到蓝湖的访问令牌填到 MCP Server 的环境变量里然后在 Trae 的 MCP 管理中添加对应命令。接好以后设计稿里的标注、切图信息都能作为上下文直接被 AI 使用。MCP 这里有个非常容易踩的坑默认配置尽量给最小权限。比如文件系统 Server 只开放需要用的目录不要直接开放整个磁盘。因为 MCP Server 相当于把你本机的能力暴露给了 AI 编排逻辑一旦出现提示词注入或误操作权限范围越小越安全。3.3 最后用 Skill 把任务流程沉淀成可复用资产前面说 Skill 是一个“技能包”落到项目里通常是目录结构my-skills/ frontend-page-generator/ SKILL.md templates/ page-template.tsx examples/ social-feed-page.tsx核心是SKILL.md它同时包含元信息和执行手册。下面是一个示意模板--- name: frontend-page-generator description: 需要根据设计稿生成 React 页面或者需要把 Figma/蓝湖 MCP 返回的设计标注转成前端代码时使用。 --- # 前端页面生成技能 ## 触发场景 - 用户提供了 Figma 链接或 MCP 设计稿数据 - 用户要求“把这张设计稿做成页面” - 用户给出了页面截图和视觉规范 ## 执行流程 1. 先获取设计稿的节点信息和样式 token 2. 判断页面类型列表页 / 详情页 / 表单页 3. 按照项目 design system 定义的颜色、圆角、间距生成代码 4. 输出 React Tailwind 实现附带组件拆分明细 5. 标注需要后端数据联调的位置 ## 禁忌 - 不要自己发明色彩变量必须使用 design system 中已有的 token - 不要让页面产生横向滚动 - 不要生成未使用的 importAgent 在执行任务前会扫描这个目录根据元数据里的description判断当前任务是否需要加载这个技能。加载之后技能里的“执行流程”和“禁忌”就会作为上下文注入引导后续所有决策。这和直接写 Prompt 有什么区别区别在复用性和可维护性。Prompt 是一次性的技能包是可持续积累的。这周总结出的经验下周团队所有人都能用这个项目沉淀的规范换个项目复制目录就能重新生效。实践下来我认为 Skill 是最值得投入的环节。因为 Function Calling 和 MCP 解决的是“能不能用”的问题而 Skill 解决的是“用得好不好”的问题。同一个工具链有没有好 Skill执行质量可以差一个档次。4. 典型组合场景从设计稿到前端代码的完整 Agent 链路4.1 场景拆解拿一个我实际做过的场景举例让 AI 根据 Figma 设计稿生成某个页面的前端代码。这个任务单靠任何一个单独概念都做不好。光靠 Function Calling你得手动写一个 Figma API 集成还要把返回值塞进上下文工作量大且难以复用。光靠 MCP你能拿到设计数据但 AI 不一定知道怎么组织代码结构。光靠 SkillAI 知道流程但没有工具也拿不到数据。把三者组合起来链路就通了。用户说“生成这个设计稿对应的商品列表页面并给图上标了交互要求”。Agent 收到请求后先判断是否命中frontend-page-generator这个技能。命中后加载技能手册手册告诉它第一步是拉取设计稿数据。接着通过 Figma MCP 获取设计稿的节点、样式、资源。MCP Server 返回结构化数据Host 把数据转成模型可理解的 Function Calling schema模型调用相关工具拿到结果继续执行 Skill 手册里的后续步骤。生成代码过程中如果页面需要动态数据Agent 会调用后端 API 接口。这个接口同样通过 Function Calling 暴露。于是整个链路里的数据源有两个一个是 MCP 暴露的设计稿工具一个是 Function Calling 暴露的业务接口。4.2 链路中三者的分工这条链路里每个部分承担的角色非常清晰。Skill 是总指挥。它规定了任务的执行顺序先读设计稿再定页面类型再按设计系统生成代码最后标注联调位。没有这一步AI 可能拿到数据就直接开写容易出现风格不统一、结构混乱的问题。MCP 是情报系统。它负责把设计稿结构转化为 AI 能读取的信息。如果没有 MCP这一步要么靠人手动整理设计数据要么靠截图让模型猜精度和效率都会差很多。Function Calling 是执行手。真正逐个调用设计稿读取接口、后端数据接口的动作都通过 Function Calling 完成。MCP 里的工具最终也会被抽象成 Function Calling 的形式只是这个封装过程由 Host 完成开发者不需要手动写。三者各司其职缺一环整个链路就跑不顺。4.3 这个组合还能扩展到哪里这套组合不只适用于设计稿转代码。我后来把它复用到很多场景比如数据分析报告生成用 MCP 连接数据库和文件系统用 Function Calling 暴露分析计算函数用 Skill 定义分析报告的结构和输出格式。再比如代码仓库巡检用 MCP 连接 GitHub用 Function Calling 暴露代码搜索接口用 Skill 规定检查哪些维度和风险点。它们的共同点是任务有明确流程、需要外部工具支持、输出有固定规范。凡是满足这三个特征的任务都值得用这个组合来搭建。我会建议你从一个小场景开始验证这个链路比如“读取本地文件并生成摘要”配合“文件系统 MCP”和“一个文件分析 Skill”跑通后再扩展到更复杂的场景。5. 常见问题与排查技巧实录5.1 “MCP 和 Function Calling 不是重复造轮子吗这是最常见的疑问也是理解最偏的一个点。它们确实有重叠部分因为 MCP Server 暴露的 Tools 最终会被 Host 转换成模型能识别的 Function Calling schema。但从产品视角看两者完全不同。Function Calling 是你和单个模型交互时的接口方式。你换一个工具就要重新定义一遍。MCP 是应用与工具之间的通用协议。一次接入多个工具复用多个 Host 复用。更直白地说Function Calling 是“模型认可的语言”MCP 是“工具和 AI 应用都认可的插头”。插头最终会让语言被触发但它们要解决的问题不同。5.2 MCP Server 连不上的排查思路MCP 连接失败是高频问题。我整理了一套排查顺序先看启动方式。npx方式连接时要先确认本机有 Node 环境并且 npx 能正常执行。大部分莫名其妙的连接失败原因是本地没有装 Node 或者 npx 网络拉取失败。再看权限和路径。文件系统 MCP 打开的路径如果不存在启动会失败。Figma 之类需要 Token 的 ServerToken 无效或过期也是常见原因。然后看协议类型。MCP 有 stdio 和 HTTP/SSE 两种传输方式。本地工具一般用 stdio远程服务一般用 HTTP。配置时选错传输方式肯定连不上。最后看日志。很多 MCP 客户端在调试模式里能输出 Server 的启动日志日志能看到具体报错信息。5.3 Skill 不生效或命中率低怎么处理Skill 不生效最常见的原因是元数据里的description太模糊。Agent 要判断“什么时候用这个技能”完全依赖这段描述。描述里只写“用于生成页面”是不够的要写清楚触发场景和输入特征。第二个原因是技能内容过长。一个 SKILL.md 塞了几千字模型加载后上下文大量被占用反而影响判断。我的经验是技能手册尽量精简超过两千字就拆分子模块按需加载。第三个原因是技能目录没有放在正确位置。不同工具识别技能目录的规则不同有的是项目根的.claude/skills有的是skills有的是通过配置文件指定。先查工具文档确认扫描路径。5.4 上下文膨胀问题工具定义和技能描述都会占用上下文长度。接的 MCP Server 太多每个 Server 的工具都注入一遍再叠加几个 Skill上下文很快就满了。我的做法是分场景管理工具。做一个项目时只启用必要的 MCP Server不要让所有工具常驻。Skill 也同理不是越多越好而是越精准越好。实践下来三个以内的核心 Skill 加两三个 MCP Server是比较理想的配置。5.5 常见问题速查表症状可能原因处理思路模型不会调用工具工具描述太含糊或参数名不语义化重写工具描述明确触发条件和参数含义MCP Server 启动失败Node 环境缺失、路径不存在、Token 失效先本地直接执行命令验证再看日志多个工具场景下选错工具工具职责重叠描述区分度不够合并同类工具或在描述中写清边界Skill 从没被触发description 不够具体补充触发场景、输入特征和示例句式上下文很快用完常驻 Server 和 Skill 过多按任务场景裁剪保持最小必要集合Agent 输出质量忽高忽低流程约束不足把执行步骤、输出模板写进 SKILL.md我在实际操作中最深的体会是这三个概念的终极关系不在于你怎么区分而在于你怎么让它们配合。区分概念只是一个起点真正的价值是把 Skill 沉淀成团队资产、把 MCP 搭成通用接口、让 Function Calling 在底层稳定输出。我自己的习惯是每次遇到一个能反复执行的任务就想着能不能提炼成一个 Skill每遇到一个新的外部工具先查有没有现成的 MCP Server每接一个模型先跑一遍 Function Calling 的测试集。这套工作流跑顺了再做 Agent 类项目会轻松很多。希望这篇文章能帮你少走一点弯路。