MCP、传统API与函数调用的解析
原创
导语：在AI驱动的系统开发中，工具调用方式深刻影响效率与能力。通过对比三大范式：作为系统基石的传统API、LLM原生的函数调用(Function Calling)，以及标准化工具生态的MCP协议。剖析其核心差异（通信模式、工具发现、上下文管理）与适用场景，并揭示LLM如何通过Function Calling表达意图、Agent执行调用、MCP统一规范，实现智能协作。掌握三者定位与协同，是构建高效、可扩展AI应用的关键，开启智能开发新范式。技术史上从不缺少“神话”，而真正的进步，往往始于祛魅之后的清醒认知。并不是所有的技术都是万能石！但我们始终应该保持积极的探索脚步。
一、技术概念对比
1.1 传统API：系统集成的基石
传统API通过预定义端点暴露功能，客户端需严格遵循接口规范进行交互。其核心特征包括：
- 静态契约：接口地址、方法、参数、返回值格式预先定义
- 请求-响应模式：同步通信，无状态交互
- 功能耦合：接口与业务逻辑强绑定
# 传统API调用示例
try:
response = requests.get("https://api.example.com/users", params={"id": 123})
response.raise_for_status() # 检查请求是否成功
except requests.exceptions.RequestException as e:
print(f"请求出错: {e}")为什么传统API不适合AI场景
在AI动态场景中缺乏灵活性：无法适应LLM输出的非结构化请求（如模糊意图、多轮交互），需额外转换层
1.2 函数调用：LLM的原生工具使用
Function Calling，这是OpenAI在API中引入的功能，允许大模型调用外部函数。
相比之下，MCP更通用，是协议标准，而Function Calling是具体实现。
函数调用是LLM内置的交互机制，通过结构化数据触发外部功能：
- 意图识别：LLM解析用户需求选择工具
- 参数生成：自动生成符合模式的参数
- 执行闭环：调用后返回结果给LLM
更多Function Calling细节的可查看之前的文章“ AI宝库-ChatGPT插件能力 ****”
1.3 MCP协议：标准化的工具生态
MCP（Model Context Protocol）目的是统一标准化大模型（LLM）与外部工具和数据源的交互方式。MCP被比作AI应用的“USB-C接口”，标准化了工具的接入，解决了数据孤岛和集成复杂的问题。
MCP通过客户端-服务器架构实现工具标准化：
- 自描述工具：工具包含语义化描述和参数定义, 面向AI模型的上下文管理协议
- 双向通信：支持流式传输和状态更新, 支持动态上下文注入与持久化
- 平台无关：工具与LLM解耦，支持跨平台
# MCP工具定义示例
@mcp.tool()
def calculate(a: float, b: float) -> float:
"""两数相加"""
return a + b为什么需要MCP
传统每个API接口或者LLM工具具有定制化的数据结构、不同的指令格式，这种模式导致开发低效，难以扩展，而MCP采用了通用的语言格式(JSON-RPC)，能够与所有支持这种协议的工具进行“对话”
MCP的工作流程
MCP的技术架构由三个核心组件
- MCP Host （执行环境） 就像是企业的办公环境和基础设施。在实际应用中，类似与我们的一些编程工具：Cursor、VS Code等，就是典型的Host，提供了用户与AI交互的界面和环境等，同时具备Agent和MCP Client的运行空间
- MCP Client （通信枢纽） 就像是Agent使用的标准化供应商。并不参与决策，不理解任务本质，只负责按照Agent的指示，以符合服务提供者的格式或协议与各自的服务提供商通信，主要处理通信协议、数据格式转换、连接管理等问题
- MCP Server （服务终端） 就像是各个服务提供商，每一个都负责特定类型的服务。
MCP不是Function Call的替代，而是基于Function Call的工具箱
程序员视角下的MCP与Function Call
MCP架构 ≈ 微服务网关 + 服务注册中心 Function Call ≈ 单体应用中的函数调用
技术实现
- MCP架构实现（Python示例）
# MCP Client实现
class MCPClient:
def __init__(self):
self.registry = ServiceRegistry() # 服务注册中心
def execute(self, request):
# 服务发现
service = self.registry.discover("data_processor")
# 协议转换
payload = self._format_request(request)
# 安全校验
if not self._validate_token(payload):
raise SecurityError("Invalid token")
# 调用服务
return requests.post(
service.endpoint,
json=payload,
timeout=service.timeout
)
# 具体服务实现
class DataService:
@mcp_endpoint
def process(self, data):
# 业务逻辑
return analyze_data(data)- Function Call实现（Python示例）
# 直接函数调用
class DataProcessor:
def __init__(self):
self.tools = {
"analyze": self._analyze,
"transform": self._transform
}
def handle_request(self, tool_name, params):
tool = self.tools.get(tool_name)
if not tool:
raise ValueError("Tool not found")
return tool(params)
def _analyze(self, data):
# 具体实现
return data_analysis(data)1.4 三者的核心差异
维度 | 传统API | 函数调用 | MCP协议 |
|---|---|---|---|
通信模式 | 同步请求-响应 | 结构化JSON交互 | 双向流式通信 |
工具发现 | 硬编码接口 | LLM内置模式匹配 | 标准化服务注册 |
上下文管理 | 无状态 | 会话级上下文 | 持久化上下文 |
跨平台能力 | 依赖具体实现 | 平台绑定 | 标准化协议 |
性能开销 | 高（序列化/网络） | 极低 | 中（协议解析） |
适用场景 | 系统间集成 | 模块化开发 | AI流水线编排 |
适用场景 | 系统间集成 | 模块化开发 | AI流水线编排 |
- ※ 传统API的静态性与AI的动态需求本质冲突：LLM需自由调用工具而非适配固定接口（静态契约 vs 动态需求）
二、技术协同工作流
大模型通过Function Calling表达，我要调用什么工具，Agent遵循指令执行工具的调用，而MCP则是提供了一种统一的工具调用规范。
2.1 典型协作场景
2.2 协同优势
- 意图分层处理：LLM负责意图识别，MCP专注工具执行
- 工具生态扩展：开发者可独立开发MCP工具供多平台使用
- 上下文增强：MCP支持跨会话的上下文保持
三、Demo：多技术协同案例
3.1 场景描述
构建智能客服系统，实现：
- 用户自然语言查询
- LLM解析意图并调用工具
- MCP协议对接多个数据源
- 传统API提供核心服务
3.2 系统设计
3.3 代码实现
3.3.1 MCP服务端（天气模块）
# weather_mcp.py
from fastmcp import FastMCP
mcp = FastMCP("weather")
@mcp.tool()
async def get_weather(city: str) -> dict:
"""获取城市天气"""
import requests
url = f"https://api.amap.com/weather?key=YOUR_KEY&city={city}"
response = requests.get(url)
return response.json()
if __name__ == "__main__":
mcp.run(transport="sse", port=8000)3.3.2 LLM Agent实现
# agent.py
from openai import OpenAI
from mcp import MCPClient
client = MCPClient(servers=["http://localhost:8000/sse"])
openai_client = OpenAI(api_key="sk-xxx")
def handle_query(query):
# LLM意图解析
tools = openai_client.chat.completions.tools(query)
# MCP工具调用
for tool in tools:
result = await client.invoke_tool(
tool.name,
parameters=tool.parameters
)
# 结果合成
return openai_client.chat.completions.synthesize(result)四、选型建议
4.1 推荐使用场景
- MCP：需要跨平台工具共享、动态扩展的场景，支持更复杂的工具集成，更适合企业级数据整合
- 函数调用：LLM原生集成、快速原型开发，主要用于参数生成和函数调用，更适合简单任务自动化
- 传统API：性能敏感、内部系统集成
4.2 混合设计实践
五、演进趋势
- 协议融合：Function Calling将逐步兼容MCP标准
- 工具市场：出现MCP工具生态平台（类似npm）
- 性能优化：gRPC-MCP等高性能传输方案
- 安全增强：工具权限分级和审计机制
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
