MCP接入CRMEB电商系统，AI驱动的经营分析与智能客服实战

做电商系统开发这几年，我越来越觉得，后台不是缺数据，而是缺一个能把数据变成行动的“中间层”。CRMEB这套开源系统我们从选型到上线用到现在，订单、商品、会员、分销、营销模块都算齐全，可真要让AI跟它对话，就得写一堆胶水代码，还得反复纠结模型支持什么格式、工具怎么注册。直到MCP（Model Context Protocol）出来，我才找到一种“一次接入、处处可用”的接入方式。这篇文章不是概念科普，而是我实际把MCP Server接到CRMEB上，跑通经营分析、库存预警、客服问答全流程的完整记录，包括架构选型、可复制的代码、以及踩过的坑。想给同样在折腾“AI+电商系统”的朋友提供一条能直接走的路。

1. MCP和CRMEB，这两个词是怎么凑到一起的

1.1 先把MCP这个“新概念”用大白话讲透

很多朋友一听到MCP就以为是又一个RPC框架或者API网关，其实不是。MCP是Anthropic在2024年底开源的一个开放标准协议，核心目标非常明确：解决“AI模型怎么安全、标准地调用外部工具和数据”的问题。你完全可以把它理解成USB-C口，以前每个设备都要单独的充电线，每个AI应用都要单独写集成代码；现在有了统一接口，任何支持MCP的AI客户端，都能插上任何符合协议的MCP服务。

一段话讲清它的工作方式：AI客户端（比如Claude Desktop、Cursor这类工具）是Host，里面内置了MCP Client；MCP Server则是一个独立进程，通过stdio或HTTP暴露自己的“工具、资源、提示词”。模型在对话中判断需要调用某个能力时，Client会把请求发给Server，Server执行完把结果返回给模型，模型再基于结果继续回答。整个过程，业务系统的代码不需要大改，AI也不需要重新训练，全靠这个协议在中间做翻译。

我在2025年初集中看了MCP的Python SDK之后就开始动手，那一周最大的感受是：MCP把“工具的定义、调用、权限控制”全部统一掉了，剩下要做的只是写清楚每个工具是干嘛的，模型自己会判断什么时候用。对电商系统这种“接口又多又杂”的场景来说，这个特性几乎是为它量身定做的。

1.2 CRMEB的扩展痛点，正好撞在MCP的枪口上

CRMEB是目前国内用得比较广的开源电商系统，技术栈是PHP（ThinkPHP 6）+ MySQL + Redis，前端用uni-app，覆盖小程序、H5、App、PC和后台管理。订单、商品、会员、分销、优惠券、拼团、秒杀这些电商标配都有，新版本还做了多商户。能跑起来一套完整的交易业务，这是它的优点；但真正让我头疼的痛点也有三块。

第一是数据孤岛。订单在MySQL里，用户行为在Redis里，营销活动状态分散在好几张表里，运营想分析一个问题，得让开发写SQL、导Excel，再人肉汇总。第二是AI接入成本高。就算想用大模型辅助运营，也得先搭一套服务，把数据查出来、格式化、喂给Prompt，再解析模型输出，链路又长又脆。第三是分析动作和业务动作是断开的，AI告诉你有几个SKU库存快见底了，你还得自己登录后台去改，或者另写一套自动化脚本。

这三块痛点，MCP恰好都能治。MCP Server可以直接连CRMEB的数据库（用只读账号）和后台API，把“查订单、查库存、看售后单、发优惠券”这些动作封装成一个个工具；模型碰到“帮我看看这周生意怎么样”这类问题时，自己就会去调对应的工具，拿到数据后再组织语言。业务动作也从“分析完再由人执行”变成了“模型直接调用工具执行”，这就是我标题里说的“无限扩展可能”的核心来源。

2. 整体方案设计：选什么架构，决定后面路好不好走

2.1 两条路线：改业务代码，还是独立MCP Server

动手之前必须先做选择题。让AI拥有CRMEB的能力，明面上有两条路。

第一条路是在CRMEB内部直接写AI模块。比如在后台加一个定时任务，调大模型接口生成日报，或者写一个客服接口去调模型。优点是跟业务靠得近，缺点是耦合太深：CRMEB一升级，你的代码就要跟着改；换一个AI客户端或者换一个模型，所有逻辑都要重写。更麻烦的是，电商系统最怕动核心交易链路，哪怕只是加一个只读查询接口，也要走一遍发布流程，风险不可控。

