好久没写博客了。这段时间一直在折腾 AI Agent 相关的东西，从 Function Calling 到 Skill，再到 MCP，踩了不少坑，也把一些概念理清楚了。这篇把这段时间学到的东西和感悟沉淀一下。

大模型本身只会生成文本，不会执行代码，也不会访问网络。要让 AI Agent 真正干活，需要给它接入外部工具。目前主流的接入方式有三种，Function Calling、Skill 和 MCP。这篇文章介绍三种方式的原理和区别。

Function Calling

Function Calling 是 OpenAI 在 2023 年年中加入的功能。开发者可以把工具声明成 JSON Schema，随请求一起发给模型。模型在回答时如果需要查询数据，会在返回的消息中带上 tool_calls 字段，指明要调用的工具和参数。

应用收到这个字段后执行真实的函数，再把执行结果作为新消息发回给模型。模型拿到结果后，生成最终的回答。

工具声明示例

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_weather",
        "description": "查询指定城市的实时天气",
        "parameters": {
          "type": "object",
          "properties": {
            "city": { "type": "string", "description": "城市名，如 北京" }
          },
          "required": ["city"]
        }
      }
    }
  ]
}

一次完整的调用流程

# 第一轮，用户提问
user: 北京今天天气怎么样？

# 模型不直接回答，返回调用意图
assistant: tool_calls=[get_weather(city="北京")]

# 应用执行真实函数，把结果作为新消息回传
user: tool_result=get_weather -> {"city":"北京","temp":31,"weather":"晴"}

# 模型基于真实结果组织最终回答
assistant: 北京今天 31 度，晴天，注意防晒。

这里需要注意，模型本身不会执行任何代码。它只负责决定调用哪个工具、传什么参数。真正的执行、权限校验和错误处理，都在应用层完成。

Skill

Function Calling 解决了模型调用工具的问题，但没有解决模型按正确流程操作的问题。以开发 Gutenberg 插件为例，需要先创建 block.json，再写渲染逻辑，还要处理块弃用。这些流程属于知识，模型需要一份操作指引。

2025 年 10 月，Claude 发布了 Agent Skills。一个 Skill 就是一个文件夹，里面有一个 SKILL.md 文件，用 frontmatter 声明 name 和 description 字段。模型根据 description 判断是否加载这个 Skill，加载后按里面的流程执行。

my-skill/
├── SKILL.md          # 主指令，何时使用、操作流程、验证清单
├── references/       # 深度参考文档
│   └── deep-dive.md
└── scripts/          # 可执行的辅助脚本
    └── check.mjs

name 和 description 的写法有规范。name 使用短横线连接的小写英文，例如 wp-block-development、human-writing，不使用空格和大写。description 用于说明 Skill 的使用场景，需要写清楚什么时候使用，规范要求达到 1024 字节。

ZCode 在这方面做得不好。它的技能列表将 description 截断在 250 多个字符，后面的内容无法显示，离 1024 字节差很多。模型判断是否加载 Skill，只能依赖前面的文字，后面的内容等于没有。下图是 ZCode 技能列表的截图，可以看到几个 Skill 的 description 都被截断了。

Skill 的安装非常简单，只需要把相关文档放到对应的位置，剩下的工作由 AI 自己完成。这个设计非常进步。

MCP

MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月开源的协议，用于统一 AI 应用接入工具的方式。应用作为 Client，工具方实现一个 Server，双方按协议通信。本地进程使用 stdio，远程服务使用 HTTP 或 SSE。

接入一个现成的 MCP Server，通常只需要一段配置

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

工具方实现一次协议，所有支持 MCP 的客户端都可以使用，这是 MCP 的主要价值。

不过 MCP 的缺点也很明显。目前网上的 MCP Server 很多都需要 Docker 容器运行，配置环境变量、挂载目录、维护镜像，一套流程下来比接入工具本身还麻烦。为了一个简单的功能起一个容器，有点高射炮打蚊子的感觉。这种使用方式对普通用户很不友好，甚至有些反人类。

相比之下，Skill 的安装就简单得多。只需要把相关文档放到对应的位置，至于如何调用 CLI，那是 AI 的事情。这个设计比 MCP 进步很多。

三者的分工

把三者放在同一个场景中看，分工很清晰。让 Agent 查询北京的天气并生成周报，MCP 负责接入天气服务，Function Calling 负责在对话中发起查询，Skill 提供周报的撰写流程。三者缺一不可。

维度	Function Calling	Skill	MCP
本质	模型调用工具的机制	指导模型行为的知识包	工具接入的标准协议
作用阶段	运行时，逐次调用	开发时，注入上下文	接入时，一次性配置
回答的问题	怎么调	怎么做	怎么接
例子	tool_calls 往返	SKILL.md 指令包	mcpServers 配置

Function Calling 解决模型如何调用工具，Skill 解决模型如何按流程操作，MCP 解决工具如何统一接入。遇到具体问题，先判断卡在哪一层，再针对性地处理。

---

本文 AI 含量：AI 文字占比 100%，人类思想占比 100%