邮件 Agent 真正容易翻车的，不是写不出回复，而是回错线程

很多团队把邮件 Agent 的注意力放在总结历史、生成措辞、补全附件上，结果真正上线后，最常见的事故却是另一类：模型明明理解了问题，却把回复发进了错误线程，或者沿用了上一次没发出的草稿。📨 这类事故不一定来自生成能力不足，而是执行面缺少“当前线程证明”。

更麻烦的是，邮箱线程天然会折叠转发、抄送、自动提醒和系统通知。Agent 如果只看当前页面可见主题，很容易把“同主题不同上下文”的邮件当成同一个会话。⚠️ 一旦自动发送打开，错误就从答偏升级成外部事故。

[外链图片转存中…(img-wK1dWt2X-1779416003411)]

症状往往出在三个位置

第一处是线程认领太弱。很多实现只用主题行或最新一封邮件时间做匹配，遇到“Re: 周报”“Re: 合同确认”这种高复用主题时，命中率看起来很高，误回复率也会一起升高。🔍 真正该认领的是 thread_id、last_message_id、参与人集合和最近未读片段。

第二处是草稿提交没有二次校验。Agent 可能在第 1 分钟生成草稿，第 3 分钟用户又切换了线程，第 5 分钟自动发送器还拿着旧上下文提交。🧷 如果没有 Draft Commit，系统根本不知道这份草稿是否仍属于当前线程。

第三处是收件人漂移。企业邮箱里常见“Reply all”“外部客户 + 内部抄送”“工单机器人回执”混在同一线程，模型即使正文写对，也可能把内部讨论发给外部客户。🚨 这类错误通常比内容瑕疵更致命。

[外链图片转存中…(img-zlWzIYS5-1779416003420)]

一套能落地的 Thread Claim 与 Draft Commit

工程上更稳的做法，是把“能不能发”拆成两个阶段：先认领线程，再提交草稿。✅ Thread Claim 负责给当前操作绑定不可混淆的上下文证明；Draft Commit 负责在发送前重放一次关键校验。

from dataclasses import dataclass
from hashlib import sha256

@dataclass
class ThreadClaim:
    thread_id: str
    last_message_id: str
    recipients_hash: str
    draft_token: str


def build_claim(thread_id, last_message_id, recipients):
    recipients_key = '|'.join(sorted(recipients))
    draft_token = sha256(f"{thread_id}:{last_message_id}:{recipients_key}".encode()).hexdigest()
    return ThreadClaim(thread_id, last_message_id, sha256(recipients_key.encode()).hexdigest(), draft_token)


def can_commit(active_claim, draft_claim, current_last_message_id):
    return (
        active_claim.thread_id == draft_claim.thread_id
        and active_claim.recipients_hash == draft_claim.recipients_hash
        and draft_claim.last_message_id == current_last_message_id
        and active_claim.draft_token == draft_claim.draft_token
    )

这段逻辑的关键不是加密，而是让草稿天然带上“它属于谁”的证明。🛡️ 只要线程末尾新增了一封邮件、收件人列表变化，或者用户切走了当前上下文，can_commit() 就会失败，系统直接拒绝发送。

再往前一步，很多团队会在发送前增加一个极轻量的 Action Preview：展示目标线程摘要、最终收件人、附件清单和最后一封消息时间。📌 这一步并不重，但能把“模型写得对、系统发错人”的事故拦在最后一道门外。

真正该优化的不是回复文案，而是提交边界

笔者认为，邮箱 Agent 下一阶段的竞争力不在“写得更像人”，而在“副作用更可证”。💡 对邮件场景来说，线程边界、收件人边界和草稿边界，比单次回复语气更重要。只要提交边界没收紧，再好的模型也会在错误上下文里稳定犯错。

未来 3 到 6 个月，这类能力会越来越像支付系统里的幂等键：不是锦上添花，而是自动化能否放开权限的前提。📈 谁先把 Thread Claim、Draft Commit 和发送前证明做成默认设施，谁的邮箱 Agent 才更可能真正进入生产主链路。

如果已经在做邮件自动化，不妨先检查一个问题：当前系统拒绝错发的依据，到底是模型“觉得像”，还是流程“能够证明”。🤝