第二条路就是独立部署一个MCP Server，让它作为“AI客户端”和“CRMEB”之间的翻译官。CRMEB这边的接口和数据库完全不动，MCP Server通过只读账号或者后台API去取数、执行操作；AI客户端那边也不用关心CRMEB是什么技术栈，只要支持MCP协议就能连。我把这条路走了下来，结论很明确：对于已经有线上业务的系统，MCP Server独立部署是唯一让我睡得着觉的方案。

选这条路还有一个附带好处：MCP Server可以同时服务多个AI客户端。运营在Claude Desktop里问数据，开发在Cursor里查订单状态，甚至以后接企业微信机器人，都复用同一个Server，不需要每个端各写一套。

2.2 MCP的三种原语，怎么对应电商业务

MCP协议定义了三种核心原语，刚开始接触时容易混，用电商业务一对照就清晰了。

Tool是可执行的工具，模型主动调用，适合“我需要知道”“我需要做”的场景。对应到CRMEB，就是查订单统计、查库存、查售后单、发优惠券这类动作。工具是MCP里最常用也是最需要谨慎对待的部分，因为它的返回值会直接进入模型的上下文。

Resource是被动读取的资源，像是一个个可寻址的数据文件，模型在需要时读取。对应到CRMEB，可以是商品详情、系统配置、用户信息卡片这类“内容型”数据。我习惯把“可能被反复读取且结构稳定”的数据做成Resource，比如crmeb://product/123这种地址。

Prompt是提示词模板，用来规范模型的输出格式。比如我定义了一个经营日报模板，告诉模型“先列核心指标，再指出波动，最后给建议”，运营每次用的时候只需要说“生成昨天的日报”，模型就会套用模板去调工具、组织答案。

这三种原语的分工可以这样记：Tool是手（做事），Resource是眼（看数据），Prompt是脑（定规矩）。在下面的代码里，我会把三样都用上。

3. 核心实现：搭一个能跑起来的CRMEB MCP Server

3.1 环境准备：SDK、数据库账号、项目结构

我这边用的是Python生态，因为MCP的Python SDK最成熟，写起来也最快。先装依赖：

bash复制pip install "mcp[cli]" aiomysql httpx

mcp[cli]会带上官方的开发调试工具，后面测试会用到。aiomysql是异步MySQL驱动，httpx用来调CRMEB的HTTP接口。项目结构我建议保持简单，一个目录放一个服务文件，后续要加东西也好维护：

text复制/mcp/crmeb/
├── crmeb_mcp_server.py   # MCP Server主文件
├── requirements.txt      # 依赖清单
└── .env                  # 数据库等敏感配置，不要提交到仓库

数据库账号这一步特别重要。不要用CRMEB业务库的管理员账号去连MCP Server，单独建一个只读账号，命令大概是：

sql复制CREATE USER 'crmeb_read'@'%' IDENTIFIED BY '你的只读密码';
GRANT SELECT ON crmeb.* TO 'crmeb_read'@'%';
FLUSH PRIVILEGES;

这样即使MCP Server被攻击，最坏情况也只是数据泄露，不会是删库。另外，不同版本CRMEB的表名和字段可能有差异，我这边用的是标准版4.x，表前缀是eb_，动手前先确认一下你的库里有哪几张表，别照着文章直接跑。

3.2 第一个Tool：订单统计，让AI看得懂经营状况

我先写一个最核心的工具：订单统计。这一步的目的，是让模型具备“看懂经营状况”的能力。代码如下，关键部分我加了注释：

python复制import os
from datetime import datetime, timedelta

import aiomysql
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("crmeb-mcp")

DB_CONFIG = {
    "host": os.getenv("CRM_DB_HOST", "127.0.0.1"),
    "port": int(os.getenv("CRM_DB_PORT", "3306")),
    "user": os.getenv("CRM_DB_USER", "crmeb_read"),
    "password": os.getenv("CRM_DB_PASS", ""),
    "db": os.getenv("CRM_DB_NAME", "crmeb"),
    "charset": "utf8mb4",
}

_pool = None

async def get_pool():
    global _pool
    if _pool is None:
        _pool = await aiomysql.create_pool(
            **DB_CONFIG, autocommit=True,
            minsize=1, maxsize=4, connect_timeout=5
        )
    return _pool

