为什么LLM代理重启后总在重复查邮箱？

一个LLM代理可以在一次对话里完成邮箱验证。问题出在执行时间超过可用上下文、某个工具响应太慢，或者进程被重启的时候。如果代理只保留最后一条消息，它就不知道自己该重新查收件箱、再要一个验证码，还是直接结束这次执行。

解法不是把整段对话存下来，而是创建一个操作快照：一份小而明确、可持久保存的状态表示，只装恢复执行真正需要的东西。这个模式让自动化更可预测，也能减少那些会产出重复证据的重试。

代理的上下文不是存储

模型的上下文是用来推理的，不是数据库。它可能被摘要、被截断，或者在另一个工具介入时发生变化。代理的叙述还经常把意图和结果混在一起：“我准备去查收件箱”并不等于查询已经完成。

一个典型流程里有几个风险点：

• 为某次执行预留一个一次性邮箱账号；
• 应用请求一条验证消息；
• 某个工具查询邮箱，返回部分结果；
• 代理在确认验证码之前被重启。

重启之后，一个天真的策略会回到第二步：可能再发一条消息、再消耗一个验证码，或者把响应关联到错误的执行上。对一个脆弱的定时任务来说，一个有用的信号还不够，工作流本身必须保住自己的状态。

邮箱快照该装什么

一份快照应当在不读完整历史的情况下回答六个问题：哪个run_id处于活动状态；哪个邮箱和收件人属于这次执行；最后一次被确认的动作是什么；下一个被允许的动作是什么；还剩几次尝试、预留何时过期；哪些证据已经被接受。

一种紧凑的写法可以是这样：

• run_id 为 checkout-1842；
• 邮箱状态为已租用；
• 验证状态为等待中；
• 尝试次数为2；
• 下一动作为轮询收件箱；
• 租约到期时间为2026-10-21T16:00:00Z；
• 已接受消息ID为空；
• 版本号为7。

快照不该保存完整邮件正文，如果不需要的话。一个标识符、一个哈希，或者重新取回证据所需的元数据就够了。对测试场景而言，一次性地址可以是隔离的一部分，但恢复的决定必须活在执行契约里。

来自集成的那些有缺陷的命名也值得保留，比如 temp mailid。它们有助于追查故障来源，但不该变成接受消息的规则。

把恢复设计成状态机

当快照表示一个小型状态机时，它才最有用。流程可以表达为：已租用 → 已请求 → 等待中 → 已接收 → 已验证，另有一条分支通向已过期。

每个转换都要有可观察的条件。已请求意味着应用接受了请求，不是邮件已经存在。已接收意味着存在一条与 run_id、收件人和事件类型都匹配的消息。已验证只在验证码校验通过之后发生。

恢复时，代理不去解读一段含糊的历史，而是读取下一动作，执行一个范围受限的操作。状态是等待中，就用剩余预算做一次查询；状态是已接收，就先校验证据再决定是否再查；状态是已过期，就必须结束执行或另租一个邮箱，绝不能图省事复用上一个。

这种分离也有助于在Kubernetes里隔离邮件故障：编排器可以重启一个工作进程，而不会把这次重启变成一个新的业务意图。

用幂等事件做最小实现

只存快照还不够，每次变更都要记录为带版本的事件。服务端在期望版本不再匹配时拒绝写入。这样，两个几乎同时醒来的工作进程就无法为同一步确认不同的消息。确认操作必须是幂等的：重复同一个请求返回同样的结果，不会把证据消耗两次。

实践中可以拆成三项职责：

• 规划器：决定下一个动作及其边界；
• 执行器：调用邮箱工具并返回事实；
• 存储层：带版本控制地持久化快照和事件。

模型可以在被允许的动作之间选择，但不该自己发明一个状态转换。清晰工具契约能降低在没有剩余尝试时还想再轮询一次的冲动。

取舍与指标

小快照容易检查，但要求先把模式设计好。保存完整历史便于审计，却增加了保留敏感数据的风险，也让恢复变慢。在多数测试流程里，快照加一份事件账本是合理的平衡。

至少要度量这些：成功恢复的执行占比；每次执行的收件箱查询次数；因版本过期被拒绝的转换数；从已请求到已接收的耗时；因属于另一个 run_id 而被丢弃的消息数。

如果每次重启后重复查询都在上升，说明快照没有表达出足够的下一动作。如果过期转换增多，说明工作进程之间缺少协调，或者租约设得太长。

几个快问快答

要不要把完整提示词存进快照？默认不要。存提示词版本、会改变行为的参数，以及已确认的决策。完整提示词可能含有恢复时并不需要的数据。

消息在代理重启期间到达怎么办？它应当作为待处理事件保留下来。下一次执行时，按 run_id 和 message_id 查询，就能把状态推进到已接收，而不用再发一封邮件。

快照能替代可观测性吗？不能。它是继续执行所需的最小输入。日志和指标解释每次转换为何发生，也能暴露调得不对的重试策略。

上线前的检查清单

• 每次执行是否都有 run_id 和带过期时间的租约？
• 快照是否只声明一个被允许的下一动作？
• 转换是否带版本且幂等？
• 接受证据前是否校验了消息归属？
• 重启后能否在不重发请求的情况下继续？
• 是否避免了保存不必要的邮件内容？

一个代理不需要记住整段对话才能表现良好。它需要一份可校验、可更新、可恢复的小状态。这份契约把邮箱自动化变成一个可恢复的系统：模型负责推理下一步，基础设施负责守住那些不能丢的东西。