给Agent邮箱测试设定明确边界
文章提出为Agent驱动的邮件验证测试定义契约，明确邮箱归属、轮询时限、证据标准和停止条件。重点防范旧邮件、跨账号链接、重复投递及并行CI共享邮箱造成的假阳性。
AI 深度解读
AI Agent 能走完「注册、收验证码、完成验证」，却未必能证明自己用的是本轮测试的邮件。旧邮件、重复投递、并行任务共用邮箱，都可能让一次错误操作看起来像成功。
作者的主张是：邮件自动化需要一份小型测试契约，把邮箱归属、轮询边界、判断证据和清理责任写清楚。它值得程序员关注的地方，是把「让 Agent 自己等一等」变成了可以检查、可以定位问题的测试流程。
找到邮件，为什么还不能算测试成功
邮件测试表面上只有三步：应用发送邮件，测试提取链接或验证码，再继续业务流程。问题藏在第二步：拿到的邮件究竟属于谁、属于哪一次运行？
作者列出了几类风险：邮件来自上一轮测试；链接属于另一个账号；重试产生两封有效邮件；邮箱服务在投递尚未完成时，只返回部分结果。并行 CI 任务复用临时邮箱时，这些边界尤其容易混在一起。
Agent 即使做出了看似合理的选择，也可能制造假阳性：测试报告通过，实际验证的却不是这次注册。
邮件探测只能证明限定条件下观察到了什么，不能单凭「有邮件」就宣布业务成功。
因此，运行前需要留下最小记录。下面这份契约用来确定邮箱归属和有效时间：
{
"run_id": "signup-1842",
"mailbox": "signup-1842@example.test",
"created_at": "2026-10-31T08:00:00Z",
"expires_at": "2026-10-31T08:05:00Z",
"expected_recipient": "signup-1842@example.test",
"seen_message_ids": []
}
重点看 run_id 和 expected_recipient：前者要进入测试日志，后者要逐封校验。应用若支持在主题或正文中加入关联标记，也应该检查它，进一步确认邮件属于本轮运行。
这里的幂等性（idempotency），可以理解为重复查看同一封邮件，不应导致重复点击、重复提交等副作用。
轮询必须回答：什么时候停止，凭什么继续
作者用状态机描述过程：CREATED -> WAITING -> FOUND -> VERIFIED，并设置 EXPIRED 和 INVALID 出口。FOUND 表示找到候选邮件，VERIFIED 才表示后续验证完成，两者需要分开。
每轮查询只取邮箱创建时间之后的邮件，再排除错误收件人、已见过的消息 ID，以及关联标记不匹配的邮件。符合条件后，先记录消息 ID，再提取链接。
停止条件也要明确：既限制总时间，也限制探测次数。预算耗尽就返回 EXPIRED 和证据，不能因为下一轮「可能成功」而继续等待。
下面的伪代码展示了如何筛选邮件，并在截止时间后退出：
deadline = clock.now() + timeout
seen = set()
while clock.now() < deadline:
messages = inbox.list(after=mailbox.created_at)
for message in messages:
if message.id in seen:
continue
seen.add(message.id)
if message.recipient != mailbox.expected_recipient:
continue
if not matches_correlation(message, run_id):
continue
return Evidence(status="found", message_id=message.id)
sleep(backoff.next())
return Evidence(status="expired", attempts=len(seen))
要注意最后一行：attempts=len(seen) 统计的是见过的不同消息数量，并非轮询次数。代码也没有落实独立的次数上限，因此它只能帮助理解流程，不能直接当成完整实现。
探测函数只观察，不点击链接、不修改应用状态。后续执行组件拿到证据再行动，才能解释清楚：究竟是哪封邮件允许流程继续。
日志和清理，也属于测试契约
作者给出的成功证据包括 status: "found"、message_id: "msg-901"、收件人、received_at: "2026-10-31T08:01:14Z"、age_seconds: 14 和 correlation_match: true。
这些字段比一句「email found」有用得多。排查时可以核对邮箱、消息 ID 和匹配结果，判断是投递问题、串号，还是筛选条件有误。
但 age_seconds 的计算基准没有说清。它可能表示查询时邮件已到达多久，不能直接当成从创建邮箱到收信的耗时；示例中的创建时间与收信时间相差 74 秒。
普通日志也不应保存含令牌或个人信息的完整邮件。作者建议记录脱敏片段或内容哈希，保留诊断依据，同时避免把验证凭证写进 Agent 对话记录。
清理同样要预先约定：进入 VERIFIED、INVALID 或 EXPIRED 后关闭邮箱，CI 再通过 finally 保证异常路径也执行清理。
如果服务商无法保证邮箱唯一，还要增加应用层租约（lease）：把邮箱与运行 ID 绑定，拒绝占用已经生效的租约，并允许重复释放。否则，一次断言失败留下的邮箱，可能继续干扰后面的任务。
原文提到的搜索错拼词 tamp mail com、tepm mail com，只与支持流量有关，不应成为测试标识或匹配规则。
我的判断
我认同这套思路。它把 Agent 容易猜错的环节变成程序规则，也延续了常规自动化测试中的隔离、超时、幂等和结构化日志做法。
不过，这是一份设计建议。作者没有提供失败率、并发规模或改造前后的对照数据，不能据此断言它能降低多少不稳定测试。
实现细节也有缺口：伪代码中的 seen 是局部变量，没有展示如何与契约里的 seen_message_ids 同步；INVALID 如何触发、租约如何在并发下安全获取，也没有展开。
与测试直接截获应用发信内容相比，真实邮箱探测能覆盖更多投递链路，但也会引入服务商延迟等变量。原文没有比较两者。团队应先确定要验证的是邮件内容与业务流程，还是实际送达，再决定探测范围。
能拿来做什么
- 给现有注册或免密登录测试补一份运行记录，让 Node 测试代码逐封检查收件人、时间和关联标记，减少 Agent 自行猜测的空间。
- 把收信探测与浏览器点击拆开，先返回结构化证据，再执行链接跳转，并单独断言应用是否完成验证。
- 为轮询分别设置总时限和次数上限，独立记录轮询次数与消息数量，避免照搬
attempts=len(seen)后误读结果。 - 在并行 CI 中明确邮箱分配与释放责任，通过
finally执行可重复清理；无法保证独占时，再补应用层租约。