@mcp.tool()
async def get_order_stats(days: int = 7) -> str:
    """统计最近N天的订单核心指标：支付订单数、支付金额、退款订单数、退款金额。"""
    pool = await get_pool()
    async with pool.acquire() as conn:
        async with conn.cursor() as cur:
            since = datetime.now() - timedelta(days=days)
            await cur.execute(
                """
                SELECT COUNT(*), IFNULL(SUM(pay_price), 0)
                FROM eb_store_order
                WHERE paid = 1 AND pay_time >= %s
                """,
                (since,),
            )
            paid_orders, paid_amount = await cur.fetchone()

            await cur.execute(
                """
                SELECT COUNT(*), IFNULL(SUM(refund_price), 0)
                FROM eb_store_order
                WHERE refund_status IN (1, 2) AND refund_time >= %s
                """,
                (since,),
            )
            refund_orders, refund_amount = await cur.fetchone()

    return (
        f"近{days}天：支付订单{paid_orders}单，支付金额{float(paid_amount):.2f}元；"
        f"退款{refund_orders}单，退款金额{float(refund_amount):.2f}元。"
    )

if __name__ == "__main__":
    mcp.run(transport="stdio")

这里有两个细节值得解释。第一，工具描述字段必须写清楚“用途+参数含义+典型问题”，因为模型是靠描述来判断什么时候调用它，写得含糊，模型就不会用。第二，我把返回值处理成了自然语言的一句话，而不是直接吐JSON，这样模型拿到后可以直接引用，减少一步解析，上下文也更省。

3.3 更多工具和资源：库存预警、商品卡片、日报模板

订单统计跑通之后，我再加了几个业务上高频使用的工具。库存预警是运营每天都要看的：

python复制@mcp.tool()
async def get_low_stock_products(threshold: int = 5, limit: int = 20) -> str:
    """查询库存低于阈值的商品列表，用于库存预警和补货建议。参数threshold为预警库存值，limit为最多返回条数。"""
    pool = await get_pool()
    async with pool.acquire() as conn:
        async with conn.cursor() as cur:
            await cur.execute(
                """
                SELECT id, store_name, stock, sales
                FROM eb_store_product
                WHERE is_show = 1 AND is_del = 0 AND stock <= %s
                ORDER BY stock ASC
                LIMIT %s
                """,
                (threshold, limit),
            )
            rows = await cur.fetchall()
    if not rows:
        return "暂无库存低于预警线的商品。"
    lines = [f"- {name}：库存{stock}，累计销量{sales}" for _, name, stock, sales in rows]
    return "库存预警商品：\n" + "\n".join(lines)

商品详情适合做成Resource，它的特点是结构稳定、不会频繁变化：

python复制@mcp.resource("crmeb://product/{product_id}")
async def get_product_info(product_id: int) -> str:
    """读取商品基本信息与库存，用于商品咨询、文案生成等场景。"""
    pool = await get_pool()
    async with pool.acquire() as conn:
        async with conn.cursor() as cur:
            await cur.execute(
                """
                SELECT store_name, price, stock, sales
                FROM eb_store_product
                WHERE id = %s AND is_del = 0
                """,
                (product_id,),
            )
            row = await cur.fetchone()
            if row is None:
                return "商品不存在。"
            return f"商品ID：{product_id}\n名称：{row[0]}\n价格：{row[1]}\n库存：{row[2]}\n销量：{row[3]}"

最后加一个Prompt模板，用来规范日报输出：

python复制@mcp.prompt()
def daily_report(date: str) -> str:
    """经营日报生成模板"""
    return (
        f"请基于你能够调用的订单、商品、库存工具，生成{date}的经营日报。\n"
        "格式要求：\n"
        "1. 先列核心指标：支付单量、支付金额、退款率、客单价；\n"
        "2. 指出环比明显波动的指标，并尝试归因；\n"
        "3. 如果有库存预警商品，单独列出并给出补货建议；\n"
        "4. 最后给出3条可执行的运营建议，建议必须能对应到具体的工具动作。"
    )

写完这些之后，我先用官方的MCP Inspector跑了一遍：

bash复制mcp dev crmeb_mcp_server.py

