介绍 Word 文档无处不在。在法律、金融和医疗等领域，Word 文档是交付物。合同、监管提交和审计报告通常以 .docx 格式起草、修改和签署，公司通常拥有常规使用的 Word 模板库。这项工作正在越来越多地转移到代理上。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 文件本质上是一个 ZIP 文件，里面包含符合 OOXML（Office Open XML）规范的 XML 文件层次结构。在 ZIP 内部，有以下文件：document.xml 包含主要文本，styles.xml 定义可重用样式（类似于 CSS 样式表），numbering.xml 定义列表/编号行为，此外还有单独的 XML 文件存储页眉、页脚、脚注、关系、媒体和文档元数据。这些 XML 文件相当冗长。例如，在 document.xml 中，即使是短短的 4-5 个句子的段落，一旦添加样式、元数据、格式信息、运行拆分和 XML 骨架，就可能变成数千个符号。用户在 Microsoft Word 中看到的文本可能分布在许多 XML 节点之间，并以非常冗长的方式保存。以下是一个互动小部件，展示了简单的 .docx 文件在后台如何工作：这种 DOCX 编辑的性质使得它与编辑代码或 HTML 不同且更加棘手。对于简单文件，文本表示通常是其本身，且更改是局部的。如果我们使用 Markdown/简单 HTML 为例，结构至少是熟悉的，样式也是局部的。对于垂直 AI 代理，此问题变得更严重。像 Harvey 这样的公司已经遇到了这个问题。当他们重建文档编辑系统时，他们得出的诊断是，他们一直要求一个代理同时充当法律助理和 Word 状态机。像 Harvey 这样的代理已经面临着艰巨的任务。它必须阅读对方的修改意见，应用公司的播放手册，检查定义术语在第 3 条与第 27 条中的含义是否相同，并捕捉到它刚刚更改的赔偿上限与两页前的责任部分相矛盾。这就是工作。分割运行和追踪编号引用并不是工作，但它与同一上下文窗口竞争。现状 回到上述解决方案，每个解决方案都有不同的权衡，但它们都落在同一个地方：代理将其上下文预算花费在 Word 机制上，而不是实际任务上。低级库（python-docx，aspose，Open XML SDK） 好：对于代理来说直观，这些库存在于预训练数据中。它们提供了完整的表达能力；通常没有什么是禁忌的。 坏：速度慢且昂贵。一个处理长法律文档的代理大部分时间花在编写和调试脚本上，简单的事情比如超链接或跟踪更改都需要代理进行复杂的操作。 MCP 服务器（SuperDoc、Office CLI、safe-docx、Adeu） 好：相比编写代码，速度快，价格便宜。 坏：每一个都是代理必须即时学习的新的 DSL，工具和选项的表面非常庞大。它们往往覆盖常见的 80%，而剩下的 20% 是实际文档所在之处。 往返（DOCX ↔ Markdown/HTML） 好：代理根本不需要考虑 Word。它只需编辑文本。 坏：转换在一个方向上是有损的，无法在另一个方向上撤消。特别是，Markdown 不能表达文档从其模板继承的样式关系。在所有这些方法中，我们相信第三种 - 往返。我们相信，通过让代理不必考虑 Word，他们在任务上的表现会更好。然而，往返的一个大问题是 - 如何创建无损转换？解决方案 在解释调和器如何工作之前，我们想说清楚我们为什么对这种形状如此看好