前言

2022年11月30日，ChatGPT的发布正式敲响了大语言模型（LLM，Large Language Models）时代的大门。而后的2023年，自然语言处理（NLP，Netural Language Process）技术飞速发展，LLM领域取得了诸多重大突破，这一年也被称为LLM元年。

同年6月13日，OpenAI在gpt-4-turbo模型中首次引入函数调用（Function Calling）能力，为LLM突破纯文本交互边界迈出关键一步。而后的2024年11 月 25 日，Claude AI的开发商Anthropic开源的模型上下文协议（MCP，Model Context Protocol）通过建立规范化的模型间通信标准，进一步扩展了LLM应用的上限。

2025年3月27日，OpenAI 宣布正式支持MCP，再次将MCP送上热搜… 在人工智能技术日新月异的今天，如何让模型更加智能、灵活地与现实系统或其他模型进行交互，已成为推动AI应用落地的关键课题。在接下来的内容中，本文将着重介绍函数调用与MCP出现的历史缘由以及必要性，并在文末结合腾讯广告API简单演示了MCP与业务结合的实践示例。

01

传统大语言模型（LLM）的短板

我们先来简单回忆下 LLM 的基本能力：

LLM 是近年来自然语言处理领域的革命性成果，它们通常基于深度神经网络+Transformer 架构，通过海量语料训练形成的参数化知识表征系统，其核心能力体现在语义理解与序列生成两个层面。LLM 的核心目标就是理解和生成自然语言，例如ChatGPT是基于自回归的方式进行文本生成，在约定范式下能够实现符合人类对话范式的交互输出，但是传统的 LLM 有两个短板严重限制了模型的能力：

1、缺乏最新信息： 模型知识固化为训练期的静态快照，这意味着它们无法提供新信息或新事件的服务；

图片

2、幻觉问题： LLM 生成的文本主要基于训练数据的统计规律，在某些场景 LLM 可能会生成看似合理实则偏离事实的输出，甚至编造问题答案。

图片

例如上图中的 LLM 就是缺乏相关知识导致其编造了回答，这种捏造事实的幻觉也称为“事实性幻觉”。传统解决方案通过注入上下文背景信息来缓解这一问题，但由于 token 窗口长度和模型注意机制的限制，难以实现有效的约束。

为了赋予 AI 更多的能力、给 LLM 插上“翅膀”，函数调用（Function Calling）率先被提出。函数调用的引入使得 LLM 可以与外部系统建立交互通道，这不仅在一定程度上解决了传统 LLM 模型短板问题，更关键的是让 LLM 突破了纯文本处理范畴，构建起实时感知并影响物理世界的能力通路。

02

函数调用（Function Calling）是什么

函数调用最早由 OpenAI 提出，旨在为 LLM 提供一种强大而灵活的方式与外部代码或外部服务进行交互的能力，例如 GPT 模型可以通过函数调用的方式调用外部函数或服务为自身的文本生成功能提供更多的上下文信息。模型本身并不执行函数，而是生成包含函数名和执行函数所需的参数，具体执行仍交由 OpenAI API 实现。

图片

例如用户希望获取特定地点的天气情况，实际执行可以粗略地分为以下几步：

图片

  1. AI 软件将 用户问题 + 可用工具 封装成一个 context 输入给 LLM（支持函数调用的模型）；
  2. LLM 即可根据情况分析出当前需要调用的工具，并生成 执行函数名 + 所需参数 的模型返回；
  3. API 将其封装成实际的函数调用，并再次将 返回结果 添加到 context 中；
  4. LLM 根据最终内容判断是否还需其他工具，直到 LLM 判断已获取到所有信息后，最终输出用户期望的回答。

函数调用机制的引入，标志着 LLM 从封闭式文本处理向开放式服务集成的关键跃迁，函数调用不仅大幅缓解了缺乏最新信息与事实性幻觉问题，更为后续 AI 协议生态的构建提供了可靠性保障框架。

03

为什么还需要模型上下文协议（MCP）

3.1 函数调用定制化程度过高

在函数调用出现后，LLM 领域有了更多的实践进步与发展，Agent 绝对算得上是其中的顶流，OpenAI 公司将获得广泛认可的 Agent 架构总结为 Agent = LLM + 记忆 + 规划技能 + 工具使用 作为 AI 智能体的典型代表。

图片

业内基于这一模型进行了很多尝试，从 ReAct 到 Plan-and-Execute，再到近期出现的现象级应用 Manus，及其3小时被复刻的开源实现 OpenManus，不仅验证了通用 Agent 架构的可行性，更以实例展示了 LLM 在复杂任务处理上的无限可能。

