邮件智能体最危险的使用方式，是把“它会写、会发邮件”直接当成运营方案。

真正要解决的事情其实很朴素：它能看什么、能分类什么、能起草什么、什么邮件可以自动发、什么必须交给人、收件人如何停止后续邮件，以及出现什么信号时系统必须自动收缩或停止。

下面这套SOP面向小团队，可用于收件箱处理、销售跟进或客户沟通。它不是全球通用的法律清单。不同国家、邮件类型和邮箱服务商的要求不同。截至2026年10月，Gmail和Yahoo仍对较高发送量的发送者强调身份认证、投诉和退订控制；美国商业邮件同时受CAN-SPAM等规则约束。真正落地时，应以业务实际适用的规则为准。

第一步：连接邮箱前，先画权限边界

不要先写Prompt。

先做一张“允许做什么”的表。

动作 默认权限 是否需要人工 原因
对入站邮件分类 允许 通常不需要 外部影响小
提取CRM字段 允许但需校验 异常时需要 数据质量风险
起草回复 允许 按规则 草稿可撤回
发送常规客服回复 有限允许 高风险问题需要 会形成外部承诺
冷启动商业邮件 严格限制 初期通常需要 合规与信誉风险
修改账户/账单条件 禁止 必须人工 后果高
删除/销毁证据 禁止或极度限制 必须人工 审计与恢复风险

如果团队无法用一句话解释某个权限为什么开放，通常意味着权限过大。

比较稳妥的做法是：一开始只给完成当前流程所必需的最小权限，等日志证明流程稳定以后再扩大。

第二步：把“身份、认证、内容政策”分开管理

很多团队把这三件事全部叫“送达率”，结果出了问题不知道从哪里查。

身份：到底由哪个域名、哪个邮箱发送？

认证：接收方能不能验证这个邮件确实被该域名授权？

内容与行为政策：这封邮件本来就应该发给这个人吗？这个形式合适吗？

Google 当前的发送者指南对达到一定发送量的域名有更高要求。其FAQ说明，如果同一主域名在24小时内向个人Gmail账户发送接近5000封或更多邮件，会被视为bulk sender，而且一旦被归类，不是简单降低发送量就自动恢复普通状态。

因此技术负责人至少要长期维护：

  • 发送域名/子域名；
  • SPF；
  • DKIM；
  • DMARC策略和报告；
  • TLS；
  • Return-Path与退信处理；
  • 适用时的一键退订；
  • 投诉与抑制名单来源。

这些东西不应该让智能体自己“决定”。

第三步：不要用一个巨大Prompt承担全部路由

稳定的邮件系统应该先路由，再生成。

一个简单的入站树可以是：

这是交易/账户关键邮件吗？
→ 进入客服或账户流程，不与营销逻辑混用。

这是有明确知识库支持的常规问题吗？
→ 可以自动起草；是否发送再看置信度和政策。

涉及退款、法律威胁、安全、支付争议、敏感数据或账户访问吗？
→ 交给人工。

明显是垃圾或自动噪声吗？
→ 按规则打标签或抑制。

销售跟进同样可以做成树：

已有业务关系，而且客户预期会收到跟进？
→ 根据CRM上下文起草。

全新商业开发？
→ 先检查地区、名单来源、是否被抑制、发送政策，再允许进入起草。

收件人已经退订或投诉？
→ 不发送。

邮件里出现模型无法找到可靠来源的事实性说法？
→ 必须人工确认。

这不是为了排斥语言模型，而是防止语言模型在不知不觉中变成“政策引擎”。

第四步：让每一封草稿都能被追溯

每一封拟发送邮件都应该带足够的记录，让审核者能回答：

  • 为什么这个人会收到？
  • 哪个流程生成的？
  • 用了什么客户数据？
  • 哪个模板/Prompt/模型版本？
  • 是否经过人工批准？
  • 从哪个邮箱发送？
  • 是否存在退订/禁止联系标记？
  • 当时使用的是哪个政策版本？

没有必要、也不应该要求系统展示所谓“私有思维过程”。

真正有价值的审计记录，是可观察的输入、规则、版本和动作。

大多数事故靠这些信息就足够定位。

第五步：把退订和投诉当成控制信号，而不是文案细节

退订绝不是邮件底部一个小链接这么简单。

Google当前发送者指南、Yahoo的发送者资料都强调：相关批量或订阅邮件需要让用户容易退订。Yahoo还提供DKIM域名的Complaint Feedback Loop，符合条件的发送者可以收到用户标记垃圾邮件后的反馈报告。

运营上最重要的结论是：

抑制名单必须位于生成和发送之前。

已经退订的人，不应该先进入“生成草稿”队列，再指望模型记得不要发。