这个命令会启动一个本地调试面板，可以手动模拟AI客户端调用工具、查看返回结果，比直接接到Claude里调试快得多。我强烈建议你养成这个习惯：先在这个调试面板里把每个工具都点一遍，确认数据正确，再接终端客户端。

3.4 接入AI客户端：Claude Desktop与Cursor的配置

MCP Server本身跑起来之后，接入客户端就是一个配JSON文件的事。Claude Desktop的配置文件在claude_desktop_config.json里，Windows一般在C:\Users\你的用户名\AppData\Roaming\Claude\，macOS在~/Library/Application Support/Claude/。内容这样写：

json复制{
  "mcpServers": {
    "crmeb": {
      "command": "python",
      "args": ["/data/mcp/crmeb/crmeb_mcp_server.py"],
      "env": {
        "CRM_DB_HOST": "127.0.0.1",
        "CRM_DB_USER": "crmeb_read",
        "CRM_DB_PASS": "你设置的只读密码",
        "CRM_DB_NAME": "crmeb"
      }
    }
  }
}

如果用Cursor，配置路径是项目根目录下的.cursor/mcp.json，结构一样。配置好之后重启客户端，在对话里问一句“查一下最近7天的订单情况”，如果能看到工具被调用并返回数据，就说明整条链路通了。

这里有一个我踩过的小坑：Windows下stdio传输经常因为Python路径问题连不上。解决办法是用where python确认解释器完整路径，然后把command写成绝对路径，比如C:\\Python311\\python.exe。另外Windows下中文输出可能乱码，在env里加一项"PYTHONIOENCODING": "utf-8"就能解决。

4. 实际落地：从“能跑”到“好用”的三个场景

4.1 经营日报：每天早上自动喂到嘴边

接好之后，我第一个实际落地场景是经营日报。之前的流程是运营每天上午导Excel、做透视表、写群消息，一套下来至少半小时；现在直接在Claude Desktop里说一句“按日报模板生成昨天的经营日报”，模型会自己去调用get_order_stats、get_low_stock_products这些工具，然后按模板输出。

实测下来，日报里的数字准确率没问题，因为数据全部来自工具实时查询，不存在模型“编造”的问题。运营拿到日报后还能继续追问“为什么支付金额降了”，模型会再去查订单明细、找退款数据，这种对话式的分析，比静态报表舒服太多。

如果你想让日报完全自动化，不需要人开客户端，可以再加一层调度：用系统cron或者你现有的定时任务平台，每天早上9点调一次mcp run或者直接调用MCP Server暴露的HTTP接口，把日报结果推送到钉钉或者企微群。我试过用cron跑，稳定用了两周，后来因为要加更多指标才调整过逻辑。

4.2 智能客服：能查能算，不再只会复读机

第二个场景是客服。传统客服机器人的问题是只能命中固定的FAQ，用户问“我的订单到哪了”“这个商品还有货吗”，它就答不上来。接上MCP之后，客服机器人的回答可以基于实时数据：用户问订单状态，模型调用查订单工具；用户问商品库存，模型调用商品Resource；用户问优惠券，模型调用营销工具。

我测试了一个真实对话，用户说“我昨天买的那个蓝牙耳机到哪了”，模型会先查出用户的订单（这里需要先解决用户身份识别的问题，我在工具入参里加了uid），再根据订单中的物流信息回答。整个过程是数据驱动的，回答不仅自然，而且有据可查。不过客服场景对安全要求更高，用户手机号、地址这类敏感数据一定要在工具里做脱敏，我后面会专门讲。

4.3 营销与库存联动：让AI把手伸到业务动作里

最让我觉得“值回票价”的场景，是把库存预警和营销动作联动起来。运营在对话里问“哪些商品快没货了”，模型查到库存预警列表后，会进一步建议“这款商品库存只剩3件，但销量不错，建议补货或者做限时促销避免超卖”。如果我把“创建优惠券”这类写操作也做成工具，模型甚至可以直接根据运营的授权去执行。

这里要分清哪些工具可以开放给模型自主调用，哪些必须人工确认。我的原则是：只读类工具随便调，写操作类工具（发券、改库存、改价格）必须走“先出方案、人工确认、再执行”的流程。你可以通过工具的描述明确告诉模型“此操作需要用户确认”，也可以在MCP Server里给特定工具加一层审批逻辑。别嫌麻烦，电商系统一旦出事就是真金白银的损失。