图片

而我们在 Agent 中仍然可以看到诸多函数调用的踪迹，通过了解 OpenManus 的具体实现，我们可以发现可用工具的存在形式是 /app/tool/ 目录下的一个 python 文件，OpenManus 允许开发者定制化地实现其所需的工具，这种高灵活度的实现方案充分释放了函数调用的技术优势，但同时也反映出当前生态的关键短板：缺乏统一规范！不同系统间工具定义的差异性导致功能复用困难，工具重复开发成本显著攀升。

3.2 MCP——AI 界的 USB-C 接口

早在 Manus 爆火前的2024年11 月 25 日，Anthropic 公司（Claude AI母公司）就开源了一款名为 Model Context Protocol 的开源协议。该协议号称是为业界 AI 工具与模型数据库间提供一套标准化统一对接接口，允许各大 AI 工具通过单一协议访问各种数据源，从而加速模型响应速度与生成质量。

Anthropic 官网的一段介绍将 MCP 比做 AI 界的 USB-C 接口：

MCP（Model Context Protocol）是一种开放协议，它标准化了应用程序向 LLM 提供上下文的方式。可以将 MCP 视为 AI 应用程序的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。

图片

现阶段很多 MCP 应用仍然是基于函数调用的方式实现的，从成本和适用性的考虑这显然是最佳选项，客观反应了在定位上 **MCP 与函数调用就不是竞品关系。**MCP 旨在为 AI 应用提供一种协议范式，其革新性在于构建了 AI 工具交互的分层解耦架构。

图片

区别于函数调用的单点功能实现，MCP 是作为一种希望建立 AI Tools 生态体系的协议问世的，其实现路径具有显著工程优势：开发者仅需研发符合 MCP 规范的服务器端工具实例（MCP Server）就可以被所有结合 LLM 实现的 MCP Client 导入并使用。通过统一协议规范，显著降低了不同系统间工具定义的差异性，避免了重复造轮子的过程，很好的解决了 LLM 应用中常见的数据孤岛与工具集成等痛点问题。

04

进一步认识 MCP

4.1 MCP 的基本架构

MCP 的核心是客户端-服务器架构，其中集成 MCP Client 的应用可以连接到多个 MCP Server：

图片

MCP的官方文档中将架构中的基本结构分为：

  • MCP 主机（MCP Hosts）： 发起请求的 LLM 应用程序（例如 Claude Desktop、IDE 或 AI 工具）。
  • MCP 客户端（MCP Clients）： 在主机程序内部，与 MCP server 保持 1:1 的连接。
  • MCP 服务器（MCP Servers）： 为 MCP client 提供上下文、工具和 prompt 信息。
  • 本地数据源（Local Data Sources）： 本地计算机中可供 MCP server 安全访问的资源或服务。
  • 远程服务（Remote Services）： MCP server 可以连接到的远程资源（例如通过 API）。

目前已经有很多可用的 MCP Host 应用程序，例如开山鼻祖 Claude、AI 代码编辑器 Cursor、VSCode 插件 Cline 等，其实用价值已经初具规模，甚至可以用其编写 MCP Server 代码，制定开发计划、使用 Git 初始化目录、编辑并保存代码、试运行…你能做的大多数它们都可以帮你实现，“唯一缺陷”可能是其中绝大多数目前都需要付费使用（主要用于消耗 Tokens），当然也有一些免费开源的应用，例如 Cherry Studio 正在敏捷迭代，可以支持绝大多数的模型以及本地模型。

大家也可以在一些开源社区（例如 https://mcp.so/ ）找到目前已开源的 MCP Client/Server 实现。

4.2 MCP 的通信协议

说了半天，其实归根结底 MCP 就是一个协议，具体 MCP 长什么样子呢？官方文档中也对其做了介绍，

（本文仅做简单搬运总结，详细可参见： https://modelcontextprotocol.io/docs/concepts/transports）

MCP 的核心是使用 JSON-RPC 2.0 作为消息格式，基础协议定义了三种基本消息类型，分别是请求（Requests）、响应（Responses）和通知（Notifications）。目前提供了两种标准传输方式：标准输入输出（STDIO）和服务器发送事件（SSE），分别可以用于本地和远程的通信，当然开发者也可以实现自定义传输方式，只要符合 MCP 传输接口要求即可。

