1. MCP简介
在之前的夏令营中笔者接触了基础的大语言模型概念（LLM），这一期的夏令营主要围绕的是MCP的概念进行学习。
在一切介绍开始之前，我们不妨对MCP下一个相对直观易懂的概念，MCP的本质是为大语言模型插上双手，使大语言模型可以通过特定的协议来直接参与到日常的工作当中。（这里的直接是重点）
我们在日常使用大模型的时候，经常会面对的场景是我们需要大模型直接介入我们的工具中，但是大模型本身扮演的是"决策大脑的角色"，他并没有办法直接介入我们的工具当中。这给我们的日常工作带来了阻碍，比如下图中我们要求本地部署的大模型帮助我们在test_file下创建一个new_file.txt，他只能给出一个间接方案来帮助我们进行创建
那我们有没有什么办法让大模型直接操纵我们的电脑进行输出呢？
这个时候我们不得不想起计算机领域的经典句子：
计算机科学中没有什么是不可以通过加一层中间层不能解决的
这里的中间层就是Model Control Protocol（MCP）
MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB-C 接口。就像 USB-C 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。
我们不妨看看下图来更好的理解MCP协议的基础架构：
不难看出MCP实际上遵循了标准的C/S架构，这里我们需要介绍几个概念：
- MCP Hosts:这个就是我们需要LLM操纵的工具，比如VScode、word、PPT等
- MCP Clients: 主要负责维护和MCP Sever的链接（这里注意链接是一对一的）
- MCP Servers: 通过标准的 Model Context Protocol 提供我们需要的能力，比如修改文档、代码等
- 本地数据源: MCP 服务器可安全访问的计算机文件、数据库和服务
- 远程服务: MCP 服务器可连接的互联网上的外部系统（如通过 APIs）
MCP的协议整体架构实际上类似于TCP/IP架构的分层式架构，主要分成协议层 和传输层
- 协议层:协议层处理消息框架、请求/响应链接和高级通信模式。
- 传输层：处理 clients 和 servers 之间的实际通信
这里我们看一个协议层的架构代码
python
class Session(BaseSession[RequestT, NotificationT, ResultT]):
async def send_request(
self,
request: RequestT,
result_type: type[Result]
) -> Result:
"""
发送请求并等待响应。如果响应包含错误则引发 McpError。
"""
# 请求处理实现
async def send_notification(
self,
notification: NotificationT
) -> None:
"""发送不期望响应的单向通知。"""
# 通知处理实现
async def _received_request(
self,
responder: RequestResponder[ReceiveRequestT, ResultT]
) -> None:
"""处理来自另一端的传入请求。"""
# 请求处理实现
async def _received_notification(
self,
notification: ReceiveNotificationT
) -> None:
"""处理来自另一端的传入通知。"""
# 通知处理实现此处不难看出MCP协议的的本质和TCP/IP协议有异曲同工之处，两者都是作为某种中间层用户提供某种统一的规范，让用户可以将各种工具联动起来。
2 MCP-Sever项目的设计与实现：七日餐饮助手
前面我们已经聊了很多的关于MCP的基础知识，在本次的夏令营中，我们需要搭建一个MCP Sever来为用户提供服务，此处我们先对我们MCP Sever进行一定的设计，在下一篇博文中我们会具体实现这个MCP-Server
2.0 痛点分析
传统的菜单或者美食软件往往提供的是基本的美食食谱，缺乏对于长时间的餐饮规划。同时不同用户往往会对于餐饮规划有个性化的要求。用户对于餐饮的要求往往是难以捕捉的，用户如果再健康目标 、饮食习惯上出现了调整，往往需要耗费大量的精力和时间对原本的餐饮计划进行调整。此类用户急需一类软件可以根据用户的个性化需求制定一段时间较长的餐饮计划的，同时可以实时根据用户的口味、健康目标变化实时进行调整。
因此我们决定设计一个七日餐饮助手
2.1 功能用途设计：
我们希望七日餐饮助手可以基于用户的个性化需求 为用户提供一周七日的详尽饮食规划 。其中我们希望主要满足客户以下的三点需求，我们针对的主要用户是对于自己的饮食有一定要求、同时需要通过饮食规划来达成自己的健康目标的用户。七日餐饮助手将会基于MCP根据用户的餐饮偏好、健康目标来设计七日菜单，主要的功能如下：
- （素食/少盐/少辣/中餐/西餐/剔除忌口/.......）
- 可以针对用户指定的餐品给出清晰明了的步骤
- 针对客户的特殊健康需求制定七日菜单（增肌/减脂/........）
2.2 技术难度评估：
目前对于这个项目的技术评估为中等难度
个人对项目的规划上主要可以依赖成熟的API及第三方库来实现，目前最大的技术难点我认为主要是数据爬取和数据清洗这两块，下面会分别介绍一下主要考虑的问题
- 数据爬取：有没有什么比较好的数据来源，这里我主要想到的是github的开源项目
程序员做饭指南，如果这个开源项目无法满足可能还可以考虑一些美食食谱网站。
- 数据清洗：这个地方的主要需要分离出菜品的原料来满足用户的需求
这里给出一个较为基础的流程图
2.3 技术栈：
-
语言：Python 3.12
-
主要框架/库：
- Gradio：用构建用户的交互界面
- BeautifulSoup4：用来爬取第三方数据，主要是作为本地数据不足情况下的补充
- PyGithub：用来动态访问程序员做饭指南这个仓库，保证在更新的时候进行同步
- LangChain：这个主要是用来做多条件食谱生成的（这个要视乎忌口和健康目标的支持规模而定，如果只是简单的或许一个决策函数就可以做得到？ ）
- Pandas：主要用来处理BS4爬取的数据，将其进行结构化
- Loguru：主要用于记录运行情况（这个到时候会根据平台自带的日志系统进行调整）
这里我们给出基本的项目架构设计
2.4 设计细节：
这里我们主要先对数据的输入输出进行规范和设计
2.4.1 输入格式
输入格式： 偏好列表+忌口列表+目标列表
输入范例：西餐 少盐，不吃洋葱，不吃乳制品， 增肌
{ "preferences": "西餐", "少盐", "avoid": "洋葱", "乳制品", "health_goal": "增肌", }
json
{
"preferences": ["西餐", "少盐"],
"avoid": ["洋葱", "乳制品"], "health_goal": "增肌",
}2.4.2 输出格式
json
{
"status": "success",
"message": "7日餐饮计划生成完成",
"data": {
"周一": {
"早餐": {
"dish": "全麦面包配牛油果",
"steps": "steps_db/全麦面包配牛油果.json"
},
"午餐": {...},
"晚餐": {...}
},
"周二": {...},
// ...其余日
}
}整体的输出流程如下图所示：
2.5 MCP声明(接口声明)：
这里我们采用Python Docstring格式，接口如下：
python
def generate_weekly_meal_plan(
preferences: list[str],
avoid: list[str],
health_goal: str,
days: int = 7
) -> dict:
"""
Args:
preferences (list[str]): 用户的饮食偏好列表
可选值: "素食", "少盐", "少辣", "中餐", "西餐", "无麸质", "低脂", "高蛋白"
示例: ["素食", "少盐"]
avoid (list[str]): 用户需要避免的食材列表
示例: ["鸡蛋", "海鲜"]
health_goal (str): 用户的健康目标
可选值: "增肌", "减脂", "均衡", "控糖"
示例: "减脂"
days (int): 生成计划的天数(1-14天)，默认为7天
示例: 7
Returns:
dict: 包含以下结构的字典:
{
"status": str, # 执行状态("success"/"error")
"message": str, # 执行结果描述
"data": { # 生成的餐饮计划数据
"monday": { # 星期一的餐饮计划
"breakfast": { # 早餐详情
"dish_name": str, # 菜品名称
"steps_reference": str # 烹饪步骤文件路径
},
"lunch": {...},
"dinner": {...}
},
"tuesday": {...},
# ...其他日期...
}
}"""3. 实机测试：
先做了一个最简单版本的，效果如下图所示：
