Multiple inboxesEmailMCPWorkflow

如何用一个 AI 智能体管理多个邮箱账户

用一个 AI 智能体同时处理工作、个人和副业邮箱:它如何发现收件箱、如何把请求限定到一个邮箱、如何让发件人名称始终正确,以及按收件箱设置的发送审核。

一个 AI 智能体通过 MCP Emails 连接工作、个人和副业邮箱账户
Outlook 和 Microsoft 365 仍在开发中。 它们还无法在生产环境中连接。下文的全部内容适用于 Gmail、iCloud、Fastmail、Yahoo、Zoho 以及其他 IMAP 邮箱。

几乎没有人只有一个邮箱。你有一个工作地址、一个个人地址,还至少有一个用于副业或你仍持有的域名。每一个跨越两个账户的问题,都会变成在两个地方手动搜索。

让一个 AI 智能体覆盖所有邮箱,就不必再来回切换,但前提是智能体知道哪个邮箱是哪个,并且回复会从正确的地址发出。

为什么一个智能体胜过在邮件客户端之间切换

邮件客户端只是把账户展示给你,它不会回答问题。“Stripe 的收据落在了我的哪个账户里?”意味着要在三个邮箱里搜索,再加上一次判断。一个可以访问每个邮箱的智能体,一次请求就能完成,你不必再充当路由。第二个收益是:只需要一套使用习惯,因为每个账户背后都是同一组工具。

智能体会自己找到这些邮箱

你永远不需要把邮箱 ID 粘贴到提示词里。智能体会调用 inbox_list,它会返回你的密钥可以使用的每一个收件箱,每一项都带有 UUID、邮件地址、显示名称、服务商、可选的服务品牌,以及一个能力对象。其他所有工具都接受 inbox_id(一个 UUID,或一个地址)或 inbox(一个地址),并从该结果中填入。

有两个细节值得了解:

  • 发现是免费的。 inbox_list 是唯一一个不计入 Free 每月操作额度的工具,因此智能体可以零成本地重新确认自己的位置。
  • 相互冲突的选择器会被拒绝,而不是被猜测。 如果一次调用带着指向某个邮箱的 inbox_id,同时又带着指向另一个邮箱的 inbox 地址,该调用会被拒绝,错误信息会把两者都指出来。常见原因是从对话早期沿用下来的过期 ID。让智能体只用地址重试即可。

把一次请求限定到一个邮箱

直接点名账户。凡是能用 ID 的地方都能用地址,所以用日常语言就够了:

只在 jane@acme.com 里,列出最近两天所有未读邮件,并告诉我今天需要回复哪些。不要动我的其他账户。

你也可以在提示词之外强制限定范围。在控制台中,每个 API 密钥都有一项收件箱访问权限(Inbox access)设置:全部收件箱,或一份明确的清单。被限定到副业邮箱的密钥无法读取另外两个邮箱,无论提示词怎么说。

所谓 fan-out,就是智能体按邮箱逐个调用

这是很多人弄错的地方:一次调用只能到达一个邮箱。 列出、读取、搜索、移动和删除都限定在单个收件箱内,并且没有自动的 fan-out。所以“搜索我的所有账户”实际上是智能体对每个收件箱各跑一次搜索,再自己把结果合并起来。这样做效果不错,但有三个后果:

  • 让它先调用 inbox_list,或者直接告诉它你有几个账户。如果它假设只有一个,它会非常笃定地只汇报一个账户的情况。
  • 要求给出合并后的答案(“一份合并列表,并标注每条来自哪个账户”),否则你会得到三份彼此独立的报告。
  • 用量会随邮箱数量增长。对三个邮箱做一次分流,至少是三次计费操作,而不是一次。

名称与发件人身份

一个字段承担三种职责。每个收件箱都有一个显示名称:它是控制台列表中的标签(Label),是智能体从 inbox_list 读到的 display_name,也是收件人在 From 头中看到、排在地址前面的名字。

因此“work2”在两个层面上都是个糟糕的名字:智能体看不出这个邮箱是做什么用的,而且某些客户端会把“work2”显示在你的地址旁边。请使用陌生人也能看懂的名称,例如“Jane Doe (Acme)”或“Northside Studio”。可以在控制台中该收件箱的发件人名称(Sender name)里设置,也可以用 signature_set 设置,并用 signature_get 读回。名称上限为 100 个字符。

用别名发送的适用范围比大多数人想象的要窄:

  • 你自己已连接的地址始终可以作为 From 值使用,在所有服务商上都如此。
  • 不同的地址必须是一个已验证的 Gmail Send As 身份,并列在该收件箱 inbox_list 条目的 sender_identities 中。
  • 在非 Gmail 的服务商上,如果 From 地址不是该收件箱自己的地址,请求会被拒绝,而不是被悄悄改写。

