苦猿的大模型日记 · 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(
    model="gpt-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("北京")

看完这段你应该懂了——模型只负责"报菜名",代码负责"上菜"。

它的天花板

每接一个工具,你都要在代码里手写三件事:

1. 这个工具的 schema(参数、返回值)
2. 一个 dispatcher(if tool_name == "xxx": call_xxx())
3. 结果回喂模型的逻辑

工具少没事,工具一多就崩——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 Server

from 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 内部的协议层,负责连接外部 Server
• MCP 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",三层分别干了啥——

1. Skills 层:模型识别出这是"周报"任务,加载 weekly-report-generator 这份菜谱
2. 菜谱第 1 步:读 Excel → 通过 MCP 协议调 excel-reader 工具
3. MCP 层:Claude Desktop 内嵌的 Client 把这次调用翻译成 Function Calling 格式,递给模型
4. Function Calling 层:模型吐出 {"name": "read_excel", "args": {...}} 的 JSON
5. 应用代码:执行函数,拿到数据,回喂模型
6. 菜谱第 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 学进简历