AutomationsInbox triageMCPEmail

无需模型参与即可运行的邮件自动分拣规则

MCP Emails 的自动化如何运作:一个保存好的搜索加上一个固定动作,按设定的周期执行,全程没有模型解读你的邮件。预览、创建、启用,并查看运行日志。

MCP Emails 中的无人值守邮件分拣规则:一个保存好的搜索加上一个按计划执行的固定动作
Outlook 和 Microsoft 365 仍在开发中。 目前还无法在生产环境中连接。

每天早上你都让智能体清理噪音:把构建通知归档,把收据标记为已读,把发票转发给记账员。它确实能做到。但每次都要消耗一次模型调用,而且周二的处理方式和周一会略有不同。

MCP Emails 为这类邮件准备了另一套入口。自动化就是一个保存好的搜索加上一个固定动作,按设定的周期执行,全程没有模型参与。邮件只会被匹配,永远不会被解读。

自动化到底是什么

只有三个部分,再无其他。

  • 一个过滤条件。 与搜索接受的结构化条件完全相同:fromtoccsubjectbodytextunreadhas_attachmentflaggedsincebefore。至少必须给出一个条件。空过滤条件会被直接拒绝:在较快的周期下,它会处理你的整个邮箱,而这远比一次有意为之更可能只是一个笔误。
  • 一个动作。 恰好一个,取自一个封闭集合,在创建规则时就固定下来。
  • 一个周期。 interval_minutes,取自一组固定档位:15、30、60、180、360、720 或 1440 分钟。之所以用档位而不是任意整数,是因为每分钟跑一次的规则除了让你被限流之外毫无收益。

同时设置 max_messages_per_run(默认 25,最大 200):它是每次运行的影响半径,限定一个糟糕的过滤条件在有人查看运行日志之前最多能触及多少邮件。规则以创建它的凭据身份运行,且每次运行都会重新推导权限,因此吊销密钥会在规则的下一次运行时让它停下来。

为什么规则胜过每天早上去问智能体

  • 成本。 规则不消耗任何 token。早上的对话则每天都在消耗,而这些邮件的处理方式你几个月前就定好了。
  • 可重复性。 同样的过滤条件产生同样的动作。不存在「它今天判断得不一样」,因为它根本没有在判断。
  • 不会有幻觉操作。 规则无法凭空造出一个文件夹,无法临时编出一个收件人,也不会执行它在邮件正文里读到的指令。
  • 你睡觉时它也在跑。 MCP Emails 在其他方面是轮询式的:你让智能体查收新邮件,它才去查。规则正是那部分不需要你开口的工作。

智能体分拣和无人值守规则做的是不同的事

规则处理的是仅凭信封就能识别的邮件:已知的发件人、稳定的主题前缀、未读标记、带附件。需要判断力的邮件交给对话处理。不要把判断力写成过滤条件:一条靠主题行猜测意图的规则,会在无人看管的情况下大规模地连续出错好几周。如果这个决定必须读懂正文,就把它留在对话里,并参考分拣与摘要指南

动手创建:预览、创建、启用

按这个顺序分三步。顺序本身就是安全保障。

第 1 步:先空跑过滤条件

automation_read 搭配 preview 动作就是一次空跑。它会报告某个过滤条件此刻能匹配到什么,不执行任何操作,不发送任何邮件,也不会在去重账本中占用任何一封邮件,因此绝不会吃掉之后真实运行本该看到的邮件。你可以预览一个未保存的 filter,也可以用 automation_id 预览一条已保存的规则。

在我的工作收件箱上预览一个自动化过滤条件:来自 notifications@github.com 的未读邮件。告诉我它现在会匹配到哪些邮件。不要创建或修改任何东西。

读一遍匹配结果。如果这个列表里有任何一封不该被移动,说明过滤条件有问题:收紧它,然后再预览一次。

第 2 步:创建规则

automation 搭配 create 动作需要四样东西:namefilterrule_actioninterval_minutes。请留意这两个键,它们很容易混淆。在工具层面,action 选择的是操作本身(create、update、enable、disable、delete)。rule_action 则是规则对匹配到的邮件做的事。

在我的工作收件箱上创建一个名为「GitHub notifications」的自动化。过滤条件:来自 notifications@github.com。规则动作:移动到 Notifications 文件夹。间隔:60 分钟。

规则创建出来时是停用状态,而且这不是你能在同一次调用里翻转的标志位。启用永远是一个独立且明确的动作,这样就不会有任何无人值守的邮箱操作,作为创建规则的副作用悄悄开始。

第 3 步:启用它

automation 搭配 enable 动作。规则会立刻到期、运行一次,然后按自己的周期继续。正是在这一刻,服务器开始在无人注视的情况下动你的邮箱,所以它必须单独成为一步。delete 会删除规则,但保留它的运行历史。