签名同样是按收件箱设置的:工作地址用一份正式签名,个人地址不用签名。参见为 Claude 设置邮件签名

按收件箱设置的发送审核

审核是按邮箱配置的。每个收件箱都有一项发送前审核(Review before sending)设置,共三个选项:立即发送、在 AI 对话中显示审核卡片,或仅在控制台中审核。

这正是混合设置用起来舒服的原因:副业邮箱保持立即发送,而每一封工作邮件都先扣下来等待审核。在两种审核模式下,邮件都会被准备好但不会投递,而且批准只能在由所有者或管理员持有的已登录浏览器会话中完成。对话中的卡片只是便利功能,并不是权限边界。AI 智能体发送邮件的人工批准对此有更深入的说明。

三个值得照搬的跨邮箱流程

对所有邮箱做一次早间分流。 要一份统一排序的列表,而不是逐个账户的摘要:

检查我所有已连接的收件箱。给我一份合并列表,列出今天需要回复的内容,按时间从新到旧排列,并标注每条来自哪个账户。不要移动、发送或删除任何内容。

收件箱分流指南里有可以粘贴进这段提示词的评判标准。

当你忘了邮件在哪个账户时找到它。

找到 Hetzner 八月份的发票。在每个已连接的收件箱中搜索,并告诉我它在哪个账户里,以及金额是多少。

在不同角色之间转移一段对话。 当一位私人联系人变成客户时,把邮件线程转发到业务邮箱,并让回复从业务地址撰写。先让智能体确认它正在用哪个收件箱发送。

混用 Gmail 和 IMAP 时会有什么不同

混合设置才是常态,而各家服务商对“文件夹”的理解并不一致。

  • Gmail 使用标签。 一次移动会添加一个标签,并把邮件从收件箱中移出。其他标签仍然保留,所以一封邮件可以同时出现在多个位置。
  • IMAP 使用文件夹。 移动就是移动:邮件离开一个文件夹,进入另一个文件夹。
  • 文件夹名称各不相同。 Archive、All Mail、Spam、Junk 以及各种本地化名称会因服务商而异。让智能体对即将操作的邮箱调用 folder_list
  • 文件夹范围是按收件箱生效的。 把搜索限制在一组文件夹内,只作用于单个邮箱,所以跨账户的按文件夹搜索仍然是每个账户一次调用。

Gmail 标签与 IMAP 文件夹解释了“归档”在两边各自的真正含义。

套餐限制落在哪里

套餐定价的依据是已连接的收件箱数量:

  • Free,$0。 一个已连接收件箱。每个 UTC 日历月 150 次计费邮件操作,其中前 7 天不计入。该月度上限适用于 2026-09-13 当天或之后创建的工作区;更早创建的工作区不受此限制。
  • Personal,$5 每月或 $48 每年。 三个已连接收件箱,没有月度操作上限,2x 突发速率限制,邮件支持。
  • Pro,$15 每月或 $144 每年。 无限已连接收件箱,5x 突发速率限制,更长的分析历史。
  • Team,$79 每月或 $756 每年。 无限成员并支持角色,为每个客户或业务提供独立工作区,SSO(SAML/OIDC)和审计日志,优先支持。

一次跨邮箱流程每个邮箱消耗一次操作,所以邮箱数量对用量的影响,和你的使用习惯一样大。详情见价格

常见问题

智能体怎么知道我指的是哪个邮箱? 通过 inbox_list,它会返回它可以使用的每个收件箱的地址和显示名称。请在请求中点名地址。相互矛盾的邮箱 ID 和地址会被拒绝,而不是被猜测。

回复会从正确的地址发出吗? 会,只要你从拥有该地址的收件箱发送:每个收件箱都通过自己的服务商、显示名称和签名发送。使用不同的 From 地址需要一个已验证的 Gmail Send As 身份,在其他服务商上会被拒绝。

我可以让智能体从一个邮箱自由发送,同时扣下另一个邮箱吗? 可以。发送前审核是按收件箱设置的,因此一个邮箱可以立即发送,而另一个邮箱要在已登录的浏览器中等待你的批准。

这些账户里的邮件会被存储在什么地方吗? 不会。邮件内容会在每次请求时从你的服务商实时获取,随后丢弃。仅保留加密后的服务商凭证。参见安全

下一步

免费开始,连接你最繁忙的邮箱,然后问问你的智能体今天有哪些需要回复。当你想要一个答案而不是三个时,再添加第二个和第三个账户。文档提供完整的工具参考,服务商细节说明了每种邮箱类型支持哪些功能。

Asgeir Albretsen
作者
Asgeir Albretsen

Asgeir builds MCPEmails — the bridge that lets AI agents read, search, and send real email over the Model Context Protocol. He writes about agents, email infrastructure, and developer experience.

为你的智能体接入收件箱

几分钟内将 Gmail、Fastmail 或任意 IMAP 账户连接到你的 AI 智能体。