“Rename ACME Corp to Globex in this contract”（將此合約中的 ACME Corp 改為 Globex）對人類而言只需三秒鐘，卻是 AI 代理人的陷阱。最直接的做法是讀取文件後重新寫一個新文件，這會丟失樣式、表格邊框、標題以及審閱者對於內容未被改動的信心。當本機執行 GroupDocs.Editor MCP 伺服器時，Claude、Cursor 或 Copilot 會直接編輯檔案而不是重新打字：它會找出關鍵字、就地取代、保留格式，並告訴你更改了多少處：

將 contract.docx 中的 ACME Corp 改為 Globex Ltd，並保留格式。

設定、提示與故障排除的逐步說明可在文件中找到：如何使用 MCP 讓 AI 代理人編輯文件.

當模型重新寫入檔案時會出現什麼問題？

語言模型並不持有 .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、編輯後再儲存回去。相關說明請參考往返編輯文章。

呼叫順序

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。每個客戶端的設定位於文件中心。引擎本身的變更請參閱GroupDocs.Editor for .NET 26.6 版本說明。

誠實的限制

  • replace_text 只會在單一格式段落內匹配；跨樣式的片語不會被找到，計數會顯示此情況。
  • 沒有修訂追蹤與註解：結果是一個編輯過的副本，而非修訂稿。
  • 評估模式：每個輸出都會以評估橫幅行開頭，已儲存的活頁簿會多出一個工作表，且僅能編輯前兩個工作表或投影片。伺服器會拒絕第三個並說明原因。
  • PDF 編輯是先轉換為可編輯的 HTML 或 Word 再轉回；並非直接在 PDF 上就地編輯。

常見問題

代理人會覆寫我的原始檔案嗎？
不會。每次編輯都會寫入一個新檔案，預設為 <name>_edited.<ext>，或使用你提供的 outputName，存放於儲存資料夾中。

如果文件中找不到該文字會發生什麼？
不會寫入任何檔案。伺服器回覆「found no matches … No file was written.」，因此代理人可以告知你，而不是回傳未變更的副本。

它在未安裝 Word 的情況下也能運作嗎？
可以。伺服器在本機使用 GroupDocs.Editor 引擎執行；不需要安裝 Office，也不需要上傳。

深入了解