苦猿的大模型日记 · Day20 · AI Agent 三件套——Function Calling / MCP / Agent Skills 怎么分-帮普通人把AI学进简历系列前言:你让 AI 做一份周报 PPT,背后其实有三件东西在分工想象一下——你打开 Claude,说一句把这周的 Excel 数据做成一份周报 PPT,过了两分钟,真的出来了。Excel 读到了,关键指标挑对了,模板套上了,甚至自动生成了一张柱状图。整个过程,你只说了一句话。但这背后不是AI 一个能力干完了所有事,是三件完全不同的东西在分工。网上教程把这三件混着讲——有人管它叫 Function Calling,有人叫 MCP,有人说 Agent Skills 才是真 Agent。越看越乱,看完还是分不清。我换个说法,你立马就懂。这三件,就像做菜里的三件事:菜谱、厨房接口、切菜动作。Function Calling 是切菜颠勺的手上功夫——最底层,2023 年就有了MCP 是厨房的标准接口——任何厨具都能插任何厨房,2024 年出的Agent Skills 是菜谱——告诉模型这道菜分几步、每步注意啥,2025 年才开始,2026 年火起来的刀工不行,菜做不熟;接口不统一,厨房乱成一锅;没菜谱,只会炒蛋。这三层不分清楚,选 AI 工具会买错、做 AI 应用会写错、看技术新闻会理解错。今天一篇讲透,以后再看到这三个词,你心里那张图就有了。PART 01:Function Calling——最底层那把刀时间倒回 2023 年 6 月,OpenAI 干了一件事——让 GPT 学会喊一声我要调函数。这就是 Function Calling。一句话本质让模型把我想调用查天气函数用结构化 JSON吐出来,而不是用自然语言胡说一通。关键反差点:模型并不会自己调用函数,它只是吐 JSON。真正执行函数的,是你的应用代码。很多人这里就误解了——以为开了 Function Calling 模型就能联网、就能查数据库。不是,它只是变成了会报菜名的人,报完之后菜还得你来做。最小代码片段from openai import OpenAI client OpenAI() resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 北京今天天气怎么样?}], tools[{ type: function, function: { name: get_weather, description: 查询某城市天气, parameters: { type: object, properties: {city: {type: string}}, required: [city] } } }] ) # 模型吐出来的不是天气,是一段 JSON 指令 tool_call resp.choices[0].message.tool_calls[0] # {name: get_weather, arguments: {city: 北京}} # 真正去查天气的,是你自己写的代码 result get_weather(北京)看完这段你应该懂了——模型只负责报菜名,代码负责上菜。它的天花板每接一个工具,你都要在代码里手写三件事:这个工具的 schema(参数、返回值)一个 dispatcher(if tool_name xxx: call_xxx())结果回喂模型的逻辑工具少没事,工具一多就崩——schema 写错、命名冲突、版本管理、跨框架不兼容。我见过一个客服 Agent 里塞了 12 个 Function Calling 工具,光维护 schema 就两个工程师干了一周。然后换到 LangChain 又得重写一遍。这就是 MCP 要解决的问题。PART 02:MCP——把工具接入做成标准接口2024 年 11 月,Anthropic 干了第二件大事——推一个标准协议,叫 MCP(Model Context Protocol)。解决什么痛工具方写一个 Function Calling schema,在 LangChain 里要用、在 LlamaIndex 里要用、在 Cursor 里要用、在 Claude Desktop 里要用……每换一个框架,重写一遍。工具方累,框架方也累。MCP 出来之后,变成这样:工具方写一次 MCP Server,所有支持 MCP 的客户端都能用。一句话类比——MCP 之于 AI 工具,就像 USB-C 之于电子设备、HTTP 之于网站。一个最小 MCP Serverfrom mcp.server.fastmcp import FastMCP mcp FastMCP(weather-server) mcp.tool() def get_weather(city: str) - str: 查询某城市天气 return fetch_weather(city) if __name__ __main__: mcp.run() # 任何 MCP 客户端都能连写完这一段,Claude Desktop、Cursor、Continue、Cline 全部能直接调你的get_weather,你不用为任何一家单独适配。三个角色的关系MCP 体系里有三个角色,新人最容易混:MCP Host:你的 Agent 应用(Claude Desktop / Cursor / 自己写的 Agent)MCP Client:Host 内部的协议层,负责连接外部 ServerMCP Server:工具方写的,暴露工具能力MCP Host (Claude Desktop) ↓ 内嵌 MCP Client ↓ 协议层 MCP Server A / Server B / Server C (天气 / 数据库 / 文件系统...)一个最关键的误解用了 MCP,就不用 Function Calling 了吗?——错。MCP 底层照样靠 Function Calling 让模型决定调谁。MCP 解决的不是模型怎么决定调谁,是工具怎么暴露给应用。一个是模型层,一个是应用层,二者不是替代,是堆叠。记住这句话:Function Calling 是模型的本能,MCP 是应用的协议。PART 03:Agent Skills——再往上一层菜谱讲到这里,前两层都还是怎么调工具。但你回头想那个周报 PPT 的例子——Claude 不是只调了一个工具,它完整地完成了一个任务:读 Excel、挑指标、选模板、做图表、排版。会切菜不代表会做菜。2025 年 Anthropic 推出 Agent Skills,2026 年 Spring AI、DeepLearning.AI 跟进——这一层,才是会做菜。一句话本质Skills 是用 markdown 写的指令包,模型自己判断何时该用、怎么用。不是调一个工具,是完成一个完整任务,中间可能调多个工具。一份最简 Skill 长这样--- name: weekly-report-generator description: 把 Excel 数据生成周报 PPT --- # 周报 PPT 生成器 ## 步骤 1. 读取用户上传的 Excel 文件 2. 提取关键指标(收入/DAU/转化率) 3. 从模板库选 business-weekly 模板 4. 每个指标生成一页幻灯片,配柱状图 5. 输出 .pptx 文件 ## 注意 - 数量级差超过 100 倍时,柱状图改用对数坐标 - 缺失值用 N/A 标注,不要用 0就这么一段 markdown,模型看到做周报任务会自动加载它,按步骤走。Skills 跟前两层什么关系回到厨房比喻——Function Calling是切菜颠勺(底层动作)MCP是厨房接口(让任何厨具都能用)Skills是菜谱(告诉厨师这道菜分几步、每步注意啥)一个 Skill 可以编排多个 MCP 工具。比如周报 Skill 里,第 1 步调的是文件读取 MCP、第 3 步调的是模板库 MCP、第 4 步调的是图表生成 MCP。Skills 是做什么,MCP 是用什么。为什么 2026 年才火Agent Skills 真正有意思的不是技术——技术就是 markdown,谁都会写。有意思的是它打开了一个市场。Skills 是 markdown 文件,意味着它可以被分享、被买卖、被打包。GitHub 上anthropics/skills仓库已经攒了一堆社区贡献的 Skill,从艺术创作到 Excel 处理到 PDF 解析。很多人开始问一个事——Skills 市场,会不会变成下一个 App Store?PART 04:三层一张图讲清——以及你该关心什么讲了这么多,落到一张图。┌─────────────────────────┐ │ Agent Skills │ ← 菜谱:做什么菜 │ (markdown 指令包) │ └────────────┬────────────┘ │ 编排调用 ┌────────────▼────────────┐ │ MCP │ ← 接口:能用哪些厨具 │ (标准协议/工具发现) │ └────────────┬────────────┘ │ 底层依赖 ┌────────────▼────────────┐ │ Function Calling │ ← 切菜:模型怎么报菜名 │ (模型吐 tool_calls) │ └─────────────────────────┘用周报 PPT 那个例子全程拆一遍你说做一份周报 PPT,三层分别干了啥——Skills 层:模型识别出这是周报任务,加载weekly-report-generator这份菜谱菜谱第 1 步:读 Excel → 通过 MCP 协议调excel-reader工具MCP 层:Claude Desktop 内嵌的 Client 把这次调用翻译成 Function Calling 格式,递给模型Function Calling 层:模型吐出{name: read_excel, args: {...}}的 JSON应用代码:执行函数,拿到数据,回喂模型菜谱第 2-5 步重复这个循环……三层缺一不可,但分工极其清晰。普通人该怎么用这三层选 AI 工具时——看它有没有 Skills 层,还是只是 Function Calling 套壳。判断方法很简单:让它完成一个多步骤的完整任务(比如读这份 PDF 然后总结成 PPT)。只会单次调用工具的,是 FC 套壳;能自己分步走完的,大概率有 Skills 类的抽象。想做 AI 应用三层分别要不要碰——Function Calling 必学:这是底层,绕不开MCP 早学:协议层不复杂,但能让你的应用接生态Skills 等生态成熟再深入:目前还在快速演进,先观察给开发者一个反直觉判断90% 的应用只需要 Function Calling,不必上 MCP。工具数低于 5 个、只服务自己一个产品,MCP 是过度工程。但 100% 的应用,最后都会被 Skills 这类抽象吃掉。今天你手写的 prompt 工具编排,明天就是一份 markdown。所以三层投入精力的比例,我给个参考——5:3:2(FC : MCP : Skills)。底层花最多时间,因为它最稳。结尾:三层不是替代,是堆叠很多人一上来就问:Function Calling、MCP、Agent Skills,我学哪个?这不是三选一,是三层楼。刀工不行,菜做不熟;接口不统一,厨房乱成一锅;没菜谱,只会炒蛋。Function Calling 是手,MCP 是路,Agent Skills 是地图——三件套缺一不可,但顺序永远是从下往上修。未来真正的 AI 应用工程师,三层都要懂;但真正的护城河,永远在最底下那一层。互动时间:你被网上哪种Function Calling Agent的教程坑过?还是 MCP 上手时被 SDK 卡到怀疑人生?评论区聊聊,下一篇把最坑的几个点拆开讲。下一篇预告:Agent 三件套讲完,Day21 回到微调主题。攒了一波 GRPO 之后的实战调参经验,准备一次性写出来——RAG/Agent 这条线告一段落,关注苦猿看微调回归。— END —苦猿 · 帮普通人把 AI 学进简历