企业官网建设流程全解析

周五下午五点半，三个分店的报表从微信群里冒出来，第二天一早要汇总成一张总表。以前我的第一反应是打开编辑器，写一段 Python 脚本去跑合并，跑完再盯着输出看两遍。脚本确实快，但需求永远不会按脚本的思路走：这个月多出两列，下个月要按区域拆分，再下次还要顺手标红异常数据。于是脚本改来改去，最后干脆退回手动复制粘贴。

直到我把 MCP（Model Context Protocol）接到自己的工作流里，情况才真正发生变化。MCP 是一套让 AI 模型与外部工具、数据源连接的开放协议，简单说就是给 AI 装上一双手，让它能直接调用你定义好的“工具”，而不只是停在对话框里给建议、贴代码。这篇文章就记录我开发自己的第一个 MCP Server 的完整过程——一个专门处理 Excel 的 AI 工具服务，支持读取、查找、写入、合并表格，让 AI 根据自然语言指令直接操作 xlsx 文件。文章适合所有日常和数据表打交道、又不想每次手工改脚本的人，尤其是想从“AI 聊得好”升级到“AI 干得完”的开发者。

1. 别再让 AI 只“提建议”了：Excel 工作流卡在哪

1.1 三类最常见的 Excel 重复劳动

我盘点了一下日常工作里反复出现的 Excel 场景，其实逃不出三类。

第一类是合并汇总：多个分店、多个部门发来结构类似的表格，需要拼到一张总表里，再加合计行、统一表头。第二类是条件抽数：从几千行明细里按关键词或数字条件筛出一部分数据，另存为清单，比如“把所有华东区的订单挑出来”。第三类是格式统一：行高列宽、字体字号、填充色、边框、数字格式，每次都要重新调一遍，纯粹是体力活。

这三类工作有一个共同特点：操作规则明确、流程重复、但每次输入文件都不一样。规则明确意味着可以被代码自动化；输入不固定又意味着每次单独写死脚本不划算。正是这种矛盾让 Excel 自动化成为典型的高频低效场景，也让它天然适合“AI 理解需求 + 工具执行操作”的组合。

1.2 写临时脚本方案的成与败

面对这些任务，我早期方案是临时写 Python 脚本，用的就是 openpyxl 和 pandas。单看一次任务，效率确实高：一个read_excel、一个concat、一个to_excel，十分钟搞定。但几个问题逐渐暴露出来。

第一，脚本是“一次性思维”写出来的。很多变量写死在文件路径里，换一个月的数据就要改代码。第二，AI 生成的脚本要经过“复制—粘贴—改路径—运行—排错”的环节，遇到环境依赖问题，折腾时间比手工处理还长。第三，团队里不是每个人都愿意碰终端。别人拿到我分享的 .py 文件，往往是先问一句：“这个怎么跑？为什么我这报错？”门槛一下子抬高了。

我意识到，真正要解决的从来不是“能不能写一段代码完成这次合并”，而是“如何让完成这个动作从需要人读代码、改代码、跑代码，变成直接下达一句自然语言指令”。这正好是 MCP 的数据。

1.3 MCP 让 AI 从“参谋”变“执行者”

普通 AI 聊天的工作方式是：你描述需求，它生成代码或给出操作建议，你再拿着建议去别的地方执行。模型见多识广，但离数据文件隔着一层。MCP 改变了这层关系：AI 通过协议直接调用你部署在本机或服务器上的工具，工具函数里写的就是读写 Excel 的真实逻辑。

效果是什么？我只需要告诉 AI“把 work 目录下三个分店表汇总成一个总表”，它就会自己决定先调用哪个工具、传什么参数、什么时候把结果写进新文件。AI 从“写方案的人”变成了“动手干活的人”，而这个干活能力由你定义的 Server 提供。

对 Excel 这个场景来说，MCP 尤其合适：表格操作的结构非常固定，读、写、查、合并，每个都能拆成独立的、参数明确的工具函数，正好是 MCP 工具化设计的强项。下一部分我详细拆解协议本身的机制，搞清楚原理，写起来才不会靠猜。

