基于MCP协议和MySQL的电商智能服务扩展

1. MCP工作机制概述

模型上下文协议（MCP）是一种开放标准，旨在充当AI模型与外部数据源/工具之间的“通用接口” 。 简单来说，MCP让大型语言模型（LLM）能够通过标准化的方式访问数据库、业务应用等外部系统，就像AI领域的“USB-C端口” 。 MCP采用客户端-服务器架构：AI应用（作为MCP客户端）可以向特定的MCP服务器发送请求，MCP服务器则连接实际的数据源或服务并返回结果 。 通过这一机制，LLM的核心对话和推理能力可以与外部功能相结合——模型负责理解用户意图，由MCP服务器执行实际操作（如查询数据库），再将结果提供给模型用于生成回答。 这样的设计实现了上下文管理和调用链编排：模型可以根据需要多次调用不同的工具，逐步完成复杂任务，而每一步的上下文（中间结果）都通过MCP在模型与工具之间传递，从而使AI系统从孤立的聊天机器人转变为“具有上下文感知能力”的集成系统  。

具体而言，当使用OpenAI等大模型接口时，可以将外部工具（如数据库查询功能）注册为MCP服务器提供的“功能 (function)”。 在对话过程中，MCP客户端会将可用功能列表提供给LLM模型，使其能够通过函数调用的形式请求外部数据。 模型根据用户输入选择合适的功能并给出所需参数，由MCP框架负责调用相应服务器上的功能并获取结果。 这种标准化的通信使用JSON-RPC协议，保证请求和响应格式统一、安全。 此外，MCP还支持双向上下文传递：不仅模型可以调用工具获取数据，MCP服务器也可提供预定义的提示模板或上下文资源给模型。 因此，在电商场景中，模型能够在保持会话上下文的同时，多次与数据库等后端交互——例如先查询商品信息，再根据结果生成推荐——所有这些调用序列都通过MCP有序编排，实现流畅的多步交互。

2. 电商场景中的意图识别

意图识别是指解析用户的自然语言输入，判断其背后的需求类别。 电商服务中常见的意图包括：商品搜索、个性化推荐、订单查询、物流/售后服务等。 例如，

传统上，开发者会为这些场景编写规则或训练分类模型来识别意图，但借助LLM，我们可以利用模型对语言的理解直接进行意图判断。

在MCP+LLM架构下，意图识别通常由大模型自动完成。 一方面，可以在系统提示中明确列出电商常见意图类型，让模型从中选择匹配的类别； 另一方面，OpenAI的函数调用能力也可以用于意图识别——我们为每类意图预定义一个对应的函数，由模型根据用户话述自动选择调用哪个函数。

举例来说，如果提供了“查询订单详情”和“搜索商品”两个函数供模型选择： • 当用户输入“我想看看上一张发票里的商品”（查询历史订单），模型会判断应调用“查询订单详情”功能。 • 当用户输入“我想买两辆红色自行车”时，模型会判定这是在寻找商品，从而调用“搜索商品”的功能。

通过上述机制，模型在理解用户语义的同时完成了意图的分类。 这种基于大模型的方式更加灵活：无论用户使用哪种表述（口语化的描述、不同的措辞），模型都能依据上下文正确映射到相应意图，而不需要我们穷举所有可能的说法。

3. 基于MCP的大模型意图解析与SQL生成

利用MCP调用大模型来识别意图并生成数据库查询，可以大幅简化传统流程，不再依赖繁琐的手工规则配置。 具体来说，当用户提出请求后，LLM会先确定用户意图并提取出关键参数（如商品名称、时间范围等），然后直接将该意图和参数转化为可执行的SQL查询，从而实时获取所需数据。 这一过程得益于OpenAI模型内置的强大自然语言理解和上下文推理能力：模型在函数调用模式下相当于自带了一层意图解析器，开发者无需再编写单独的逻辑去解析语句。 换句话说，大模型本身承担了以往需要规则引擎或NLU模块完成的工作（意图判断、参数提取），OpenAI为我们做了“大部分繁重工作” 。

