2025年，伴随着LLM智能体(Agent)应用的兴起，MCP(Model Context Protocol)技术的热度也被迅速被点燃。短短数月，国内外与AI模型相关的各类厂商纷纷下场支持MCP，迅速为LLM构建起丰富的可用工具生态。如今，MCP已成为AI模型调用外部工具的事实标准。但其技术并非成熟，协议中并未妥善的解决安全认证问题，业内正在完善该部分协议。除此外，“小酌”在整合、支持MCP技术架构的时候发现其接口设计以及通讯技术选型上可能存在一些过度设计，下面就简单的探讨一下。

MCP技术架构简介

MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。

MCP 核心采用客户端-服务器架构，主机应用可以连接多个服务器:

MCP的Client本质上是一个LLM调用工具的代理。LLM通过Client实现对外部工具的调用。此时LLM所使用的能力仍然是LLM的Function Calling能力。

MCP Server将各类功能包装为一组标准的工具展示给MCP Client。MCP Client将这些工具告知LLM，由LLM决定什么时候使用什么工具。

MCP是首个定义了LLM如何与应用程序交互的标准协议。其为传统的各类应用与LLM的结合提供了生态解决方案。这也是其能够得到火爆支持的主要原因。但我们也知道，其目前尚不完善，仍有很多细节需要去补充。下面我们将尝试探讨相关技术，看是否有合适的技术路线来优化它。

LLM的Function Calling技术

众所周知，目前LLM已经拥有了相当可观的推理能力，在图中扮演了大脑的角色。但由于其缺乏直接与外部世界交互的能力，故而其需要借助一个“身体”帮助其完成与外部环境的交互。因此，其引入了Functing Calling的技术。LLM结合“身体”获取到的外部可用工具集判断完成任务需要使用哪个工具，并按照工具信息推理生成一个Function Calling请求。该请求会填写好调用工具所需的参数。“身体”解析LLM输出的Function Calling信息，完成对工具的实际调用，并将结果返回给LLM；如此多步迭代，直至完成任务。

这里的“身体”实际是一个LLM与现实世界交互的代理，在MCP中，其就是MCP Client。除此外，还有诸如Dify、n8n、LangChain以及笔者开发的工具"HuggingFists"中都有这种代理，用于帮助LLM完成与现实世界的信息交互。

Function Calling技术是LLM实现工具调用的基础，虽然各厂商的接口标准存在一定差异，但OPENAI公司的接口标准在业界也获得了很大的兼容性。其与MCP提供的标准在一定程度上解决了同类问题，但开放性上来说，MCP显然会更好一些。

下面，我们就探讨一下“小酌”认为的MCP框架中几个可能存在过度设计的地方。

MCP中的Resources，Prompts以及Tools

MCP协议中涉及到了Resource，Prompt以及Tool三种核心原语。它为每种核心原语都设定了一套管理和访问的API接口规范。单从三种原语在AI场景的应用抽象看，还是非常合理的。Resources代表了所有的可用数据类资源；Tool代表了所有的可用功能；Prompt则是LLM应用中的一类特殊知识资源，方便LLM应用。

但当我们回到LLM的视角来看问题时就会发现，对于LLM，只有与Function Calling技术最相关的Tool原语是有意义的。其它原语都可转换为Tool原语。比如获得数据资源列表，可以转换为一个获取数据资源列表的工具；读取数据资源，可以转换为一个接受数据资源url参数的读取工具。由于现实世界的业务复杂性，绝大多数数据资源都存在一定的访问限定，简单的接口规范有时很难满足真实的数据访问要求。因此，目前我们看到的绝大多数访问数据资源的接口都是通过Tool原语来完成的。Prompt原语应用场景相对较少，可以理解为是Resource的一种特殊形式，在此就不进一步讨论了。

从上面的情况看，“小酌”认为，MCP只提供Tool原语将更为简练，更符合“奥卡姆剃刀”原则。

