Vespper 用 HTML 投影搞定 Word 文档编辑，比直接操作 XML 快三倍

Word 文档看起来只是几页纸，实际上它是 OOXML 规范定义的一堆冗长 XML 文件的压缩包。如果你让 AI Agent 直接去改 .docx，它得先解压、grep、sed，或者写 Python 脚本操作 python-docx。加个有序列表得去 numbering.xml 里新建 ID 再链接回 document.xml；加粗一句话可能要把段落拆成三个以上的 run 元素。这种机械性的底层操作极其烧 Token，也让 Agent 很容易因为上下文窗口爆满而迷失方向。

YC F24 的 Vespper 刚发了一个解决这个问题的 MCP（Model Context Protocol）工具。他们的思路很直接：不让 Agent 去啃 XML，也不让它通过 Pandoc 这种高损耗的工具转换来回去猜样式。他们把 .docx 转换成 HTML，让 Agent 像编辑网页一样进行查找和替换，最后再把改动合并回原始的 Word 文件。

为什么现有的方案都不够好

在做这个工具之前，两位创始人 Dudu 和 Topaz 花了一年时间为制药公司构建 AI 文档编辑器。制药行业的监管文档（比如临床研究报告 CSR）通常有几万字，且格式严格。起初他们用 Markdown 输出，但用户坚持要用自己的 Word 模板。这就暴露了 Agent 在处理 Word 时的三个主要瓶颈：

1. 底层库太啰嗦：让 Agent 写代码调用 Open XML SDK 或 python-docx，Agent 需要学习这些库的 API，而且每次修改都要处理 XML 结构，Token 消耗巨大。
2. 专用 MCP 引入新 DSL：像 SuperDoc 或 Office CLI 这样的工具提供了预定义的操作指令，但这意味着 Agent 要额外学习一套领域特定语言（DSL），增加了推理负担。
3. 中间格式有损严重：用 Pandoc 或 mammoth.js 把 Word 转成 Markdown/HTML 再转回来，往往会丢失细微的样式和排版信息，导致最终文档格式崩坏。

在他们的实际测试中，填充一份 CSR 文档大约需要 50 分钟，而且经常漏掉字段或搞乱样式。Harvey.ai 的团队也得出了类似的结论：Agent 在探索文档结构和调试失败编辑上浪费了大量时间。

Vespper 的做法：HTML 作为代理层

Vespper 的核心逻辑是“投影”。他们编写了自己的 DOCX 到 HTML 转换器，保留了足够的结构和高保真度，让 Agent 能看懂原文的布局和样式。关键点在于，他们不会把修改后的 HTML 转换回 DOCX。原始文件始终是唯一真相源（Source of Truth），HTML 只是给 Agent 看的“视图”。

Agent 接收 HTML，执行查找替换（Find-and-Replace），然后 Vespper 的后端将这些变动精准地映射回原始的 .docx 文件中。选择 HTML 而不是 Markdown，是因为 HTML 的结构和 CSS 样式关联方式更接近 OOXML 的内部逻辑。

性能与成本数据

根据 Vespper 团队的对比，相比最接近的替代方案：

• 速度：快了 3 倍。
• 成本：便宜了 2 倍（主要得益于 Token 效率的提升）。
• 准确性：更高，因为避免了多次格式转换带来的精度损失。

怎么接入使用

这是一个标准的 MCP 服务，适合集成到支持 MCP 的 Agent 框架中（如 Cursor、Claude Desktop 或你自己的 Agent 代码）。

你需要安装 @vespper/mcp 包：

npm install @vespper/mcp

然后在你的 MCP 客户端配置中启用它。具体配置取决于你使用的宿主程序，以 Claude Desktop 为例，在 claude_desktop_config.json 中添加：

{
  "mcpServers": {
    "vespper": {
      "command": "npx",
      "args": ["-y", "@vespper/mcp"]
    }
  }
}

接入后，你可以在对话中直接上传 .docx 文件，然后下达指令：“把第三段中关于‘患者筛选标准’的描述改为最新协议版本，并保持原有的加粗和列表格式。” Agent 会自动处理底层映射，返回更新后的文件。

局限性与注意事项

虽然速度快，但这毕竟是一个较新的工具。目前的“最快”和“最便宜”是基于他们内部基准测试得出的，主要对比对象是通用的大模型+脚本组合。对于极度复杂的嵌套表格或自定义样式极多的文档，任何自动化工具都可能存在边缘情况下的样式漂移。建议在实际应用前，先用几个典型模板跑一遍全流程，检查生成的 .docx 是否符合人工预期。

另外，Vespper 的模型是经过微调的，这意味着它对 Word 结构的理解比通用 LLM 更强，但这也可能带来一定的封闭性。如果你的文档模板非常规整且数量巨大，这种专用的 MCP 确实能省去大量调试 Agent 逻辑的时间。

对于需要频繁处理 Word 模板的开发者和业务人员来说，这比让 Agent 瞎猜 XML 结构要靠谱得多。如果你正在构建自动化文档流水线，不妨试试这个工具，看看那 3 倍的速度提升能否转化为你项目里的实际效率。