一旦模型通过MCP确定需要调用数据库查询功能，它可以有两种方式生成SQL：

无论哪种方式，关键在于模型根据意图自动完成从人话到SQL的转换。 这避免了传统“如果…则…”流程配置：当新增一种用户问法或业务需求变化时，我们无需改规则，大模型依靠上下文就能适应生成新的查询逻辑。

4. 基于MCP的实现步骤

下面整理在电商场景下，结合MCP协议和MySQL数据库，实现智能查询/推荐的主要步骤：

  1. 上下文建模： 首先构建对话和用户上下文模型。包括识别用户身份（用于权限控制和个性化，例如知道用户ID以查询其订单）、会话历史（了解用户之前提及的商品或偏好）等。 通过MCP的资源功能，可以在对话开始时提供用户画像、订单历史摘要等上下文信息给大模型，帮助其更准确地理解后续请求。 例如，当用户询问“我上周买的耳机”，系统已经知道该用户最近的订单列表，从而辅助模型锁定相关订单记录。

  2. 意图识别： 当用户提出请求后，由MCP客户端调用LLM来解析意图。 系统提示会引导模型将用户请求分类为预定的意图类型（搜索、推荐、订单查询、售后等），并从话语中提取执行该意图所需的参数。 通常这是通过OpenAI的函数调用接口实现的：我们为每种意图设计一个函数（或API端点），模型会选择调用哪个函数，并填入提取出的参数（例如商品名称=“耳机”, 时间=“上周”）。这一阶段的输出是结构化的意图和参数表示。

  3. SQL查询生成与执行： 接下来，系统根据模型给出的意图和参数构造对应的SQL查询。 在没有函数调用支持的情况下，模型可能直接返回一条SQL语句字符串；但在MCP框架内，更安全的做法是由服务器端工具生成SQL（模型返回调用哪个工具及参数)。 例如，对应“订单查询”意图的MCP服务器工具会将参数插入预先定义的查询模板并得到SQL。 然后通过数据库连接执行该SQL查询（在MySQL上运行），获取结果数据集。 整个过程由MCP的调用链自动编排：客户端收到模型的函数调用意图后，向MCP服务器发起请求执行，服务器查询数据库并返回结果，客户端再将结果转交给模型。

  4. 结果返回与响应生成： 最后，大模型收到数据库返回的结果数据（通常已被格式化为JSON或表格形式），将其与原始用户请求上下文结合，生成自然语言的答复呈现给用户。 例如，数据库返回了订单的详细信息，模型可以整理回答：“您上周购买的耳机订单号是12345，下单日期为3月25日，当前状态：已送达。” 对于商品推荐查询，模型则会根据查询结果的商品列表，结合用户画像生成推荐语。如：“为您推荐以下轻薄笔记本电脑：A品牌XX型号（适合学生，重量仅1.2kg），B品牌YY型号…” 等。 整个响应生成过程仍保留在LLM中完成，使回复更加智能和符合人类语言习惯。

通过以上步骤，系统实现了端到端的智能扩展：用户用自然语言提出需求，大模型经由MCP理解意图并获取实时的数据库信息，最后返回个性化的答案，全程无需人工编写特定场景的规则逻辑，具有较高的灵活性和可扩展性。

5. 实际功能范例

下面以具体例子演示基于MCP+MySQL的大模型能力在电商场景中的工作流程：

5.1. 示例1：订单详情查询

生成SQL：MCP服务器将上述参数转换为SQL查询，例如：

SELECT order_id, product_name, order_date, status
FROM Orders
WHERE user_id = 10086
AND order_date BETWEEN ‘2025-03-20’ AND ‘2025-03-27’
AND product_name LIKE ‘%耳机%’;

该查询获取用户（ID=10086）在上周期间购买商品名称包含“耳机”的订单记录。

系统通过这种方式自动完成了订单查询的全过程。

