在 HN 发布: Vespper (YC F24) – 顶尖 Docx MCP

# 推出 Vespper DOCX MCP：速度提升3倍、成本降低50%、准确性更高 来源：https://www.vespper.com/blog/launching-vespper-docx-mcp ## 引言 Word文档无处不在。在法律、金融和医疗等领域，Word文档是最终交付物。合同、监管文件和审计报告的起草、修改和签署都在`.docx`格式中进行，企业通常拥有大量日常使用的Word模板。这些工作正越来越多地转向智能体（Agent）。Microsoft Copilot和Claude等Word内置的文档AI工具已成为主流，而越来越多的垂直领域智能体——尤其是在法律科技领域——需要处理`.docx`文件。 然而，AI智能体在Word文档处理方面仍面临挑战。我们与数十位软件工程师（主要来自法律科技和医疗行业）交流发现，他们通常需要数周甚至数月时间调试工具链，以实现可靠的Word文档编辑，并被迫维护极其复杂的内部解决方案。 目前智能体编辑Word文档主要有以下三类方式： - 让智能体编写使用底层SDK（如python-docx、aspose或Open XML SDK）的代码 - 连接MCP服务器（如SuperDoc、Office CLI、safe-docx或Adeu），为智能体提供标准化工具 - 通过有损转换实现Word文档往返处理：使用pandoc/mammoth.js等工具转换为Markdown/HTML，让智能体编辑后再转回`.docx` 现有方案在简单场景下尚可应对，但在复杂场景中往往力不从心。在深入探讨这些方案及其缺陷之前，我们首先需要了解`.docx`文件的本质。 ## 问题分析 `.docx`本质上是遵循OOXML（Office Open XML）规范的ZIP压缩包，内含层级化的XML文件。ZIP包内主要包括： **document.xml**包含主文本内容，**styles.xml**定义可重用样式（类似CSS样式表），**numbering.xml**定义列表/编号行为，此外还有独立的XML文件存储页眉、页脚、脚注、关联关系、媒体内容和文档元数据。 这些XML文件极其冗长。例如在**document.xml**中，即使是一个4-5句话的简短段落，一旦加入样式、元数据、格式信息、文本段分割和XML模板代码，就可能变成**数千个**标记（token）。用户在Microsoft Word中看到的文本可能被分散在多个XML节点中，并以非常冗长的方式存储。 以下交互式组件展示了简单.docx文件的后台工作原理： 这种DOCX编辑特性使其与代码或HTML编辑存在本质差异。对于简单文件，文本表示基本等同于内容本身，且修改是局部的。以Markdown/简单HTML为例，其结构至少是熟悉的，样式也保持局部性。垂直领域AI智能体在这一问题上面临更大挑战——Harvey等公司已遭遇此问题。 当他们重建文档编辑系统（https://www.harvey.ai/blog/building-an-agent-for-complex-document-drafting-and-editing）时，诊断结论是：他们之前要求单个智能体同时充当法律助手和Word状态机。像Harvey这样的智能体任务已经极其复杂——需要审阅对方批注、应用律所标准条款、验证第3条与第27条中的定义术语一致性，并检查刚修改的赔偿上限是否与两页前的责任条款冲突。这些才是核心工作。而分割文本段、追踪编号引用等操作不属于核心任务，却会占用相同的上下文窗口资源。 ## 现状分析 回到上述解决方案，每种方案都有不同的权衡取舍，但最终都陷入相同困境：智能体将上下文预算消耗在Word机制而非实际任务上。 **底层库**（python-docx、aspose、Open XML SDK） - **优点**：智能体易于理解——这些库出现在预训练数据中，提供完整表达能力，通常无功能限制 - **缺点**：速度慢且成本高。智能体处理长篇法律文档时，大部分时间花在编写和调试脚本上，即使是超链接或修订追踪等简单操作也需要复杂的变通处理 **MCP服务器**（SuperDoc、Office CLI、safe-docx、Adeu） - **优点**：相比编写代码更快捷经济 - **缺点**：每个MCP都是智能体需要即时学习的新DSL，面对大量工具和选项。它们通常只覆盖常见80%场景，剩余20%正是真实文档的复杂所在 **往返转换**（DOCX ↔ Markdown/HTML） - **优点**：智能体完全无需考虑Word机制，只需编辑文本 - **缺点**：转换过程存在单向有损，反向转换无法完全还原。特别是Markdown无法表达文档从模板继承的样式关系 在这些方案中，我们坚信第三种方案——往返转换的价值。我们相信通过将智能体从Word思维中解放出来，它们能更好地完成任务。然而往返转换的最大挑战在于：如何实现无损转换？ ## 解决方案 在解释协调器（Reconciler）工作原理前，我们想说明为何看好这种解决方案形态。灵感来自基础设施即代码（IaC）领域。在IaC工具流行前，开发者需要登录云账户"手动点击"，耗费数小时在AWS/GCP控制台中导航、点击按钮、手工管理基础设施。若不幸需要同步多个环境（预发布、生产、测试、客户环境）或快速创建新环境，情况将迅速失控。 随后Terraform和Pulumi出现。现在开发者只需修改代码，工具就能自动计算（或更准确地说——**协调**）云端所需变更。我们不再需要花费数小时操作控制台。 我们认为这个理念可以很好地迁移到智能体与Word文档的交互中：智能体编辑可读且直观的内容，其他组件则负责将这些编辑映射到实际文件。但如前所述，现有工具尚未成熟。pandoc和mammoth.js等工具在转换过程中损失过多信息，且无法真正"协调"回**原始**文件，意味着这是一种高损耗的方案。 简言之：理念很好，但工具尚不完善。我们决心寻找更好的方案。 首先确定表示格式。Markdown是显而易见的首选，但我们很快放弃——它无法表达样式或关联样式到元素。最终我们选择HTML： - HTML结构接近OOXML：``→``、``→``、``→`` - CSS能将样式关联到特定元素，这与OOXML的样式机制大致相似 这仍然存在有损问题。现有转换器（pandoc、mammoth.js）能将DOCX转为HTML，但生成的HTML无法同时做到最小化、高保真和干净。因此我们从头构建了自己的转换器。 理论上智能体现在只需编辑我们的HTML，剩下只需协调回原始.docx文件。这正是复杂性所在。OOXML拥有庞大体系：无数元素、选项和样式。若在此之上添加自定义HTML表示，将产生极长的边缘案例列表。 我们决定训练模型作为协调器，而非构建巨型协调引擎并手工编写代码处理每个边缘案例：向模型展示大量HTML ↔ OOXML变更对，训练它预测HTML变更对应的OOXML变更。 该模型是解决方案的核心。它接收智能体的HTML意图，生成有效的OOXML块。然后我们将结果与原始块进行差异对比，确定性计算修订追踪，将变更补丁写入文件，最后返回给调用方。 以下交互式序列图展示了我们解决方案的端到端工作流程： 下一节将说明我们如何评估该方案与其他方案的对比。 ## 评估验证 为基准测试我们的方案，我们在内部测试集的279个DOCX编辑任务中对比了5种其他方案，每个任务在两种模型上运行：GPT 5.6 Sol和GPT 5.6 Terra，均采用中等推理强度： - MCP服务器方案 - Vespper MCP（我们的方案） - SuperDoc MCP - v0.18.1 - Office CLI（通过MCP） - v1.0.145 - Adeu MCP - v3.0.2 - 技能/工具链方案 - Anthropic的DOCX技能 - 原生python-docx工具链 对于工具链方案，我们使用LangChain的create_agent（https://reference.langchain.com/python/langchain/agents/factory/create_agent），它简化了智能体实例化和模型切换，与官方mcp包（https://github.com/modelcontextprotocol/python-sdk）兼容良好。我们排除了开箱即用的工具链（如LangChain的deepagents（https://github.com/langchain-ai/deepagents）、Vercel的eve（https://vercel.com/eve）），因为我们希望完全控制并在后台尽可能减少"魔法"操作（如自动压缩、系统提示修改等）。 关于候选方案的补充说明： - **统一系统提示**——所有方案（包括我们的）均未针对特定方案调整提示词 - **移除设置步骤**——几乎所有方案都要求智能体在编辑前执行初始化操作：加载技能、打开文件、追踪会话、完成后保存关闭。我们统一移除了这些步骤：DOCX技能预加载到上下文，会话ID和文件路径在后台注入，SuperDoc的`open`/`save`/`close`等生命周期工具完全隐藏。每个候选方案从第一轮对话起即可读取和编辑文件 - **python-docx作为基准**——我们想观察未经工具设计和调优时的性能表现 ## 数据集构建 ### 智能体任务集 为评估上述方案，我们构建了高质量的Word编辑任务数据集。构建过程大致分为三个阶段： **获取原始文档** 从docxcorp.us（http://docxcorp.us/）获取原始DOCX文件，保留各领域（政府、医疗、金融、法律）的英文文档，剔除低置信度分类文档。 **合成任务** 每个文档需要一组自然语言指令（"任务"）和相应的评分机制。我们构建了内部标注工具，可快速预览原始文档并在浏览器中合成编辑任务。每条任务都经过人工审核、批准/丢弃/修改。 关于数据集的补充说明： - 确保任务明确直接；避免"撰写引人入胜的介绍"这类模糊任务，而是合成"撰写包含以下内容的引言部分：..."这类明确任务 - 真实文档无噪声（不添加未请求的修改、使用正确样式等） - 为保持数据集纯净，我们手工标注300条任务，并对齐LLM评判器和修复智能体来标记和修正噪声任务 最终数据集包含2046条任务，按文档级别约70/15/15分割（避免数据泄露），并按文档主题、任务领域等元数据分层。每条任务包含三个要素： - **original.docx** - 智能体接收的未修改源文档 - **modified.docx** - 显示预期编辑的参考"标准"版本 - **Prompt** - 描述编辑请求的自然语言提示 以下是数据集中的示例任务： ``` 为附表1（本法案不适用的实体及范围）添加新条目："根据2005年规划与发展法成立的西澳大利亚规划委员会"。按字母顺序插入，位于"根据2004年州行政法庭法设立的州行政法庭"之后。 ``` 预期输出为： 西澳大利亚规划委员会插入附表1列表的修订追踪记录，附带Vespper建议卡片 示例任务的预期输出。新条目被标记为修订，与周围列表缩进一致，并以与上方行相同的斜体样式显示法案名称。如图所示，样式需要保持一致。本例中，智能体需采用与其他条目相同的缩进格式，并将法案名称设为斜体。**注意**：我们并未明确告知智能体该使用何种样式。我们期望智能体能隐式理解这些要求。 #### 评分机制 评估时，我们运行特定智能体（如GPT 5.6 Sol + DOCX技能）处理上述任务。每个智能体运行生成output.docx，最终得到： - original.docx - modified.docx（标准答案，即文件在预期修改后的状态） - output.docx（智能体生成的文件） 执行以下步骤： 1. 将每个Word文档转换为块序列，大致对应每个`` 2. 对齐original.docx ↔ modified.docx（标准答案）找出实际变更的块，然后对齐modified.docx ↔ output.docx检查智能体是否正确生成。对齐算法采用最长公共子序列（https://en.wikipedia.org/wiki/Longest_common_subsequence） 3. 按内容和样式比较这些块。内容指读者可见的已应用修订内容，样式指渲染后的视觉呈现（非Word格式化XML） 以下是展示特定任务评分流程的交互式图示： ### 协调器任务集 在开发协调器前，我们先定义了两项要求： - 必须高精度（保留内容，样式准确） - 必须**极快** 基于第二项要求，智能体方案不可行。处理文档（如法律文件）通常需要智能体进行数十甚至上百次编辑。如果每次编辑需20秒协调，用户体验将极其糟糕。因此我们将其重构为翻译问题。 模型接收三元组`(html_old, html_new, xml_old)`，输出对应块的`xml_new`。无推理、无工具调用、无循环。寻找`xml_old`不是模型的任务——我们编写了确定性定位器，将HTML块映射到对应OOXML块（单独测试）。这完全将搜索问题排除在模型之外，使其只需专注自身优势：生成与预期变更匹配的有效OOXML。 在模型选择上，我们选定3-8B参数范围。后训练运行的数据集远小于预训练，更新所有参数效率低下。我们采用低秩适配（LoRA）（https://arxiv.org/abs/2106.09685），冻结基础模型并训练少量"适配器"矩阵。早期实验确定采用rank 16、alpha 32、LR 2e-4、AdamW 8-bit配置。 数据集从智能体任务集中自监督挖掘：`(html_old, html_new, xml_old, xml_new)`四元组，加上根据生产环境中智能体实际提交内容生成的增强数据。最终协调器数据集包含约16k任务，按70/15/15分割训练/验证/测试集。 数据集准备就绪后，训练采用监督微调（SFT）。框架使用Unsloth，GPU通过Modal提供： 训练损失曲线在约2800全局步骤后持续下降并趋于稳定 在Unsloth/Modal上协调器SFT训练的损失曲线。我们希望在训练过程中使用可理解的指标评估模型（因为损失值本身解释性有限）。为此采用上文评分方法的简化版本。