规则能做什么,不能做什么

五种规则动作:

  • move,移动到你指定的文件夹。
  • label,作为 Gmail 标签、Outlook 类别或 IMAP 关键字应用。在 IMAP 上标签是一个原子串,因此空格会变成下划线。
  • mark_read
  • forward,最多转发给十个收件人,可附一段简短说明。无论收件箱的审批设置是什么,转发始终会被扣下来等待人工审批:那项设置的含义是「有人在盯着这个邮箱发出的邮件」,而一个无人值守的执行器恰恰打破了这个前提。
  • draft_reply,它只会写出草稿,永远不会发送。它的模板只替换 {{sender_name}}{{sender_email}}{{subject}}{{date}},除此之外什么都不替换。邮件正文根本不会被插值。

规则不能做的事:

  • 删除邮件。 自动化没有删除能力。移动到回收站、垃圾邮件或 Spam 同样会被拒绝:每家服务商都会定时清空这些位置,所以把邮件归入其中等于一次带延时引信的删除。请归档到你自己的文件夹,等你读过运行日志之后再自己删除。
  • 解读任何内容。 不做摘要,也没有「如果听起来很紧急」这种判断。
  • 串联两个动作。 又打标签又标记已读,那是同一个过滤条件上的两条规则。

查看运行历史

automation_read 搭配 runs 动作会列出最近的运行及其计数器:匹配数、已处理数、成功数、失败数、跳过数。list 动作会列出工作区里的每一条规则及其计划、动作和健康状况;get 会完整读取其中一条,包括过滤条件和失败状态。

值得理解的计数器是跳过数(skipped)。跳过数很高而已处理数很低并不是问题:它说明一次重叠的运行被正确地去重了。每条规则在处理一封邮件之前都会先占用它,因此被重新派发的运行不可能把同一封邮件移动两次。此外,规则在连续五次运行失败之后会自行停止,而不是永远地对着一个错误的文件夹名硬磨。

什么时候不该写规则

  • 这个决定必须读懂正文才能作出。把它留在对话里。
  • 发件人不稳定。针对一个移动目标的过滤条件很快就会失效。
  • 这是一次性的清理。让智能体执行一次 email_search_and_move,并在旁边看着。
  • 你还没有预览过它。一条没有空跑过的规则,只是一次被排进日程的猜测。

一个现实的收件箱:几条规则加一次对话

四条规则清掉所有机械性的邮件,再加上一次针对剩余邮件的晨间对话:

  1. 来自已知发件人的部署通知,移动到某个文件夹,每 60 分钟一次。
  2. 收据和订单确认,打标签,每 180 分钟一次。
  3. 来自已知账单地址的发票,转发给你的记账员并扣下等你审批,每 720 分钟一次。
  4. 一个你保留但从不阅读的新闻邮件发件人,标记为已读,每 1440 分钟一次。

这样一来,你要问智能体的就是剩下的三十封邮件,而不是收到的一百八十封。这些规则并不试图变聪明。它们只是移走了所有本来就不需要智能的东西。

规则也会计入你套餐的操作次数

规则执行的每一个动作,都会和交互式操作完全一样地计量,因为它对邮箱产生的效果是相同的。在 Free 套餐上,这意味着每个 UTC 自然月 150 次计费的邮件操作,其中前 7 天不计入。这个月度上限适用于 2026-09-13 及之后创建的工作区;在此之前创建的工作区不受限制。当一个工作区用完额度时,规则会暂停而不是失败:它仍然处于启用状态,下一次运行会推迟到额度周期结束的那一刻。Personal 每月 $5,取消月度操作上限,并允许连接 3 个收件箱。参见价格

常见问题

自动化会用到大语言模型吗? 不会。规则就是一个保存好的搜索加上一个固定动作。邮件只会被匹配,永远不会被解读,邮件正文也永远不会被复制进规则产出的任何内容里。

规则会删除我的邮件吗? 不会。自动化没有删除能力,出于同样的原因,把邮件移入回收站、垃圾邮件或 Spam 也会被拒绝。

这需要什么权限? 每一个自动化操作都需要 manage:automations,它是一项独立于读取和发送的授权,因为拥有它就意味着客户端可以创建长期生效、在无人值守时动你邮箱的规则。

转发规则会自己把邮件发出去吗? 绝不会。无论你的收件箱审批设置如何,转发始终会被扣下来等待人工审批,而 draft_reply 规则永远只写草稿。

下一步

创建一个免费账户,连接一个收件箱,并让你的智能体在保存任何东西之前先预览一个过滤条件。当匹配结果看起来无误时,创建规则、启用它,明天再来读运行日志。文档里有完整的工具参考。

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 智能体。