最好建立一个统一抑制层，能够接收：

  • 退订；
  • 投诉；
  • hard bounce；
  • 人工“禁止联系”；
  • 法务/账户级排除。

所有外发路径都必须先检查这一层。

对于美国商业邮件，FTC的CAN-SPAM指南要求准确的头部信息、非欺骗性主题、有效邮政地址以及退订机制等，并要求在规定期限内处理退订。其他司法辖区可能要求更严格，因此全球发送必须另外做法域检查。

第六步：把系统真正跑成一个“周节奏”

小团队完全可以用一套固定周循环管理。

周一：发送健康与信誉

检查：

  • 送达与退信趋势；
  • 垃圾邮件/投诉信号；
  • 退订量；
  • DMARC或认证异常；
  • 服务商合规面板；
  • API或邮箱授权故障。

如果发送者健康正在明显恶化，先暂停扩量，别继续追求“多发一点”。

周二：抽样看质量

随机抽取：

  • 已发送邮件；
  • 被人工拒绝的草稿；
  • 被升级到人工的对话；
  • 产生投诉或明显误解的对话。

把失败原因归类：

  • 数据错；
  • 路由错；
  • 无来源的事实；
  • 语气；
  • 缺上下文；
  • 审批规则不对；
  • 送达问题；
  • 目标客户本身不合适。

不要一出问题就只改Prompt。

先修真正失败的那一层。

周三：更新知识和政策

更新：

  • 已批准事实；
  • 价格或产品变化；
  • 合规说明；
  • 升级规则；
  • 禁止承诺；
  • 已失效模板。

每次变化都要有版本。

周四：小范围测试

一次只试一个运营改动。

比如：

  • 更准确地路由账单问题；
  • 高风险承诺必须人工；
  • 缩短销售跟进序列；
  • 抑制名单同步更严格。

控制影响范围，不要一改就全量。

周五：做决策并归档

记录：

  • 本周改了什么；
  • 质量抽样看到了什么；
  • 投诉/退信有没有变化；
  • 哪条规则保留或回滚；
  • 哪些问题仍未解决。

一周应该以“决定了什么”结束，而不是以“看完一堆仪表盘”结束。

第七步：指标必须有能力让系统停下来

邮件智能体看板不能只有效率。

效率

  • 每小时分类邮件数；
  • 草稿采纳率；
  • 中位处理时间；
  • 每个已解决线程的人工作业次数；
  • 跟进完成率。

质量

  • 事实被人工修正的比例；
  • 发出后又被升级处理的比例；
  • 客户二次澄清率；
  • 草稿被拒绝的主要原因。

发送者健康

  • hard bounce；
  • 垃圾/投诉；
  • 退订；
  • 认证失败；
  • 服务商合规报警。

业务

  • 有效回复；
  • 预约/解决数量；
  • 在归因合理时看收入或案件价值。

不建议把open rate当成最高优先级的经营事实。Google自己的发送者资料也提醒打开率存在准确性限制。更值得依赖的是实际回复、转化、投诉、退订和发送者健康。

第八步：提前写好自动停止条件

团队要在出事前决定，哪些信号有权停止自动化。

例如：

  • 认证突然失败；
  • 投诉快速升高；
  • 抑制同步异常；
  • 已退订的人再次收到邮件；
  • 连续出现无法验证的承诺；
  • 退信异常；
  • 邮箱授权失效；
  • 关键数据源宕机，导致上下文不完整。

停止条件触发以后，默认动作应该是缩小影响范围，而不是让智能体“聪明地绕过去”。

暂停受影响路径，保存日志，判断到底是数据、规则、模型、权限还是发送基础设施出了问题，再用小流量恢复。

一棵决定“可以自动到什么程度”的树

这个动作会形成外部承诺、法律或商业后果吗？
如果不会 → 自动化可以更宽，但必须留日志。

如果会，再问：

它容易撤回吗？
不容易 → 必须人工审批。

如果容易，再问：

内容是否被批准事实和明确政策约束？
不是 → 必须审核。

如果是，再问：

监控和自动停止条件是否已经存在？
没有 → 先别自动发送。

如果有 → 小范围自动化，质量稳定以后再扩大。

这套方法看起来保守，但真正想快速扩张邮件智能体，最有效的路线不是第一天给最大权限，而是建立一个可以扩量而不丢追溯能力的系统。

成熟的一周结束时，团队应该能回答什么

  • 智能体这周处理了哪些邮件？
  • 哪些必须人工？
  • 草稿为什么被拒绝或升级？
  • 发送者信誉是否正常？
  • 退订和投诉是否被正确抑制？
  • 哪条规则发生变化？
  • 这次变化是否提升了质量而没有制造新风险？
  • 下周是否可以安全增加更多量？

这才是邮件智能体真正的运营系统。

模型只是其中一个零件。

Sources

Related Reading