5.2. 示例2：个性化商品推荐

SELECT name, brand, price, weight 
FROM Products 
WHERE category='笔记本电脑' AND weight<1.5 AND target_customer='学生';

（假定数据库有针对“学生”或“校园”的标识）。也可能综合用户过往浏览/购买数据，由推荐引擎返回排名靠前的几款轻薄本。

5.3. 示例3：物流状态查询（售后服务）

SELECT order_id, tracking_number 
FROM Orders 
WHERE user_id=10086 AND status <> 'Delivered' 
ORDER BY order_date DESC LIMIT 1;

假定得到订单号12345，快递单号XYZ123。随后查询物流表：

SELECT status, last_update, location 
FROM Shipments 
WHERE tracking_number='XYZ123';

得到当前状态比如“运输中，3月27日更新，于上海分拨中心”。

5.4. 示例总结

以上范例展示了在电商服务场景下，结合MCP协议和MySQL数据库，大模型能够智能地理解用户意图并执行相应操作。 从商品搜索、推荐到订单和物流查询，各环节均由LLM驱动逻辑判断，通过标准化接口获取实时数据，最终返回自然语言结果。 这种架构极大减少了人工规则配置：当业务需求变化或出现新表述时，无需手动更新流程，模型的上下文理解和生成能力即可自适应，使电商系统具有更高的智能扩展性和用户友好性。

6. 复杂意图识别方案设计

此设计，客户端可灵活处理多步骤MCP调用，将业务逻辑控制权交给服务端意图识别模块，实现动态化、低耦合的复杂场景支持。

6.1 MCP 定义

6.2 复杂意图识别返回的结构范例

{
  "intent": "复合意图/物流状态查询",
  "confidence": 0.92,
  "actions": [
    {
      "step": 1,
      "method": "query_order_info",
      "params": {
        "user_id": "{{context.user_id}}",
        "status_filter": "!Delivered"
      },
      "error_response_template": "请问你要查询哪一笔订单的物流状态？"
    },
    {
      "step": 2,
      "method": "track_shipment",
      "params": {
        "tracking_number": "{{actions[0].output.tracking_number}}"
      },
      "error_response_template": "您的包裹（订单{{tracking_number}}）目前没有物流信息，请稍后重试"
    }
  ],
  "response_template": "您的包裹（订单{{actions[0].output.order_id}}）目前处于{{actions[1].output.status}}状态（最新更新：{{actions[1].output.last_update}}，在{{actions[1].output.location}}）。"
}
字段 说明
intent 标识复合意图类型（如物流查询需分步操作）
confidence 置信度
actions 包含有序执行的动作列表，每个动作对应一个MCP接口调用
method MCP接口名称（如查询订单、查询物流）
params 动态参数注入，支持从上下文或前序动作结果提取（{{}}模板语法）
response_template 最终回复模板，可组合多步骤结果

6.3 客户端处理流程

  1. 解析意图结构

    • 检测到actions数组中包含多个步骤时，标记为链式调用场景
    • 按step顺序执行每个动作，并动态注入参数

  2. 执行第一次MCP请求

# 示例：解析第一个动作参数
params = replace_template(actions[0].params, context)
# 调用 query_order_info
response1 = call_mcp("query_order_info", params)
# 提取并存储输出字段
store_output(step=1, output=response1.output)
  1. 动态绑定第二次请求参数
# 从第一次结果提取 tracking_number
tracking_num = get_stored_output(step=1, key="tracking_number")
# 动态生成第二次参数（模板替换）
params = {"tracking_number": tracking_num}
# 调用 track_shipment
response2 = call_mcp("track_shipment", params)

store_output(step=2, output=response2.output)
  1. 组合最终结果
# 填充回复模板
final_response = render_template(
    intent.response_template,
    actions=[response1, response2]
)
# 示例输出：
# "您的包裹（订单12345）目前处于运输中状态（最新更新：3月27日，在上海分拨中心）。"