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

当这种情况第一次发生时，值班工程师正盯着已经全红的 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 层通常不具备的数据记录。但它是保护送达率的关键——无论你是否配合，收件箱服务商都会按域名进行限流。

加载中…