LLM工具调用：Function Calling与MCP协议的本质区别与应用场景

1. 项目概述从“傻白甜”到“多面手”的LLM进化之路如果你最近在折腾Claude Desktop、Cursor这类AI编程工具或者研究LangChain、Dify这些AI应用框架大概率会频繁遇到两个词MCP和Function Calling。乍一看它们都像是让大语言模型LLM去“调用外部工具”的技术网上很多文章也把它们混为一谈导致不少开发者越看越迷糊。我自己在搭建AI工作流时也踩过坑今天就来掰开揉碎把这两个总被搞混的概念彻底说清楚。简单来说你可以把LLM想象成一个知识渊博但“四肢不勤”的顾问。Function Calling是给了它一张“工具使用说明书”告诉它“这里有把锤子可以这样敲钉子”。而MCPModel Context Protocol则是为它建立了一个完整的“工具库管理体系”不仅告诉它工具怎么用还定义了工具如何被发现、如何被安全地调用、以及不同工具之间如何协同工作。前者是一次性的、临时的指令后者是系统性的、可持续的架构。理解这个根本区别是你设计高效、可靠AI应用的关键。这篇文章适合所有正在或打算将LLM集成到产品、工作流中的开发者、产品经理和技术决策者。无论你是想给Claude Desktop添加一个查询数据库的“技能”还是想在自己的应用中构建一个能联网搜索、执行代码的AI助手分清MCP和Function Calling的适用场景都能帮你少走很多弯路。2. 核心概念拆解Function Calling的本质是“格式化提示词”让我们先攻克看起来更简单的那个Function Calling。这个词听起来很高大上好像模型真的在“调用函数”但其实它的本质是一种标准化的、结构化的提示词Prompt工程。2.1 Function Calling到底在做什么当你在OpenAI API或Anthropic Claude API的文档里看到Function Calling时其核心流程是这样的定义你开发者向LLM描述一个或多个“函数”。这个描述包括函数名、功能说明以及它需要哪些参数每个参数是什么类型。请求你向LLM发送一个用户问题比如“北京今天天气怎么样”同时附上你定义好的函数列表。决策LLM根据你的问题和函数描述进行“思考”。它会判断“用户的问题是否需要调用某个函数来解决如果需要是哪个函数调用这个函数需要哪些具体的参数”响应LLM不会真的去执行函数它只是返回一个结构化的JSON对象里面包含了它“决定”要调用的函数名以及它“推理”出来的参数值。执行你的应用程序收到这个JSON响应后由你的代码去真正地执行对应的函数比如调用一个天气API获取结果。回调你将函数执行的结果比如{“temperature”: 22, “weather”: “sunny”}再次发送给LLMLLM结合这个结果生成最终面向用户的自然语言回答。关键洞察在整个过程中LLM只做了两件事理解需求并“计划”调用步骤3以及整合结果并组织语言步骤6。它从未脱离文本生成的范畴所谓的“调用”只是一个精心设计的“幻觉”。你的应用程序才是真正的执行者。2.2 一个典型的Function Calling代码示例假设我们想让AI助手能查询天气一个典型的Function Calling交互如下以OpenAI风格为例# 1. 定义函数工具 tools [ { “type”: “function”, “function”: { “name”: “get_current_weather”, “description”: “获取指定城市的当前天气”, # LLM靠这个描述决定是否调用 “parameters”: { “type”: “object”, “properties”: { “location”: { “type”: “string”, “description”: “城市名例如‘北京’‘San Francisco’” }, “unit”: { “type”: “string”, “enum”: [“celsius”, “fahrenheit”], “description”: “温度单位” } }, “required”: [“location”] } } } ] # 2. 将用户问题和工具定义一起发送给LLM response client.chat.completions.create( model“gpt-4”, messages[{“role”: “user”, “content”: “北京今天热吗”}], toolstools, tool_choice“auto” # 让模型自己决定是否调用 ) # 3. 解析LLM的“决策” tool_call response.choices[0].message.tool_calls[0] if tool_call.function.name “get_current_weather”: arguments json.loads(tool_call.function.arguments) # 4. 在你的代码中真正执行函数 weather_data get_current_weather( locationarguments.get(“location”), unitarguments.get(“unit”, “celsius”) ) # 5. 将结果回调给LLM让它生成最终回答 # ... (后续步骤)实操心得写好description字段是Function Calling成功的关键。这个描述是给LLM看的“任务说明书”必须清晰、无歧义。例如“获取天气”就比“查询气象信息”更好因为前者更直接地关联了用户常说的“天气怎么样”。参数描述也要具体告诉LLM“location”期望的是“城市名”而非“邮政编码”。2.3 Function Calling的优缺点与适用场景优点简单直接对于简单的、已知的、数量有限的工具调用场景实现起来非常快速。模型原生支持主流LLM APIOpenAI, Anthropic, DeepSeek等都内置了此功能无需额外依赖。控制力强开发者完全掌控函数的执行环境、安全性和错误处理。缺点与局限紧耦合工具列表必须在每次请求时硬编码或预先定义好无法动态发现新工具。上下文局限工具描述会占用宝贵的上下文窗口Token。工具一多描述文本就会挤压对话历史的空间。静态绑定工具和LLM的绑定是静态的。如果你想在Claude Desktop、Cursor、你自己的App等多个客户端使用同一套工具需要在每个地方重复实现这套定义和调用逻辑。缺乏协议它没有规定工具如何被注册、如何被管理、调用时的身份验证和授权怎么做。这只是一个API设计模式而非一个协议。适用场景Function Calling非常适合封闭的、工具集固定的单一应用。比如你开发了一个客服机器人它只需要调用“查询订单状态”、“生成退货单”等几个内部API。这些工具很少变化且整个逻辑封装在你自己的后端服务里。3. 深入MCP为LLM构建“即插即用”的生态协议如果说Function Calling是给LLM一把定制扳手那么MCPModel Context Protocol就是为它建立了一个符合ISO标准的现代化五金工具箱生态系统。MCP的核心目标是标准化LLM与外部工具和数据源之间的交互方式使其变得可发现、可组合、可移植。3.1 MCP的核心架构客户端、服务器与协议MCP协议主要包含三个部分理解它们的关系至关重要MCP 客户端 (Client)这是LLM或AI应用所在的一端。比如Claude Desktop、Cursor编辑器、IDEs或者任何集成了MCP SDK的应用。客户端负责发起工具调用请求并消费服务器提供的内容。MCP 服务器 (Server)这是提供具体工具或数据的一端。每个MCP服务器都是一个独立的进程它对外暴露一组定义好的“工具”Tools和“资源”Resources。例如filesystem-mcp提供读写本地文件系统的工具。sqlite-mcp提供查询SQLite数据库的工具。brave-search-mcp提供联网搜索的工具。MCP 协议 (Protocol)这是连接客户端和服务器的“通信语言”。它基于JSON-RPC 2.0定义了一套标准的消息格式用于服务器注册、工具列表发现、工具调用执行、数据流传输等。正是这个协议使得任何兼容MCP的客户端都能自动识别并使用任何兼容MCP的服务器。生活化类比把MCP想象成电脑的USB协议。客户端是你的电脑Claude Desktop服务器是各种USB设备U盘、键盘、摄像头。USB协议规定了电压、数据格式、插口形状。只要设备遵循USB协议MCP Server电脑MCP Client就能即插即用自动识别并使用它无需为每个设备重写驱动无需为每个工具重写Function Calling逻辑。3.2 MCP的核心能力超越简单的“函数调用”MCP协议定义了几种核心的“能力”这使它比Function Calling丰富得多工具Tools和Function Calling类似代表一个可执行操作如“搜索网络”。但MCP的工具定义更规范且通过协议动态注册。资源Resources这是MCP的一大特色。它代表一个可读取的数据源比如一个文件、一个数据库表、一个网页URL。客户端可以“提示”LLM有这些资源可用LLM可以请求读取资源内容作为上下文。例如一个SQLite MCP服务器可以将数据库表暴露为资源LLM在回答问题时可以直接请求读取相关表结构或数据。提示词模板Prompts服务器可以预定义一些复杂的提示词模板客户端可以直接调用简化交互。例如一个代码审查服务器可以提供一个“review_this_code”的提示词模板。采样器Samplers用于提供更复杂的生成控制但目前应用较少。3.3 一个完整的MCP工作流示例在Claude Desktop中添加SQLite查询能力让我们通过一个具体场景看看MCP是如何运作的。假设你想让Claude Desktop能直接查询你本地的项目数据库。安装MCP服务器你通过npm或pip安装一个社区开发的sqlite-mcp服务器。npm install -g modelcontextprotocol/server-sqlite配置Claude Desktop客户端编辑Claude Desktop的配置文件如claude_desktop_config.json告诉它去启动这个SQLite服务器进程并传入数据库路径参数。{ “mcpServers”: { “sqlite-project-db”: { “command”: “npx”, “args”: [ “modelcontextprotocol/server-sqlite”, “/path/to/your/project.db” ] } } }动态注册启动Claude Desktop后它会自动启动你配置的sqlite-mcp服务器。该服务器通过MCP协议向Claude Desktop“自我介绍”“嗨我这里有这些工具run_sql_query还有这些资源tables://users,tables://orders。”自动集成Claude Desktop将这些工具和资源信息动态地整合到与Claude模型的对话上下文中。现在当你问Claude“我的用户表里有多少条记录”时Claude会意识到有一个run_sql_query工具可用并通过MCP协议发起调用。执行与返回MCP服务器收到请求执行SQL查询并将结果通过协议返回给Claude DesktopClaude Desktop再呈现给Claude模型生成最终回答。整个过程中Claude Desktop和Claude模型本身都不需要预先硬编码关于SQLite查询的任何逻辑。所有功能都由独立的、可插拔的MCP服务器提供。3.4 MCP的优缺点与适用场景优点解耦与可插拔工具服务与AI客户端完全分离。可以独立开发、更新服务器客户端无需改动代码即可获得新能力。动态发现客户端启动时能自动发现服务器提供了哪些工具和资源实现了真正的“即插即用”。生态潜力标准化协议催生生态。任何人都可以编写MCP服务器如playwright-mcp用于网页自动化github-mcp用于操作GitHub并在任何兼容MCP的客户端中使用。上下文丰富通过“资源”机制能为LLM提供更结构化、更强大的外部数据集成能力。缺点与挑战复杂度高需要理解客户端-服务器架构、进程间通信和JSON-RPC协议。部署和调试比Function Calling复杂。安全性考量MCP服务器通常具有较高的本地权限如文件访问、命令执行。需要谨慎管理服务器来源和配置。新兴技术作为较新的协议主要由Anthropic推动工具生态虽在快速增长但尚未完全成熟最佳实践仍在形成中。适用场景MCP非常适合构建开放的工具生态和复杂的AI应用平台。AI IDE/智能助手如Claude Desktop、Cursor它们需要集成文件系统、Git、数据库、搜索引擎等数十种异构工具。企业AI工作流企业内部有各种数据源CRM、ERP、数据库。可以为每个数据源开发一个MCP服务器让AI助手能安全、统一地访问所有系统。工具开发者如果你开发了一个很棒的工具希望它能被集成到各种AI应用中将其包装成MCP服务器是最通用、最可持续的方式。4. 横向对比MCP与Function Calling的核心差异为了更直观地理解我们可以从多个维度对二者进行对比特性维度Function CallingMCP (Model Context Protocol)本质LLM API的一个特性/参数是一种结构化提示词模式。连接LLM客户端与工具服务的标准化通信协议。架构紧耦合、单体式。工具定义和调用逻辑内嵌在应用代码中。松耦合、客户端-服务器式。工具作为独立服务存在通过协议与客户端通信。工具发现静态预定义。必须在请求前完全定义好所有可用工具。动态注册。客户端启动时可自动发现服务器提供的所有工具和资源。工具管理由应用开发者集中管理。增减工具需修改代码并重新部署/更新上下文。分布式、可插拔。每个工具是一个独立服务器可独立安装、更新、配置。数据交互主要围绕“函数调用”输入是参数输出是结果。除了“工具调用”还有“资源”概念支持更丰富的数据提供和订阅模式。适用范围单一应用内部工具集相对固定、简单的场景。跨应用、跨平台的工具生态需要集成大量异构、动态工具的复杂场景。技术栈依赖特定LLM提供商如OpenAI的API实现。基于开放的JSON-RPC 2.0协议理论上任何LLM或客户端均可实现。示例让GPT调用一个内部计算器函数。让Claude Desktop通过filesystem-mcp读文件通过brave-search-mcp搜网页通过sqlite-mcp查数据。核心结论Function Calling是让LLM在单次对话中“学会”使用你给它的几个特定工具。而MCP是为LLM构建一个它随时可以接入的、不断扩大的“工具世界”。前者是“授人以鱼”这次给你用这几个后者是“授人以渔”给你一个能找到并使用所有鱼的渔场入口。5. 如何选择从实际需求出发的技术选型指南面对具体项目时该如何选择这里有一套简单的决策逻辑选择 Function Calling如果你的应用是自包含的所有功能都在一个代码库内。你需要调用的工具数量很少10个且基本不变。你希望实现快速原型验证追求最简单的集成方式。你的工具调用逻辑高度定制化且不希望引入额外的进程间通信复杂度。你完全控制着调用环境没有跨平台、跨客户端共享工具的需求。选择 MCP如果你正在构建一个AI应用平台或智能助手如类Claude Desktop的产品需要集成大量第三方或用户自定义工具。你的工具集需要动态扩展你希望用户能自行安装“插件”来增加功能。你需要在多个不同的客户端如Web应用、桌面应用、CLI工具中复用同一套工具能力。你除了“执行动作”外还需要为LLM提供丰富的、可动态加载的数据资源如文档、数据库。你作为工具开发者希望你的工具能被广泛集成到不同的AI生态中。混合使用模式在实际复杂系统中二者并非互斥。例如一个基于MCP架构的AI助手客户端其内部在与某个具体的LLM如GPT-4通信时依然会使用Function Calling作为“最后一公里”的通信方式。即MCP客户端收到用户请求 - 通过MCP协议调用合适的工具服务器 - 拿到结果 - 将结果和用户问题通过Function Calling的方式发送给LLM API生成最终回复。MCP解决了工具生态的问题Function Calling解决了与特定LLM模型交互的标准化问题。6. 实战配置与常见问题排查理论说再多不如动手试一遍。这里以最流行的Claude Desktop配置MCP服务器为例分享实操步骤和避坑指南。6.1 为Claude Desktop配置一个MCP服务器以SQLite为例确保环境已安装Node.js (18) 和 Claude Desktop应用。安装MCP服务器打开终端全局安装社区提供的SQLite服务器。npm install -g modelcontextprotocol/server-sqlite注意务必从官方或可信社区源如Model Context Protocol官方GitHub组织下的仓库安装服务器。随意安装不明来源的服务器可能带来安全风险因为它通常具有访问本地文件的权限。定位配置文件Claude Desktop的MCP配置文件路径通常位于macOS:~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:%APPDATA%\Claude\claude_desktop_config.jsonLinux:~/.config/Claude/claude_desktop_config.json如果文件或目录不存在手动创建即可。编辑配置文件用文本编辑器打开该文件添加你的MCP服务器配置。以下是一个连接多个服务器的配置示例{ “mcpServers”: { “sqlite-projects”: { “command”: “npx”, “args”: [ “modelcontextprotocol/server-sqlite”, “/Users/yourname/Projects/my_project.db” ] }, “filesystem”: { “command”: “npx”, “args”: [ “modelcontextprotocol/server-filesystem”, “/Users/yourname/Downloads” // 仅允许访问Downloads目录 ] } // 可以继续添加更多服务器如 brave-search-mcp } }关键配置解析“sqlite-projects”这是你给这个服务器实例起的任意名字。“command”启动服务器的命令。对于npm包通常用“npx”。“args”传递给命令的参数。第一个是服务器包名后面是传给该服务器的参数如数据库文件路径、权限目录等。重启Claude Desktop完全退出并重新启动Claude Desktop应用。验证在Claude Desktop中开启一个新对话尝试问“你能查看我项目数据库里有哪些表吗” 或 “列出我下载文件夹里的PDF文件。” 如果配置成功Claude会识别出可用的工具并尝试使用它们。6.2 常见问题与排查技巧实录即使按照步骤操作也可能会遇到问题。以下是我在配置过程中遇到的一些典型情况及其解决方法问题1Claude Desktop重启后MCP功能似乎没生效Claude完全不提新工具。排查首先检查配置文件路径和格式是否正确。JSON文件对格式要求严格多一个逗号或少一个引号都会导致解析失败。可以使用在线JSON校验工具检查。查看日志Claude Desktop通常会输出日志。在macOS上可以通过控制台Console.app查看claude-desktop相关的日志在终端中直接启动应用也可能看到错误信息。日志中常会提示“Failed to load MCP server config”或具体的执行错误。检查命令路径确保npx或你指定的command在系统PATH中。对于全局安装的包有时需要指定绝对路径如“command”: “/usr/local/bin/npx”。问题2MCP服务器启动失败提示“Command failed”或“Module not found”。排查这通常是因为MCP服务器包没有正确安装或者它自身的依赖有问题。尝试在终端中直接运行配置中的命令例如直接执行npx modelcontextprotocol/server-sqlite /path/to/db.db看是否报错。如果报模块找不到尝试重新安装该服务器包npm install -g modelcontextprotocol/server-sqlite --force。有些服务器可能需要Python环境或其他运行时请仔细阅读对应服务器的README文档。问题3Claude识别到了工具但调用时出错例如“Permission denied”或“Database is locked”。排查这是服务器层面的运行时错误。权限问题检查MCP服务器进程是否有权限访问你指定的文件或目录。例如filesystem-mcp配置的目录路径是否正确、是否可读。资源占用像SQLite数据库如果已被其他进程如你的IDE独占打开MCP服务器就无法写入。确保数据库文件未被锁定。参数格式确认传递给服务器的参数格式符合其要求。有些服务器可能需要额外的启动参数。问题4我想自己开发一个简单的MCP服务器该如何入手起点Anthropic官方提供了多种语言的MCP SDK如TypeScript/JavaScript和Python。从官方示例开始是最佳路径。核心步骤初始化项目安装MCP SDK (modelcontextprotocol/sdkfor JS,mcpfor Python)。创建一个服务器实例。使用server.set_request_handler或类似方法注册你的工具定义name,description,parametersschema。在工具处理函数中实现具体的业务逻辑如调用一个API、执行一段计算。实现标准输入输出stdio传输因为MCP协议默认通过stdio与客户端通信。使用官方提供的modelcontextprotocol/server-adapter-stdio等适配器来简化通信层。调试技巧开发时可以先用一个简单的测试客户端官方SDK通常提供来连接你的服务器验证工具注册和调用是否正常再集成到Claude Desktop等真实客户端中。安全警告这是最重要的一点。MCP服务器通常以与Claude Desktop相同的用户权限运行并能执行你赋予它的任何操作读/写文件、执行命令、访问网络。绝对不要配置你不信任的MCP服务器或给予其超出必要范围的权限例如不要让filesystem服务器拥有整个硬盘的访问权。始终遵循最小权限原则。7. 未来展望与个人实践建议虽然MCP协议由Anthropic主导推出但其设计是开放和协议驱动的。这意味着它有着超越单一厂商的生态潜力。我们可以看到Cursor、Windsurf等新一代AI IDE已经积极集成MCP未来可能会有更多的AI应用、框架甚至云服务将其作为标准的工具集成接口。从我个人的实践来看对于独立开发者和中小团队初期从Function Calling入手快速验证想法是完全合理的。但当你的项目开始涉及整合多个外部系统、或者你希望构建一个允许用户扩展功能的平台时投资时间理解并采用MCP这样的协议化方案从长期看会带来更大的灵活性和更低的维护成本。它迫使你提前思考工具层的抽象和解耦这种架构上的清晰性本身就是一种价值。最后一个小技巧关注MCP的社区动态。除了Anthropic官方的服务器GitHub上已经出现了大量社区维护的服务器从连接Notion、GitHub到控制智能家居设备。在动手造轮子之前先去社区看看有没有现成的解决方案能节省大量时间。同时在配置任何社区服务器时养成检查其代码和权限要求的习惯安全永远是第一位的。