5. 踩过的坑、排查思路和安全红线

5.1 高频问题速查表（建议收藏）

我整理了一张问题速查表，基本都是这一周内真实遇到过的：

5.2 权限与安全：电商系统接AI的第一条红线

接MCP Server这一步，安全再怎么强调都不过分。我给自己定了几条红线，你可以直接抄。

第一，数据库只用只读账号，SQL语句里绝不出现UPDATE、DELETE、DROP。如果确实需要写操作，走CRMEB后台API，并且API token用最小权限的那个角色。第二，敏感字段必须脱敏。查询用户信息时，在SQL层面就把手机号处理成138****8888，地址只显示到城市，这样即使模型输出内容被泄露，损失也可控。第三，MCP Server本身要加访问控制，如果走网络传输，一定要放在内网或者加认证，不要裸奔到公网。第四，记录审计日志，每次工具调用的入参、出参大小、耗时都记下来，出问题能回溯。

这四条里我最想强调第一条。MCP Server本质上是“AI能直接操作的数据通道”，通道一旦被攻破，攻击者相当于拿到了数据库的钥匙。只读账号虽然不能写，但至少把破坏范围限制住了。

5.3 性能与稳定性：别让MCP服务成为新瓶颈

MCP Server虽然只是中间层，但它的性能直接决定AI回答的体验。我遇到过一个典型问题：订单统计工具在数据量大了之后，查询要3秒多，模型就会觉得“卡住了”。排查后发现是pay_time字段没走索引，加上索引后降到100毫秒以内，体验立刻不一样。

另一个优化点是把高频查询缓存起来。比如库存预警这类数据，没必要每次都查库，可以在MCP Server里加一层Redis缓存，缓存1到5分钟，响应速度会快很多。工具返回的数据也要控制体积，我的经验是单次返回控制在2000字以内，超过就分页或者聚合。

稳定性方面，建议用pm2或systemd给MCP Server做进程守护，进程挂了自动拉起。MCP这个生态还在快速迭代，SDK偶尔会有不兼容的更新，锁版本是最好的选择：requirements.txt里把mcp、aiomysql的版本固定下来，别一升级就踩新的雷。

6. 从开发到上线的补充建议

6.1 上线前检查清单

折腾了一周，最后沉淀出这么一份清单，每次加新工具我都会对照跑一遍：

• 数据库账号是否是只读，权限是否最小化
• 是否所有敏感字段都已脱敏
• 每个工具是否有清晰描述，参数是否有默认值和边界
• 工具返回是否有长度限制，是否做了聚合
• 日志是否完整，能否回溯每次调用
• 进程是否有守护，崩溃能否自动拉起
• 写操作类工具是否有确认机制
• 是否在MCP Inspector里逐工具验证过

这份清单看着琐碎，但每一行背后都是真金白银的教训。尤其是“写操作确认机制”这一条，我最初图省事没有做，后来AI在测试中真的自己执行了一批发券动作，虽然没造成损失，但吓出一身冷汗。从那之后，写操作一律走审批。

6.2 后续还能往哪些方向扩展

MCP+CRMEB的组合，往深了挖还有很多玩法。我自己规划了几个方向，有些已经开始做了。

第一个方向是RAG+商品知识库。把CRMEB的售后政策、常见问题、商品卖点做成向量库，MCP工具负责召回，客服回答会准确很多。第二个方向是多Agent协作：一个Agent负责看数据，一个Agent负责写营销文案，一个Agent负责执行营销动作，它们共享同一个MCP Server作为操作层。第三个方向是内容生产自动化，把商品Resource喂给模型，批量生成详情页文案、标题、短视频脚本，电商运营的效率会有一个质的提升。

第四个方向是接入更多办公入口。MCP Server本身是协议无关的，你可以做一个小程序管理后台，在里面直接对话问数据，也可以接企业微信机器人，把“AI运营助理”放到工作群里。

最后再分享一个我个人的体会：跑通MCP+CRMEB那天晚上，我让AI自己查了库存、分析了销量、生成了补货建议，然后把建议发到了运营群。那一刻我突然意识到，做系统集成的意义不在于写多少代码，而在于终于给了业务人员一个“用大白话使唤系统”的入口。这套东西的技术门槛不高，但一旦接好，它带来的想象空间是真的很大。