让邮件 Agent 可控：校验层与测试收件箱

让 LLM 发一封邮件，难点往往出现在发送之后：用了什么身份、寄给了谁、有没有重复发送、能否在不打扰真实用户的情况下复现？作者给出的方案，是在模型和邮件服务之间加一层明确的执行契约，再用测试收件箱验证结果。

这套设计适合验证 onboarding、账号恢复和 AI 通知流程。它没有提供性能数据，也没有展示完整实现，但把一个容易被当成工具调用的小功能，拆成了可检查、可追踪的工程流程。

模型提出发送请求，系统负责决定能不能发

作者将流程拆成三部分：LLM Agent 生成结构化的动作参数，邮件适配器校验参数并执行发送，测试收件箱接收邮件、提供验证证据。

为什么不能让模型直接调用邮件服务？因为「发送确认邮件」只描述了意图，系统还需要检查收件人、模板、环境、权限和执行结果。提示词可以要求模型守规矩，却不能承担最终的执行约束。

模型输出了合法 JSON，不代表这次发送获得了授权。

下面是原文的最小契约，它让适配器能够逐项判断发送请求是否符合要求：

{
  "run_id": "checkout-1842",
  "recipient": "qa-inbox@example.test",
  "template": "welcome-v3",
  "allowed_environment": "staging",
  "action": "send"
}

要留意 allowed_environment：请求中写着 staging，仍然需要适配器检查实际执行环境。未知字段、不在允许范围内的域名、不存在的模板，也都应该被拒绝。

拒绝之后，还要返回可读的原因，让 Agent 修正下一次提案。否则模型没有可靠反馈，可能继续生成错误参数，甚至在对话里声称发送成功。

这里还有一个容易忽略的区分：临时邮箱是某次测试拥有的接收能力，不是用户身份。作者建议按执行创建临时地址，保存执行标识、测试收件人和模板哈希，避免把实验内容送进个人邮箱，也避免把测试审批误认成真实审批。

邮件服务接受请求，还不算测试通过

原文最有用的部分，是把「发了」拆成几个不同状态。下面这段状态机用于区分发送进度和验证结果：

CREATED -> RESERVED -> SENT -> OBSERVED -> VERIFIED
             |          |        |
             v          v        v
          EXPIRED    RETRYING  FAILED

重点看 SENT -> OBSERVED -> VERIFIED。SENT 只表示邮件服务商接受了消息；OBSERVED 表示测试收件箱收到消息；VERIFIED 才表示内容、链接和收件人满足约定。

这三个状态不能混用。服务商返回成功，不保证邮件已经到达；收件箱里有邮件，也不保证邮件里的链接指向正确环境。

作者要求每次状态转换都携带 run_id、agent_step、message_id 和时间戳。这样出现问题时，才能判断错误发生在模型提案、邮件服务，还是结果验证阶段。

它也关系到重试。Agent 没有收到确认时，第一封邮件可能已经送达。此时直接再发一次，就可能产生重复通知。作者建议先查询 message_id 和执行状态，再决定是否重试，并要求重试具备幂等性且有次数上限。

不过，原文没有交代幂等键如何生成、并发重试如何协调，也没说明首次发送超时、尚未拿到 message_id 时怎么办。这些仍需实现者补齐，不能仅靠这张状态图解决。

测试收件箱也要有验收条件和有效期

收件箱的作用不只是证明「收到过东西」。原文给出的检查项很具体：邮件确实到达、主题完全匹配、链接使用 staging 的 host，并且没有外部收件人。

这些条件把模糊的成功提示，变成了可观察的验收结果。对于账号恢复流程，链接指向哪个环境尤其关键。测试邮件即使正常送达，链接指向错误环境，测试仍应失败。

收件箱还需要 TTL，也就是有效期。时间短能减少数据暴露，但过短会让服务商的正常延迟变成测试失败。作者建议参考当前环境观察到的最坏耗时设置有效期，并记录过期原因，没有给出可以直接照抄的秒数。

数据保留也应跟着验证目标走。如果只检查结构和链接，就不必长期保存完整正文。若要验证正文内容，则需要另外明确证据如何保存；原文没有展开这一层。

作者还提醒，不要把搜索中的拼写错误，例如 tempail mail、tepm mail com，写进变量名、锚点或验证逻辑。搜索文本表达的是模糊意图，程序应依赖稳定标识。这个提醒不复杂，却能避免把临时检索词带进长期维护的代码。

我的判断

我认同它对职责的划分：模型判断下一步做什么，确定性的代码约束执行范围，再用外部证据确认结果。这比只在 prompt 中强调「不要重复发送」「只能发测试邮箱」更容易检查，也更方便定位故障。

但这是一套设计建议，作者没有提供可核对的实测记录、故障率变化或对照数据。关于降低风险、改善排查效率的结论，应视为工程经验，不能当成已经证明的收益。

它也未必需要全套落地。如果当前只测试模板渲染，mock 邮件适配器可能已经足够；如果要验证服务商接受请求之后的投递和链接内容，测试收件箱才更有价值。两种方式覆盖的边界不同。

另外，状态机只是骨架。接收者白名单、环境权限、重试上限和有效期，都要变成实际校验。接口里出现了这些字段，不等于约束已经生效。

能拿来做什么

• 给 Node Agent 增加邮件工具时，先定义固定的动作结构，再由适配器校验字段、模板、域名和环境，并向模型返回明确的拒绝原因。
• 测试注册欢迎邮件或账号恢复流程时，把收到邮件、主题匹配、链接 host 正确分别作为断言，不要用发送接口返回成功替代验收。
• 在内部调试面板中展示执行状态、run_id、message_id 和失败原因，让开发者知道当前应该等待、排查还是重试。
• 为测试收件箱设置有依据的 TTL，并按验证需求保留内容；重试前先查执行记录，同时明确幂等规则和次数上限。