前言

这是我的agent系列文章的第2篇，该系列分为三部分：

• AI认知篇：详细讲解相关基础概念
• AI实践篇：分享诸如skills怎么写、怎么ai coding、怎么写好prompt等的最佳实践
• AI八股篇：分享我自己整理的应付大模型应用开发岗位必备的八股笔记

如果觉得有帮助，欢迎关注我并期待后续文章！预期是日更哦！当天没更可能是因为太累了，周末会弥补的。

做 AI Agent 开发，总被 Function Calling、MCP、Skills 这三个概念绕晕？其实三者层层递进，MCP 和 Skills 都基于 Function Calling 打造，只是解决的实际问题不同，二者甚至并非互补，而是核心竞争关系。这篇文用通俗的语言讲清三者的本质、差异和适用场景，快速上手不踩坑。

1.先懂底层：AI Agent 工具调用的核心逻辑

不管是哪种技术，AI Agent 调用工具的核心流程都只有 4 步，也是 Function Calling 的设计基础：

一个典型的 AI Agent 工具调用流程是这样的：

1、LLM 接收用户请求和工具描述

• 用户提出需求（比如 "帮我查一下北京今天的天气"）
• 系统向 LLM 提供可用工具的列表和描述（比如 "天气查询工具：可以查询指定城市的天气信息"）

2、LLM 决定是否需要调用工具

• LLM 根据用户需求和工具描述，判断是否需要调用工具
• 如果需要，LLM 会生成结构化的工具调用请求

这里的关键是 LLM 返回的是结构化的 JSON 格式，而不是自然语言。比如用户说 "帮我查一下北京今天的天气"，LLM 可能会返回：

{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "id": "call_abc123",
            "type": "function",
            "function": {
              "name": "get_weather",
              "arguments": "{\"city\": \"北京\", \"date\": \"today\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ]
}

这种结构化的输出格式，就是 Function Calling 的核心机制。它让系统能够稳定地解析 LLM 的意图，而不需要复杂的文本解析逻辑。注意关键字段：

• tool_calls：当需要调用工具时，这里包含工具调用的信息；
• function.name：要调用的工具名称；
• function.arguments：工具的参数（JSON 字符串格式）；

3、系统解析并执行工具调用

• 系统解析 LLM 生成的工具调用请求；
• 执行对应的工具函数（比如调用天气 API）；
• 获取工具执行结果

还是以上面的 llm 返回为例，上面的 JSON 格式会被系统解析并转换为真正的函数调用。以 JavaScript 为例：

// 1. 从LLM响应中提取工具调用信息
const toolCall = response.choices[0].message.tool_calls[0];
const functionName = toolCall.function.name;  // "get_weather"
const functionArgs = JSON.parse(toolCall.function.arguments);  // {city: "北京", date: "today"}

// 2. 根据工具名称找到对应的函数
const tools = {
  get_weather: (city, date) => {
    // 执行天气查询逻辑
    return `北京今天天气：25°C，晴天`;
  },
  // ... 其他工具
};

// 3. 执行工具调用
const result = tools[functionName](functionArgs.city, functionArgs.date);
// 实际调用：tools["get_weather"]("北京", "today")

这个过程是自动的：系统根据function.name找到对应的函数，解析function.arguments获取参数，然后执行调用。这就是 Function Calling 让工具调用变得可预测和可靠的核心机制。

4、将结果返回给 LLM

工具执行结果被返回给 LLM；

LLM 根据结果决定下一步行动（继续调用工具，或者生成最终回答）。

小结：function calling工具调用的本质

这个流程的核心在于：LLM 需要把用户的非结构化需求（一段自然语言文本）转换为结构化的函数调用（函数名和参数），然后与其他应用程序交互，再将结构化结果返回给模型，让模型能够基于这些结果进行下一步决策。

问题的本质在于，历史上其他系统（数据库、API、文件系统等）只能处理结构化信息，而 LLM 擅长处理非结构化信息（文本）。因此，LLM 必须想办法在两种信息形式之间架起桥梁：将非结构化的用户需求转换为结构化的函数调用，这样才能与外部系统交互。

这就是 Function Calling 的本质，也是后面 MCP 和 Skills 能够存在的前置条件。

2.既然有了function calling，为什么又会有 MCP 和 Skills 呢？

Function Calling 确实解决了核心问题：让 LLM 能够稳定地输出结构化的工具调用请求，实现了 "非结构化→结构化" 的转换。这是 AI Agent 工具能力的基础。

但在实际应用中，开发者很快发现了一个新的问题：工具集成成本太高。

Function calling 会有工具集成成本高的问题

现实世界中，有大量的既有系统和数据：数据库里存储着业务数据，文件系统里有各种文档和代码，GitHub 上有项目仓库和 Issue，dingding 里有团队沟通记录，还有各种 API 服务提供实时数据。这些既有系统里有着丰富的信息，如果能让 LLM 直接使用这些系统和数据，AI Agent 的能力会大大增强。

但问题是：如何让 LLM 能够使用这些既有系统？

在 Function Calling 的框架下，每个既有系统都需要单独集成到应用中。每个组织或公司都有自己的 API、认证方式、数据格式，开发者需要为每个组织或公司编写对应的函数实现。这就是 MCP 产生的原因：提供一个服务，可以让既有系统快速集成到 LLM 中。

MCP 的核心其实还是基于 Function Calling 的。它做的事情很简单：把 Function Calling 的调用，在客户端转换成一套 JSON+HTTP 的请求。然后提供一套 Server 来响应这个 JSON+HTTP 请求，这样就能实现各类应用都可以被 LLM 使用的效果。

LLM -> Function Calling -> MCP Client -> JSON+HTTP请求 -> MCP Server -> 既有系统（GitHub/Slack/数据库等）
                                                                          ↓
LLM <- Function Calling结果 <- MCP Client <- JSON响应 <- MCP Server <- 既有系统返回结果

1. LLM 决策：用户提出需求，LLM 判断需要调用工具，并通过 Function Calling 生成结构化的调用请求（包含工具名和参数）。
2. 协议转换：MCP Client 捕获这个请求，将其转换为标准的 JSON-RPC over HTTP 格式。
3. 服务端处理：MCP Server 收到标准请求，根据预定义的逻辑，去调用具体的既有系统（如执行 SQL 查询、调用 GitHub API、读取本地文件）。
4. 结果回传：既有系统的执行结果被 MCP Server 封装成标准 JSON 格式，沿原路返回给 LLM。
5. 最终响应：LLM 结合工具返回的数据，生成自然语言回答给用户。

但 MCP 解决了工具集成的问题后，又出现了另一个问题。

Function Call