大量业务知识存在于电子邮件中，而您需要的部分通常在附件中：报价单、已签署的修订、修订后的时间表。GroupDocs.Search.Mcp 在 Docker 本地运行，打开电子邮件文件和归档（PST、OST、MSG、EML），并为每条消息和每个附件建立索引，因此 Claude Desktop、Cursor 或 Copilot 可以就地搜索归档，并准确指出匹配来自哪个附件：

索引邮件文件夹。哪条消息提到了价格上涨，具体说了什么？

带有配置和故障排除的逐步版本在文档中：如何在本地使用 AI 代理搜索电子邮件归档和附件。

为什么电子邮件对代理来说很难？

因为归档是容器的容器。PST 包含文件夹，文件夹包含消息，消息包含附件，而附件本身是 Word 文件、PDF 和电子表格。拥有文件工具的代理只能看到一个大的二进制文件。先将归档导出为松散文件是可行的，但速度慢，会将敏感数据复制到磁盘，并且在归档更改时必须重新执行。而且模型根本无法读取 PST。

搜索引擎自行处理这种嵌套。每条消息和每个附件都成为可搜索的项目，结果会记录容器所在的位置以及匹配在其内部的具体位置。

附件内部的匹配是什么样的？

以下是服务器在我们使用三个 EML 消息的测试中返回的内容。短语“price increase”仅出现在其中一个附件的 Word 报价单中；消息正文仅写着 “please find the updated quotation attached”。

-> add_to_index {"documentsPath":"mail","indexName":"mail"}
<- Indexed 'mail' into index 'mail': 3 document(s) added, 3 in the index.

-> search {"query":"\"price increase\"","indexName":"mail"}
<- { "documentsFound": 1, "documents": [
     { "filePath": "mail/2026-09-18-re-q3-pricing.eml",
       "innerPath": "quotation-Q-2026-118.docx",
       "occurrences": 1 } ] }

-> get_text_fragments {"query":"\"price increase\"","indexName":"mail"}
<- === mail/2026-09-18-re-q3-pricing.eml → quotation-Q-2026-118.docx
   (1 occurrence(s)) ===
     …Due to raw material costs we announce a price increase
   of 6 percent from 2026-11-01.…

filePath 是消息；innerPath 是附件。代理可以回答“来自 Contoso 的 Re: Q3 pricing 消息，附件中的报价单 Q-2026-118：自 11 月 1 日起上涨 6%”，并且该句子的每个部分都可追溯。

mail/2026-09-18-re-q3-pricing.eml          <- filePath
  |- body: "please find the updated quotation attached"
  '- attachment: quotation-Q-2026-118.docx  <- innerPath
        "...we announce a price increase of 6 percent..."

在邮件上有效的查询

常规查询语言适用，并且有一些模式对往来邮件特别有用。所有这些都在同一测试邮箱中进行了验证：

  • “Which message from Fabrikam mentions a delivery delay?”：fabrikam AND delay。发件人地址与消息一起被索引，因此 contoso 也找到了一个正文中从未提及该公司的发票。
  • “Find every email that mentions order 77812”：77812。完整的数字被视为词。
  • “Which invoices fall due in October?”：invoice AND content: daterange(2026-10-01 ~~ 2026-10-31)。这会匹配消息文本中写的日期，例如 “due on 2026-10-22”。content: 前缀很重要：如果没有它，日期范围也会匹配引擎为每个文件记录的日期。

为什么本地化对邮件比对其他任何东西更重要

电子邮件是敏感信息的载体：个人数据、谈判、HR 线程、法律建议。需要将邮箱上传或同步到服务的搜索工具对许多团队来说根本不可行。在这里，归档以只读方式挂载到机器上的容器中，在容器内建立索引并进行搜索。唯一离开的文本是代理在答案中引用的内容，而使用本地托管的模型，甚至这些也不会离开。

为了更紧凑的设置，将归档以只读方式挂载，并为索引提供单独的卷：

docker run --rm -i \
  -v /srv/mail:/data:ro \
  -v /srv/mail-index:/index -e GROUPDOCS_MCP_INDEX_PATH=/index \
  ghcr.io/groupdocs-search/search-net-mcp:latest

为大型归档设定范围

拥有数万条消息的归档在有许可证的情况下可以顺利建立索引，但有计划地进行会更有价值。按文件夹或年份作为独立路径进行索引（mail/2025、mail/2026），这样可以单独删除或重建某一年，因为引擎会删除整个已索引的路径，而不是单个文件。将邮件保存在独立的索引中，区别于合同或报告，这样关于往来邮件的提问就不会遍历其他所有内容。当归档增长时，update_index 会捕获新消息，而无需重新读取旧的。

真实的限制

  • 在评估模式下，索引最多容纳 100 个文档，搜索最多返回 10 条结果，且 每条消息和附件都计入，因此真实的归档需要许可证。请先调用 get_license_status。
  • 大型 PST 的索引需要时间：每条消息和附件都会被打开。先完整索引一次，然后使用 update_index。
  • 没有文本层的扫描附件仅通过文件属性进行索引；不提供 OCR。
  • 仅支持 Docker；在 Linux 上除非使用上述只读设置，否则添加 --user "$(id -u):$(id -g)"。

常见问题

我可以在没有 Outlook 的情况下使用 AI 搜索 PST 文件吗？
是的。引擎直接读取 PST、OST、MSG 和 EML；不涉及 Outlook，也不会导出任何内容。

它会搜索电子邮件附件内部吗？
是的。附件被索引为其所属消息的项目，匹配的附件会通过 innerPath 返回其名称。

我的邮箱会被上传到任何地方吗？
不会。它在本地容器内读取；只有代理引用的段落会发送到您的模型提供商。

深入了解