很多团队把 Agent 接进操作后台后,第一反应是把日志打全。可事故复盘里最常见的问题不是没日志,而是 Agent 把看过的证据和做过的动作混成一件事。它读到一条旧的“已禁用账号”记录,就以为这次工单也完成了禁用;或者看到旁路成功提醒,就把提交动作跳过去。⚠️ 审计一多,更容易制造“做过了”的错觉。这类问题不是权限越界,而是证据归属漂移。同一个页面里同时存在历史操作、提醒、草稿状态和最终结果,模型如果没有明确的证据窗口,就会把任何像结果的文本都拿来当提交依据。📌 审计真正缺的不是记录密度,而是“哪条记录能证明这次动作真的发生过”。
pythonfrom dataclasses import dataclassfrom typing import Iterable@dataclassclass AuditEvent: seq: int target_id: str action: str status: str receipt_id: str | Nonedef build_action_proof(submit_seq: int, target_id: str, action: str, events: Iterable[AuditEvent]): window = [e for e in events if e.seq >= submit_seq] for event in window: if event.target_id == target_id and event.action == action and event.receipt_id: return { "target_id": event.target_id, "action": event.action, "status": event.status, "receipt_id": event.receipt_id, } raise ValueError("missing action proof inside evidence window")| 方案 | 能看到历史记录 | 能证明本轮动作 | 误把旧结果当新结果的风险 ||------|----------------|----------------|--------------------------|| 只堆审计日志 | 高 | 低 | 高 || 仅做对象匹配 | 中 | 中 | 仍然偏高 || Evidence Window + Action Proof | 高 | 高 | 低 |这套约束并不复杂,却直接改变了协作方式。以前人工复盘常问“它明明看到了,为什么还会做错”;加上这两层后,问题会变成“它这次拿到的 proof 是什么”。前者是在猜模型,后者是在验动作。📉 一旦讨论对象从“感觉像完成”变成“有没有 proof”,误操作链路就更易被提前拦住。