微信扫码
添加专属顾问
我要投稿
最新研究挑战MCP优势,揭示性能差距与优化策略。核心内容: 1. MCP与传统函数调用的性能对比 2. MCPBench评估框架的设计与应用 3. 关键性能提升技巧与案例研究
你是否正在投入大量资源开发基于MCP的Agent,却从未质疑过一个基本假设:MCP真的比传统函数调用更有优势吗? 2025年4月的这项开创性研究直接挑战了这一广泛接受的观点,其执行摘要明确指出:"使用MCPs并不显示出比函数调用有明显改进"。令人震惊的是,研究发现Qwen Web Search函数调用的准确率达到55.52%,实际上超过了包括Exa Search、DuckDuckGo、Tavily和Brave Search在内的多个MCP服务器!同时,不同MCP服务器之间的性能差异高达50%以上,从Bing Web Search的64%准确率到DuckDuckGo的仅13.62%。这项发布于GitHub的MCPBench评估框架,首次系统性地将MCP任务分为"数据获取"和"世界改变"两大类,并重点评估了前者。研究者在MySQL 9.2和PostgreSQL 15.8环境中进行了严谨测试,发现了提升MCP性能的关键:将复杂的参数构建(如SQL语句)从LLM移至服务端的声明式接口,在PostgreSQL实验中提升了惊人的22个百分点!无论你是正在选择MCP服务还是思考如何优化现有架构,这篇对既有假设的挑战不仅提供了全面的性能数据,还通过详实的案例研究(涵盖Frames、中文新闻、SQL_EVAL等多个数据集和多种服务实现)揭示了背后的设计原则。未来已来,一起来!
Model Context Protocol(MCP)作为一个开放协议,使AI模型能够通过标准化服务器实现安全地与本地和远程资源交互。在近几个月,已有数千个MCP被提出,同时OpenAI和阿里云等多个模型平台宣布在其LLM产品中支持MCP。你可能已经注意到MCP协议正在迅速普及,但作为开发Agent产品的工程师,你是否曾思考过不同MCP服务器的实际表现如何?它们在效率和效果上是否存在显著差异?更重要的是,MCP是否真的比传统的函数调用方式有明显优势?
研究者设计了一个名为MCPBench的评估框架,用于测试各种MCP服务器在准确性、时间消耗和令牌使用量方面的表现。
项目地址:https://github.com/modelscope/MCPBench
这一评估聚焦于两个关键任务:
研究者确保所有MCP服务器都在相同的环境中使用相同的LLM和提示,以确保评估的公平性和可靠性。
研究中的Web搜索任务要求LLM将问题重写为关键词或简短句子,然后使用工具搜索互联网并返回结果。为消除数据集偏差,研究者引入了多种数据源,包括中文和英文语言的各个领域,如下表所示的从Frames开源数据集(100条)、中文新闻(100条)和中文知识领域(100条)收集的数据。而数据库搜索任务则要求LLM通过数据库MCP服务器从数据库中检索数据,使用的数据源包括合成的汽车制造商数据源(355条)和基于Spider架构的SQL_EVAL数据集(256条)。
研究者从GitHub和Smithary.AI收集了多种MCP服务器,并选择了那些在2025年4月有较多调用记录的服务器进行评估。
这些服务器都提供Web搜索功能但使用不同的搜索引擎和数据处理方法。
它们提供与数据库交互的不同方式和接口。
研究采用了多维度的评估标准:
此外,实验在新加坡的双核CPU、2GB RAM服务器上执行,所有MCP服务器(除DuckDuckGo外)都以SSE模式在服务器上启动,超时设置为30秒,这确保了评估结果的一致性和可比性。
研究结果显示,不同MCP服务器在效果和效率方面存在显著差异,如下表所示:
效果差异:Bing Web Search达到最高的64%准确率,而DuckDuckGo仅有13.62%,相差超过50个百分点。
效率差异:更加明显 - Bing Web Search和Brave Search处理时间不到15秒,而Exa Search则需要231秒,这些数值均基于正常返回而非超时的有效样本。
令牌消耗:相对一致,输出令牌通常在150到250之间,表明模型始终提供简洁答案而不会不必要地解释其MCP使用情况。
研究者将MCP服务器与函数调用的性能进行了比较,结果令人意外,如下图和下表所示:
这表明MCP并不一定在各方面都优于传统的函数调用方式。
研究者探索了如何提高MCP服务器性能,关注点放在数据库搜索任务上。他们发现:
为深入了解不同Web搜索服务的性能差异,研究者使用Frames数据集评估了Brave Search、BochaAI和Qwen Web Search的搜索性能:
如下图所示,提供了前十个相关的wiki百科页面,包括标题、描述和URL,但缺乏详细描述使LLM难以有效地将问题与相关搜索结果联系起来。
如图4所示,总结了搜索结果并明确告知LLM正确答案是"Crimson Tide",这种直接方法使LLM能够准确无误地提供正确答案。
尝试分析和总结搜索结果,但产生了不正确的结果,且没有向LLM展示原始搜索结果,大大阻碍了LLM推导正确答案的能力。
研究者使用SQL_EVAL数据集评估了PostgreSQL MCP Server和XiYan MCP Server在数据库搜索任务上的性能差异:
如下图所示,通过接收LLM生成的SQL查询语句,执行查询并返回结果,实际上只处理数据库连接和执行SQL查询。
如下图所示,设计为直接接受原始问题作为输入,在服务器内部完成SQL生成和执行过程,输出为数据库查询结果,然后由LLM推导最终答案。这种声明式接口方法显著提高了性能,特别是在复杂查询场景中。
研究结果清晰地表明以下关键发现:
对你作为开发Agent产品的工程师而言,这一研究提供了宝贵的指导原则:
通过这些优化,你可以显著提升Agent产品的性能和可靠性。
往期推荐
未来已来,不如结伴而行!
<本文完结>
?让我们一起创造更多美好!
?
如果您觉得这篇文章对您有帮助
感谢您为我【点赞】、【在看】
<您为我点赞在看,只有我能看到>
?微信号:xiumaoprompt
添加请注明来意!
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2025-04-25
OpenAI 白送 200 美元的深度研究功能?实测后发现这个「阉割版」不如不用
2025-04-25
为什么一定要做Agent智能体?
2025-04-25
医疗大模型案例分析(一):Google Med-PaLM
2025-04-25
vLLM+Qwen-32B+Open Web UI构建本地私有大模型
2025-04-25
AI产品经理思考MCP(3):MCP的未来可能
2025-04-25
AI产品经理思考MCP协议(2):标准化的必要性
2025-04-25
AI产品经理思考MCP协议(1):预见MCP——我的“万能库”与标准化之路
2025-04-24
温度参数:调节AI输出的确定性与创造性平衡
2024-08-13
2024-06-13
2024-08-21
2024-09-23
2024-07-31
2024-05-28
2024-08-04
2024-04-26
2024-07-09
2024-09-17