2. MCP 的三层结构与 Excel 场景的契合点

2.1 Host、Client、Server 别搞混

MCP 的架构把参与方分成三层：Host、Client、Server。

Host 是模型所在的应用程序，也就是用户交互的地方，通常是 Claude Desktop、Cursor、或者我自己用 Python 写的小客户端。Server 是工具服务的提供方，持有真实的操作逻辑，比如“读 Excel”“写 Excel”这些函数都运行在 Server 里。Client 则负责两者之间的通信，包括请求转发、响应封装、协议握手。

我用一个比喻帮助记忆：Host 是操作员，Server 是工具箱，Client 是连接操作员和工具箱的传送带。操作员不需要知道工具箱内部拧螺丝的具体方式，只要通过传送带发出“我要一把十字螺丝刀”的请求，拿到工具就能干活。这个分工让工具与智能体解耦：换一个更聪明的模型，不用改工具；换一套工具，也不用改模型调度逻辑。

2.2 三个协议原语怎么分工

MCP 协议定义了三个核心原语，我的理解是它们对应 AI 与外部世界交互的三种方式。

Resources 用于向 AI 提供可读取的内容，比如文件内容、数据库查询结果。它像是递给 AI 的资料，AI 可以“阅读”但一般不能修改。Tools 是可被 AI 调用的函数，每个函数有名字、描述、参数契约，AI 按要求传参，服务端执行后返回结果。用我上面的比喻，Tools 是可以按按钮的设备，按下去就会产生真实效果。Prompts 则是一套可复用的交互流程模板，相当于把常用的工作步骤固化成指令序列，“合并分店表并输出汇总.xlsx”这种固定流程，用 Prompts 保存下来，下次一句话即可触发。

对 Excel 工作流来说，Tools 用得最多，因为读表、写表、合并表本质都是带参数的操作。Resources 适合让 AI 直接读取表格内容做分析判断，比如判断两张表的表头是否一致。Prompts 适合把“三步合并流程”“格式统一流程”这类经常重复的套路固化下来，减少描述成本。

2.3 为什么工具描述比实现更重要

这是我从实践中总结出的最重要经验之一：模型看不到你的函数体代码，它判断“什么时候该用这个工具”“参数该填什么”的唯一依据是工具名和工具描述。描述写不好，再牛的实现也发挥不出来。

举个反差例子。如果你把工具描述成“处理 Excel”，模型完全不知道这个工具是读还是写，更不知道什么时候该调用。但如果你写清楚“读取 Excel 指定工作表，返回所有行数据，适合用户要求看看表格内容、了解表结构时调用”，模型在用户说出“这个表里都有什么”时就会自动匹配这个工具。

所以我在给后续每个工具写描述时，都会遵循一个模板：这个工具干什么，参数是什么意思，什么时候适合调用，返回值长什么样。这一段功夫花下去，联调阶段的错误率能下降一大半。理解了原理，下面就可以真正开工搭环境了。

3. 开工：选型、环境与服务端骨架

3.1 技术栈选择：FastMCP + openpyxl 的理由

MCP 官方提供了 Python 和 TypeScript 两种 SDK，我选 Python 路线主要因为数据相关生态更熟。在此基础上我用了 FastMCP 这个封装库，它的优势是把定义工具的过程简化成了加装饰器这件事，代码直观，也内置了参数校验和 API 文档生成。

Excel 操作层面，我需要的是对 .xlsx 文件的结构化读写，最后还用到了 openpyxl。之所以没有直接上 pandas，是因为 openpyxl 对单元格样式、合并单元格、列宽、数字格式的控制粒度更细，适合做偏“办公风格”的表格处理；pandas 强在数据分析，但读进来出去的格式会丢失，不适合保留原表观感的场景。

我整理了一个选型对比表：

我这边的目标很明确：做一个稳定、跨平台、能读写常见格式的 Excel 工具服务，所以 FastMCP + openpyxl 是最平衡的选择。如果你以后要处理大批量数据分析任务，再在 Server 里加一个 pandas 工具也不冲突。

3.2 环境准备：几分钟装好依赖

