核心定义:MCP和Function Calling是AI大模型与外部世界进行交互的两种核心处理机制。
本质定位:标准化协议VS专有接口
MCP:
-
定义了LLM与外部工具交互的标准流程、消息格式和错误处理机制。
-
不依赖特定的模型。所有的模型都统一了这种调用模式。
Function Calling:
-
是特定模型的模型API扩展。针对不同的模型,可能需要编写一些不同的调用API的格式或者参数。
-
模型生成要调用的函数+参数,应用程序执行函数并返回结果。
核心架构对比:
| 对比项 | MCP | Function Calling |
| 架构模式 |
客户端-服务端: -MCP HOST:运行LLM的应用 -MCP CLINET:负责协议交互 -MCP SERVER:提供外部功能 |
点对点直连: -模型直接与预定义函数交互 -无中间层,简化集成 |
| 通信方式 |
异步+同步混合: -支持SSE流和HTTP请求 -发送请求后不阻塞,结果返回再处理 |
同步阻塞: -调用后必须等待结果返回 -下一轮对话需前次调用完成 |
| 消息格式 | JSON-RPC 2.0标准 | 模型特定JSON结构 |
核心能力对比:
| 能力 | MCP | Function Calling |
|---|---|---|
| 动态发现: 无需预先定义,可发现新工具 | 支持工具自动发现和探索 | 必须预定义所有可用函数 |
| 并行调用: 同时执行多个工具 | 支持多工具并行调用 | 一次只能调用一个函数,需串行执行 |
| 上下文管理: 保持多轮交互状态 | 内置会话管理,自动保存中间状态 | 状态需开发者手动维护,调用间无关联 |
| 错误处理: 统一的异常处理机制 | 详细结构化错误信息,支持错误恢复和重试,可保存错误发生时的上下文 | 简单错误处理,易造成上下文丢失 |
| 扩展性: 添加新功能的便携性 | 支持动态扩展和插件机制,可方便添加新功能模块,易于功能组合 | 扩展性差,需修改代码才能添加新功能难以进行复杂功能的组合 |
1207

被折叠的 条评论
为什么被折叠?



