当前位置：首页 > news >正文

MCP‌和LangGraph‌结合2

news 来源：原创 2025/4/25 13:31:53

“确保不同团队开发的模型（意图识别、问答）通过统一协议交换上下文”是什么意思？
我理解的一是因为使用的是统一标准的接口协议，所以可以对接不同厂商的大模型；
二是不同厂商的大模型提供的接口也支持mcp协议；
我认为应该是一吧？

核心确实是“统一标准的接口协议”（即你提到的第一点）‌，但需要进一步明确协议覆盖的范围。以下是详细解释：

‌1. 你的理解正确：关键在于“接口标准化”‌

当提到 ‌“通过统一协议交换上下文”‌，核心是解决两个问题：

‌技术兼容性‌：不同团队开发的模型对外暴露的接口（如 HTTP/gRPC）遵循‌相同的调用规范‌（例如请求方法、参数格式、错误码）。
‌语义一致性‌：传递的上下文数据（如对话历史、任务状态）使用‌统一的数据结构‌（例如 JSON Schema 或 Protobuf 定义）。

‌示例‌：假设团队A开发意图识别模型，团队B开发问答模型：

‌无 MCP 协议时‌：
- 团队A的接口：POST /intent {text: string}，返回 {"intent": "weather"}。
- 团队B的接口：POST /answer {query: string, history: array}，返回 {"answer": "今天晴天"}。
- ‌问题‌：两个接口的输入输出格式不兼容，无法直接协作。
‌使用 MCP 协议后‌：
- 团队A和B均遵循 MCP 定义的接口：POST /mcp {context: MCPContext, input: string}。
- 输入输出强制使用 MCP 的 MCPContext 数据结构（如包含 session_id, history, metadata 等字段）。
- ‌结果‌：两个模型可直接互相调用，无需额外适配。

‌2. 为什么不是“厂商主动支持MCP协议”（你的第二点）？‌

‌MCP 是技术中立的协议‌：它的本质是一套规范文档（类似 HTTP 协议的定义），‌不要求厂商必须“官方支持”‌。
‌实际应用方式‌：
1. ‌适配层‌：如果某厂商的大模型未原生支持 MCP，可以通过封装一个‌适配层（Adapter）‌，将其原生接口转换为 MCP 格式。
2. ‌开发约束‌：企业内部或合作团队间‌约定强制使用 MCP‌，所有新开发的模型必须实现该协议。

‌示例‌：调用未支持 MCP 的 OpenAI 模型：

pythonCopy Code

# MCP 适配层示例 def call_openai_with_mcp(mcp_request: MCPRequest): # 将 MCP 请求转换为 OpenAI 所需格式 openai_format = { "messages": [{"role": "user", "content": mcp_request.input}], "context": mcp_request.context.get("openai_params", {}) } # 调用原生 OpenAI 接口 response = openai.ChatCompletion.create(**openai_format) # 将 OpenAI 响应转换为 MCP 格式 return MCPResponse( output=response.choices[0].message.content, context={"openai_params": openai_format} )

‌3. 协议的核心价值：解耦与协作‌

‌场景：跨团队协作开发客服系统‌

‌团队‌	‌职责‌	‌依赖 MCP 的行为‌
意图识别团队	开发意图分类模型	通过 MCP 接收用户输入和上下文，返回意图标签
问答团队	开发领域知识问答模型	通过 MCP 接收意图和上下文，生成回答
流程编排团队	集成所有模型	调用 MCP 接口，无需关心各团队内部实现细节

‌解耦‌：各团队只需遵守协议，无需等待其他团队开发完成即可并行工作。
‌协作‌：上下文格式统一后，模型间的数据传递无歧义（例如所有团队对 history 字段的定义一致）。

‌4. 类比：现实世界的标准化协议‌

‌场景‌	‌协议‌	‌作用‌
不同设备连接Wi-Fi	IEEE 802.11	规定信号频率、加密方式等，确保设备兼容
不同浏览器访问网站	HTTP/HTTPS	统一请求方法、状态码，确保跨平台通信
不同模型交换上下文	MCP	统一接口和数据格式，确保跨模型协作