// 请求{  jsonrpc: "2.0",  id: number | string,  method: string,  params?: object}// 响应{  jsonrpc: "2.0",  id: number | string,  result?: object,  error?: {    code: number,    message: string,    data?: unknown  }}// 通知{  jsonrpc: "2.0",  method: string,  params?: object}

05

在腾讯广告业务场景下探索MCP应用示例

在了解完基础原理与历史演变后，我们需要重新认知 AI 技术的产业渗透现状：如今的 AI 能力已超越过去 LLM 智能对话工具的单一形态，逐步进化为具有领域垂直任务处理能力的智能体生态。

为了更深入了解 MCP 与 LLM 的结合机理并进一步探索 MCP 与业务场景结合的可能性，本文将通过 Python 实现轻量化 MCP 示例，用于展示 LLM 如何通过 MCP 架构调用腾讯广告 API 实现特定业务数据的获取，大致架构如下图。

图片

原本广告主只能通过腾讯广告 API 手动获取数据，现在可以借助 LLM 的能力，输入自然语言即可完成同样的工作（本示例以说明意义为主，官方网站提供了4种可用的 MCP SDK——Python、TS、Java 和 Kotlin，具体实现建议参考官方 SDK 示例： https://github.com/modelcontextprotocol/python-sdk ）。

5.1 MCP Server 示例——面向 LLM 的接口改造

MCP Server开发相对简单，定位更偏向定制化的可用工具服务，只需要做一层MCP的适配即可，利用官方提供的Python SDK可以很轻易完成，下面以**“获取广告支持的创意形式列表工具”**为例，我们只需着重做好两件事。

1、将接口调用返回翻译成模型能“理解”的语料：

首先让AI用Python写一段API接口调用代码，代理到本地服务器后简单debug下就可以输出接口的JSON返回了，然后我们针对接口返回参数做一些业务上的文字处理，这一步可以理解为将接口返回处理为可阅读的格式，同时精简掉无用/干扰信息，这里做示例用我仅仅将字段名翻译了下：

// 原格式{"creative_template_id": 311, "creative_template_name": "常规大图 1:1", "creative_template_size": "", "bid_mode":  ["BID_MODE_CPC",  "BID_MODE_OCPC",  "BID_MODE_CPM",   "BID_MODE_OCPM"],   "site_set":   [{"site_id": "SITE_SET_WECHAT",    "site_name": "微信公众号与小程序"},    {"site_id": "SITE_SET_WECHAT_PLUGIN",    "site_name": "微信新闻插件"}],    ...与AI结合场景无关的其他字段，不需要模型理解...}  // 翻译后 {"创意形式ID": 311,  "创意形式名称": "常规大图 1:1",   "尺寸要求": "",   "出价方式": ["BID_MODE_CPC",     "BID_MODE_OCPC",    "BID_MODE_CPM",    "BID_MODE_OCPM"],     "支持投放版位": [{"版位ID": "SITE_SET_WECHAT",     "版位名称": "微信公众号与小程序"},      {"版位ID": "SITE_SET_WECHAT_PLUGIN",       "版位名称": "微信新闻插件"}]}

2、使用MCP协议封装MCP Tools：

使用官方SDK声明一个MCP Tool的核心代码只有简单几行，这里重要的是要附上工具说明（相当于工具对模型的自我介绍，LLM会根据说明决定是否采用）：

@mcp.tool(name="hello", description="在广告投放过程中，当需要查询特定广告id支持的创意形式时非常有用，输出的创意形式可以用于查询支持的组件。")async def hello(adgroup_id: int) -> str:     其他业务相关处理代码     ...

PS：官方还贴心的给出了可视化工具MCP Inspector，在开发完MCP Server后执行如下命令即可用可视化界面进行调试：

// [run-command]可以自定义服务的启动方式，本文采用ux管理工具将server demo打包成uv tool，使用uvx运行CLIENT_PORT=[p1] SERVER_PORT=[p2] npx -y @modelcontextprotocol/inspector [run-command]

图片

上图为实际运行的界面，可以看到功能还是比较全面的，几乎支持所有功能的测试，由于篇幅限制本文仅作简单说明，具体使用指南可以参考： https://modelcontextprotocol.io/docs/tools/inspector

5.2 MCP Client 示例——“通用轮子工具”

MCP Client 的开发目的是服务于MCP Host 和 LLM，更偏向于通用“轮子工具”，本文不作展开，这里强调 Client 必备的两大主要功能：

1、初始化与 MCP Server 的连接，同时获取并保存可用 Tool、Source、Prompts 列表；

2、提供执行指定工具的调用方法。

5.3 MCP Host 示例

