万字图文:从 Function Calling 到 MCP 再到 Skills：AI 工具调用的三次进化

导读上期小编挖了个坑——“后面会单独出一个系列介绍工具调用”。坑挖太久容易塌所以这期赶紧来填。本文带你一口气搞懂 AI 工具调用的三代技术演进Function Calling → MCP → Agent Skills。看完你就明白为什么给 AI “装手脚” 这件事比你想的复杂得多。万字长文建议收藏。一、填坑来了为什么工具调用值得单独写一篇“后面小编会单独出一个系列介绍工具调用这里先挖个坑。”说实话小编本来想挖着坑慢慢填。但后来发现——这个坑越不填越大。因为最近一年工具调用领域发生了太多事• Anthropic 发布了 MCP 协议整个行业跟进• OpenAI、Google、微软都宣布支持 MCP• Claude Code 引入了 Skills 机制改变了工具 vs 知识的边界• 社区开始争论MCP 是不是过度工程Function Calling 是不是就够了小编想了想与其分几期零散讲不如一篇文章把三代技术全部捋清楚。你只需要记住一条主线Function Calling → MCP → Agent Skills 硬连接 标准接口 操作手册好开始。二、Function CallingAI 从只会说到能动手2.1 它解决了什么问题在 Function Calling 出现之前LLM 就是一个**“缸中之脑”**——它能推理、能聊天但• 不知道现在几点• 不知道今天天气• 不能发邮件• 不能查数据库• 不能操作任何真实系统说白了它有脑子没有手。一句话定义Function Calling 让 LLM 学会了下达结构化指令——它不直接执行任务而是告诉你的程序我想调用哪个函数、传什么参数。小编给你打个比方想象一个坐在轮椅上的天才指挥官。他不能自己冲锋陷阵但他可以精确地下达命令“3 号士兵用步枪朝东南方向 200 米的目标射击。”Function Calling 就是这个精确下达命令的能力。模型是指挥官你的代码是士兵。2.2 它是怎么工作的——三步走早期的工具调用依赖 Prompt Engineering——开发者苦口婆心地写“请务必返回 JSON 格式不要多说废话。”结果呢模型经常抽风一会儿返回 JSON一会儿返回散文程序解析直接崩。OpenAI 引入 Function Calling 后把这个过程变成了严格的三步规范。小编用一个场景带你走一遍你问 Agent“查一下杭州明天天气”第一步契约定义Schema——给模型一份说明书开发者预先定义好工具的名片——用 JSON Schema 说清楚{ name:get_weather,description:查询指定城市的天气预报,parameters:{ type:object, properties:{ city:{ type:string, description:城市名称如 Hangzhou } }, required:[city]}}这张名片告诉模型我这里有个工具叫get_weather你想用它就必须给我一个city参数。第二步大脑决策——模型下达订单你问杭州明天天气怎样模型一看• 我自己没有实时天气数据• 但我有一个get_weather工具可以用• 用户提到了杭州于是它不再瞎编而是输出一份精确的调用请求{ name: get_weather, arguments: {\city\: \Hangzhou\}}注意此时模型没有联网没有调 API。它只是精准地提炼了你的意图翻译成了结构化指令。第三步闭环执行——Agent 跑腿 模型回复你的 Agent 程序收到这个 JSON去调真正的天气 API→ 调用 weather_api(Hangzhou)← 返回12°C小雨然后把结果塞回给模型。模型拿到真实数据后组织一段自然语言“杭州明天 12°C有小雨记得带伞哦”整个过程用一张图总结你杭州明天天气 ↓模型决策我要调用 get_weather(cityHangzhou) ↓Agent 执行调用真实 API → 得到 12°C/小雨 ↓模型回复杭州明天12°C有小雨带伞2.3 Function Calling 的局限Function Calling 很好但当你的工具从 3 个变成 30 个、甚至 300 个时——问题来了。小编自己经历过问题 1重复造轮子你给 Claude 写了一套工具定义给 GPT-4 又要重写一遍给 Gemini 再来一遍。格式不同、字段名不同、行为不同。三个模型三套代码维护成本爆炸。问题 2紧耦合工具定义硬编码在代码里。换个模型全部重写。换个应用场景全部重写。想让别人复用你的工具把代码 copy 给他。问题 3工具描述占上下文每个工具的 JSON Schema 都要塞进上下文窗口。工具一多光工具描述就占了几千个 Token——留给真正对话的空间就少了。“Function Calling 就像有线耳机——好用但每台设备都要买一根专用线。”这时候你就会想能不能有个标准接口写一次工具到处都能用这就是 MCP 要解决的问题。三、MCPAI 世界的USB-C 接口3.1 它是什么一句话定义MCPModel Context Protocol模型上下文协议是 Anthropic 推出的一套开放协议让 AI 应用可以通过标准化接口连接任何外部工具和数据源——写一次到处用。2024 年 11 月Anthropic 正式发布了 MCP 协议。他们给出的类比是MCP 之于 AI 工具就像 USB-C 之于硬件设备。以前每个手机充电器都不一样Micro-USB、Lightning、各种私有接口USB-C 一出来——一根线搞定所有设备。MCP 做的是同样的事以前每个 AI 应用Claude、GPT、Cursor接工具都要单独写代码有了 MCP——写一个 MCP Server所有支持 MCP 的应用都能直接接入。3.2 MCP 的三层架构Host / Client / ServerMCP 不是一个工具它是一套通信协议。要理解它怎么工作你得先知道三个角色小编用一个类比帮你记住•Host宿主 你家的电脑。它运行 AI 应用管理所有连接。•Client客户端 电脑上的 USB 接口。每个接口对接一个外设。•Server服务端 外接设备。键盘、鼠标、硬盘——各管各的功能。一个 Host 可以连多个 Server。每个 Server 独立提供能力。互不干扰。3.3 MCP 是怎么通信的两种传输方式方式使用场景大白话stdio(标准输入输出)本地server,跑在你自己的电脑上像两个人面对面说话不用网络sse/http远程server,跑在云端像打电话通过网络连接通信协议是JSON-RPC 2.0——说白了就是用 JSON 格式发消息按规范办事。3.4 MCP 的完整工作流小编用杭州天气这个例子走一遍 MCP 的全流程第一步建立连接InitializeClaude DesktopHost启动时看到配置里有一个天气 MCP Server。于是Host → Server你好我是 Claude Desktop你能干啥Server → Host我能查天气get_weather也能查空气质量get_air_quality双方握手完成Host 知道了 Server 有哪些能力。第二步发现工具List ToolsHost 把 Server 提供的工具列表注入到 LLM 的系统提示词中。现在模型看到了你有以下工具可用- get_weather(city: string)查询城市天气- get_air_quality(city: string)查询空气质量第三步调用工具Call Tool你问杭州天气模型决定调用get_weather模型 → Host我想调 get_weather参数 cityHangzhouHost → Client → Server转发调用请求Server调真实 API拿到结果Server → Client → Host → 模型返回12°C小雨和 Function Calling 有什么不同核心区别在于维度Function CallingMCP工具定义在哪硬编码在你代码里独立的server 进程换个AI应用重写一遍直接接入不用改别人写的工具复制代码到你项目加个server配置就行工具更新了该你的代码server自己更新你不用动3.5 MCP 的三大能力MCP Server 不只能提供工具它实际上有三种能力能力谁来决定使用大白话类比Tool(工具)模型自主决定调用“我能帮你干活”–查天气、发邮件、写文件你桌子上的计算器–你觉得你需要就拿起来用Resourses(资源)应用程序决定注入“我有数据给你看”–数据库内容、文件列表领导放你桌子上的参考资料–不是你选的但是你得看Prompts(提示模版)用户主动选择“我又现成的流程”–一键启动特定的工作流用户点击一个“快捷操作”按钮小编觉得这个设计挺聪明的不是所有东西都让模型自己决定用不用。有些信息是应用自动塞进去的Resources有些是用户手动触发的Prompts。**分层控制避免模型瞎调用。**3.6 MCP 的生态有多火自 2024 年底发布以来MCP 的生态增长速度超乎想象•主流大厂全面跟进GoogleGemini、OpenAI、微软VS Code、Copilot、AWS、Cloudflare 先后宣布支持•第三方 Server 爆发GitHub、Stripe、Linear、Slack、Notion、Postgres、Docker 等都发布了官方 MCP Server•开发工具原生支持Cursor、Windsurf、Claude Code、Zed 等 AI 编辑器已原生集成 MCP•MCP Registry社区搭建了中央发现仓库开发者可以搜索、安装、发布 MCP Server•远程 MCPCloudflare Workers 等平台支持将 MCP Server 部署为 Serverless 函数无需本地运行小编自己体验下来——MCP 最香的地方是别人写好的 Server你加一行配置就能用。比如要让你的 Agent 操作 GitHub以前要自己写 GitHub API 封装代码现在{ mcpServers:{ github:{ command:npx, args:[-y,modelcontextprotocol/server-github], env:{GITHUB_TOKEN:your-token} }}}加这么一段配置Agent 就能创建 PR、查看 Issue、管理仓库了。零开发成本。这就是标准化带来的生态红利——一个人写所有人用。四、MCP 出来后Function Calling 是不是就过时了这个问题最近社区争论很热闹。小编先说结论没过时。两者是不同层面的解决方案各有适用场景。4.1 一个反常的案例龙虾 AgentOpenClaw2025 年有一个现象级的开源项目叫OpenClaw中文名龙虾做的是本地个人 Agent。有意思的是——它明确选择了回归 Function Calling没有用 MCP。这是在开历史倒车吗小编研究了他们的设计文档总结出两个核心原因原因 1开发成本MCP 需要单独启动 Server 进程涉及生命周期管理连接、握手、心跳、断线重连。对于一个本地 Agent 就用 5-10 个工具的场景——这太重了。MCP 方式 启动 Server A 进程 → 启动 Server B 进程 → 握手 → 注册工具 → 调用 → 管理心跳...Function Calling 方式 定义 JSON Schema → 写业务逻辑函数 → 搞定说白了能跑就行远比符合国际协议重要。对很多独立开发者来说这是大实话。原因 2性能延迟MCP 在动态拉取工具列表list_tools时会消耗额外的 Token 和往返时间。在生产环境中如果工具列表是固定的——直接把 Function 定义写死在 Prompt 里速度更快、更省钱。小编实测过MCP 的 stdio 模式每次调用多了大约 50-100ms 延迟。单次不明显但如果一个任务需要连续调 20 次工具——这就是 1-2 秒的额外等待。4.2 那什么时候该用 MCP场景function callingMCP工具数量少10个且固定不变✅过度工程你只是一个模型/应用✅不需要标准化追求极致的延迟✅有额外开销工具被多个应用共享不够用✅工具由第三方提供自己重写累不稳定✅ 直接接入工具列表动态变化硬编码不稳定✅动态发现需要安全隔离(server独立进程)自己做隔离✅天然隔离一句话总结MCP 是工具的**分发方案**Function Calling 是工具的**集成方案**。分发给全世界用 MCP自己内部用 Function Calling 就够了。五、Agent Skills比能连接更重要的是会使用5.1 MCP 的两个痛点MCP 解决了标准化连接的问题。但小编在实际使用中发现了两个新问题痛点 1上下文爆炸一个 MCP Server 可能暴露几十甚至上百个工具。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中。社区开发者实测数据仅加载一个 Playwright MCP Server 就占用了 200K 上下文窗口的 8%。你接 3-5 个 Server20-40% 的上下文就被工具描述占了。留给真正对话的空间严重压缩。在多轮对话中这个问题更严重——Token 成本飙升推理能力下降。痛点 2能力鸿沟——“能连上≠会用”MCP 解决了能够连接的问题但没有解决知道如何使用的问题。举个例子你给 Agent 接了一个数据库 MCP Server。Agent 现在可以执行 SQL 了。但它知道• 你的数据库有哪些表表结构是什么• 查员工信息应该 JOIN 哪几张表• 有哪些查询是绝对不能执行的比如 DROP TABLE• 返回结果太多时应该怎么分页答案是它不知道。MCP 只给了它手没给操作手册。小编打个比方这就像给一个新入职的员工开通了所有系统的访问权限但没给他任何培训资料和操作规范。他有权限登录 CRM、ERP、数据库——但他完全不知道该怎么用。5.2 Agent Skills 是什么一句话定义Agent Skills 是一种标准化的程序性知识封装格式——如果 MCP 给了 AI “手”Skills 就给了 AI “操作手册”。Skills 不是工具不提供 API不是 Prompt不只是文字指令。它是一个知识包包含• 什么时候该用这个技能• 具体怎么一步步做• 有哪些注意事项和坑• 需要调用哪些工具、怎么组合• 可能还有脚本和参考文件一句话区分三者属性Function CallingMCPAgentSkills本质一次函数调用一个标准化接口一本操作手册提供的是“手”“标准化的手”“大脑里面的SOP”类比一个按钮USE-C接口应用软件小编再展开类比•MCP像 USB 接口或驱动程序——定义设备如何连接•Skills像应用软件——定义如何使用这些设备完成任务你可以有一个完善的打印机驱动MCP但如果没人告诉你怎么在 Word 里设置双面打印Skill你还是搞不定。5.3 Skills 最核心的创新渐进式披露前面说了MCP 的一大问题是上下文爆炸——所有工具描述一次性全塞进去。Skills 的解决方案非常聪明分三层加载按需逐步披露。小编用一个比方帮你理解想象你新入职一家公司。公司不会在第一天就把所有部门的操作手册、全部流程文档、几百个系统的使用指南全塞给你。那样你会当场崩溃。合理的做法是•第一天入职手册告诉你公司有哪些部门、各干什么——你大概知道有什么就行•接到任务时岗位培训你被分到市场部OK现在才给你市场部的详细流程•遇到具体问题时查手册你需要用某个系统这时候才打开那个系统的操作指南Skills 的三层加载机制一模一样第一层元数据Metadata—— “公司有哪些部门”Agent 启动时只扫描每个 Skill 的名片——名称、一句话描述、触发词。---name: wechat-article-writerdescription: 撰写微信公众号技术文章时使用此 skilltriggers: - 写公众号文章 - 微信文章 - 改写成公众号---每个 Skill 的元数据只占约 100 个 Token。就算你装了 50 个 Skill初始消耗也只有 ~5000 Token。对比 MCP连一个 Playwright Server 就占 16000 Token。差距是数量级的。第二层技能主体Instructions—— “岗位培训手册”当用户的请求匹配到某个 Skill 的触发条件时Agent 才加载这个 Skill 的完整内容。比如用户说帮我写一篇公众号文章Agent 匹配到wechat-article-writer这时才把完整的写作规范、文章结构、风格要求全部加载进上下文。这部分通常 1000-5000 Token取决于指令复杂度。第三层附加资源Scripts References—— “具体问题查手册”对于复杂的 Skill还可以附带脚本、模板、参考文档。Agent 只在具体执行到那一步时才加载。skills/pdf-processing/├── SKILL.md # 主技能文件├── parse_pdf.py # PDF 解析脚本需要时才执行├── forms.md # 表单指南遇到表单任务才加载└── templates/ # 模板文件需要时才访问结果你可以给 Agent 装几十个 Skill它的初始上下文消耗非常小。只有当任务真正需要某个 Skill 时才展开那个 Skill 的详细内容。这就是渐进式披露的威力——**不是一次性全塞进去而是用多少加载多少。**5.4 Skills MCP不是竞争是互补理解了三代技术的差异后你会发现——它们不是互相替代而是各管一层。最佳实践是把三者组合成分层架构小编用一个实际场景带你走一遍这个分层场景用户问 “分析一下公司里谁的话语权最高”Skills 层介入Agent 识别到这是一个数据分析类任务加载mysql-employees-analysis技能。Skill 里定义了• 分析话语权需要看哪些维度管理关系、薪资水平、任职时长、汇报线• 应该查哪些表、怎么 JOIN• 返回结果应该怎么解读MCP 层执行Skill 指导 Agent 调用数据库 MCP Server执行具体的 SQL 查询•SELECT * FROM managers JOIN employees ON ...•SELECT salary, title FROM ...Function Calling 层MCP Server 底层调用实际的数据库驱动执行 SQL。最终结果Agent 基于 Skill 里的领域知识把原始数据解读为有意义的结论返回给用户。这种架构的好处优势说明关注点分类MCP管“能力连接”Skills管“领域智慧”成本优化渐进式加载token消耗最小化可维护性业务逻辑(skills)和基础设施MCP解耦复用性同一个MCP Server 可被多个skills复用5.5 如何写好一个 Skill小编总结了几条实战原则基于自己写代码审查 Skill 的经验原则 1描述要回答什么时候加载我不是我是什么# ❌ 坏的描述description: 这是一个代码审查技能# ✅ 好的描述description: 当用户提交代码要求 Review、检查代码质量、或合并 PR 前审查时使用Agent 扫描描述是为了判断要不要加载你——所以描述要像触发条件不像自我介绍。原则 2触发词覆盖多种说法用户可能说帮我 review 代码也可能说看看这段代码有没有问题。你的触发词要尽量覆盖各种说法triggers: -review 代码-代码审查-检查代码质量-帮我看看这段代码-PR review- code review原则 3指令要像 SOP不像散文# ❌ 坏的指令散文式审查代码时要注意安全性、性能和可读性同时关注命名规范和错误处理...# ✅ 好的指令SOP式## Step 1 — 理解上下文1. 确认变更的目的修 Bug / 新功能 / 重构2. 查看关联的 Issue 或需求描述3. 了解影响范围涉及哪些模块## Step 2 — 逐层审查1. 安全性是否有 SQL 注入、XSS、硬编码密钥2. 正确性边界条件、空值处理、并发安全3. 性能是否有 N1 查询、内存泄漏、死循环风险4. 可维护性命名清晰度、函数长度、重复代码...越结构化、越具体Agent 执行得越好。原则 4声明退出条件——什么算做完了## 完成标准- [ ] 所有文件都已逐一审查- [ ] 安全类问题标记为「必须修复」- [ ] 每条审查意见标注了严重等级P0/P1/P2- [ ] 给出总体评价通过 / 需修改 / 打回重写没有退出条件的 SkillAgent 可能无限循环或提前结束。原则 5Skill 内部可以调用 MCP 工具好的 Skill 不是替代MCP而是编排MCP。在指令里明确说用什么工具做什么事## Step 3 — 提交审查结果1. 使用 GitHub MCP Server 在 PR 上逐行添加 Review Comment2. 对于安全类问题调用 Jira MCP Server 自动创建 Bug 工单3. 使用消息 MCP Server 通知提交者审查已完成这样 Skill 负责决策和编排MCP 负责执行具体操作——职责清晰。5.6 一个完整的 Skill 工作场景小编用一个大家都遇到过的场景带你走一遍有 Skill 的 Agent是怎么工作的场景你对 Agent 说帮我看看这周的 Bug 列表写封周报邮件发给领导这件事你自己做大概要打开 Jira 查 Bug → 筛选本周的 → 分类汇总 → 写成邮件 → 发送。30 分钟起步。现在看 Agent 怎么做——第一步元数据匹配Agent 扫描所有已安装 Skill 的元数据发现weekly-report-writer匹配了用户说的写封周报邮件Skill 触发词[周报, weekly report, 写周报, 汇报邮件]→ 匹配加载这个 Skill此时消耗~100 Token。其余几十个 Skill 完全不占上下文。第二步加载完整指令Agent 读取这个 Skill 的完整内容。现在它知道了• 周报的标准格式本周完成 / 进行中 / 下周计划 / 风险项• Bug 应该按严重程度分组不是按时间• 领导喜欢先看结论再看细节金字塔结构• 邮件标题格式[周报] XX团队 第N周工作汇报• 语气要求专业但不啰嗦重点加粗没有这个 SkillAgent 可能写成流水账或格式乱七八糟。有了 Skill它写出来的周报就像你组里最靠谱的那个同事写的。第三步按 SOP 执行Skill 编排 MCP 执行Skill 定义了清晰的步骤Agent 依次执行Step 1调用 Jira MCP Server → 查询本周所有 Bug状态、优先级、负责人Step 2按 Skill 指令分类 → P0/P1/P2 分组 已解决/进行中/待处理Step 3调用日历 MCP Server → 看看本周有没有重要会议/里程碑Step 4根据 Skill 模板组织邮件正文 → 金字塔结构结论先行Step 5调用邮件 MCP Server → 发送给领导抄送组内成员注意这里的分工•Skill 负责怎么做分组逻辑、格式模板、语气要求•MCP 负责去执行查 Jira、读日历、发邮件第四步退出检查Agent 对照 Skill 里定义的完成标准自检• Bug 数据来源是本周不是上周的旧数据• 邮件标题符合格式• 有风险项板块领导最关心的• 收件人正确发给领导抄送组员• 邮件已成功发送全部通过 → 任务完成。你收到 Agent 的回复“周报已发送本周共处理 12 个 Bug其中 P0 级 2 个已修复。”从你说话到邮件发出可能就 30 秒。小编想强调的点是——如果没有 SkillAgent 也能写周报。但它写出来的很可能是• 格式不对领导看了想打人• 分类混乱P0 和 P2 混在一起• 重点不突出埋在一堆细节里• 语气不合适要么太随意要么太正式Skill 的价值不是让 Agent “能做”而是让它做得对、做得好。Skill 让 Agent 从什么都能干但什么都干不精变成了接到任务就像老员工一样驾轻就熟。六、全景总结三代技术一张表维度Function CallingMCPAgentSkills诞生时间20232024年底2025年底创造者OpenAIAnthropicanthrppic定义让模型输出结构化工具调用让模型通过标准协议被任何应用接入让Agent拥有领域的知识和工作流解决的问题AI不能动手工具不能被复用AI会玲姐但是不会精准的使用工具类比有线耳机USB-C接口应用软件上下文消耗中等工具定义常驻高每次都需要加在所有schema低渐进式加在适用场景内部简单工具绑定跨应用工具共享复杂领域任务编排关系基础层中间层上层演进关系Function Calling → MCP → Agent Skills 能动手 手能通用 知道怎么用好手“从 Function Calling 到 Skills本质上是从’连接’到’智慧’的跃迁。”好了三代工具调用技术全部讲完。回到最开始的问题——该选哪个小编的建议很实际•刚入门、做 Demo直接用 Function Calling简单够用•要做跨应用共享、接第三方工具上 MCP•做复杂的领域任务、需要 Agent “真的懂业务”写 Skills•生产级系统三层都用各管各的层说实话小编自己目前的项目就是三层混合的——MCP 接数据库和文件系统Skills 定义写作流程和质量标准Function Calling 处理一些简单的内部逻辑。分工明确各司其职。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】