我的开发环境是 Windows，Python 3.11。建议在虚拟环境里安装依赖，避免污染全局环境。

mkdir excel-mcp cd excel-mcp python -m venv venv venv\Scripts\activate pip install fastmcp openpyxl

安装完成后，可以用一行命令验证核心依赖就绪：

python -c "import fastmcp, openpyxl; print('ok')"

这个步骤很快，但值得单独强调：如果你之后在客户端里配置 Server 时反复出现“连接失败”，先回到这一步确认虚拟环境里的 Python 解释器路径与客户端配置里写的 command 是否一致。这个坑我在联调阶段踩过一次，后面细说。

3.3 一个能跑通的最小 MCP Server

先写一个最小的 Server 文件server.py，目的是确认端到端通道是通的，再往里面加 Excel 工具。

from fastmcp import FastMCP mcp = FastMCP("Excel Assistant") @mcp.tool() def ping() -> str: """连通性测试：返回 pong。""" return "pong" if __name__ == "__main__": mcp.run()

默认情况下，mcp.run()走 stdio 传输方式，也就是客户端通过标准输入输出与 Server 通信。对于本机开发场景，stdio 是最省事的选择，不涉及端口和防火墙问题。启动命令就是：

python server.py

如果你用fastmcp dev server.py，FastMCP 会启动一个内置的 MCP Inspector 调试面板，浏览器打开后可以看到工具列表和调用测试入口，这个我在联调章节会细讲。确认最小 Server 能跑起来，核心链路就通了，接下来就是往里面填充真正的 Excel 工具集。

4. 把 Excel 能力做成工具集：核心实现

4.1 工具契约设计：让 AI 能读懂输入输出

在设计工具集之前，我定了几条小原则：每个工具只做一件具体的事，粒度宁细勿粗；参数尽量扁平，不要嵌套复杂对象；返回值用可 JSON 序列化的基础类型；所有文件路径统一要求绝对路径，并在函数内部用Path.resolve()处理。

这几点都是来自实际联调的教训。工具粒度太粗，比如一个“处理所有 Excel 需求”的函数，AI 根本不知道该传什么参数；参数嵌套太深，模型的输出很容易不符合预期格式，导致服务端解析失败；返回值如果不是 JSON 友好的，比如直接返回一个 openpyxl 的 worksheet 对象，AI 侧也无法理解。

我统一把文件路径设计成字符串参数，并约定“路径必须是绝对路径”。原因是 AI 在对话中经常会猜相对路径，比如用户说“读一下销售表”，模型可能直接就传"销售表.xlsx"，然后服务端在当前目录找不到文件报错。我在描述里强调绝对路径，再配合后面要讲的路径白名单，就能很大程度规避这类问题。

4.2 读取与查找类工具实现

读取工具是整个服务的基础。我写了read_excel、get_sheet_names、find_rows这三个函数。

from pathlib import Path import openpyxl from fastmcp import FastMCP mcp = FastMCP("Excel Assistant") def _resolve_path(file_path: str) -> Path: return Path(file_path).resolve() @mcp.tool() def get_sheet_names(file_path: str) -> list[str]: """列出 xlsx 文件中所有工作表的名称。 参数: file_path: xlsx 文件的绝对路径 适用场景: 用户要求读取某个表、合并多个表前，先确认表结构 """ wb = openpyxl.load_workbook(_resolve_path(file_path), read_only=True) names = wb.sheetnames wb.close() return names @mcp.tool() def read_excel(file_path: str, sheet_name: str = "", limit: int = 100) -> list[list]: """读取 Excel 指定工作表的内容，返回最多 limit 行数据。 参数: file_path: xlsx 文件绝对路径 sheet_name: 工作表名称，留空则读取第一个工作表 limit: 最多返回的行数，默认 100，防止上下文被大表撑爆 返回: 二维数组，每个元素是一行；空单元格为 None 适用场景: 用户要求“看看这张表有什么内容”“提取前几行数据” """ wb = openpyxl.load_workbook(_resolve_path(file_path), data_only=True, read_only=True) ws = wb[sheet_name] if sheet_name else wb.active rows = [] for idx, row in enumerate(ws.iter_rows(values_only=True)): if idx >= limit: break rows.append(list(row)) wb.close() return rows @mcp.tool() def find_rows(file_path: str, keyword: str, sheet_name: str = "") -> list[list]: """在指定工作表中按关键词搜索，返回所有包含该关键词的行。 参数: file_path: xlsx 文件绝对路径 keyword: 要查找的关键词，如“华东” sheet_name: 工作表名称，留空则搜索第一个工作表 适用场景: 用户要求“找出所有包含某某关键词的行”“筛选出某某部门的数据” """ wb = openpyxl.load_workbook(_resolve_path(file_path), data_only=True, read_only=True) ws = wb[sheet_name] if sheet_name else wb.active matched = [] for row in ws.iter_rows(values_only=True): if any(keyword in str(cell) for cell in row if cell is not None): matched.append(list(row)) wb.close() return matched

