你的智能体发件箱将是你的下一个送达率事故

当这种情况第一次发生时，值班工程师正盯着已经全红的 Gmail Postmaster 仪表盘，支持信箱因为客户重置密码邮件落入垃圾邮件箱而告急，而导致这一切的智能体（Agent）仍在运行。在当地时间凌晨 4 点到上午 9 点之间，它从公司的主要发送域名发送了 8 万封“个性化跟进邮件”，且全部使用了计费系统所用的同一个 DKIM 密钥签名。等有人注意到时，花费三年建立的域名声誉已毁于一旦，接下来六周内，公司所依赖的每一条事务性消息的收件箱投递率也将随之化为乌有。

从智能体发送邮件看起来就像是一个单行的工具调用。send_email(to, subject, body) 是最经典的演示，每个框架都将其作为入门集成提供。但邮件不同于其他工具。错误的数据库查询可以回滚，错误的 API 调用会返回错误。而一批糟糕的邮件会降低你公司发送的每一封其他邮件的送达率，且持续数周之久。这里没有可以回滚的事务，因为邮件已经发送到了接收方的邮件服务器，而这些服务器正在记录你域名的声誉历史。

经验丰富的邮件团队在二十年间建立起来的规范——分离发送流、专用子域名、每个流独立的 DKIM 密钥、谨慎的预热曲线、基于退信和投诉反馈的自动压制——并不是为了应对对抗性场景而设计的。它们是基于这样一个现实：邮件声誉是一个变化缓慢、全组织共享的资源。智能体团队在他们的发送域名第一次进入 Gmail 惩罚区时，才通过惨痛的教训发现这一点。而这种局面的出现，是因为从没有人询问过负责送达率（Deliverability）的团队：是否应该允许智能体发送邮件。

邮件声誉涉及全组织且难以重建

一个有用的基本原则是：邮件声誉属于域名，而不属于应用程序。当你的营销平台从 acme.com 发送活动邮件并收到过多的垃圾邮件投诉时，从 acme.com 发送重置密码邮件的事务性服务也会受到牵连。像 Gmail 和 Yahoo 这样的收件箱提供商在发送域名（和 IP）层面评估声誉。自 2024 年起，他们强制要求批量发送者（每天向个人收件箱发送 5000 封或更多邮件的任何人）必须将垃圾邮件投诉率保持在 0.3% 以下，建议目标为 0.1%。一旦超过这个阈值，邮件将不再仅仅是延迟，而是直接停止送达。

智能体的扇出发信会将 0.1% 的投诉率变成一个可承受的信号还是一个域名杀手，完全取决于你如何隔离发送任务。如果你的智能体与重置密码邮件使用相同的域名发送，那么一个在早晨赚取了 1% 投诉率的 8 万封邮件智能体，刚刚为共享声誉池贡献了 800 个投诉。在所有接收方看来，多年来一直保持 0.05% 投诉率的事务性系统现在与那 1% 被绑定在了一起。惩罚适用于该域名发送的所有内容。

这是人类发送邮件时自然能做对，而智能体团队却系统性出错的地方。市场运营团队绝不会从与账户验证邮件相同的子域名发送冷开发邮件——这种错误在行业内属于常识性反面教材。然而，为了追求“直接调用 SendGrid API”的便捷，智能体团队在第一天就会犯下这种错误，因为智能体的发送工具指向的是手头恰好有的凭据。基础设施是继承来的，而不是设计出来的。

智能体在第一次发送前需要的架构隔离

在任何智能体获得 send_email 权限之前，发送基础设施应该已经具备以下设计：

