"会说不会做"的大模型
LLM虽然能力非常强大，但其应用不应局限在语言或者对话，但是如果需要做更深入细节的相关相关的AI应用除了对
MCP全称是 Model Context Protocol，是Anthropic在2024年11月25日提出的一个开源协议标准，用来解决大预言模型处理外部资源以及工具的的问题。即使是目前最先进的LLM，仍受到很多限制，很多数据需要来源于外部工具来实现共享和调用。
Function Calling
关于外部工具调用，最早的是OpenAI的在gpt-4中引入的Function Calling 功能，该功能通过定义工具的名称、功能、参数、描述等信息，将工具库提供给大模型，大模型会根据业务需求自主判断是否需要以及调用工具库中的工具。下面是一个简单的tools定义和fucntion calling的示例：
tools = [
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "Get the current weather in a given location",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city and state, e.g. San Francisco, CA",
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"]},
},
"required": ["location"],
},
},
}
]
调用使用openai的标准库
def get_completion(messages, model="gpt-3.5-turbo-1106", temperature=0, max_tokens=300, tools=None):
response = openai.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
max_tokens=max_tokens,
tools=tools
)
return response.choices[0].message
但是最初版的Function Calling 功能存在以下问题：
+ 没有统一的行业标准，每个厂商LLM提供的JSON结构和实现方式都不同
+ 需要开发者为每个模型编写特定的适配代码
+ 不负责执行，无法提供函数管理，通常只生成指令，需要开发者手动完成调用
这导致实际AI应用中集成Function calling开发量过大。因此MCP应运而生。
MCP协议
MCP定义了应用程序和大模型之间信息交换的方式，让开发者可以用一致的方式吧数据源、工具和功能连接到大模型中，类似USB-C可以让不同的设备进行连接一样。
| 类别 | MCP（Model Context Protocol） | Function Calling |
|---|---|---|
| 性质 | 协议 | 功能 |
| 范围 | 通用（多数据源、多功能） | 特定场景（单一数据源或功能） |
| 目标 | 统一接口，实现互操作 | 扩展模型能力 |
| 实现 | 基于标准协议 | 依赖于特定模型实现 |
| 开发复杂度 | 低：通过统一协议实现多源兼容 | 高：需要为每个任务单独开发函数 |
| 复用性 | 高：一次开发，可多场景使用 | 低：函数通常为特定任务设计 |
| 灵活性 | 高：支持动态适配和扩展 | 低：功能扩展需要额外开发 |
总的来说MCP和Function Calling一样，都是为了实现大模型和外部资源的集成，解决LLM只能说不能做的问题。
使用Cline和MCP Inspector 构建能源系统优化MCP Server
构建能源系统优化程序
要使用MCP协议封装一个能源系统优化程序，首先要将能源系统优化问题的代码和资源封装成函数，然后将函数注册到MCP服务器上，最后通过MCP客户端调用函数。
def opt(ramp_up,pv_osi) -> tuple:
"""_summary_
Args:
ramp_up (float): fuel cell ramp up rate
pv_osi (int): pv oscillation index
Returns:
tuple: device capacity, operation results
"""
# optuimize
return device_cap, res
device_cap,res = opt(1/6,0)
这里不展开优化函数内部的逻辑，总的来说是根据输入的爬坡速率参数和光伏波动指数计算出设备容量和运行结果。
注册和构建MCP Server
这里使用mcp库构建stdio的mcp server，注册工具函数，然后启动server。具体脚本如下
from mcp.server.fastmcp import FastMCP
from model_idc.model import opt
# Create an MCP server
mcp = FastMCP("Demo")
# Add an addition tool
@mcp.tool()
def copt_opt(dict_in) -> int:
"""计算一组规划问题，考虑不同的燃料电池爬坡速度
Args:
ramp_rate (float): 燃料电池爬坡时间，通常为0.3,0.8,0.1等
pv_osi (int): in [0,1,2],描述波动程度，通产给0即可
Returns:
device_cap: 设备规划容量
"""
device_cap,_ = opt(float(dict_in["ramp_rate"]),int(dict_in['pv_osi']))
print(device_cap)
if __name__ == "__main__":
mcp.run(transport="stdio")
值得注意的是这里mcp虽然使用修饰器@mcp.tool()来注册，但是实际上函数的输出应当是print的io形式返回，return是无法给出具具体内容的。
使用MCP Inspector 调用MCP Server
MCP Inspector是一个基于MCP协议的客户端，用于调用MCP服务器上的函数。它提供了一个图形化的界面，让用户可以方便地调用MCP服务器上的函数。
具体安装方法可以参考MCP Inspector
这里使用以下命令启动inspector
npx @modelcontextprotocol/inspector
启动后默认端口在6274，在左侧创建新的mcp server，这里使用命令行创建。在创建的时候一定要注意路径的选择，包括server的路径和python的路径。
PATH_PYTHON\\python.exe PATH_SERVER\\mcp_server.py
启动后的界面上可以connect到server，然后可以调用工具函数。
点击tools中枚举以下识别的，随后设置好测试的输入即可调试输出。这里我们的输出是一组设备的规划容量。
使用Cline集成大模型并调用MCP Server
为了方便使用，使用vscode的cline插件，这里需要使用以下json注册一个mcp server。
{
"mcpServers": {
"copt": {
"disabled": false,
"timeout": 60000,
"command": "PAHT_TO_PYTHON\\python.exe",
"args": [
"PAHT_TO_SERVER\\optMCP\\server.py"
],
"transportType": "stdio"
}
}
}
随后使用cline进行测试，如果有绿点和info而没有error则说明成功
最后可以每次直接与大模型对话，大模型会自动识别并申请调用。因为MCP消耗的token较大，所以每次需要给用户申请。
