邮件验证智能体需要明确等待预算

让 LLM 操作浏览器、注册账号，再去邮箱里取验证码，演示时等一等就能继续。放进真实工作流，等待会占用 worker，重试可能重复创建账号，旧邮件还可能被当成这次任务的凭证。

作者给出的结论是：先设计邮件的延迟预算，再写 agent 的 prompt。把等待时长、邮件归属、超时结果和重试规则交给程序控制，模型只处理已经确认的结果。这套思路适合需要邮件验证的浏览器自动化和 CI 测试，但文中的时间配置仍是示例，没有实测对照数据。

等待邮件为什么需要一份预算

作者把流程拆成：应用触发邮件、邮件进入测试邮箱、worker 找到证据、agent 继续操作。每一步都可能慢。如果只给模型返回「还没收到」，它无法判断该继续等、重新发送，还是结束任务。

临时邮箱可以隔离测试账号，却不能保证即时送达，也不能自动证明某封邮件属于当前执行。任务需要一个稳定的 run_id，用来关联注册操作、邮箱和后续证据。

延迟预算分成三部分：

• 传播时间：邮件服务接受并投递消息所需的时间。
• 观察时间：worker 查到邮件或收到事件所需的时间。
• 行动时间：agent 处理证据并继续任务所需的时间。

总预算是三部分之和，再留少量余量。作者举的 staging 配置是 90 秒，其中传播 45 秒、观察 30 秒、行动 15 秒；这组数字已用满 90 秒，示例没有单列余量。作者也强调，它只是需要用系统数据修正的假设。

截止时间必须由模型之外的程序执行。

模型可以解释状态，但是否继续等待，应由控制器或队列决定。对应状态包括 waiting、received、invalid、expired 和 failed。到期后再返回含糊的「重试一下」，容易让模型重复已经成功的业务操作。

轮询只负责等，不能负责认领邮件

每 2 秒查一次，90 秒内最多读取 45 次；并行到 100 个 worker，读取压力就会累积。作者建议采用有上限的退避：逐渐拉长间隔，同时让等待受 deadline 约束。

这段代码用单调时钟计算截止时间，并限制每次休眠时长：

deadline = monotonic() + 90
delay = 2

while monotonic() < deadline:
    message = inbox.find(run_id=run_id)
    if message is not None:
        return validate_message(message)

    sleep(min(delay, max(0, deadline - monotonic())))
    delay = min(delay * 2, 10)

raise EmailEvidenceExpired(run_id)

要看的是 sleep(min(...)) 和 delay = min(delay * 2, 10)：前者避免休眠越过剩余预算，后者把退避间隔封顶在 10 秒。不过，这段代码没有给 inbox.find 或 validate_message 展示超时约束，不能据此认定整个操作一定在 90 秒内结束。

查到邮件也不代表邮件可用。验证还需要核对预期发件人、本次执行的收件地址、主题或关联 token，并确认邮件没有被另一轮执行消费。旧执行留下的邮件应当丢弃并记录，否则回滚后的验证可能被旧证据误导。

如果已有 webhook 或队列，可以等待事件，减少反复查询。但事件驱动同样需要 deadline：任务已经过期，迟到邮件不能自动把它重新唤醒。

排查问题时，每次查询应记录 run_id、尝试次数、时间点、累计延迟和丢弃原因。通常保留邮件指纹与最少字段即可，无须把整封邮件写入日志。

重试查询和重新发信，必须分开处理

反复查邮箱通常不会改变业务状态，重新要求应用发信却可能创建重复用户、token 或消息。把两种操作都叫「重试」，是这类流程容易出错的地方。

作者要求发送请求使用幂等键，也就是让同一操作重复提交时仍按同一次处理。这个键应由 run_id 和步骤派生，不能跟着轮询次数变化。worker 重启后恢复同一操作；业务确实需要再发一次时，则创建明确的新步骤，并保留与前一步的关系。

证据判断也应放在服务端。服务确认「这封邮件属于这次执行」，LLM 接收一个小而明确的结果：

{
  "run_id": "run_482",
  "status": "received",
  "evidence_id": "msg_91",
  "action": "continue",
  "observed_at": "2026-11-04T14:20:00Z"
}

这里要看 action：下一步应受允许的动作集合限制。原文没有列出完整动作集合，但明确要求模型不能在 expired 时自行发明后续操作。

上 CI 前，还要确认 worker 有独立邮箱或关联标识，区分投递失败与验证失败，并检查网络重试是否会重复业务动作。作者要求 deadline 同时出现在日志和结构化响应里，不过上面的最小 JSON 示例尚未包含这个字段。

还应专门测试「邮件刚好晚于 deadline 到达」：任务保持过期，迟到事件可以留下诊断元数据，但不能自动恢复工作流。

我的判断

我赞同把邮件验证做成确定的程序协议。邮件属于哪次执行、是否已经消费、任务有没有过期，这些条件都可以由程序核验，交给模型自由判断只会增加排查难度。

不过，文章提供的是架构建议，没有给出上线前后的故障率、吞吐量或成本对照。90 秒预算、2 秒起步和 10 秒退避上限，都不能直接当成通用配置。固定轮询实现简单，webhook 或队列能减少查询，但原文没有证明哪种方案在具体系统里更划算。

预算的覆盖范围也要补全。示例循环从查邮箱开始计时，而前面的总预算还包括传播和行动阶段。实际实现需要说明计时起点，并约束邮箱请求、验证和后续操作，否则只有循环表面上受控。

遇到超时，先区分投递慢、观察慢和邮件无效，再决定是否延长等待。作者建议按「请求被接受、邮件收到、邮件验证、动作完成」分阶段观测延迟，这比直接把 timeout 调大更有诊断价值；具体阈值仍要结合延迟分布和服务目标决定。

能拿来做什么

• 给涉及邮箱验证的浏览器测试建立统一的 run_id，让注册、收件和验证都能关联到同一次执行，并把旧邮件误命中纳入测试。
• 在 Node 编排服务中分开实现发送重试与查询重试，为发送操作设置基于执行和步骤的幂等键，让 worker 重启后能恢复原操作。
• 给 AI 编程产出的验证流程补上明确状态和有限动作，把邮件归属验证放进服务端，并测试过期后到信是否会错误恢复任务。
• 在 CI 日志中记录各阶段延迟、deadline 和丢弃原因，用这些数据调整预算，同时限定证据保留期限，避免保存不必要的邮件内容。