• 为每个智能体应用场景配置专用子域名。 如果你的支持智能体给客户发邮件，而销售智能体给潜在客户发邮件，它们不应该共享 mail.acme.com。请使用 support-bot.acme.com 和 sales-bot.acme.com。当其中一个污染了声誉时，爆炸半径是受控的。事务性子域名（承载重置密码和收据的域名）应该对任何不属于该特定用例的智能体设限。
• 每个子域名使用独立的 DKIM 密钥对。 绝不要在不同服务间共享 DKIM 密钥。每个子域名拥有自己的选择器（Selector）和私钥，每个签名域名维护两个选择器以便在不中断服务的情况下进行轮换。这听起来像是在走形式，直到有一天你需要撤销某个受损智能体的签名能力，而不必关停整个邮件流。有了独立的密钥，撤销操作只需修改一次 DNS；而使用共享密钥，撤销意味着停机。
• 在智能体边界强制执行针对每个接收方域名的频率限制。 收件箱提供商会针对发送者进行限流，但他们是静默执行的——你的邮件只会开始落入垃圾邮件箱。在提供商动手之前，你自己先执行限制。如果一个销售智能体想在同一分钟内给 gmail.com 的 500 个潜在客户发邮件，你的网关应该将其限流为每分钟 50 封，将其排队并缓慢释放。智能体没有选择不执行的权利。
• 建立退信和投诉反馈循环，在提供商封禁前挂起智能体。 订阅提供商的 Webhook（SendGrid、Mailgun、SES、Postmark 都提供此类接口）。当某个特定智能体的滚动投诉率超过一个严格的内部阈值（例如 0.05%，远低于 Gmail 0.3% 的强制执行线）时，自动挂起该智能体的发送权限。智能体应该从工具错误中发现问题，而不是等 CEO 来问责。

这些都不是新奇的邮件工程技术。这是每一位资深送达率工程师都烂熟于心的操作手册。新奇之处在于，智能体团队需要在第一个智能体上线之前就构建好这些，而不是在第一次事故发生之后。

速率限制是 Agent 的安全特性，而不止是成本控制

讨论 Agent 限流时，大多将其视为成本或死循环问题。对于“邮件即工具”而言，它是送达率（Deliverability）问题，其反馈周期比 CFO 的推理账单要短得多。

帮助理解的心智模型是：每个接收方域名都有自己的速率配额，且配额在以小时为单位的时间尺度上恢复。五分钟内发往 gmail.com 的 40 条消息没问题。五分钟发 4000 条，则会让发件人、该子域名甚至主域名直接进入垃圾邮件箱。接收方决定一切，且这种决定可能会持续数周。

因此，Agent 边界需要三个限流维度，而不仅仅是一个：

• 按 Agent 运行次数（单次用户发起的会话）。限制单次执行产生的消息总数，仅此而已。如果用户让 Agent “跟进我整个线索管道”，从一个 Prompt 产生的一万次发送应该需要人工明确确认，而不是悄无声息地发生。
• 按 Agent 身份，滚动统计。一个给定的 Agent 界面应有每小时和每日配额。配额耗尽时，应进入队列或拒绝。这能捕获一个编排器产生多次运行、而每次单次运行看起来都合理的情况。
• 按接收方域名。这是最难补丁的一项，因为它需要 Agent 层通常不具备的数据记录。但它是保护送达率的关键——无论你是否配合，收件箱服务商都会按域名进行限流。

网关的理想形态是：每次 Agent 发送都通过一个统一的出口服务，该服务维护每个发送者/每个接收方域名的计数器，Agent 的工具调用返回 queued（已排队）、sent（已发送）或 rate_limited（受限）的结果，Agent 必须处理这些结果。如果你让 Agent 直接与你的邮件服务商 (ESP) 通信，这一切都不复存在。

披露、同意与“这是 AI 发的”辩护

有一类 Agent 生成的邮件，技术上的送达逻辑没问题，但法律上却行不通。美国的 CAN-SPAM 要求每封商业邮件必须标明发送者、包含物理地址，并提供在 10 个工作日内生效的退订机制。加拿大的 CASL 更严格——发送第一条消息前需获得选择性加入（Opt-in）许可，每家机构违规罚款最高可达 1000 万加元。欧盟的 GDPR 要求有文件化的合法依据。这些法律都没有“这是 AI 发的”豁免条款。

