发送请求超时，只说明调用方没及时拿到结果。邮件服务是否接收了请求，还需要另查。让跟单Agent此时换一种措辞再发，买家可能收到两封近似邮件，而且无法确定后发的内容是不是一项更正。
Meta在10月12日介绍Muse Wonder时，称Active Focus可帮助模型在遇到困难时继续工作、尝试其他方法并从错误中恢复。这是能力描述，不是外部邮箱的去重承诺。让Agent接入跟单流程时，恢复动作仍要依据发送系统的真实状态，而不能只依据对话里的失败提示。
结果未知，需要第三种状态
明确发送成功、明确拒绝发送和没有拿到结果，应分别处理。接口在接收请求前拒绝，与邮件服务已接收、但回复途中断开，是两种情形。超时本身没有告诉调用方属于哪一种，立即重发就把不确定性变成了重复触达风险。
在跟单记录中保留“结果待核”，比只允许成功或失败更实用。销售看到这个状态时，应先查询已发送记录或服务提供的任务查询结果，而不是手工补一封。查询不到也未必立刻证明没发送；若服务记录有延迟，需要按该服务的实际说明等待，不能由Agent随意猜一个等待时间。
发送端接受请求也不等于买家已经收到、阅读或理解邮件。去重解决的是同一动作是否被重复执行，不能据此更新客户阶段为“已沟通”。退信、收件人变化和后续回复仍是各自的事实。
给一次跟进一个不会随重试改变的标识
发送权限回答“能不能发”，结果核对回答“是否已经发过”，两者都要成立。在调用外部服务之前，先为本次跟进建立稳定任务标识，关联收件人、内容版本和业务对象。如果服务支持幂等键，用同一键重试同一动作；如果不支持，团队自己的记录仍可帮助查询和阻止无依据的再次发送，但不能宣称它自动消除了全部竞争条件。
不要把正文哈希当成唯一去重依据。Agent重试时可能换了开场或调整标点，内容哈希变了，业务上仍是同一次跟进。相反，同一份产品介绍发给不同买家，也不应被全局当成重复。判断单位需要包含具体对象和跟进目的，而不是只看文字是否一样。
同一买家由人工和Agent同时处理时，还要让二者看到同一待发状态。系统可以在执行前占用这项任务，完成后保存外部消息标识；人工若接手，要先看到已有记录。只有一张待办表，却没有谁正在执行的状态，仍可能让两个发送者同时出手。
查清上一封，再决定下一步
对于能明确查询到已发送消息的情形，恢复应继续到记录结果，不再执行发送。对于确认未接受请求、且仍在允许范围内的情形，可以按服务规则重试。找不到可靠状态时，交给指定人员核对，尤其涉及报价版本、附件或交期表述，不应靠不断改写来尝试“完成”。
若已发生重复，不要自动再发一封解释邮件。先核对两封内容是否一致，是否有需要买家澄清的差别，再由负责销售决定如何联系。无意义的道歉触达可能只增加第三封干扰。
参考来源
Meta Newsroom，Introducing Muse Wonder and Muse Wonder Full: Frontier Models for Agents，2026年10月12日。本文的发送去重设计为针对外部动作的工程分析，并非Meta产品实现说明。