给你的 AI 智能体一个收件箱：通过 MCP 收发邮件的实用指南

大多数“AI 邮件”演示都止步于一张截图：智能体起草一封回复，大家鼓掌，然后没人去问那个尴尬的问题——模型究竟是怎样真正连上一个真实收件箱的？要做到跨服务商、安全无虞，还不用你把应用专用密码粘到提示词里。

这篇文章会讲清楚为什么这“最后一公里”出乎意料地难，以及 Model Context Protocol（MCP）如何把 Gmail、Outlook、Fastmail 以及通用 IMAP 变成一个端点，让你的智能体能像调用任何其他工具一样去调用它。

“直接把我的邮箱给它”到底难在哪

邮件看起来是个已解决的问题，其实不然——至少对一个自主智能体来说不是。有三件事横在中间：

1. 认证方式因服务商而异。 Gmail 要用带正确 scope 的 OAuth。Outlook 要用 Microsoft 身份。Fastmail 要用应用专用密码。每一种都有自己的令牌生命周期和各式各样的失败情形。
2. 凭据是“放射性”的。 你绝不会希望邮箱密码出现在聊天记录、日志行或向量库里。一次都不行。
3. 邮件的“形态”很乱。 MIME、会话线程、HTML 与纯文本之分、附件、其实是标签的文件夹。智能体需要的是一个干净、可预测的接口——而不是原始的 RFC 5322。

最天真的做法——把一个 IMAP 库和你的密码丢给模型——会一下子在这三点上全部翻车。

MCP 真正改变了什么

MCP 是一种把工具（tools）和资源（resources）暴露给语言模型的标准方式。你不必再教会每个智能体如何讲 IMAP，而是运行一个服务器，把邮件呈现为一小组类型清晰的工具：

{
  "tools": [
    "inbox_list",
    "email_read",
    "email_compose"
  ]
}

智能体永远看不到密码，它看到的是一组动词。正是这一个转变，让邮件可以被安全地自动化。

最好的智能体集成是刻意做得“无趣”的：一个稳定的动词、一个可预测的响应，提示词里没有任何机密。

先发现，再行动

一个表现良好的邮件工具，从智能体的视角看是无状态的。智能体不应该把某个邮箱 UUID 写死。它应当先调用 inbox_list，发现有哪些可用资源，然后再动手：

• inbox_list → 返回已连接的账户及其能力
• email_read（动作 list） → 按收件箱分页、最新优先
• email_read（动作 read） → 某一封邮件已解析的正文、发件人和元数据
• email_compose（动作 send） → 撰写并发送，服务商已替你选好

这种“发现优先”的模式，正是一个演示和一个你在某个周二下午也敢放心交托的东西之间的区别。

一个具体的演练

假设你想让 Claude 帮你分拣早上的收件箱。当邮件通过 MCP 暴露出来后，对话大致是这样的：

1. 智能体调用 inbox_list，找到你的工作用 Gmail。
2. 它调用 email_read（动作 list）取最近 24 小时的邮件。
3. 对任何看起来紧急的邮件，它调用 email_read（动作 read）拿到完整正文。
4. 它起草回复并调用 email_compose（动作 reply）——或者只是做个摘要，等你点头。

没有任何密码经过网络传输，提示词里也没有任何与具体服务商绑定的代码。智能体围绕动词进行推理，把真正的活儿干完了。

安全本身就是功能

这一切之所以行得通，是因为那些无趣的部分被放在了它们该在的地方处理——在服务器上，而不是在模型里：

• OAuth 令牌在静态存储时是加密的，并且永远不会返回给客户端。
• scope 保持最小化：读取和发送，仅此而已。
• 智能体向服务器认证，服务器再向服务商认证。 两跳，一个机密存储。

如果这篇文章你只记住一件事，那就记住这个：模型应当持有能力（capabilities），而绝不该持有凭据。

接下来该去哪

连接一个收件箱应该只要几分钟，而不是一整个下午的 OAuth 调试。如果你想试试上面这套“发现优先”的流程，快速开始指南能带你从零搭到一个上线的端点，而服务商对照表则会清楚地告诉你，Gmail、Outlook、Fastmail 以及它们的同伴各自点亮了哪些功能。

给你的智能体动词，而不是密码——然后让它开始干活。