“Rename ACME Corp to Globex in this contract” 对于人来说只需三秒钟，对 AI 代理来说却是个陷阱。最直接的做法是读取文档并重新写一个新文档，这会丢失样式、表格边框、页眉以及审阅者对未被移动内容的信心。借助本地运行的 GroupDocs.Editor MCP 服务器，Claude、Cursor 或 Copilot 可以直接编辑文件，而不是重新输入：它会定位到词语，原位替换，保留格式，并告诉你更改了多少处：

将 contract.docx 中的 ACME Corp 重命名为 Globex Ltd 并保持格式。

包含设置、提示和故障排除的逐步版本请参见文档：How to edit documents with AI agents using MCP。

当模型重写文件时会出现什么问题？

语言模型并不持有 .docx 文件，它只持有文本。当你让它“更新合同”时，自然的路径是读取文字、修改后再生成一个新文档。途中会丢失三件事。

格式。 粗体的当事方名称、编号标题、表格网格线、费用表的列宽、带页码的页脚：这些都不属于模型读取的文本，因此除非有东西重新构建它们，否则在传输过程中全部消失。

模型未被要求触碰的所有内容。 重新生成意味着每个句子都会再次经过模型。一个条款可能被“整理”，数字可能被重新格式化，句子可能因上下文窗口已满而被删除。审阅者现在必须对整个文档进行差异比对，才能信任仅有的三个字的改动。

审计轨迹。 “我更新了合同”这一回复无论模型改动了一个名字还是七个名字都是相同的。没有计数，也无法区分一次细致的编辑和一次自信的编辑。

现有的仅限 DOCX 的编辑服务器已经解决了 Word 的第一个问题。其余两个问题以及所有非 Word 的格式仍未解决。

有针对性的编辑是什么样的？

两次调用。以下示例取自 GroupDocs.Editor.Mcp 26.10.0 对一个合成服务协议的操作，其中 “ACME Corp” 出现了七次：

-> get_document_info {"file":{"filePath":"contract.docx"}}
<- { "family": "WordProcessing", "pageCount": 1, "canEdit": true,
     "canSaveTo": [ "docx", "doc", "rtf", "odt", "pdf", "md", ... ] }

-> replace_text {"file":{"filePath":"contract.docx"},
                 "find":"ACME Corp","replace":"Globex Ltd","wholeWord":true}
<- Replaced 6 occurrence(s) of 'ACME Corp' in 'contract.docx'
   Saved to: …/contract_edited.docx

-> replace_text {"file":{"filePath":"contract.docx"},
                 "find":"Initech","replace":"Globex Ltd"}
<- Text replacement found no matches for 'Initech' in 'contract.docx'.
   No file was written.

编辑后的副本保留了粗体的当事方名称、标题样式和费用表。原始文件保持不变；结果是一个新文件 contract_edited.docx，位于存储文件夹中。

为什么是六次而不是七次？

这点值得细读两遍。第七个 “ACME Corp” 出现在通知条款中，其中 “ACME” 为斜体而 “ Corp” 为普通体。在文件中它们是两个格式运行，而 replace_text 只能在单个运行内匹配。它既没有猜测，也没有合并样式以强制匹配；它报告了六次，第七次仍然是 “ACME Corp”。

这正是你希望用于编辑合同的工具的行为。计数低于预期时会提示你去检查；而一次悄无声息的“完整”重写则不行。代理可以继续使用服务器提供的另一条路径：将该部分提取为 HTML，编辑后再保存回去。相关的 round‑trip post 有详细说明。

调用顺序

user              agent                        Editor MCP server
 |  "Rename ACME Corp to Globex Ltd in contract.docx"          |
 |---------------->|                                           |
 |                 |-- get_document_info {"file":...} -------->|
 |                 |<- WordProcessing, 1 page, canEdit --------|
 |                 |-- replace_text {"find":"ACME Corp",       |
 |                 |     "replace":"Globex Ltd",               |
 |                 |     "wholeWord":true} ------------------->|
 |                 |<- "Replaced 6 occurrence(s) ...           |
 |                 |    Saved to: .../contract_edited.docx" ---|
 |<- "6 changed; one more is split across formatting - check  |
 |    the notices clause. The original is kept."               |
      (a find that matches nothing: 'No file was written.')

为什么这不仅仅是 Word 的技巧

相同的调用同样适用于工作表、幻灯片、PDF 或文本文件。在我们的测试中，"worksheet": 1 将预算汇总表中的供应商名称改为新名称，而其他两个工作表保持不变；"slide": 1 在审阅幻灯片中实现了同样的效果。"format": "pdf" 在一次调用中完成编辑和转换，因此 “修正名称并发送 PDF” 只需一步。"regex": true 能处理诸如版本号之类的模式。

在编辑之前，get_document_info 会告诉代理它正在处理的内容：文件族、页数、工作表或幻灯片数量、是否受密码保护以及可以保存的格式。谨慎的代理会先调用它，而你也可以要求它这么做。

设置

dnx GroupDocs.Editor.Mcp --yes

将 GROUPDOCS_MCP_STORAGE_PATH 指向代理可以编辑的文件夹，或使用 Docker 镜像 ghcr.io/groupdocs-editor/editor-net-mcp。每个客户端的配置位于 documentation hub。引擎本身的变更请参阅 GroupDocs.Editor for .NET 26.6 release notes。

诚实的限制

  • replace_text 只能在单个格式运行内匹配；跨样式拆分的短语不会被找到，计数会反映这一点。
  • 没有修订痕迹和评论：结果是编辑后的副本，而非红线对比。
  • 评估模式：每个输出都会以评估横幅行开头，保存的工作簿会额外增加一个工作表，且只能编辑前两个工作表或幻灯片。服务器会拒绝第三个并说明原因。
  • PDF 编辑实际上是先转换为可编辑的 HTML 或 Word 再返回；并非原位 PDF 编辑。

FAQ

代理会覆盖我的原始文件吗？
不会。每次编辑都会写入一个新文件，默认命名为 <name>_edited.<ext>，或使用你提供的 outputName，存放在存储文件夹中。

如果文档中不存在要替换的文本会怎样？
不会写入任何内容。服务器会回复 “found no matches … No file was written.”，因此代理可以告诉你而不是返回未改变的副本。

不安装 Word 能工作吗？
可以。服务器在本地运行 GroupDocs.Editor 引擎，无需 Office 安装，也无需上传。

深入了解