★ FEATURED ARTICLE 1. 为什么我要自己写一个 MCP而不是继续堆 Excel 脚本我做了七八年数据处理Excel 一直是我手里最顺手的工具。但这两年有个很明显的感受Excel 本身没变变的是我们处理它的方式。以前写个 Python 脚本读 xlsx、做透视、再写回去跑通一次能用半年现在业务方一天一个口径字段说改就改脚本改到最后自己都不想看。真正让我下决心动手写 MCP 的是一个特别具体的场景。财务那边每周要处理一批对账表格式固定但列名偶尔变中间还要按关键词做条件求和、按部门拆分、最后生成一份汇总。我一开始用 pandas 写了个脚本后来发现每次改需求都要动代码改完还得重新测。再后来我试着把读表、清洗、统计、导出这几步拆成独立的工具函数让 AI 来调用——这时候问题就来了AI 怎么知道我有这些工具怎么知道每个工具要传什么参数这就是 MCP 要解决的事。MCP 全称 Model Context Protocol你可以把它理解成一套AI 和外部工具之间的通用插座标准。以前每个 AI 应用要接你的工具都得单独写适配有了 MCP你只要把工具按协议暴露出来任何支持 MCP 的客户端都能直接调用。我这次做的就是把 Excel 处理能力封装成一个 MCP Server让 AI 能直接指挥它干活。这篇文章适合两类人看一类是像我这样天天跟 Excel 打交道、想用 AI 提效但不想被平台绑死的从业者另一类是想入门 MCP 开发、但被各种概念绕晕的开发者。我会把整个开发过程拆开讲包括我踩过的坑、参数怎么设计、为什么这么设计以及跑通之后怎么继续扩展。核心不是教你复制一份代码而是让你理解这套东西背后的取舍逻辑。2. 先把 MCP 这件事想清楚它到底解决什么问题2.1 MCP 不是又一个 AI 框架它是接口层很多人第一次听到 MCP会下意识把它跟 LangChain、Coze 工作流这类东西放一起比较。其实它们不在一个层面。工作流框架解决的是多个步骤怎么编排MCP 解决的是AI 怎么发现并调用一个具体能力。打个比方工作流像是餐厅的菜单和上菜流程MCP 像是厨房和前台之间的传菜窗口。窗口本身不做菜但它规定了菜怎么递出去、单子怎么传进来。你完全可以在一个工作流里调用多个 MCP Server也可以让一个 MCP Server 被多个工作流复用。我选择 MCP 而不是直接写个 HTTP 接口给 AI 用主要看中三点标准化工具的描述、参数、返回值都有统一格式AI 客户端能自动理解不用我每次写一堆 prompt 解释。可组合Excel 处理的每个动作做成独立工具AI 可以按需串联而不是我提前把所有流程写死。解耦业务逻辑在 Server 里AI 只负责决策调用哪个工具改需求时大部分情况不用动 AI 那侧。2.2 一个 MCP Server 的最小构成从开发角度看一个 MCP Server 核心就三样东西组成作用我的 Excel 场景对应工具定义告诉 AI 有哪些能力、参数是什么读表、筛选、条件求和、导出调用处理收到请求后真正执行逻辑pandas 读写、分组聚合返回结果把执行结果按协议回传结构化数据或文件路径协议本身支持多种传输方式本地开发最常用的是标准输入输出stdio部署成服务时可以用 SSE 或 WebSocket。我这次先用 stdio 跑通因为调试最直观日志直接打在终端里。提示不要一上来就纠结传输方式。先把工具逻辑跑通传输层是最后一步的事换起来成本很低。2.3 为什么选 Python 而不是别的语言Excel 处理这块Python 的生态几乎没有对手。pandas 负责表格运算openpyxl 负责读写格式两个库配合能覆盖我 95% 的需求。如果用别的语言光是把 xlsx 里的合并单元格、公式、格式读对就得折腾半天。而且 MCP 的官方 SDK 对 Python 支持很完整装个包就能开始写不用自己实现协议解析。我实测下来从零到跑通第一个工具大概两个小时其中一半时间花在环境配置上。3. 环境搭建那些教程不会告诉你的细节3.1 Python 环境别用系统自带的我见过太多人卡在第一步。系统自带的 Python 往往版本旧、权限乱装包动不动就报权限错误。我的做法是直接用虚拟环境隔离python -m venv mcp-excel-env source mcp-excel-env/bin/activate # Windows 用 mcp-excel-env\Scripts\activate建完环境先升级 pip这一步能省掉后面很多莫名其妙的安装失败python -m pip install --upgrade pip然后装核心依赖pip install mcp pandas openpyxl这里有个细节pandas 和 openpyxl 的版本要匹配。我有一次 pandas 装的是最新版openpyxl 还是两年前的旧版结果写 xlsx 的时候格式全丢了。后来固定了版本组合再没出过问题。如果你也遇到写出来的文件打不开或者格式丢失先查这两个库的版本。3.2 编辑器配置让调试不那么痛苦我用的是 VS Code关键配置就两项一是把解释器指向刚才建的虚拟环境二是打开保存时自动格式化。MCP Server 的代码结构比较固定格式化能帮你保持整洁。如果你之前遇到过Excel 加载项被禁用之类的提示那跟 MCP 开发没关系那是 Office 层面的插件管理问题。我们做的是独立进程不往 Excel 里塞插件所以不受那些限制影响。这也是我选这条路的原因之一——不依赖 Office 的插件机制部署和迁移都简单。3.3 目录结构一开始就分清楚我建议一开始就把结构定好不然后面工具一多就乱mcp-excel/ ├── server.py # MCP 入口注册工具 ├── tools/ │ ├── reader.py # 读表相关 │ ├── transform.py # 清洗、筛选 │ └── export.py # 导出相关 ├── data/ # 测试数据 └── requirements.txt这么分的好处是每个工具文件只关心自己的逻辑server.py 只负责注册。等工具涨到十几个的时候你会感谢自己当初分了目录。4. 核心工具设计把 Excel 操作拆成 AI 能理解的原子动作4.1 工具拆分的粒度怎么把握这是整个开发里最需要想清楚的问题。拆得太粗比如只做一个处理 Excel的工具那 AI 根本不知道该传什么参数等于没拆拆得太细比如读第一列读第二列各做一个工具AI 调用起来会疯掉。我的原则是一个工具对应一个业务上说得清的动作。最后我定了四个核心工具read_excel读取表格返回列名、行数、前几行预览filter_rows按条件筛选行sum_by_keyword按关键词做条件求和export_excel把处理结果写成新文件这四个覆盖了我 90% 的日常需求。注意read_excel返回的是预览而不是全量数据这是故意的——AI 的上下文有限全量数据塞进去既浪费又容易出错让它先看结构再决定下一步。4.2 参数设计让 AI 不用猜参数设计直接决定 AI 能不能用对工具。我踩过的坑是一开始参数名起得太随意比如col、val结果 AI 经常传错。后来改成明确的名字并在描述里写清楚server.tool() def sum_by_keyword(file_path: str, keyword: str, target_column: str) - dict: 在指定列中查找包含关键词的行并对目标列求和。 Args: file_path: Excel 文件的完整路径 keyword: 要匹配的关键词支持部分匹配 target_column: 需要求和的数值列名 关键在于 docstring。MCP 会把这段描述传给 AIAI 靠它判断什么时候调用、参数怎么填。所以描述要写人话把使用场景说清楚而不是写技术细节。提示参数类型尽量用基础类型str、int、bool复杂结构用 JSON 字符串传。我试过直接传 dict某些客户端解析会出问题。4.3 返回值格式结构化比好看重要工具返回给 AI 的内容我统一用 dict里面包含success、data、message三个字段。这样 AI 能明确知道成功还是失败失败时也能拿到原因去调整。return { success: True, data: {total: 12345.67, matched_rows: 28}, message: 在备注列匹配到 28 行金额列合计 12345.67 }message字段是给 AI 看的自然语言总结data是给后续步骤用的结构化数据。两者都要有缺一个都会让 AI 变笨。4.4 错误处理别让异常直接抛出去Excel 处理最容易出的错就那几类文件不存在、列名写错、数据类型不对。如果直接让异常抛出去AI 收到一堆 traceback 会懵。我的做法是全部捕获转成结构化错误try: df pd.read_excel(file_path) except FileNotFoundError: return {success: False, data: None, message: f文件不存在{file_path}} except Exception as e: return {success: False, data: None, message: f读取失败{str(e)}}这样 AI 收到失败信息后能自己判断是路径错了还是列名错了甚至能自动重试。我实测下来加了这层处理后AI 自主纠错的成功率明显提升。5. 从零跑通第一个工具完整过程与实测记录5.1 写一个最小的 Server先不搞复杂逻辑写个能跑起来的最小版本from mcp.server import Server from mcp.server.stdio import stdio_server import pandas as pd server Server(excel-mcp) server.tool() def read_excel(file_path: str, preview_rows: int 5) - dict: 读取 Excel 文件返回列名、总行数和前若干行预览。 try: df pd.read_excel(file_path) return { success: True, data: { columns: df.columns.tolist(), total_rows: len(df), preview: df.head(preview_rows).to_dict(orientrecords) }, message: f读取成功共 {len(df)} 行{len(df.columns)} 列 } except Exception as e: return {success: False, data: None, message: str(e)} async def main(): async with stdio_server() as (read, write): await server.run(read, write, server.create_initialization_options()) if __name__ __main__: import asyncio asyncio.run(main())这段代码跑起来后Server 会等待客户端连接。注意stdio_server是异步的main函数必须用asyncio.run启动这点跟普通脚本不一样。5.2 接到 AI 客户端上测试把 Server 配置到支持 MCP 的客户端里配置大概长这样{ mcpServers: { excel-mcp: { command: python, args: [/path/to/server.py] } } }配置完重启客户端如果一切正常AI 就能看到read_excel这个工具了。我第一次测试时直接问 AI帮我看看 data 目录下 sales.xlsx 有哪些列它自动调用了工具并返回了列名。那一刻的感觉还是挺爽的——不用写一行 prompt 解释AI 自己就知道该干什么。5.3 实测中遇到的三个意外第一个意外是路径问题。AI 传过来的路径有时候是相对路径有时候带引号直接丢给 pandas 会失败。我的处理是在工具内部先做一次路径规范化把引号去掉、相对路径转绝对路径。第二个意外是中文列名。pandas 读中文列名没问题但 AI 传参数时偶尔会多带空格。我在匹配列名前统一做了 strip 处理这个小改动解决了一大批列名找不到的报错。第三个意外是大文件。有一次测试一个五万行的表read_excel返回预览没问题但 AI 拿到列名后想直接做全量统计结果上下文爆了。后来我在工具描述里明确写了本工具只返回预览全量统计请用专用工具AI 就不再乱来了。注意工具描述不是写给人类看的文档是写给 AI 的使用说明书。措辞要直接把边界条件写清楚。6. 把条件求和做成一个真正好用的工具6.1 需求拆解一句话背后的多个动作统计备注列里包含退货的行的金额总和——这句话听起来简单拆开其实有三步定位备注列、筛选包含关键词的行、对金额列求和。如果让 AI 自己用 pandas 一步步做它得写代码、执行、再读结果中间任何一步出错都得重来。做成一个工具后AI 只需要传三个参数剩下的都在 Server 里完成。这就是 MCP 的价值把多步操作封装成一个原子能力降低 AI 的决策负担。6.2 实现细节关键词匹配的坑关键词匹配看着简单实际有好几个坑。第一个是大小写英文关键词如果不统一处理会漏掉一半。第二个是空格用户输入的关键词经常带前后空格。第三个是全角半角中文标点混进来会导致匹配失败。我的处理逻辑是这样的server.tool() def sum_by_keyword(file_path: str, keyword: str, target_column: str, source_column: str None) - dict: 按关键词筛选后对目标列求和。source_column 不传则搜索所有文本列。 df pd.read_excel(file_path) keyword keyword.strip() if source_column: mask df[source_column].astype(str).str.contains(keyword, caseFalse, naFalse) else: text_cols df.select_dtypes(include[object]).columns mask df[text_cols].astype(str).apply( lambda col: col.str.contains(keyword, caseFalse, naFalse) ).any(axis1) matched df[mask] total pd.to_numeric(matched[target_column], errorscoerce).sum() return { success: True, data: {total: float(total), matched_rows: len(matched)}, message: f匹配到 {len(matched)} 行{target_column} 合计 {total:.2f} }caseFalse解决大小写naFalse避免空值报错pd.to_numeric加errorscoerce处理非数值内容。这几个参数看着不起眼但少一个就会在真实数据上翻车。6.3 让 AI 自己决定搜哪一列上面代码里source_column是可选的不传就搜所有文本列。这个设计是刻意的大部分时候用户不会明确说搜哪一列让 AI 根据上下文决定或者干脆全搜。全搜的代价是慢一点但胜在不容易漏。我实测下来AI 在明确知道列名时会传source_column不确定时就留空。这种能省则省的参数设计比强制要求所有参数都填要友好得多。6.4 返回值的可读性优化一开始我只返回数字AI 拿到后还得自己组织语言。后来我在message里直接拼好一句话AI 基本可以原样转述给用户。这个改动让最终输出的自然度提升明显也减少了 AI 二次加工出错的可能。7. 工作流串联让 AI 把多个工具组合起来7.1 一个完整的处理链路单个工具跑通后真正的价值在于组合。我设计了一个典型链路读表看结构 → 按条件筛选 → 条件求和 → 导出结果。AI 会根据用户的一句话需求自动决定调用顺序。比如用户说把销售表里华东区的数据筛出来统计退货金额导出成新文件AI 会依次调用read_excel确认列名、filter_rows筛选、sum_by_keyword统计、export_excel导出。整个过程用户只说了一句话。7.2 工具之间的数据怎么传递这里有个设计选择工具之间是传文件路径还是传数据我选了传文件路径。原因是数据在内存里传来传去一旦量大就会拖慢整个链路而且中间状态不好排查。传路径的话每一步的中间结果都落盘出问题能直接打开看。代价是会产生一堆中间文件。我的处理是给中间文件加统一前缀处理完统一清理。这个取舍我觉得值——可调试性比省那点磁盘空间重要得多。7.3 导出工具的格式保留问题export_excel最容易出的问题是格式丢失。pandas 默认写出来的 xlsx 是裸数据没有列宽、没有格式。如果业务方要求保留原格式就得用 openpyxl 手动处理。我的做法是分两档默认导出裸数据够快够简单需要保留格式时传一个preserve_formatTrue参数走 openpyxl 路径。这样大部分场景用默认档特殊需求也有兜底。if preserve_format: from openpyxl import load_workbook wb load_workbook(template_path) ws wb.active # 逐行写入保留原有样式 else: df.to_excel(output_path, indexFalse)7.4 实测一句话完成原本半小时的活跑通之后我拿真实数据测了一次。原本手动操作大概要半小时的筛选加统计加导出AI 调用工具链大概十几秒完成中间我只确认了一次列名。当然前提是数据格式相对规整如果表头有合并单元格、有多层索引还是得先人工整理。这个边界要清楚MCP 加 AI 不是万能的它擅长的是结构清晰、动作明确的重复劳动。数据本身一团乱的时候先花时间把数据理顺比指望 AI 硬扛要靠谱。8. 踩过的坑与排查思路8.1 工具注册了但 AI 看不到这是最常见的问题。排查顺序我总结成三步先看 Server 有没有正常启动日志里有没有报错再看客户端配置的路径对不对尤其是虚拟环境的 python 路径最后看工具函数的装饰器和类型注解有没有写全。我遇到过一次是函数忘了加类型注解AI 那边直接不显示这个工具。8.2 调用成功但结果不对这种问题最隐蔽。有一次条件求和的结果总是偏小查了半天发现是关键词匹配时把空值当成了不匹配而实际数据里有一批行的关键词列是空的但应该算进去。后来调整了na参数的处理逻辑才解决。排查这类问题的通用方法是把工具单独拿出来用真实数据跑一遍不经过 AI直接看输入输出。这样能快速定位是工具逻辑问题还是 AI 传参问题。8.3 中文路径和编码问题Windows 环境下中文路径偶尔会出问题。我的处理是在读写文件前统一做一次编码规范化路径用pathlib处理而不是字符串拼接。这个改动之后中文文件名再没出过乱码。8.4 并发调用时的文件锁如果 AI 同时调用多个工具操作同一个文件可能会撞上文件锁。我的做法是给每个中间文件加时间戳后缀避免重名。简单粗暴但有效。9. 后续可以怎么扩展跑通基础版本后我列了几个扩展方向。第一个是加pivot_table工具把透视表也封装进去这样复杂统计也能一句话搞定。第二个是加merge_sheets处理多表关联的场景。第三个是接入更多数据源比如从数据库直接读而不只是 Excel 文件。还有一个方向是把常用链路固化成复合工具。比如月度对账这个动作每次都调用同样的四个工具那不如直接封装成一个工具AI 调用一次就行。这算是从原子能力往业务能力演进。我个人在实际操作中的体会是MCP 这东西的价值不在于技术多新而在于它把AI 调用工具这件事标准化了。标准化的好处是你今天为 Excel 写的这套工具明天换个 AI 客户端照样能用甚至能跟别人写的工具组合起来用。这种可复用性才是它真正省时间的地方。最后分享一个小技巧开发阶段把每个工具的输入输出都打日志格式用 JSON。等工具多了之后翻日志比翻代码快得多尤其是排查 AI 传参错误的时候。
阅读完成 · 觉得有帮助？