这里有两个 openpyxl 的关键参数值得说明。read_only=True是只读模式，读取大型表格时内存占用大幅下降；data_only=True表示取单元格的缓存计算结果而不是公式字符串，比如单元格里是=SUM(A1:A10)，读取时你会拿到数值。但要注意，如果文件从未被 Excel 或 WPS 打开过，公式可能没有缓存值，这个坑我留给第 6 章细讲。

limit参数是我整改后加上的。第一次联调时，AI 读取一个 8 万行的明细表，返回值直接把上下文窗口塞满了，后续所有对话质量急剧下降。给读取工具加上限值，再配合“需要更多请通过起始行参数继续取”的设计，才是可控的做法。

4.3 写入与汇总类工具实现

读是基础，写才是让 AI 真正“干活”的开始。我实现了write_cell、append_rows、merge_excel_files三个工具。

@mcp.tool() def write_cell(file_path: str, value: object, row: int = 1, column: int = 1, sheet_name: str = "") -> dict: """向指定单元格写入一个值。 参数: file_path: xlsx 文件绝对路径 value: 要写入的值，可以是数字、文本 row: 行号，从 1 开始 column: 列号，从 1 开始 sheet_name: 工作表名，留空则写入第一个工作表 适用场景: 用户要求“把某个值写到指定位置”“修改某个单元格” """ wb = openpyxl.load_workbook(_resolve_path(file_path)) ws = wb[sheet_name] if sheet_name else wb.active ws.cell(row=row, column=column, value=value) wb.save(_resolve_path(file_path)) return {"ok": True, "cell": f"{row},{column}"} @mcp.tool() def append_rows(file_path: str, rows: list[list]) -> int: """向工作表末尾追加多行数据。 参数: file_path: xlsx 文件绝对路径 rows: 二维数组，每个子数组代表一行单元格数据 返回: 实际追加的行数 适用场景: 用户要求“把这几行加到表尾”“往总表里追加数据” """ wb = openpyxl.load_workbook(_resolve_path(file_path)) ws = wb.active for row in rows: ws.append(list(row)) wb.save(_resolve_path(file_path)) return len(rows) @mcp.tool() def merge_excel_files(file_paths: list[str], output_path: str) -> dict: """将多个 xlsx 文件中的全部工作表数据纵向合并写入一个新的 xlsx 汇总文件。 参数: file_paths: 要合并的 xlsx 文件绝对路径列表 output_path: 输出文件绝对路径，注意不能与输入文件相同 返回: 输出路径和汇总行数 适用场景: 用户要求“把几个表合并成一个总表”“汇总分店数据” """ out_wb = openpyxl.Workbook() out_ws = out_wb.active out_ws.title = "汇总" for path in file_paths: wb = openpyxl.load_workbook(_resolve_path(path), data_only=True, read_only=True) for ws in wb.worksheets: for row in ws.iter_rows(values_only=True): if any(cell is not None for cell in row): out_ws.append(list(row)) wb.close() out_wb.save(_resolve_path(output_path)) return {"output": str(_resolve_path(output_path)), "rows": out_ws.max_row}

