Summary

  • AACP 草案要求确认服务在大模型推理流程之外展示所有标记为必须确认的操作参数，提供明确的同意和拒绝按钮，并为用户的决定签名。
  • 执行端须把签名证据与眼前的实际操作、目标代理、有效期及一次性挑战逐项核对；用户明确拒绝与联系不上用户会产生不同结果。

“用户已经点头。”代理能把这句话说得毫无破绽，却说不清屏幕上究竟写了多少钱、发给谁、删掉哪条记录。11 月 2 日发布的《Agent Action Confirmation Protocol》草案把证据放在执行前的最后一道门。准备动手的代理先写出结构化操作说明；确认服务向用户展示被标记的字段，收下同意或拒绝，再签发确认记录。它可以装在用户客户端、企业授权系统或专门的确认应用中。关键是确认界面由程序驱动，用户决定不经过大模型猜测。

草案对屏幕上那几行字格外较真。需要人工确认的参数标上 confirm=true，并带有人能读懂的名称。确认服务必须把这些参数全部显示出来，才摆出同意和拒绝控件；字段名和值只能当作数据，不能在界面中执行嵌入的链接或指令。代理可以建议一次转账，不能靠一句“已获批准”把金额、收款对象或操作效果从人眼前抹掉。

点击之后，签名来自实际展示并收集决定的确认服务。执行 API 或代理的执行控制点会根据即将实施的操作重新计算摘要，与签名证据比对，再检查确认服务的密钥、证据面向的代理、一次性挑战、有效期以及是否重放。签给一个执行者的同意不能被另一个执行者拿去用。对难以撤销的操作，草案还建议核对展示摘要：用户到底看到了哪些必须确认的字段。这一步把“有人按过按钮”和“有人看见完整条件后按按钮”分开。

拒绝也被当成事实，而不是待重试的网络故障。denied 是带签名的用户拒绝，下一次尝试只能由用户发起；unobtainable 表示确认无法取得，作为未签名状态报告。过期、重复使用、对象不符、操作参数不符或密钥无法核验，各有单独的结果。任何一个环节失败，执行端都不能挑着合格字段先放行。付款和档案系统若把沉默当成拒绝，或把拒绝当成连接不畅，后续动作会完全不同。

IETF Datatracker把这份 11 月 2 日文本列为个人提交的草案。下一项真正有分量的证据，是两个独立实现能否在金额被替换、必看字段被藏起、旧签名被重放时一致地拒绝执行。协议把门画了出来；实现才会证明门锁是否咬得住。