夜雨聆风学习资料网

ARTICLE · 1150135

给 AI 助手装上 Office:在 NAS 上自建一个文档 MCP 服务

给 AI 助手装上 Office:在 NAS 上自建一个文档 MCP 服务

给 AI 助手装上 Office:在 NAS 上自建一个文档 MCP 服务

AI 助手已经能聊天、能查资料、能跑脚本了,但它对你自己硬盘里的 Word、Excel、PPT 依然是"睁眼瞎"。这篇记录一次真实的动手过程:在一台 NAS 上用 Docker 自建一个文档 MCP 服务,让 AI 直接读写 Office 文件。

一、先说结论

最终形态是一个单容器服务:Python + 无头 LibreOffice + 官方 Office 解析库,对外用 MCP(Model Context Protocol)的 Streamable HTTP 端点,挂了 13 个工具——读文档、查元信息、全文搜索、新建 Word/Excel/PPT、追加、查找替换、改单元格、格式转换。

NAS 上跑这个,优势是天然的:它本来就 24 小时开机、本来就在存文件、本来就在内网。AI 读写的不是上传到别处的副本,而是你放在 NAS 上的原始文件。

二、为什么是"自建",不是"用 NAS 自带的 Office"

很多 NAS 系统都自带办公套件(绿联等机型内置的是 OnlyOffice 引擎),但它没有公开 API,程序读不进去,只能当"人用的编辑器"。所以它不能当 AI 的后端。

一个折中反而很香:让 MCP 服务和自带 Office 共享同一个目录。AI 改完的文件,你直接在网页 Office 里接着编辑,两边看到的是同一份。

至于为什么做成一整个 HTTP 服务,而不是本地插件——因为移动端 App 的「MCP 工具服务」列表只认 URL 型远端服务,本地 stdio 型根本不会出现在那页。做成 HTTP,一份服务就能同时给 App 聊天、消息通道、桌面端三处复用。

三、技术选型

组成
选择
理由
运行时
Python 3.12 slim
依赖全是纯 Python,体积小
格式引擎
LibreOffice(headless / nogui)
格式转换、兼容老的 doc/xls/ppt
读写库
python-docx / openpyxl / python-pptx / pypdf
精确读写 Office 与 PDF
协议
MCP Streamable HTTP
移动端 App 可直接填地址接入
安全
Bearer Token
单个共享密钥,够用不啰嗦

装的是 noGUI 版本的 LibreOffice(core/writer/calc/impress 四件套),不带界面,镜像约 700MB,NAS 上毫无压力。

四、部署:一个 compose 文件

services:office-mcp:build:.image:office-mcp:latestcontainer_name:office-mcprestart:unless-stoppedenvironment:-OFFICE_MCP_PORT=18070-OFFICE_MCP_HOST=0.0.0.0-OFFICE_MCP_TOKEN=<自行生成一串随机串>-OFFICE_MCP_DOCS=/data/docs-OFFICE_MCP_ROOTS=/data/work-TZ=Asia/Shanghai-HOME=/tmpvolumes:-<NAS上的文档目录>:/data/docs-<NAS上的工作资料目录>:/data/workports:-"18070:18070"

两个挂载目录分别对应"沙箱文档区"和"真实工作资料区",AI 都按相对路径访问,不能跳出这两个根目录。

docker compose build && docker compose up -ddocker logs --tail 50 office-mcp

Dockerfile 里有三个细节值得抄:

  1. 换国内源:NAS 直连 deb.debian.org 会挂死,apt 与 pip 都换国内镜像;
  2. 装中文字体:fonts-noto-cjk 必装,否则转 PDF/图片时中文全是方块;
  3. 给个可写的 HOME:无头 soffice 需要一个可写的 HOME(这里用 /tmp),不给会直接启动失败。

五、接进 App:填个地址就行

在 轻聊 App 的「设置 → MCP 工具服务」里,右上角 + →「自定义 URL(高级)」,把服务地址和 token 填进去即可;也可以用「从模板添加(推荐)」快速配好其余几项。

保存后回到列表,看到 office 处在「已启用」,就说明这条链路挂上了。同样的端点也可以写进桌面端的 MCP 配置里,两处共用一套服务。

六、实测一遍

配好不等于能用,必须真跑一次。实测结果:

  • 健康检查 /health 返回 200;
  • 新建一个 docx → 读回内容,与写入完全一致;
  • 查元信息:3 段落 / 0 表格 / 36,700 B;
  • 列目录能看到刚建的文件,按通配符筛选正常;
  • 收尾删除测试文件,目录还原。

读、写、查、删四条路径都通了。现在可以直接说"把这份 Excel 读一下,汇总成 Word 发我",或者"把这个 PDF 转成 Word"。

七、踩过的坑

  1. 工具列表出来 ≠ 能干活。MCP 连上、13 个工具都列出来了,也不代表配置没问题——真正调用那一下才暴露凭据或路径错误。配完务必实跑。
  2. 移动端只认 URL 型。本地 stdio 型服务不会出现在 App 列表里,别指望在 App 里管理它。
  3. 目录权限。宿主目录属主和容器内用户 uid 不一致时,表现为"能列出文件但写不进去",挂载前先对齐权限。
  4. 鉴权只留一个免鉴权口。除了 /health,其余端点一律要求 Bearer Token;NAS 内网不等于安全。
  5. 路径限制是安全底线。只允许访问两个挂载根下的相对路径,禁止 .. 和绝对路径,避免一句提示词就把敏感文件读走。

八、获取方式

轻聊 App(含后端与插件):https://pan.quark.cn/s/737d02a5bddb[1]

(正文里的链接在公众号中不可直接点击,长按复制到浏览器打开即可。)

自建 MCP 服务的过程并不复杂,核心就三件事:选对格式引擎、把入口做成 HTTP、真跑一次验收。动手过程中遇到问题,欢迎在公众号留言。

引用链接

[1]https://pan.quark.cn/s/737d02a5bddb

相关学习资料