写操作的核心注意点是：load_workbook之后如果修改了内存里的对象，一定要save()才会落盘。常见的坑是 AI 调用写入工具时报了成功，但文件没有变化，多半就是 save 路径写错了或者文件被占用。另外，append_rows对每个工具调用都重新打开、保存一次文件，在并发场景下效率不高，但胜在简单可靠，作为第一版够用。

merge_excel_files处理的是纵向合并，也就是把分表数据依次追加到总表。实际使用中我还需要跳过全空行，所以加了any(cell is not None ...)的判断。如果你手头有列结构不一致的分表，合并前先让 AI 调用read_excel对比两边的表头，再决定是否需要适配，这个检查步骤非常必要。

4.4 给 AI 加缰绳：路径白名单

最后一个实现细节是安全边界。没有路径约束时，AI 可能会在对话中猜测路径、误写已有文件，甚至把输出写到奇怪的位置。我的做法是在 Server 里加一个统一的路径校验函数，所有工具先过一遍白名单再执行。

WORK_DIR = Path.home() / "excel_work" def _safe_path(file_path: str) -> Path: p = Path(file_path).resolve() if not str(p).startswith(str(WORK_DIR.resolve())): raise PermissionError(f"路径 {p} 不在允许的工作目录 {WORK_DIR} 内") if not p.parent.exists(): p.parent.mkdir(parents=True) return p

然后把所有工具里的_resolve_path替换成_safe_path。这样 AI 只能操作~/excel_work目录下的文件，路径混乱和误覆盖的风险都大大降低。

提示：不要在 Server 里开放“执行任意 Python 代码”这类工具。就算模型再聪明、你再信任它，白名单小工具已经足够覆盖绝大多数 Excel 流程，可控性和安全性才是长期维护的保障。

5. 联调实测：AI 第一次脱离键盘碰我的表格

5.1 先用 MCP Inspector 做冒烟测试

写完 Server 后别急着接客户端，先用 FastMCP 自带的调试工具验证每个函数是否工作正常。我用fastmcp dev server.py启动，浏览器会打开一个本地调试页面，里面列出所有已注册工具，可以手动传参、查看 JSON 格式的返回值。

这一步的价值在于：先把工具本身的行为摸透，再让 AI 来调用。比如我发现read_excel返回的单元格空值是None，在 Inspector 里看得很清楚，后续设计提示词时就知道提醒 AI“结果里的 None 代表空单元格”。如果没有这层验证，直接接客户端，AI 报错你都不知道是模型理解错了，还是工具本身有 bug。

冒烟测试我建议至少覆盖三类用例：传正常参数看返回是否符合预期；故意传不存在的文件，确认错误信息是可读的；传中文路径和中文 sheet 名，确认编码没有问题。

5.2 完整任务实测：“把三个分店表汇总成总表”

冒烟测试通过后，我用支持 MCP 的客户端把 Server 配上，开始真实对话测试。这里的配置方式因客户端而异，但底层都是一组 JSON 服务描述：客户端通过command拉起 Python 进程，args指向server.py。

我输入的需求是：“把桌面 excel_work 目录下三个分店表汇总成一个总表，放到 output 里。”AI 的动作链大致如下：

• 调用get_sheet_names查看每个文件的 sheet 结构，确认三个表结构一致。
• 依次调用read_excel读取三个文件的内容。
• 调用merge_excel_files把读取的数据纵向合并，输出到指定目录下的汇总.xlsx。
• 最后用文字报告：三个表分别有多少行、合并后总行数、哪个表存在空值行已跳过。

整个过程大约一分钟。最让我惊喜的不是它“会”调用工具，而是它会自己先检查表结构再决定下一步。这相当于把一条多人协作的流程压缩进了单轮对话：理解需求、确认结构、执行操作、反馈结果。对比之前“复制代码—改路径—运行—看报错”的流程，效率提升非常明显。

5.3 减少误操作的两轮调优

第一次实测也不是完全顺利，我遇到了两个典型问题，后来通过调整工具设计解决了。

