只有在您檢查了即將發布的檔案，且 AI 代理能在本地透過幾次呼叫執行此檢查時，遮蔽才算完成。將 GroupDocs.Redaction.Mcp 連接至 Claude Code、Cursor 或 GitHub Copilot，首先以文字形式讀回已遮蔽的副本並搜尋：

提取 case-file_redacted.pdf 的文字，並告訴我其中是否出現任何電子郵件地址。

預期沒有。包含設定與故障排除的逐步說明位於文件中：如何驗證遮蔽已完成.

為何「工具執行」不是證據？

因為即使遮蔽工具順利完成且未出錯，也無法說明模式、檔案、授權狀態或資料隱藏的其他位置。未經驗證的遮蔽僅是聲明，非控制。這種錯誤的常見原因並不罕見。失敗類別很少：

  • 資料被遮蔽而非移除。覆蓋在文字上的不透明區塊仍保留文字於檔案中，讀者可以將其複製。維基百科上關於 遮蔽 的條目描述了 2005 年美國軍方關於 Nicola Calipari 死亡的報告，該 PDF 以遮蔽區塊呈現，但可透過複製貼上至文字處理器取得（另見 BBC News, 2 May 2005）。
  • 模式遺漏了變體：不同的分隔符、換行、大小寫不同。
  • 某一步驟套用在錯誤的檔案上，導致後續步驟撤銷了先前的處理。
  • 註解或文件屬性仍然包含該人的姓名。
  • 未授權的執行在取代上限處靜默停止。

驗證的錯誤方式是什麼？

詢問代理「你已取得全部內容了嗎？」並接受「是」的回答。代理並未取得新資訊；它只是在總結自己的呼叫。第二種錯誤方式是驗證您認為自己產生的檔案。鏈接規則意味著完全有可能驗證一個已跳過某步驟的文件。

正確的驗證方式是什麼？四項檢查

在您計畫發布的確切檔案上執行這些檢查。

1. 以文字形式讀回已遮蔽的副本。 頂部的提示使用返回文字的工具執行此操作，例如 GroupDocs.Parser.Mcp 中的 extract_text（文件），該工具以 Docker 映像提供。任何命中都表示模式遺漏了變體，或執行已達評估上限。此檢查請勿使用 redact_text：它回報的是已儲存的檔案，而非計數，且會寫入另一個副本，因此看似乾淨的回覆並不能證明什麼。

2. 檢查其他三個位置。 註解與屬性不會出現在文字搜尋中。GroupDocs.Annotation.Mcp 伺服器可使用 get_annotations 列出註解，每則註解包含其頁碼與訊息。

現在檢查已遮蔽的副本是否有註解，並讀取其文件屬性。

若要對每個套件進行更深入的屬性檢查，可使用 GroupDocs.Metadata.Mcp 伺服器的 read_metadata 工具，它以 JSON 形式返回所有中繼資料屬性，並同時讀取 EXIF、XMP 與 IPTC。這形成跨伺服器的迴圈：Redaction 伺服器負責移除，第二個伺服器負責讀回。

3. 查看各頁面。 區域遮蔽無法透過文字搜尋驗證。開啟文件，或讓代理使用 GroupDocs.Viewer.Mcp 的 render_page 工具渲染每一頁，並確認每個方框完全覆蓋其應遮蔽的內容且位於正確頁面。

4. 確認產生該檔案的執行之授權狀態。

Redaction 伺服器的授權狀態是什麼？

如果回覆為 evaluation，表示遮蔽已被限制在四次取代。驗證通常會顯示此情況，但若文件恰好有四個匹配項仍會通過，卻仍不正確。始終先確認授權，再進行驗證。get_license_status 回答第一個問題，而 get_document_info 在涉及區域遮蔽時返回頁數與尺寸。

範例會話（節錄）

You:    What is the license status of the redaction server?
Agent:  -> get_license_status()   mode: licensed
You:    Extract the text of case-file_redacted.pdf and tell me whether any email address appears.
Agent:  -> extract_text (Parser server)   No email addresses in the extracted text.
You:    Now check it for annotations and read its document properties.
Agent:  -> get_annotations (Annotation server)   no annotations
        -> read_metadata (Metadata server)       Author, Company: empty
You:    Summarize what you redacted, in which file, and what the verification found.

如何保留證據？

驗證紀錄（即使用的模式、產生的檔案以及讀回結果）即為已執行且已檢查遮蔽的證明。向代理請求此摘要，並與案件檔案一起保存。這適合作為稽核追蹤，而非結果的認證。

驗證無法告訴您的事是什麼？

它無法告訴您您的模式是否正確。上述內容僅證明您要求移除的內容已不存在。判斷應移除什麼屬於您的判斷，沒有任何工具能替您決定。

評估模式的限制是什麼？

每個程序僅能處理一份文件、一次遮蔽，且限制在 4 次取代，加上試用徽章。此上限為示範限制；未授權的執行看似已遮蔽，實際仍可能包含資料，因此在信任任何驗證之前請先檢查 get_license_status。

  • PDF 在 Linux 上。 在 Linux（包括 Docker 映像）中，redact_image_area 與 erase_metadata 目前無法處理 PDF 檔案（PDF 引擎的影像處理依賴於 System.Drawing，而 .NET 僅在 Windows 上支援）；兩者在 Word 文件上可正常運作，且 redact_text 可用於 PDF。請在 Windows 上使用 dnx 執行 PDF 區域遮蔽與中繼資料抹除。

常見問題

我的已遮蔽 PDF 真正被遮蔽了嗎？ 只有在對已遮蔽副本進行文字讀回時未發現任何被移除的值，且註解與屬性皆為空，並且您已檢查過區域遮蔽時，才能確定。檢查全部四項只需幾次呼叫。

AI 代理能檢查已遮蔽 PDF 是否有資訊洩漏嗎？ 它可以讀回文字、透過中繼資料伺服器讀取屬性，並為您渲染頁面供檢視。但它無法判斷您選擇的模式是否正確。

中繼資料會在文字遮蔽後仍然存在嗎？ 會，除非您同時執行 erase_metadata。文字遮蔽僅改變文字內容，作者、公司與日期等屬性是獨立的。

深入了解