关于MCP

MCP（Model Context Protocol）是一种开放协议，可实现 LLM 应用程序与外部数据源和工具之间的无缝集成。在 AI 驱动的 IDE、增强聊天界面、自定义 AI 工作流等场景，MCP 都能提供一种标准化方法，将 LLM 与其所需的上下文连接起来。其总体架构如下：

（图片来源于官网介绍）

MCP通过提供Resources、Prompts、tools等核心功能，将各种丰富实用的功能封装为标准方法以供模型驱动，其中的设计细节有许多，这里就不过多介绍了。本文主要分享在mcp-server开发过程中遇到的一些问题、思考与解决方式，如果大家有更好的解决方案，欢迎一起探讨。

开发功能介绍

本次开发的功能是用户提供一张kv图和一套页面，通过大模型的意图识别能力，将网页中的图片识别出来并进行加工，从而生成适配kv图风格的页面。

mcp-server包含以下tools：

1. 解析页面协议，识别出页面中需要被替换的图片信息和位置，并将图片地址返回。

2. 根据kv图的风格和页面配图信息，新生成适配kv图的页面配图。

3. 将新页面配图信息重新写入页面协议，得到适配kv图风格页面。

在开发过程中，这些工具都是已有能力，所以开发工作难度不大，更多的工作是适配mcp协议和让大模型能理解这些工具的使用。

实际效果

页面生成流程

原页面与kv图生成页面

问题与解决方案

问题1：mcp-server的tools之间有较强的联系，agent在调用不同的tool时，如何保证参数的准确？

以该功能为例，工具需要识别出被替换配图信息，作为参数传给工具二进行图片生成，同时工具二的生成结果要作为参数调用工具三修改页面协议。这一过程关联性很强，且参数必须精确且一一对应，稍有误差就会导致最终页面不用。

这一问题产生的原因是模型不能稳定地、准确地理解字段含义，因此解决这一问题方式是提供更多准确的信息帮助模型理解。首先考虑的是在agent调用模型时，在prompt中给予较强的约束，同时工具描述参数时尽可能详尽，让模型更多的理解参数含义。其次，通过对tools出入参协议的优化，尽可能保证协议字段的一致性，以帮助模型更好的理解意图。在开发测试过程中，也的确发现字段一致时，模型的犯错概率更低，甚至不出错。

在mcp-server tools设计直出，是希望工具三能作为一个通用的页面协议修改工具，不仅能修改生成配图信息，也可以修改"生成文案"等其它信息，所以入参设计为generate_info_list。但实际验证发现，模型并不能很好的将generate_image_list与generate_info_list进行匹配（有时无法匹配，有时只将列表中的部分内容匹配），最终在工具三汇中加上了generate_image_list字段来帮助模型理解，修改后模型的确能很好理解并关联相同字段。

问题2：当需要调用的tools次数很多时，用户等待服务响应的时耗会较长。

主要原因是模型响应请求很慢，调用tools次数越多，也意味着需要与模型对话的次数越多，整体耗时也就上去了。该项目采用了两种方式来减少tools调用次数：

1. 一个tool尽可能只调用一次，比如需要生成的配图有多张，这里一次性将所有需要生成图片传给工具二进行生图，避免反复调用。

2. 设计tool时，在保证功能的通用性情况下，尽可能完成多的步骤，当然这也需要平衡服务耗时和工具复用（在该场景中，如不考虑复用，这里的三个工具实际可以合并为一个）。

实测下来，每少一次tools调用可以减少5-20s的整体耗时，具体取决与模型推理速度与返包大小。

问题3：工具的返回内容太多，超过了大模型的输入上限导致输出截断。

该场景中，工具三需要返回页面协议给前端展示，整体长度是超过大模型输入限制的，这种场景下，前端往往拿不到完整的页面协议进行渲染。该项目通过引入result-server，将工具执行结果进行存储，然后将查询id返回前端，前端再通过id查询result-server获取执行结果，进行页面渲染。

新增result-server读取mcp执行结果

问题4：单个工具执行时间过长，导致前端较长时间无响应。

工具二需要根据kv图信息来生成配图，并发生成配图的效率约为20秒生成10张配图。但页面中的配图很多，而且生成配图时需要提供备选方案（生成图片有瑕疵或风格不匹配可能导致配图不可用），最终一次工具执行过程中，需要生成40+张配图，共计耗时在1分钟以上，显卡资源被占用情况下耗时则会更高。为避免用户界面长时间无响应的糟糕体验，这里需要合理利用mcp协议中的notify功能，将生图进度以及生成好的图片通知上游返回给前端展示。这样虽然整体耗时不变，但用户可以看到图片生成进度，而且每隔10秒就可以看到新生成好的数张配图，整体体验会得到提升。

在mcp-server开发过程中，也遇到了mcp的一些其他问题。但这些问题都在开发过程中，因版本更新和工具迭代得以解决，后续mcp-server开发过程中不会再遇到，所以统一记录下。

1. 后端开发时，更希望用go语言来开发mcp-server，但官方没有支持go-sdk，这里一开始是使用开源的mcp-go包（https://goo.su/E6y6），开发过程中trpc-go也支持了mcp协议。

2. mcp的session是基于本机内存实现的，在多pod场景，无法保证上游的连续请求调用到同一个pod。也是在开发过程中trpc-go-mcp支持redis session 模块，通过redis存储session，解决了该问题。

整体感受上，mcp社区生态十分活跃，解决问题的效率很高，同时有许多mcp-server项目也非常的有趣，体验下来十分优秀，大家感兴趣也可以去尝试一下: https://t.cn/A6gK8Ghz

思考与展望

MCP将模型和外部工具通信协议标准化，优化了工具开发者的开发体验，同时标准化的协议与丰富的mcp-server，极大的提升了AI应用的使用体验，更加为后续AI应用提供了巨大的想象空间。

但MCP并不是万能的，它更像是一个“中间产物”，是通用模型能力不足时，用于拓展模型能力边界的产物，当通用模型能力达到一定高度，又或者专业领域模型能够较好应用时，也许就不再需要MCP进行扩展了（仅个人观点）。当然，目前MCP仍然是提高产品的智能化与使用体验的最优方案之一。

 

 大模型&AI产品经理如何学习

求大家的点赞和收藏，我花2万买的大模型学习资料免费共享给你们，来看看有哪些东西。

1.学习路线图

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

2.视频教程

网上虽然也有很多的学习资源，但基本上都残缺不全的，这是我自己整理的大模型视频教程，上面路线图的每一个知识点，我都有配套的视频讲解。

（都打包成一块的了，不能一一展开，总共300多集）

因篇幅有限，仅展示部分资料，需要点击下方图片前往获取

3.技术文档和电子书 

这里主要整理了大模型相关PDF书籍、行业报告、文档，有几百本，都是目前行业最新的。

4.LLM面试题和面经合集

这里主要整理了行业目前最新的大模型面试题和各种大厂offer面经合集。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集***

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