第一轮问题是 AI 猜文件名。用户只说了“三个分店表”，AI 在没有list_work_files工具的情况下，直接猜测文件名是store1.xlsx、store2.xlsx、store3.xlsx，结果服务端一路报“文件不存在”。解决方式是在 Server 里加了一个工具：列出工作目录下所有 xlsx 文件，并在读取类工具的描述里强调“如果用户没有给出具体文件名，先调用列出文件的工具确认”。AI 学会“先侦察、再行动”之后，这类错误就消失了。

第二轮问题是读取量超限。AI 调用read_excel读取大表时，一次返回了全部 8 万行，导致上下文过载。解决方式是给read_excel加limit参数，默认 100 行，同时新增一个get_row_count工具返回总行数，让 AI 在需要全量处理时心里有数。现在 AI 面对大表，会先看行数，再分批读取，行为合理多了。

这两轮调试让我明白一个道理：很多 MCP 项目的体验差，不是模型不够聪明，而是工具设计没给模型提供足够好的“决策依据”。工具不是越强越好，而是越清晰越好。

6. 踩坑记录与这个工作流的适用边界

6.1 我踩过的五个坑和对应解法

做这个项目的时间不长，但踩过的坑已经足够填一张表。

其中data_only那个坑最隐蔽。我第一次测试时，明明 Excel 单元格里显示=SUM(...)的结果是数字，但 Python 读回来却是公式字符串。查了文档才知道 openpyxl 不执行公式计算，它只读单元格存的两个东西：公式字符串和最后一次计算缓存。用 Excel 打开过、保存过的文件才有缓存；单纯由脚本生成的 xlsx，data_only=True也读不到值。遇到这种情况，你要么用 Excel 打开原文件另存一次，要么换 LibreOffice 环境做一次公式计算。

6.2 哪些 Excel 任务适合 MCP，哪些不适合

这个边界我越用越清晰。适合交给 MCP 的是那些规则明确、重复性高、操作粒度清晰的任务，包括多表合并汇总、按条件筛选导出、格式批量统一、模板报表生成、跨表格数据比对。这类任务的结构是“需求一句话能说清，操作拆开是固定几步”，正好匹配 MCP 的工具化模型。

不适合的有这么几类。第一类是极度依赖视觉判断的复杂排版美化，比如让 AI 把一张乱表排成发布会级别的 PPT 风格，工具能做的只是一个单元格级操作，拼出来的效果远不如人工手动调。第二类是需要事务保证的数据处理，比如同一批数据要同时写入多个关联表，一旦中间某一步失败需要回滚，MCP 目前的工具隔离粒度撑不起这种强一致场景，更建议直接用代码逻辑包一个事务。第三类是超大数据集分析，上百 MB 的明细表不适合走 JSON 序列化来回传，这种情况让 AI 生成 pandas 代码去跑，比把全表内容塞进对话更合理。

另一个兼容性优势值得提：以前我用 Office 加载项给别人做工具，经常收到“Excel 加载项被禁用”的反馈，折腾配置半天。MCP 服务不依赖 Office 宿主环境，只要对方客户端能拉起 Python 进程就能用，跨机器复用省心很多。

6.3 下一步扩展思路

第一版跑通后，我打算在三个方向上继续扩展。

一是把读取范围从本地文件扩展到更多数据源，比如接入数据库查询结果生成 Excel 报表，或者读取 CSV 后统一转成带格式的 xlsx。二是配置定时触发：用一个简单的脚本在每天固定时间调用 Server 里现成的合并工具，把自动化和 AI 结合起来，相当于给工作流加了一个定时器。三是团队复用：把 Server 部署到内网机器上，成员从各自的 AI 客户端连接同一个 Excel 服务。现在不少工作流平台（像 Dify、Coze）也都支持 MCP 节点，意味着我可以用同样的 Server 接入不同的平台，不用为每个平台单独写一套 Excel 集成。

做这个项目最深的体会是：MCP 真正值得投入的地方，不是那些听着很酷的演示，而是把手头最重复、最没技术含量、但又必须有人做的 Excel 流程一个个固化下来。工具一次开发，后续每次使用都是一句话的事。那些周五深夜的报表汇总，以后真的可以放心交给 AI 去动了。