会话型后台最危险的错误，不是答错而是回错人

客服、工单、企业 IM 这类后台一旦交给 Agent 自动处理，真正高频的事故往往不是模型理解失败，而是 它明明看到了正确问题，却把动作提交到了另一个会话。😵 只要列表会重排、未读会插队、筛选会刷新，上一轮观察到的“第 3 条会话”下一秒就可能变成另一位用户。很多团队把问题归因于视觉识别不稳，实际上更常见的根因是：系统没有证明“当前活跃线程”和“刚才声明要操作的线程”还是同一个对象。⚠️

根因不在点击本身，而在缺少会话所有权证明

很多实现会直接采用“找到包含目标用户名的列表项，然后点击，再发送回复”的两段式流程。表面看不复杂，线上却很脆弱。🧩 因为点击动作只证明“某一刻命中了一个元素”，并不能证明“发送框当前绑定的就是目标线程”。如果列表刷新、DOM 复用或快捷键自动聚焦插入其中，Agent 后续所有输入都可能落到错误会话。🔍

更稳的做法是把一次会话操作拆成三步：先拿到 Conversation Claim，即本轮准备处理的会话身份证明；再拿到 Active Thread Proof，即当前编辑区确实绑定到这条会话的证据；最后在提交前做一次轻量复核。✅ 只有 claim 与 proof 同时成立，动作才允许落地。

一套能落地的护栏：Claim、Proof、Commit Fence

建议 claim 至少包含 4 类字段：会话主键、标题文本、最近一条消息摘要、列表时间戳。🧱 这些字段里，主键负责唯一性，标题和摘要负责抗 DOM 复用，时间戳负责识别列表是否被新事件改写。进入详情区后，再从右侧会话头部或隐藏字段读取 proof，验证当前 thread id、会话标题和最近消息摘要是否仍与 claim 对齐。🛡️

from dataclasses import dataclass

@dataclass
class ConversationClaim:
    conv_id: str
    title: str
    preview: str
    updated_at: str


def can_commit(claim, active_thread):
    same_id = claim.conv_id == active_thread.conv_id
    same_title = claim.title == active_thread.title
    same_preview = claim.preview[:24] == active_thread.preview[:24]
    return same_id and same_title and same_preview

如果 proof 不成立，不要强行继续，而是回到列表重新 claim。很多事故都不是因为系统不会重试，而是因为它把“重试”设计成了“继续操作当前焦点”。🚨 这里必须加一道 Commit Fence：发送、关闭、转派、加标签这类有副作用的动作前，统一先跑 can_commit()。只要不通过，立即阻断。🧯

实战里最值钱的，不是更聪明，而是更会放弃

笔者更认可一种“宁可少做，也别做错”的策略。📌 会话型系统的真实成本，不在单轮处理时延，而在误回复后的补救成本。一次串会话，往往意味着人工追查、用户投诉、审计回放，代价远高于多一次重新定位。对 Agent 来说，学会在 proof 不足时退出，比盲目追求无缝自动化更重要。🤝

未来 3 到 6 个月，越来越多 Agent 平台会把“线程证明”内建成标准能力，而不是留给业务侧临时补丁。📈 尤其是客服、销售、企业协同这类多会话场景，谁先把 claim、proof、commit fence 这三层护栏产品化，谁的自动化才真正有资格走到生产。你所在的系统，现在有能力证明“回复一定发给了对的人”吗？💬