邮箱 Agent 最危险的，不是写不好，而是回错线程

很多团队把 Agent 接入邮箱后，最常见的事故不是“不会写”，而是“回错人”。💥 一封跨部门催办邮件、一串历史抄送、一次主题被改写的转发，都会让 Agent 把本该发在当前线程里的回复，落到另一条相似会话上。

邮箱系统和普通聊天最大的不同，在于上下文不只靠当前页面决定。⚠️ 用户看到的是主题和最新内容，真正决定归属的却常常是 message-id、references 和 thread id。只要 Agent 丢掉这些身份，就会误判线程。

[外链图片转存中…(img-wOU011Gl-1779524352189)]

错发回复，通常卡在三段链路里

第一段是线程归属只看标题。很多实现会把 Re:、项目名和发件人当成主锚点。🔍 但现实里同一周内可能出现多封“发布确认”“账单审批”或“合同修改”，标题几乎一样，真正能区分的是 thread id 与引用链。

第二段是起草与发送没有分离。Agent 看到上下文就直接生成并发送，缺少中间态草稿。⏳ 只要引用错线程，错误就会立刻外发，而不是停留在可复核的草稿区。

第三段是线程状态没有被 claim。即使系统能拿到 thread id，如果没有在动作前登记“本次回复绑定哪条线程、哪封原始邮件、哪组收件人”，页面刷新或切换标签都可能把草稿重新挂到别的会话。🚨 真正缺的不是更会写邮件，而是一份能证明“这份草稿属于这条线程”的 Claim。

[外链图片转存中…(img-se3q3d2S-1779524352204)]

一套更稳的 Thread Claim 与 Draft Commit

更可靠的做法，是把邮箱动作拆成“先锁定线程身份，再提交草稿，再决定发送”三层。✅ Thread Claim 负责证明当前回复属于哪条会话；Draft Commit 负责把正文、收件人与引用头固定成待确认版本；真正发送只发生在 claim 与 draft 都通过校验之后。

from dataclasses import dataclass

@dataclass
class ThreadContext:
    thread_id: str
    message_id: str
    recipients_fingerprint: str


def can_send(claim: ThreadContext, draft: dict) -> bool:
    return (
        draft.get("thread_id") == claim.thread_id
        and draft.get("reply_to") == claim.message_id
        and draft.get("recipients_fingerprint") == claim.recipients_fingerprint
        and draft.get("status") == "committed"
    )

这段逻辑的重点，不是多做一次字符串比较，而是把“写邮件”变成“证明这封邮件发在正确线程里”。🛡️ 只要 thread id、reply-to 和收件人指纹没有同时对齐，Agent 就不该把草稿推进到发送态。即便页面重载，系统也会先恢复 claim，再恢复 draft，而不是直接沿用最像的一条线程。

很多团队还会在发送前做一个极轻量的 Reply Preview：同时展示主题、原邮摘录和收件人差异。📌 这一步能拦住大多数“正文没问题，但线程错了”的事故，成本远低于补发。

[外链图片转存中…(img-HZOaPtKL-1779524352211)]

真正该收紧的，不是文风，而是线程证明

笔者认为，邮箱 Agent 的核心能力不在“回复更像人”，而在“外发更可证”。💡 对邮件系统来说，正文质量当然重要，但更关键的是这封回复是否真的属于当前线程、当前收件人和当前意图。谁先把 Claim、Draft Commit 与发送前校验做成默认设施，谁的邮箱自动化才敢进入高风险协作场景。

未来 3 到 6 个月，这类机制会越来越像代码评审里的 merge gate：不是锦上添花，而是自动外发前的最低门槛。📈 尤其在销售、法务、财务和客户支持场景，系统不会再只问“这段话写得对不对”，而会先问“这封信该发给谁、挂在哪条线程里”。

如果已经在做邮箱自动化，不妨先检查一个问题：当前系统防止错发回复的依据，到底是“主题和发件人看着差不多”，还是“每次发送前都能证明草稿与线程身份一致”。