Agent 团队有时认为“我们运行了一个自动化工作流”就是有效的披露。在实际法规下，这并不成立。如果收件人根据邮件中的声明采取行动——预约电话、购买、签署合同——法律责任将追踪至发送邮件域名的主体。没有人类打字这一事实并不是辩护理由。

实际的含义是，某些内容类别在发送工具触发前需要人工介入确认（Human-in-the-loop）：

• 向未经事先同意的接收者发送外链邮件（冷销售触达）。这至少需要一个同意检查，限定 Agent 被允许给谁发邮件，而不仅仅是允许它说什么。
• 代表个人做出承诺的消息。“我已经安排在周二了”由人类签名和由 Agent 签名的效果完全不同，争议解决的范畴也不同。
• 发往具有事先同意制度司法管辖区的接收者的消息。如果你的收件人列表没有按管辖区细分，那么默认安全的策略是在所有地方都要求获得同意。

仅限内部的发送（通知、发给已订阅认证用户的摘要）是另一回事。界限在于：收件人是否是不知情的第三方，且无法从邮件中判断出这是由自动化系统生成的。

可观测性：每次发送都应追溯到工具调用、Agent 运行和用户

当滥用发生时——在规模足够大时，滥用总会发生——真正重要的问题是“谁干的”。廉价的答案是“API 密钥干的”。这毫无用处。调查会陷入死胡同，修复方法只是轮换密钥，而下一次事故会如出一辙。

昂贵但正确的答案要求每封外发邮件在离开网关前，都要丰富以下信息：

• Agent 身份（哪个界面，哪个版本的 Prompt 和工具定义）。
• Agent 运行 ID（哪个会话，哪个用户请求触发了此操作）。
• 发起用户（发起这一系列动作的人类——即使隔了三层调用）。
• Agent 发出的工具调用参数，与实际发送内容分开记录（这样你可以看到 Agent 是否试图发给一个后来被网关拦截的收件人列表）。

常见的实现方式是在外发邮件中添加自定义请求头（X-Agent-Run-ID），并在邮件事件存储中记录一条以消息 ID、Agent ID 和运行 ID 为键的结构化日志。当投诉通过服务商的反馈机制传来时，通过消息 ID 可以在几秒钟内追溯到整个链条。

当下游团队询问“是我们的 Agent 给客户发了重复的退款确认，还是人工干预的？”时，这种做法就能体现价值。没有追踪，你只能靠猜。有了它，你就能确切知晓。

出问题的组织缝隙

最深层的失效模式并非技术问题——而是结构性问题。可送达性（Deliverability）归属于消息或营销运维团队。智能体（Agent）基础架构归属于平台或 AI 团队。发布邮件发送智能体功能的产品团队通常与这两方都没有交流，因为集成被认为“只是调用一下 SendGrid API”。

解决方法是将“邮件即工具（email-as-tool）”视作任何高爆炸半径（high-blast-radius）的能力：这项权限需要负责承担后果的团队进行审批。在智能体界面获得发送邮件权限之前，可送达性团队会审查子域名隔离、速率限制配置、退信列表（suppression list）集成以及智能体将生成的内容类别。他们拥有否决权。他们之所以拥有这项权力，是因为当域名声誉跌落谷底时，负责处理报警（page）的是他们，无论如何，警报都会发给他们。

基础架构组件——子域名、DKIM 密钥、网关、可观测性——都是可送达性工程师以前构建过的。新出现的是威胁模型：一个持有 API 密钥的非确定性行为体，以机器速度进行扇出，能够生成看起来像人类创作的内容，并且可能遵守也可能不遵守你系统提示词（system prompt）中关于发送量的提示。防御手段是成熟的，但在智能体第一次发送之前就部署这些手段的需求是全新的。

枯燥的事实是，经验丰富的邮件团队之所以存在，是为了应对那些智能体团队需要通过惨痛教训才能发现的问题。学习这一课的廉价方式是阅读他们的手册（playbook）。昂贵的方式则是经历一个发出 8 万条消息的早晨、变红的 Postmaster 仪表盘，以及随之而来的长达 6 周的收件箱投递率（inbox placement）下降。