MCP中的通讯协议SSE

MCP目前提供了三种不同的传输方式，本地工具调用采用Stdio的传输方式；远程通讯早期采用了SSE，而最近又新扩展了Streamable Http。

“小酌”在产品集成MCP的过程中，对于其采用SSE作为远程工具调用通讯协议的设计引发了思考。主要是这种通信协议的引入,导致前几十年中互联网积累的各类HTTP API服务都面临重构的问题。这将是一个非常庞大的成本投入。那这个通讯协议设计的必要性如何？

为避免对MCP设计初衷的理解不够全面，“小酌”与“通义千文”大模型进行了一次深度的探讨。总结而言，“通义千文”对于SSE从最初的强烈支持转为保守支持(大模型总是比较圆滑)。其核心原因在于，目前的LLM都没有给出可渐进式处理的请求方式。它们只给出了“渐进式”输出的返回方式。即目前我们向大模型发起请求都是通过标准的HTTP接口调用的，无论请求体有多大，都是一次性调用完成的。当LLM通过MCP的Client去调用工具时，工具通过SSE返回结果数据。当结果全部返回后，MCP Client调用LLM的访问接口，一次性将结果返回给LLM，而不是边接收，边返回。理论上，MCP Client可以每收到一部分数据就调用一次LLM接口，模拟可渐进式处理的场景，但编程复杂度，控制难度都是非常大的，也比较难写出通用的控制逻辑。

那么我们回到可渐进式处理的概念上，什么是可渐进式处理？可渐进式处理意味着即使数据还在传输过程中，只要接收到部分信息，系统就可以开始分析和处理这些信息。我们人类能够做到这种处理能力，因此，LLM在结果返回时采用了SSE通讯协议，也就是上一段中我们提到的LLM给出了“渐进式”的输出方式。如果当前的LLM普遍拥有了这种渐进式处理的能力，在工具部分的返回结果中就可明确结果，从而中断工具的后续返回，以增强交互效率，那么SSE此时无疑是一种更优秀的技术方案。但就此时而言，其带入的业务重构成本，技术复杂度来说，值得商榷。

在MCP采用SSE作为传输方式的另一个场景需求中，我们看到，其可以更快速的解决工具等资源的变更同步问题。一般而言，这类变更都是比较低频的，如此实时的同步变更其实代价是比较高的。

“小酌”理想中的MCP

就目前我们探讨到的技术前提而言，“小酌”认为，最理想的MCP协议应该尽可能兼容当前已经存在的庞大的基于HTTP协议的API体系。这可以让LLM快速获得丰富的各类可用工具集，并省去服务商迁移工具所需的大额开发及验证成本(适当的接口改造还是需要的)。下面我们就抛一块“砖”供大家一起探讨思考：

如上图，MCP架构所示，MCP架构体系由MCP Client、MCP Server以及MCP Directory Server组成。

MCP Server负责对已有的API接口进行转义封装，将其接口封装为支持json-rpc标准的接口形式。然后将所有的工具注册到MCP Directory Server中。

MCP Directory Server是一个可信的工具目录服务器，这里存放了各个MCP Server提供的工具。

MCP Client通过MCP Directory Server查询获得可用的工具并缓存。当LLM调用工具时，其帮助LLM完成工具的调用。

以上架构的通讯均基于标准Http协议，可大幅的复用当前各类服务的API接口。架构中没有给出本地工具的调用方式，可复用当前MCP的技术方案。

结语

系统设计是一种艺术，没有标准的答案。设计时，需要捕获各种需求，权衡需求，并给出最终的设计方案。当前的MCP方案是第一个全面将工具生态化的解决方案，价值是毋庸置疑的。其在方案设计时应该权衡了一些需求并做出了选择。“小酌”在上面文章中提到的设计问题则权衡了另外的需求。无意其它，只希望更多的人加入思考，在这个时代，走出自己的协议步伐。像Deepseek那样，走出自己的特色。