先交代下背景。我大概从去年底开始,被一堆 Excel 杂活压得喘不过气:月底汇总各渠道订单、给不同部门出格式各异的报表、把临时的 CS V数据清洗成可分析的表格。传统玩法是开 Python 脚本或者录个宏,可每次业务口径一改,脚本也得跟着改,改到后面我自己都不想再动了。后来接触了 MCP(Model Context Protocol),花了一个周末把第一个 Excel 处理 MCP 服务跑通,整个思路一下就打开了:让 AI 直接“操作”Excel,而不是让 AI 只“读”Excel。这篇文章就把我从零到一开发的过程、踩过的坑、以及最终靠自然语言指挥 AI 处理 Excel 的完整链路整理出来,适合正在用 AI 提效、又不想被重复数据工作困住的人。1. 为什么是 MCP:AI 能力的“插线板”逻辑1.1 MCP 给我的第一印象第一次看到 MCP 这个词,我下意识以为又是什么新框架。查了之后才明白,它本质上是一套通用协议,让 AI 模型能通过统一标准去调用外部工具和数据源。你不需要为每个软件写一套独家的插件适配,只要实现同一套协议,AI 就能自然调用。我当时的反应是:这不就是个插线板吗?以前每个设备都要自己的充电头,现在统一成 Type-C,谁支持这个口谁就能插上。换句话说,MCP 拆成了三个角色:MCP Host:承载 AI 的客户端,比如 Claude Desktop、Cline、Cherry Studio,也包括一些支持 MCP 的浏览器扩展和 IDE 插件;MCP Server:提供具体能力的服务端,比如我这次写的 Excel 操作服务;MCP Client 与协议传输:负责 Host 和 Server 之间的连接,常见传输是 stdio 和 SSE/HTTP。我用一句话总结自己踩完整个流程后的理解:MCP 让 AI 的能力边界从“聊天窗口”扩展到了“真实世界”。过去 AI 只能基于你粘贴的内容回答,现在它能主动读文件、写文件、调工具,然后把结果拿回来继续推理。这不是简单的 API 调用,而是把工具能力变成了模型推理的一部分。1.2 为什么 AI 直接“看”Excel 不够用在动手之前,我先回顾了以前让 AI 处理 Excel 的几种笨办法,方便对比出 MCP 的价值:方式问题直接把 CSV 内容复制进对话框文件一大就超出上下文上限,而且表格语义很容易错乱让 AI 生成 Python 脚本,再手动运行数据路径、字段名都要人肉告诉它,来回修改特别费劲本地安装插件插件只能在固定软件里用,不能被 AI 自主编排最典型的问题就是 AI 读文件只能读前几行,合并单元格读出来是一堆 NaN,日期格式识别成字符串。原因很简单:模型本身没有“打开文件”的能力,它只能看到你给它看到的东西。MCP 的做法是把“读 Excel”变成可以被模型动态调用的工具——需要读哪张表、读多少行、用什么粒度,都由 AI 根据你的问题临时决策。1.3 MCP 和传统宏、RPA、脚本的根本区别很多人会问:我用 Python 写个脚本、用 Excel 宏、用 RPA 工具不也能处理吗?能,但根本逻辑不同。宏和脚本是“写死的逻辑”:领域模型全在代码里,业务一变,代码就得跟着变;RPA是“录制的流程”:擅长固定界面操作,但对内容的理解为零,稍微异常就卡死;MCP AI是“动态决策”:模型随时根据你的自然语言需求,决定调用哪个工具、传什么参数、按什么顺序执行。举个实际例子。以前同事让我“把销量表按地区汇总,顺势做个占比分析”,我得去问清楚“按哪个地区维度”“占比是指总量占比还是渠道占比”。现在 AI 可以先调用读取工具看一眼表结构,再根据上下文判断“按省”汇总,然后自动生成汇总数据和占比字段,最后把结果写回新 Sheet。整个过程里,AI 替代的是“分析需求 操作软件 形成结论”的链路,而不是单纯的按钮点击。这也就是我为什么坚持推荐先做一个 Excel 方向的 MCP:它把传统“人写逻辑”变成“人提需求 AI 调用能力”,刚好踩中工作流重构的核心。2. 选 Excel 当第一个 MCP 项目的几个理由2.1 Excel 工作流里的真实痛点我日常接触的 Excel 场景可以分成四类:数据导入与清洗:导出的数据总是带格式杂质、重复行、缺失值,清洗逻辑不难但很花时间;报表生成与格式化:同样的业务数据要按不同部门出不同格式的表,表头颜色、行高列宽、页眉页脚,每处都要手动调;透视与汇总:按月、按区域、按 SKU 做多维汇总,公式反复套;跨表关联:把多个 Sheet 或多个文件根据关键字段合并,Excel 自带 VLOOKUP 能用,但表一多就容易出错。这些痛点不是“不会做”,而是“重复做”太浪费时间。传统工作流里,我大概要花一半时间在“把数据从 A 表挪到 B 表并调格式”上,真正该做分析的时间反而被挤压。MCP 的价值在于把这一大段重复劳动交给 AI,让它基于工具能力去完成,而人只需要确认结果。2.2 为什么 AI 直接处理 Excel 总“读不准”我第一次尝试用 AI 处理 Excel 时,直接用自然语言让它“帮我算一下这张表各部门的平均薪资”。它给我的结果是错的,原因是它只看到了我贴进去的前 20 行。后来我把整个文件路径给它,它又说看不懂 xlsx 二进制内容。真实原因有几层:二进制格式:xlsx 本质是 zip 压缩的 XML,模型没法直接解析;上下文限制:即便转成文本,一个几万行的 Sheet 也远远超出模型的上下文长度;语义丢失:合并单元格、单元格格式、公式缓存值,转成纯文本时都会丢失或错乱。MCP 恰恰把“解析 xlsx”的活从模型手里转移到了服务端脚本里。服务端用 pandas 或 openpyxl 读取后,把结果结构化成 Markdown 表格或 JSON 返回给模型,这样模型只处理“已经解析好的结构数据”,自然就准了。2.3 为什么它是练手项目的最好选择选 Excel 作为第一个 MCP 项目,不是因为它最复杂,而是因为它边界清晰、反馈直观、单点技术栈足够小:读写 Excel 的 Python 库非常成熟,不需要处理复杂协议;操作结果看得见摸得着,写错一眼就能发现;核心流程(读取→分析→写入→格式化)与大部分工作流场景通用,练完之后能平移到 PDF、数据库、Web 自动化等方向。我的建议是:别一上来就搞多工具聚合的复杂 MCP,先把一个 Excel 服务做到能稳定读取、稳定写入、稳定格式化,你就已经掌握了 MCP 开发 80% 的核心。3. 搭项目骨架:SDK 选型与最小实现3.1 选型:fastmcp 还是官方 SDK?MCP 官方提供了 TypeScript 和 Python SDK,但封装度不算高,很多底层细节要自己处理。社区里比较成熟的是fastmcp这个库,它对 Python 做了高度封装,把工具注册、参数校验、传输协议都简化了,特别适合我这种“想快速跑通”的场景。我对比过两种方式:对比项官方 SDKfastmcp学习成本偏高,需要理解协议细节低,装饰器注册即可代码量较多极少扩展性自由度高核心场景足够社区活跃度官方维护社区活跃,更新快我最终选了 fastmcp。倒不是说官方不好,而是对于第一个项目,先把链路跑通、把思路验证完是最重要的。等后面需要极致控制底层时,再考虑回到官方 SDK 不迟。3.2 环境准备这一步我用的是 Python 3.11,项目里主要依赖这几个库:pip install fastmcp openpyxl pandas tabulatefastmcp:负责 MCP 服务框架和传输协议;openpyxl:负责 Excel 读写和格式控制;pandas:负责数据结构化、聚合、清洗;tabulate:把 DataFrame 转成 Markdown 表格,方便返回给模型阅读。另外我建议用uv来管理 Python 环境,比直接用 pip 更清爽。目录结构大致如下:excel-mcp/ ├── server.py # MCP 服务入口 ├── tools/ │ ├── read_excel.py # 读取模块 │ ├── write_excel.py # 写入模块 │ └── format_excel.py # 格式化模块 ├── storage/ # 放待处理的 Excel 文件 ├── logs/ # 运行日志 └── requirements.txt3.3 最小 MCP 服务一个能跑的最小服务其实很短:from fastmcp import FastMCP mcp FastMCP(excel-mcp) mcp.tool() def ping() - str: 健康检查用,客户端连接后可以调用此工具确认服务正常。 return pong if __name__ __main__: mcp.run(transportsse)这里关键就几行代码:创建 FastMCP 实例并命名服务;用mcp.tool()注册一个工具函数,函数名、参数、docstring 都会变成模型的工具描述;mcp.run(transportsse)启动服务,SSE 模式适合通过 HTTP 远程连接。我本地调试时,比较喜欢用transportsse,因为它可以在浏览器里直接看到工具列表和调用日志。如果只在同机调试,transportstdio更轻量。建议初学先用 SSE,排错直观。提示:fastmcp 会基于函数的 type hint 和 docstring 自动生成工具描述,所以写工具函数时,docstring 一定要写清楚用途、参数含义、返回值格式,这直接决定了 AI 会不会正确调用。4. 核心实现:让 AI 学会操作 Excel4.1 工具粒度怎么拆这是整个设计里最重要的一步。我一开始犯过错误,只写了一个do_everything工具,参数乱七八糟,AI 经常调错。后来把工具拆成“读、写、格式化、转表”四个基础能力,AI 的组合空间反而更大。最终我保留了这几个工具:list_sheets:列出 Excel 文件里所有 Sheet 名称;read_excel:读取指定 Sheet 为 Markdown 表格,支持指定行数范围;write_dataframe:把二维数据批量写入指定 Sheet;write_cell:单点写入某个单元格(偶尔会用);format_range:对指定区域设置字体、对齐、列宽、背景色;excel_to_markdown:把 Excel 区域转成 Markdown,便于 AI 阅读分析;set_autofilter:给数据区域添加筛选按钮。拆这么细的原因,类比一下就是:你给 AI 的不是一台只会在“模式 A”下运行的机器,而是一套乐高积木。模型根据当前问题自己决定怎么拼。比如“读出来→筛选→找出异常→写回去”,这四步对应四个工具的连续调用。4.2 读取工具的实现读取是整个流程的地基。实现上我优先使用 pandas 来解析,因为它在类型推断、缺失值处理上都比 openpyxl 更适合给模型提供结构化数据。import pandas as pd from io import StringIO mcp.tool() def read_excel(file_path: str, sheet_name: str None, max_rows: int 200) - str: 读取 Excel 文件的指定工作表,返回 Markdown 格式的数据预览。 Args: file_path: Excel 文件完整路径 sheet_name: 工作表名称,默认读取第一个工作表 max_rows: 最多返回多少行,默认 200 行 xl pd.ExcelFile(file_path) if sheet_name is None: sheet_name xl.sheet_names[0] df pd.read_excel(xl, sheet_namesheet_name) if max_rows and len(df) max_rows: preview df.head(max_rows) return f[仅预览前 {max_rows} 行,总行数 {len(df)}]\n preview.to_markdown(indexFalse) return df.to_markdown(indexFalse)这里我把数据转成 Markdown 而非 JSON,原因是 Markdown 表格对模型来说更易读,而且直接粘贴到对话里人类也能看。模型拿到这个表格后再做聚合分析,正确率会明显提升——它看到的不再是“第 3 列是乱码”,而是一张干净清晰的表。4.3 批量写入与 Excel 公式读取解决的是“AI 怎么获取数据”,写入解决的则是“AI 怎么把结果落盘”。实际使用中,单点write_cell用得很少,因为 AI 驱动的流程大多是“算好一个 DataFrame,整体写回去”。所以我主要提供了write_dataframe:import openpyxl from openpyxl.utils import get_column_letter mcp.tool() def write_dataframe(file_path: str, sheet_name: str, data: list[list], start_row: int 1, start_col: int 1) - str: 将二维数组数据写入指定工作表的指定区域。 Args: file_path: Excel 文件路径 sheet_name: 工作表名,不存在则创建 data: 二维数组,第一行通常会作为表头 start_row: 起始行号(1 开始) start_col: 起始列号(1 开始) wb openpyxl.load_workbook(file_path) if sheet_name in wb.sheetnames: ws wb[sheet_name] else: ws wb.create_sheet(titlesheet_name) for row_idx, row_data in enumerate(data, startstart_row): for col_idx, value in enumerate(row_data, startstart_col): ws.cell(rowrow_idx, columncol_idx, valuevalue) wb.save(file_path) return f已写入 {len(data)} 行数据到 [{sheet_name}] 工作表,起始坐标 ({start_row},{start_col})。对于公式,我单独强调一点:AI 生成的公式字符串写入单元格后,openpyxl 默认只保存公式,不会立即计算。如果你之后用 pandas 去读这个单元格,拿到的是公式字符串而不是计算结果。解决方案是写入后调用一次 Excel 计算引擎,或者在本服务里用formulas库做公式解析计算。我更推荐的做法是:凡是涉及统计类结果,尽量在服务端用 pandas 算好再写入,让 Excel 存纯数值,这样后续任何工具读取都不会踩“公式没缓存值”的坑。4.4 格式化:你把表格调成业务想要的样子格式化是 80% 重复劳动所在。实际开发中我封装了format_range,支持设置表头背景色、加粗、对齐、列宽和自动筛选。from openpyxl.styles import Font, PatternFill, Alignment mcp.tool() def format_range(file_path: str, sheet_name: str, start_row: int, start_col: int, end_row: int, end_col: int, bold_header: bool True, header_fill: str D9E1F2, column_width: int 18, wrap_text: bool True) - str: 对工作表指定区域进行统一的表格格式化。 Args: file_path: Excel 文件路径 sheet_name: 工作表名 start_row/start_col/end_row/end_col: 目标区域范围 bold_header: 是否加粗表头 header_fill: 表头背景色(十六进制 RGB) column_width: 列宽 wrap_text: 是否自动换行 wb openpyxl.load_workbook(file_path) ws wb[sheet_name] header_cells list(ws.iter_rows(min_rowstart_row, max_rowstart_row, min_colstart_col, max_colend_col)) for cell in header_cells[0]: if bold_header: cell.font Font(boldTrue) cell.fill PatternFill(start_colorheader_fill, end_colorheader_fill, fill_typesolid) cell.alignment Alignment(horizontalcenter, verticalcenter, wrap_textwrap_text) for col in range(start_col, end_col 1): ws.column_dimensions[get_column_letter(col)].width column_width ws.auto_filter.ref f{get_column_letter(start_col)}{start_row}:{get_column_letter(end_col)}{end_row} wb.save(file_path) return 格式化完成。之所以把格式化也做成工具,是因为我发现很多 Excel 工作流的最后 10% 都耗在这里。AI 算出结果了,但表头配色、列宽、筛选按钮都得手动调,每次都调,每次都想骂人。让 MCP 承担这部分,才能算真正意义上的“全链路重构”。5. 实测:让 AI 独立完成一份销售汇总表5.1 我设的测试场景为了验证这套服务能不能撑起真实场景,我用一份模拟的三个月销售明细表来测,包含字段:订单号、日期、区域、渠道、产品线、销售额、成本。人工操作流程是:筛选出近三个月的有效订单;按区域 渠道汇总销售额和成本;计算毛利润和毛利率;生成新 Sheet,套用格式;加上自动筛选,方便后续人工继续看。放在以前,我要写一小段 pandas 脚本,跑完再编辑格式。这次我只在客户端里给 AI 下达了一段自然语言指令。5.2 完整的对话链路与工具调用序列我给 AI 的原始指令大致是:“请打开 storage/销售明细_2024.csv,查看结构后按区域和渠道两列汇总销售额、成本,并计算毛利润与毛利率。汇总结果写入原 Excel 文件的新工作表‘汇总报表’里,表头加粗并填充浅蓝色背景,列宽调整到 18,最后加上自动筛选。”AI 自动执行的工具序列大致如下:调用read_excel查看文件结构和前 20 行,确认字段名;调用read_excel读取全部数据;内部用 pandasgroupby([区域, 渠道]),聚合销售额与成本;计算毛利润 销售额 - 成本,毛利率 毛利润 / 销售额;调用write_dataframe把结果写入新工作表;调用format_range设置表头格式与列宽;调用format_range添加自动筛选。整个执行过程大约 1 分钟,输出结果我检查了一下:汇总粒度正确,毛利率保留两位有效数字,格式也完全符合要求。唯一需要人工调整的是它把“合计”行放在了下方,而我希望放在上方——这是我指令里没有表达清楚的地方,调整后再次让它重排,就完成了。5.3 实测中最让我惊喜的部分最让我惊喜的不是“它能算对”,而是它会在执行前先读一下数据再决定聚合方式。比如我故意把销售额字段里的两行写成了字符串“N/A”,AI 读到时自动做了缺失值处理,并且在返回结果里主动提示“有 2 行销售额缺失,已按 0 处理”。这是传统脚本完全做不到的——脚本是按我的预设逻辑跑,遇到异常就报错;AI 是根据实际情况动态处理,然后告诉你它做了什么。这也是我强调“工作流重构”的原因:过去人必须要预判所有异常;现在 AI 可以在执行中识别异常并自主决策,把人的工作从“写逻辑”变成“下达目标 确认结果”。6. 调试与避坑:最耗时间的那几个问题6.1 预处理:让客户端正确连上服务服务写好后,需要在 MCP 客户端里注册。比如 Claude Desktop 的配置文件里,要新增一段mcpServers配置:{ mcpServers: { excel-mcp: { command: python, args: [server.py], env: { PYTHONPATH: ${workspace}/excel-mcp } } } }这里有个容易踩的坑:不同客户端的配置格式不同。Claude Desktop 使用 JSON,有些 IDE 插件使用 YAML。要把command和args写对,尤其 Windows 下 python 可能不是系统 PATH 里的命令。我一开始就是没配好 PATH,客户端一直报spawn python ENOENT,后来改成绝对路径才解决。6.2 路径与文件的坑这是 Excel MCP 最典型的问题之一:Windows 路径反斜杠:AI 返回的文件路径里容易出现\被当转义符的情况,建议在服务端把所有路径参数统一用Path()处理,并且在输出给模型的示例里直接给正斜杠路径;文件占用:如果文件正在 Excel 中打开,openpyxl 保存时会因权限问题失败。我后来在服务端加了一个 try-except,返回“文件被占用”的明确报错;BOM 编码:读取 CSV 时如果不指定encodingutf-8-sig,会出现\ufeff 字符混在表头里的问题。第一次我没注意,AI 读出来的列名变成了\ufeff订单号,后面所有聚合都出错。6.3 公式读取和合并单元格这里单独拎出来说,因为遇到的人太多。用 openpyxl 读取一个单元格时,如果这个单元格存的是公式,你会拿到公式字符串,而不是计算结果。要拿到计算结果,需要用data_onlyTrue重新加载一次,而且前提是文件曾经被 Excel 打开保存过,才会缓存公式结果。wb_value openpyxl.load_workbook(file_path, data_onlyTrue) ws_value wb_value[sheet_name]如果文件是 pandas 生成的,公式没有缓存值,所有公式单元格读出来都是 None。这也是我上面强调“尽量在服务端算好再写数值”的另一个原因。合并单元格也是个大坑。pandas 读取合并单元格时,除了左上角那个格有值,其余全是 NaN。如果你的源数据带合并表头,直接让 AI 跑聚合,结果一定错。我现在会在读取前先输出一份“表格结构说明”,帮助 AI 避开这些坑。6.4 排查链路:当 AI 说“我写入了”但文件没变化这个问题在调试阶段很常见。AI 告诉你写入成功,但你打开 Excel 一看,文件纹丝不动。我的排查顺序是:先确认服务日志:fastmcp 在启动时如果开了 debug 日志,能看到每一步工具的入参与返回,确认 AI 是否真的调用了write_dataframe;确认文件路径:AI 有可能写到了工作目录下的另一个文件,或者因为路径错误而静默失败;确认保存动作:openpyxl 必须调用wb.save(),而且保存的是内存中的 Workbook 对象。如果你先load_workbook后来又用 pandas 重新创建了文件,前面的修改就会丢;确认文件是否被占用:Windows 下 Excel 打开着文件时,保存会报 PermissionError,AI 会把这个报错吞掉,只告诉你“写入完成”。把这条链路走完,基本能定位 80% 的写入问题。我后来养成的习惯是:每个写工具都在结尾返回保存的绝对路径和 Sheet 名,让 AI 可以双重复核。6.5 工具描述写得不好,AI 就会乱调这个坑最隐蔽。fastmcp 会根据函数的 docstring 自动生成工具说明,如果你的 docstring 含糊不清,AI 就分不清read_excel和list_sheets的区别。比如我在初版里把参数写成了sheet_name: str 第一个Sheet,AI 在某些情况下会真的去搜索一个叫“第一个Sheet”的工作表,然后报错。正确做法是每个工具描述都写清“适用场景 参数含义 返回格式”。比如:读取 Excel 文件的指定工作表,返回 Markdown 格式的数据预览。 当需要查看数据内容、结构、字段名时调用此工具; 如果需要查看所有工作表名称,请调用 list_sheets。别小看这段描述,它直接决定了 AI 会不会用错工具。工具写的再多,描述不清晰,等于没有。7. 从 Excel 出发:下一步能重构的更多方向7.1 MCP 和 Coze、n8n、Camunda 不是一回事最近看到很多人把 MCP 和各种工作流引擎搞混。Coze、n8n、Camunda 是流程编排引擎,它们解决的是“任务如何串起来”;MCP 解决的是“AI 如何调用具体工具”。两者其实是互补的。我的理解是:n8n 负责定义流程(比如订单入库后触发报表生成),MCP 负责给流程里的每一步提供工具能力(比如报表生成这一步让 AI 调用 Excel MCP 操作文件)。在 Excel 这个场景里,你完全可以用 n8n 定时触发 AI Agent,Agent 再通过 Excel MCP 完成汇总和发送。这个组合不复杂,但很能说明问题。7.2 更多值得接的 MCP 方向做完 Excel MCP 之后,我的工具箱里又陆续接入了几个方向:Playwright MCP:让 AI 驱动浏览器,做网页数据抓取、表单填写、自动化验证;本地文件系统 MCP:让 AI 直接管理项目文件、批量重命名、整理目录;PDF 表格提取 MCP:从 PDF 里抽取结构化表格,再配合 Excel MCP 写回工作簿,这个对财务对账非常有用;数据库 MCP:让 AI 直接查询业务数据库,再把结果落到 Excel 报表里。你会发现这些方向有一个共同点:只要你想让 AI“操作”而非“讨论”某个东西,它就值得做成 MCP。而 Excel 正是这个思维模式的最佳起点——因为它的工具边界最清晰,最容易做小闭环。7.3 云端 MCP 与本地 MCP 怎么选做第一个项目时,我直接用了本地服务。本地的好处是文件都在自己机器上,数据不外传,安全边界好控制。后来也试过把服务暴露到公网,用 SSE 地址让远程客户端连接(比如社区里常见的 apixiaozhi.me 这类云端 MCP 服务,也可以直接作为一个远程端点来体验)。但说实话,日常个人使用,本地跑就足够了。如果后面做团队协作,我建议把 MCP 服务部署到一台内网机器上,通过 SSE 或 HTTP 暴露给内网客户端,这样所有数据都留在公司网络里,又能让 AI 统一访问公共数据文件。这比每个人在自己电脑上配一份环境要省心得多。最后说点个人体会。开发第一个 MCP 的完整过程让我很强烈地意识到一件事:AI 能不能真正改善工作流,不取决于模型有多强,而取决于你给它的“工具边界”定义得有多清楚。一个工具描述混乱、边界模糊的 MCP,即使模型再聪明,也会给你乱来;一个工具粒度合理、描述清晰的服务,哪怕是一个普通的小模型,也能把活干得漂漂亮亮。所以如果你正准备动手,我建议别追求功能多,先把“读、写、格式化”这三个基础能力打磨顺,再在真实需求里慢慢加。等这个闭环跑通了,你会看到 AI 的角色从“聊天助手”变成了“帮你操作电脑的实习生”——它虽然偶尔笨,但胜在随叫随到、执行速度快,更重要的是,它愿意被你反复指挥却毫无怨言。