消息通知中心最难的不是找到按钮而是列表一直在变。Agent 刚把一条告警标成已读未读分组就重排刚点进一条审批提醒顶部又插进一条高优先级消息。 这时模型看到的还是“第二行”系统里的对象却已经不是刚才那条批量操作就很容易从提效变成误处理。图 1通知中心的列表位置稳定目标对象却不稳定很多团队会先补一个“点击前再识别一次文案”的小修但它挡不住实时刷新。⚠️ 消息中心的风险不在识别能力而在动作和目标没有被绑定进入详情、标记已读、批量忽略本质上都是对同一批消息对象做提交只要列表顺序和过滤条件在动作间发生漂移后续操作就会落到别的对象上。问题不是点击错而是批次没有被声明做通知自动化时页面通常同时存在三种漂移一是新消息插队二是已读后列表重排三是筛选条件被别的动作联动刷新。 如果 Agent 还按“看见什么点什么”的方式工作它处理的其实不是消息而是一个不断漂移的视口。图 2实时刷新会让视觉位置和真实目标脱钩更稳的做法是先做Batch Claim先把“本轮要处理的通知集合”提取成稳定对象再进入动作阶段。✅ 这一步至少要记录通知 ID、标题摘要、来源模块、时间戳与当前筛选条件。这样后面哪怕列表重排执行器也知道自己处理的是哪一批而不是哪几行。用 Target Proof 把每一步提交回证到对象真正决定稳定性的是每次动作后都回证目标对象仍然一致。下面这段约束比“多看一眼页面”更有用claimedclaim_notifications(limit5,filters{unread:True})foriteminclaimed:open_detail(item.id)proofcollect_target_proof()assertproof[id]item.idassertproof[title]item.title mark_read(item.id)assertis_processed(item.id,stateread)它把处理流程拆成两段先声明处理集合再验证当前动作仍落在声明对象上。 只要详情页 ID、标题摘要、来源模块三项里有一项对不上就不提交 destructive action而是退回列表重新定位。图 3通知处理应该像工单认领而不是像人在列表里顺手点选方案处理对象页面刷新后结果风险逐行点选第 N 行容易变成别的消息高文案二次识别近似文案易撞同类通知中Batch Claim Target Proof稳定消息 ID可回证同一对象低实战里最该守住的三个约束第一批量按钮必须晚于对象回证。️ 先证明“当前选中的 5 条消息就是 claim 的 5 条”再执行批量已读或批量归档。第二任何会触发重排的动作后都要重新拉取 proof而不是沿用旧快照。第三列表页和详情页要共享同一套对象键至少能稳定映射到消息 ID 或业务单号。笔者认为消息通知中心是 Agent 最容易被低估的一类页面因为它看起来比表单简单却同时具备流式刷新、批量提交和对象跳转三种副作用。 如果没有 Batch Claim团队会把误处理归因到模型不够聪明实际上更常见的问题是系统没给执行器一个稳定的目标声明层。接下来 3 到 6 个月通知类自动化会越来越依赖“先认领、再提交”的对象协议而不是继续堆视觉识别。 能把消息对象、筛选上下文和提交结果都做成可回放证据链的团队才更可能把 Agent 从演示脚本推进到真实值班与协同流。你们现在的通知中心是按位置在点还是按对象在提交
