「我批准了」这句话，正在失去含义
智能体要执行敏感操作，产品设计的通行答案是人机协同审批：动作执行前弹出确认框，人点一下批准，风险就此兜住。这个设计被当作最后一道防线写进了几乎所有主流 Agent 框架。arXiv 2609.21081 号论文的 Loopjacking 研究给这道防线做了次系统性体检，结论是：防线本身没问题，问题在于防线成立有一个几乎没人检查的前提——审批时人看到的那件事，和之后实际执行的那件事，必须是同一件。一旦这个前提被打破，「我批准了」就变成了一句空话。
论文把攻击面拆成两类变体。变体一是展示层歪曲（representation-based）：真正要执行的危险操作在编码时就被藏起来了，审批界面展示的 A 是省略或歪曲后的版本，人看到「删除临时缓存」，实际批准的可能是清空生产数据表。变体二更隐蔽：审批后状态替换（post-approval state-substitution）——人确实看到了正确的操作 A 并批准，但工作流状态是可变的，审批凭证存进系统后，状态在中途被换成操作 B，审批时所见与之后释放的已经对不上。
复现矩阵：框架之间的防御成色差别很大
论文的实证部分做得很扎实：审批后状态替换在 7 个 Agno AgentOS 版本、12 个 LangGraph Agent Server 组合里成功复现；OpenClaw 在 2026.2.23 版本可复现展示层歪曲，2.24 版本已能拒绝表示不匹配的请求——修复速度本身就是一个有价值的信号。更有参考意义的是负对照：OpenAI Agents SDK 0.22.x 没有被攻破，原因是它的序列化续接机制保留了逐调用绑定，被篡改的操作 B 无法冒用 A 的审批。同一道防线，绑定粒度不同，防御结果完全不同。
危害场景不难想象：智能体获得了删除数据库、转账、群发邮件这类高权限操作的执行链，审批环节被劫持后，人以为自己在批准一件无害的小事。随着智能体在更多生产流程里拿到执行权，这类攻击面的价值会持续上升——它攻击的不是模型，而是人对流程的信任本身。
值得再深一层的是责任划分问题。两类变体里，展示层歪曲的锅更难分：审批界面上的操作描述由谁生成——框架、编排层还是上层产品——决定了防御该在哪一层做。如果框架只提供「这个操作等待审批」的原始事件，展示文案由产品层拼装，那么产品层任何一次文案改动都可能无意间制造歪曲；反过来，框架直接负责渲染，又很难覆盖千差万别的产品形态。OpenClaw 两周内修复的经验说明，把「审批凭证与展示内容做一致性校验」做成框架的强制项，是比各自打补丁更省力的路线。
工程团队的防御清单
从论文的复现与负对照里，可以提炼出三条可落地的防御原则。其一，审批要绑定操作实例而非意图描述：把操作的函数名、参数哈希一起写进审批凭证，凭证明细与实际调用逐项比对，OpenAI SDK 的表现说明这条路走得通。其二，执行前重放校验：在真正执行前，把审批时的快照与当前工作流状态逐项核对，状态有变就重新审批——这直接封死审批后状态替换的路。其三，审批通过后冻结可变状态：从批准到执行之间的窗口期里，工作流上下文不允许被其他分支修改，同时全程留审计日志，任何状态变更都可回溯。
辩证地看，这是一篇负结果导向的安全研究，价值在于把「审批」从一个被默认可信的 UI 动作，还原成一个需要工程保障的协议问题。各框架的修复节奏不一，论文披露时部分问题可能已被上游修补；企业团队与其等待框架更新，不如先按上述清单自查自家的审批链路。论文未披露受影响框架的完整名单与全部细节，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。