为什么把 AI 接入收件箱时，“邮件从不存储”很重要

当你把一个 AI 智能体接入收件箱时，最重要的问题只有一个：你的邮件最终去了哪里。在 MCP Emails 这里，答案是：哪儿也没去。每一次工具调用都会实时地从 Gmail、Microsoft Graph 或你的 IMAP 服务器拉取邮件，把它交给智能体，然后立刻丢弃。我们唯一保留的，是一个加密令牌，好让下一次调用能够发生。

这听起来像个无关紧要的实现细节。其实不是。它的区别在于：你是把一把进你家的钥匙交给智能体，还是把你家里所有东西的复印件交给它，并永久存放在别人的文件柜里。许多“AI 邮件”工具悄悄做的正是后一件事。这篇文章要讲的，就是为什么这件事很重要，以及它们的架构究竟有何不同。

把邮件交给智能体的两种方式

真正的设计其实只有两种，大多数产品都干净利落地落在其中一个阵营里。

全量复制（同步并存储）。 这类工具连接一次你的邮箱，然后把你的邮件拉进它自己的数据库——往往是持续不断地拉。你的收件箱被镜像进它们的基础设施，以便建立索引、嵌入向量库、喂给模型，或者快速回传。智能体读取的是它们的副本，而不是你的服务商。

实时获取（从不存储）。 这类工具只持有一份凭据。当智能体需要某封邮件时，服务器会实时调用你的服务商，返回结果，然后丢弃正文。关于内容的一切都不会被保留。这就是 MCP Emails 的工作方式。

全量复制模式之所以流行，是因为它易于构建，而且让搜索感觉起来很即时。但它改变了你点击“Connect”时真正同意的内容。你授予的不是访问权限，你授权的是一份复制件。

一个“已同步”的收件箱实际会积累什么

一旦某个工具复制了你的邮件，不管供应商是否对外宣传，下面四件事都会随之而来。

一份你无法掌控的邮件副本

你真正的收件箱位于 Google、Microsoft 或 Fastmail，受它们的安全团队守护，也带着它们各自的泄露历史。一个同步工具会在别处再造一份完整保真的副本——某家创业公司的 Postgres 实例、一个 S3 桶、一个搜索索引。你收到过的每一个密码重置链接、法律邮件往来、医疗化验结果、两步验证备份码，如今都存在于一个你没有审查过、也无法审计的地方。

更大的泄露面

这正是人们低估的部分。如果供应商的数据库泄露了，攻击者拿到的不是你的凭据——而是你的邮件，已经解密并建好索引，随时可读。根本不需要登录你的账户。一次邮件泄露中最具破坏力的部分就是邮件本身，而一个全量复制的工具非常“贴心”地把它们集中堆在了一处。你在自己服务商的安全态势之上，又额外继承了它们的那一份。

你不得不操心的留存问题

当你断开连接时，那份副本去哪儿了？在一个管理良好的同步工具里，删除是一个应该运行的后台任务。在一个马虎的工具里，你离开很久以后，你的邮件仍然躺在备份和嵌入向量里。而采用实时获取的设计，根本没有什么可删的，因为什么都没留下。在仪表盘里撤销访问权限，就是故事的全部。

训练与“产品改进”的风险

一份存下来的真实邮件语料让人难以抗拒。用它来改进搜索排序、微调模型，或训练一个分类器，都很有诱惑力。哪怕出于善意，一旦你的邮件躺在某个数据库里，“它会不会被用于我没同意过的用途？”这个问题就永远悬而未决。如果数据从来没被存过，这个问题压根就不会出现。

实时获取到底是怎么运作的

下面是单次 email_read 调用（动作 read）在 MCP Emails 中走过的路径：

agent  →  MCP server  →  isolated Edge Function
                              ↓ decrypt token (in memory)
                         your provider (Gmail / Graph / IMAP)
                              ↓ message body
agent  ←  parsed result  ←  Edge Function
                         (body discarded, nothing written)

唯一处于静态存储中的就是那份凭据，而它用 AES-256-GCM 加密。解密只发生在调用时、在一个隔离的 Edge Function 内部，而加密密钥是一个与数据库分开存放的环境密钥——所以单凭一份数据库转储毫无用处。邮件本身从不触及持久化存储。它被解析、返回给你的智能体，然后消失。

发送邮件以同样的方式运作，并且多了一重保证：外发邮件经由你自己的服务商——Gmail API、Microsoft Graph，或你自己的 SMTP。我们绝不从我们自己的域名转发，所以你的送达率和域名信誉完全归你所有。这里没有共享的发送池，不会把你拖进别人的垃圾邮件信誉里。

如果你想深入了解凭据模型的内部机制——OAuth 令牌与应用专用密码的对比，以及为什么两者都保持加密——我在 面向 AI 邮件访问的 OAuth 与 API 密钥之争 一文里写过这个。

诚实的取舍

从不存储并非没有代价。它有实实在在的成本，与其假装它不存在，我宁愿把它说清楚。

因为我们不持有本地索引，每一次搜索都是直接对你服务商的搜索发起的。你得到的是 服务商原生搜索——Gmail 操作符、Outlook KQL、IMAP 文本搜索——它很强大，但它用的是它们的延迟和它们的查询语义，而不是一个由我们调优过的自定义索引。而且没有推送：我们无法在邮件到达的那一刻通知你的智能体，因为我们并没有盯着一份同步副本。要对新邮件做出反应，你的智能体需要轮询（例如，按计划定期调用动作为 list、带 unread_only: true 的 email_read）。

对大多数人来说，这是一笔很划算的交易。略慢一点的搜索和一个轮询循环，换来的是绝不为你最敏感的数据再造一份副本。这笔账我认。

该向任何 AI 邮件工具发问什么

在你把任何东西接入收件箱之前，向供应商直截了当地问四个问题。答案会告诉你它们属于哪个阵营。

• 你们存储我的邮件内容，还是每次请求时实时获取？ “实时获取、立即丢弃”才是你想要的答案。
• 究竟有哪些东西被持久化了？ 那应该只是一份加密凭据，与邮件内容无关的任何东西都不该有。
• 凭据在静态存储中是否加密，密钥又放在哪里？ 与数据库分开存放才是正确的答案。
• 发送是经由我的服务商还是你们的？ 经由你的，能保护你的域名信誉；经由它们的，则把你和陌生人混在一起。

如果一个工具没法干脆利落地回答这些问题，那本身也是一条信息。这正是我在 让 AI 智能体访问你的邮件安全吗？ 中审视更宏观的安全问题时所用的同一视角——决定你真实风险的，是营销话术底下的那套架构。

这块拼图的位置

从不存储模式，只是一个更大决策中的一块：如何在不做将来会后悔的事的前提下，把一个智能体接到一个真实的收件箱上。2026 年让你的 AI 智能体访问邮件的完整指南 覆盖了全貌；而如果你正在权衡是否运行自己的服务器，托管版与自托管的 Gmail MCP 会深入探讨在每种情形下加密密钥到底归谁掌管。

你不必在“给智能体有用的收件箱访问权限”和“把邮件挡在第三方数据库之外”之间二选一。有了实时获取，两者兼得。连接一个收件箱，你可以一键撤销它——而且撤销之后，什么都不会留下。