MCP Host需要LLM能力，建议搭建本地LLM进行开发测试：https://km.woa.com/articles/show/623337?ts=1741697403

MCP Host 一般需要集成 MCP Client，但除 MCP Client 外其他实现非常接近函数调用的实现模式，本文参考 OpenAI 的 Function Calling 实现，做轻微改造实现一个简易版的 MCP Host，改造步骤主要分为：

1、将 MCP 的工具列表翻译为 Function Calling 的工具列表，目的主要是为了将 MCP Tools 提供给 LLM：

def convert_tool_to_function(tool):    """将工具对象转换为function格式"""    properties = tool.inputSchema.get('properties', {})    parameters = {        "type": "object",        "properties": {            prop_name: {                "type": prop.get('type', 'string'),  # 默认类型为string                "description": prop.get('description', '')  # 确保有默认描述            }            for prop_name, prop in properties.items()        },        "required": tool.inputSchema.get('required', [])  # 直接从inputSchema获取required字段    }    return {        "type": "function",        "function": {            "name": tool.name,            "description": tool.description,            "parameters": parameters        }    }

2、在 LLM 输出调用工具后，由于 Function Calling 没有 Server 的概念，所以还需要额外建立 MCP Tools 与所属 Server 的映射关系：

while assistant_output["tool_calls"] != None:      tool_name = assistant_output["tool_calls"][0]["function"]["name"]   args = json.loads(assistant_output["tool_calls"][0]["function"]["arguments"])   tool_info = {"name": tool_name, "role": "tool"}   res = asyncio.run(clis[tool_name].run(tool_name=tool_name, arguments=args))   tool_info["content"] = res

运行结果示例如下：

图片

从上述实践中可以发现，LLM 仍是以 Function Calling 的方式认识并调用 MCP Server 提供的工具，区别在于：工具开发者可以借助 MCP 脱离 Function Calling 的定制化开发，而是面向 MCP 协议开发单独 Server，甚至只用 MCP Inspector 即可完成测试流程。至于 MCP Hosts 和 MCP Clients 已经有很多开源选择，如果需要定制化的功能也只需结合自己的业务场景改造下即可。

当前MCP技术的产业化部署正处于开放生态共建的关键阶段，全球开发者社区的创新活力已初见成效。在商业实践前沿，Google Ads 率先发布了用于广告分析的MCP Server（https://github.com/cohnen/mcp-google-ads ）。

值得关注的是，2025年3月27日，OpenAI Agents SDK的最新版本（https://openai.github.io/openai-agents-python/mcp/ ）也接入了 MCP 生态，这标志着主流技术框架正式进入标准化实施阶段。相信随着 LLM 模型能力的迭代进步与 MCP 生态的扩展完善，在不久的将来，MCP 协议真的有望成为 AI 时代智能化建设的“USB-C 端口”。

最后的最后

感谢你们的阅读和喜欢，作为一位在一线互联网行业奋斗多年的老兵，我深知在这个瞬息万变的技术领域中，持续学习和进步的重要性。

为了帮助更多热爱技术、渴望成长的朋友，我特别整理了一份涵盖大模型领域的宝贵资料集。

这些资料不仅是我多年积累的心血结晶，也是我在行业一线实战经验的总结。

这些学习资料不仅深入浅出，而且非常实用，让大家系统而高效地掌握AI大模型的各个知识点。如果你愿意花时间沉下心来学习，相信它们一定能为你提供实质性的帮助。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

大模型知识脑图

为了成为更好的 AI大模型 开发者，这里为大家提供了总的路线图。它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。
在这里插入图片描述

经典书籍阅读

阅读AI大模型经典书籍可以帮助读者提高技术水平，开拓视野，掌握核心技术，提高解决问题的能力，同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说，阅读经典书籍是非常有必要的。

在这里插入图片描述

实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

在这里插入图片描述

面试资料

我们学习AI大模型必然是想找到高薪的工作，下面这些面试题都是总结当前最新、最热、最高频的面试题，并且每道题都有详细的答案，面试前刷完这套面试题资料，小小offer，不在话下

在这里插入图片描述

640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

在这里插入图片描述

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

# 语言模型
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

cover

用MCP+Agent突破大模型最大token限制，完成超长网页翻译

avatar MCP技术社区
cover

CodeBuddy Craft：AI重塑智能办公——对话式开发打造微信办公助手终极形态

avatar MCP技术社区
cover

超简单使用A2A和MCP开发DeepSearch和AgentRAG（含源码)

avatar MCP技术社区