2026-03-28
邮件在开发者视野中沉寂了近十年。实时通信（Slack、Discord）、webhook 和 API-first 架构逐渐取代了它在系统间交互中的角色，邮件退化为通知渠道和遗留对接层。但过去一年里，一个不太引人注意的趋势正在改变这一格局：越来越多的 agent 框架和工具链开始把邮件作为一等能力来集成，而不是作为需要兼容的旧协议来容忍。
这篇文章试图从第一性原理出发，理解这个趋势背后的逻辑。本文讨论的不是邮件整体的复兴，而是邮件作为 agent interface 为何重新变得重要。核心问题有三个：邮件为什么在 agent 时代重新获得价值？agent 使用邮件的方式跟人类有什么根本差异？这些差异对基础设施和产品设计意味着什么？
文章最后会画出这个品类的初步图谱，用几个代表性产品来说明不同层次的设计选择。
要理解邮件的回归，需要先看清 agent 在通信层面面临的约束条件。
一个在生产环境中运行的 agent，需要与人类用户、其他 agent、以及现有互联网服务进行异步交互。它需要一个身份来发起和接收通信，这个身份最好是通用的、不依赖特定平台的。它需要能携带结构化上下文（收件人、主题、附件、对话历史），因为 agent 的工作往往涉及多步骤、多轮次的任务。它需要异步能力，因为 agent 的工作节奏跟人类不同步，不能假设对方随时在线。
逐条检查现有的通信协议，邮件在这些约束条件下的匹配度出人意料地高。
首先是身份的通用性。邮件地址是互联网上唯一被几乎所有服务接受的身份标识。一个 agent 拥有邮件地址，就可以注册账号、接收验证码、与人类通信、与其他 agent 交换信息，这些操作不需要双方共享任何平台。Slack bot 需要对方也在 Slack 里，webhook 需要对方暴露 HTTP endpoint，但邮件不需要任何前提。
其次是上下文的丰富性。每封邮件天然携带 sender、recipient、subject、In-Reply-To、References、附件等元数据。这些字段构成了一个隐式的对话图谱，对 agent 来说提供了比纯文本消息流更多的可操作信号。附件支持意味着 agent 可以直接收发文件，不需要额外搭建文件传输通道。
第三是协议的开放性。SMTP 和 IMAP 是开放标准，没有平台锁定。围绕邮件构建的 agent 基础设施天然具备互操作性，不会因为某个平台修改 API 而失效。这一点在 agent 生态仍在快速变化、没有明确赢家的阶段尤其重要。
第四，也是最容易被忽视的一点：邮件的异步性跟 agent 的工作模式天然匹配。人类用户对实时响应有强烈期待，所以 Slack 和聊天 UI 成为主流。但 agent 之间的协作，或者 agent 与人类之间的任务交接，往往天然是异步的。agent 可能需要几分钟到几小时来完成一个调研任务，然后把结果发回。邮件的异步语义消除了需要维护长连接或轮询机制的工程成本。
这四个特性叠加在一起，解释了为什么邮件正在从遗留兼容层变成 agent 通信基础层。这不是怀旧，而是因为邮件恰好拥有 agent 所需的通用身份、结构化上下文、开放互操作和异步语义，而这些特性在过去十年里被低估了，因为人类用户的偏好推动了实时、平台化通信的崛起。
认识到邮件对 agent 有价值只是第一步。更重要的问题是：agent 使用邮件的方式跟人类使用邮件的方式有哪些根本差异？如果差异足够大，那么为人类设计的邮件产品和基础设施就不能直接复用。
第一个差异是身份的粒度。人类的邮件身份通常是粗粒度的：一个人有一个或少数几个邮箱，每个邮箱对应一个长期稳定的身份。但 agent 的自然单元可能是一个任务、一次会话、一个协作循环或一个工作流阶段。一个研究 agent 可能同时跟五个外部协作者进行独立的多轮对话，每个对话有独立的上下文和生命周期。如果所有对话共用一个邮箱，路由和上下文隔离就变成了应用层需要自己解决的复杂问题。如果每个对话有独立的邮件地址，路由就变得简单，但收件箱的创建和销毁就变成了高频操作，而不是人类邮件世界里的罕见事件。
第二个差异是路由确定性的优先级。人类用邮件时，线程关系主要靠 In-Reply-To / References 头和主题行来推断。这套机制在人类场景下工作得足够好，因为人类能容忍偶尔的线程断裂，可以手动把对话拉回正轨。但 agent 需要的是可编程的路由确定性。当一封回复到达时，agent 需要确定性地知道它属于哪个会话、对应哪个任务上下文，而不是通过模糊匹配主题行或解析引用链来猜测。这意味着 agent 对路由的需求从”通常正确”变成了”必须精确”。
第三个差异是生命周期管理。人类的邮箱是创建一次、使用多年的长期资源。agent 的邮件身份可能需要按需创建、任务结束后归档或销毁。这意味着收件箱的 provisioning 和 teardown 需要成为 API 原语，而不是需要人工操作的管理后台功能。
第四个差异是交互模式。人类主要用邮件客户端的图形界面来阅读和撰写邮件，对排版、附件预览、线程折叠等视觉体验有要求。agent 通过 API 消费邮件内容，关心的是结构化数据的可解析性，而不是渲染效果。这意味着邮件产品为 agent 服务时，投入 UI/UX 的资源应该转移到 API 设计、事件模型和开发者文档上。
这些差异不是程度上的，而是类别上的。它们意味着 agent 时代的邮件产品不是”给现有邮件加一个 API”，而是需要重新思考邮件产品的核心抽象。
上一节提到的路由确定性差异，值得展开成一个独立的论点，因为它触及了邮件协议设计中的一个深层假设。
人类邮件系统中的会话追踪，主要依赖内容层面的信号。RFC 2822 定义的
Message-ID、In-Reply-To 和
References
头构成了线程关系的技术基础；邮件客户端和服务端通过这些字段加上主题行的规范化匹配来重建对话结构。工单系统（Zendesk、Freshdesk
等）在此之上加了一层：它们往往在主题行中嵌入工单编号（如
[Ticket #12345]），然后通过正则匹配来把邮件路由到对应的工单。
这套机制的共同特征是：身份和路由信息嵌在邮件内容中，信封（envelope，即发件人地址和收件人地址）被当作可替换的传输层。也就是说，人类邮件的隐含设计是”内容承载身份，信封承载传输”。
agent 场景可能需要反转这个关系。
agent 发出的邮件，主题行可能是 LLM 生成的，未必遵循人类的主题行延续惯例。agent 的回复可能不完整地保留 References 链，尤其是在多轮任务中 agent 可能重新组织对话而不是简单回复。更根本的是，agent 需要的路由精度比工单系统更高：它不只是要把邮件分到正确的工单，还要把邮件绑定到正确的运行时会话上下文。
一个正在浮现的模式是把会话标识放进邮件地址本身。例如，agent
可以给每个会话生成一个唯一的回复地址（如
session-abc123@agent.example.com），对方的回复自然路由到这个地址，系统根据地址前缀就能确定性地定位会话上下文，完全不需要解析主题行或引用链。这是一种”信封承载身份，内容承载语义”的设计，跟人类邮件的假设正好相反。
这个反转的意义在于：它把路由的确定性从”尽力推断”提升到了”协议保证”。对于需要可编程路由的 agent 来说，这个差异是根本性的。当然，这个模式也有代价：它需要邮件基础设施支持高频的地址创建和路由，这就引出了下一节要讨论的基础设施层面的矛盾。
值得指出的是，这个分析并不意味着 RFC 线程模型或工单系统的路由模式对 agent 完全无用。在许多简单场景中（agent 回复人类发来的邮件，维持单线对话），传统线程追踪仍然适用。反转主要发生在 agent 需要主动管理多个并行会话、或者需要在运行时动态创建通信通道的场景。工单/帮助台模式是一个有价值的历史基线，但把它直接当作 agent 时代的默认答案是不够的。
产品层面的设想（每个会话一个地址、按需创建收件箱、动态身份管理）碰到邮件基础设施时，会遇到一组深层约束。这些约束不是产品设计能绕过的，因为它们内嵌在邮件生态系统的运行机制里。
邮件送达率的信任体系以域名和 IP 地址为单位运作。一个新域名需要经过 warm-up 过程来建立发送声誉：从少量邮件开始，逐步提高发送量，让收件方的反垃圾邮件系统积累正面信号。这个过程是域名级别的，不是收件箱级别的。在同一个域名下创建一百个收件箱，这一百个收件箱共享同一个域名声誉。如果其中某个收件箱的发送行为触发了垃圾邮件投诉，影响的是整个域名。
这就产生了一个直接的矛盾：产品层面希望收件箱是轻量级的、可以频繁创建和销毁的应用层资源；但基础设施层面，发送声誉是域名级别的重资产，需要长期维护和保护。一个 agent 平台如果让用户随意创建收件箱并从这些收件箱发送邮件，它面临的核心挑战不是收件箱管理的技术实现，而是如何在多租户环境下保护共享域名的发送声誉。
Plus-addressing（如
agent+session123@example.com）看起来是一种轻量级的折中方案：它不需要创建真实的收件箱，但可以在收件侧实现基于地址的路由。问题在于，plus-addressing
只是一种路由便利，不提供真正的身份隔离或送达率隔离。所有 plus-addressed
邮件仍然从同一个发件人地址发出，共享同一个 SPF/DKIM 认证上下文。
Catch-all 路由（接收发送到域名下任何地址的邮件）是另一种接收侧方案，适合需要动态地址但不需要独立发送身份的场景。它的局限是：它只解决接收问题，不解决发送身份问题。
综合来看，可能最务实的架构是解耦发送身份和接收身份：用少数经过 warm-up 的稳定发送身份来保证送达率，同时用更灵活的接收地址（plus-addressing、catch-all 或动态收件箱）来实现会话级路由。这意味着 agent 邮件平台的产品模型可能需要区分”发送身份”和”接收身份”这两个概念，而不是把它们合并在”收件箱”这一个抽象里。
这个区分很重要，因为它决定了产品设计的约束边界。如果一个产品承诺”每个 agent 会话一个独立邮箱”，它需要回答的关键问题不是怎么创建收件箱（那是 API 设计问题），而是怎么在不损害域名声誉的前提下让这些收件箱独立发送邮件（那是基础设施问题）。
理解了 agent 邮件的需求、跟人类用法的差异、以及基础设施的约束之后，可以把当前的产品图谱按抽象层次整理出来。这个图谱不是产品推荐，而是帮助理解不同层次的工具各自解决了什么问题、留下了什么问题。
代表产品：Postmark Inbound、SendGrid Inbound Parse、Mailgun Routes、Cloudflare Email Workers。
这些产品的核心模型是协议转换：把入站的 SMTP 邮件翻译成 HTTP POST 事件，让 web 应用可以处理邮件。它们没有收件箱概念（或收件箱仅是路由规则的别名），不维护线程状态，不提供身份管理。开发者获得的是原始事件流，所有上层逻辑需要自行构建。
对 agent 来说，如果只需要”收到邮件时触发一个动作”，这一层就够了。但如果需要 agent 拥有持久邮件身份、维持多轮对话、管理多个并行会话，开发者需要在这些工具之上自建收件箱抽象和会话管理。
代表产品：OwlRelay、Resend（入站能力方面）。
这一层的产品思维更现代，开发者体验更好，但核心抽象仍然是”处理邮件事件”而非”管理收件箱”。OwlRelay 是一个开源项目，比 SendGrid Inbound Parse 更懂 agent 的入站场景，但不提供完整的收件箱生命周期管理。Resend 的核心业务是开发者体验极好的邮件发送 API，入站能力还在早期。如果 Resend 认真投入 agent 方向，它的开发者品牌和 DX 优势会构成严肃竞争。
这一层和上一层的分界线在于：开发者体验和 agent 场景的适配度有了明显提升，但产品模型没有根本变化。收件箱在这里仍然不是一等资源。
这是最新、也最不稳定的一层。过去一年里，多个产品和项目开始明确地把邮件定位为 agent 能力，而非人类收件箱的 API 扩展。
这一层产品的共同特征是把收件箱作为核心资源来暴露：收件箱有自己的创建、删除和配置 API，每个收件箱对应一个真实的邮件地址，线程和事件作为内建概念维护，而不是留给开发者自建。目前出现在这一层的包括 AgentMail、KeyID、mails.dev、AgenticMail 等。它们的差别不只在功能多少，更在于它们把产品边界放在哪一层：有的更像收件箱即服务，有的更像 agent 身份层，有的更接近自托管通信基础设施。
这些产品的存在本身就是一个有意义的信号：多个独立团队从不同角度汇聚到了同一个设计空间。但这个品类仍然处于前共识阶段，不同产品对边界问题的回答差异很大。有的侧重收件箱即服务，有的侧重 agent 身份管理，有的侧重自托管灵活性。
如果前面的图谱看起来还是有点抽象，可以把它压缩成一个场景。假设一个 agent 需要同时维护三个独立的外部邮件对话，每个对话都有自己的上下文，而且这些对话会持续几轮。
如果你用的是基础设施层的工具，比如 SendGrid Inbound Parse 或 Cloudflare Email Workers，那么平台只负责把邮件变成事件。邮件到了，你拿到了 payload，但它属于哪个会话、回复该怎么路由、线程状态放哪里，这些都还是你的问题。
如果你用的是中间层的工具，比如 OwlRelay，那么入站解析和 webhook 转发已经更友好一些，开发者体验也更好，但会话管理和身份生命周期仍然主要落在你这边。它减少了摩擦，但没有改变核心抽象。
如果你用的是应用层的产品，比如 AgentMail 或同类 agent-native inbox 工具，平台开始直接把收件箱当作资源提供给你。你可以为每个对话分配一个独立地址，线程、事件和路由也更接近内建能力。这样做的好处是直观，坏处是你把更核心的通信路径交给了平台，而平台自己也要面对前面说过的基础设施约束：域名声誉、warm-up、多租户发送风险，以及发送身份与接收身份是否应该分离。
这样看，三个层次的差别就清楚了。第一层解决的是把邮件接进系统。第二层解决的是让开发者更容易处理邮件。第三层解决的是把邮件身份本身产品化。它们不是简单的高低配关系，而是在回答不同层级的问题。
这个视角也能把品类里的几个开放问题一起看清。首先，很多产品会把自己描述成 AI-native，但公开 API 真正证明的往往只是 agent-ready：也就是更适合 agent 调用的邮件基础设施，而不是平台本身已经内建了强 AI 处理能力。其次，生态集成是有价值的信号，但它更像分发和共振信号，不直接等于生产流量或稳定护城河。再次，品类的主导抽象仍然在竞争中：会话级收件箱、地址级身份、线程级路由、自托管通信基础设施，这几条路都有人在试。最后，所有应用层产品都还要面对同一个底层现实：域名声誉和 warm-up 按域名与 IP 运作，不按产品想象中的每个小 inbox 运作。
所以这篇文章真正想建立的直觉不是哪家公司更强，而是这个品类到底在试图回答什么问题：邮件事件怎么接进来，邮件身份要不要变成一等资源，agent 的会话边界该落在地址、线程还是应用层，以及这些产品抽象怎么和现实的邮件基础设施接起来。
邮件在 agent 时代的回归不是怀旧，而是因为邮件协议恰好具备 agent 所需的通用身份、结构化上下文、开放互操作和异步语义。但 agent 使用邮件的方式跟人类有根本差异，尤其在身份粒度、路由确定性和生命周期管理方面。这些差异催生了一组新的产品设计问题和基础设施约束。
路由模型可能需要从”内容承载身份”反转为”信封承载身份”，以获得 agent 所需的可编程路由确定性。但产品层面对多身份、高频 provisioning 的需求跟基础设施层面以域名为单位的声誉体系存在张力，务实的方案可能需要解耦发送身份和接收身份。
多个产品从不同角度汇聚到了 agent 邮件能力这个设计空间，说明品类需求是真实的。但品类仍在前共识阶段，最终的主导抽象还在竞争中。对于正在构建 agent 系统的开发者来说，选择哪一层工具，取决于实际的并行会话规模和身份动态程度，而不是品类叙事的吸引力。