DeepMind最新论文提出智能委托框架,但止步于监督与权限管理,忽略了执行前的授权判定。本文剖析其缺失的三大构件——授权证据、运行时边界、失败闭合规则,揭示AI治理从协调走向强制所需的关键工程。
2026年2月,Google DeepMind 的研究团队发表了《Intelligent AI Delegation》(论文编号 arXiv:2602.11865),试图构建AI代理之间以及AI与人类之间的委托框架。这篇论文的价值在于,它把委托定义为权力、责任与问责的转移,附带明确的角色、边界和信任机制,而不是简单的任务路由。这个起点是对的,但问题在于:框架止步的地方,恰恰是工程难题开始的地方。

论文在监督机制上花了不少笔墨:结果级和过程级目标、直接与间接可观测性、黑盒与白盒透明度、隐私保护选项、跨委托链传递证明……这些是很有用的地图,但本质上都是事后观察。
论文还提出了“可验证任务完成”机制——把临时输出变成事实:付款释放、信誉更新、责任绑定、争议解决。这套机制回答的是“委托工作是否按规格完成”,但受监管的系统需要先回答另一个问题:这个产生效果的动作在执行之前就被授权了吗?事后能独立重建这个判定结果吗?
论文最接近边界的部分是权限处理:高风险场景需要风险自适应、即时发放的权限,严格限定任务范围,必要时加入人或第三方的审批。它还讨论了递归委托链的权限衰减、操作语义约束、自动撤销、算法熔断和策略即代码。
这些都是认真的权限控制,但依然不是授权。权限管理回答的是“谁可以持有哪些凭证”,而授权回答的是“这个具体动作在当前上下文中是否被允许执行”,并且给出一个判定结果。一个持有完美限定权限的代理,仍然可以在其权限范围内提议一个有害动作。论文自己举的不可逆副作用例子——金融交易和删除数据库——正好说明了这种风险。
论文中几个最有意思的段落,都在陈述框架自身没有机制化的要求:
每个要求都对,但都留下同一个问题:用什么构件满足这个要求?当这个构件无法产生时会发生什么?
框架缺少了三样东西,而这三样正是把委托治理从“协调”变成“强制”的关键。
第一,授权证据(authorization artifact):一个在执行之前,由决策程序(输入策略、上下文、提议动作规格)产生的判定结果。其形式必须足够让独立第三方在不访问提议系统内部状态的情况下重建这个判定。没有这个对象,委托或许可以被协调、被监控、被结算,但没有任何记录能证明某个产生效果的动作在执行前就被允许了。
第二,运行时授权边界:介于提议动作和执行之间的强制点。在这里产生授权证据,并且只有获得证据才允许释放动作。论文对现有协议的调研直接暴露了缺失:现有AI代理协议需要添加字段或流来携带委托专用的验证、监控、竞价、权限衰减语义。论文提出的扩展本身就是证据,证明原生协议语义仍然没有完整承载授权对象。
第三,失败规则:一个声称具有执行前授权的系统,需要闭合的判定语义——每个产生效果的提议动作都解析为ALLOW、DENY或ABSTAIN。ABSTAIN阻止执行,等待人类授权覆盖,上报是ABSTAIN的后果,而不是第四个判定。任何不确定状态(策略引擎不可用、上下文过期、证据不可产生)都解析为阻止结果。论文考虑了人类监督、分级审批、熔断、撤销,但从未承诺“非授权即不执行”这个规则。
这个区别并非FERZ的工作首创。FERZ之前的出版物《基于可观测性的授权之不可能性》和《五项测试标准》已经论证:对AI产生效果的治理不能靠监控、日志或完成审查来满足。控制必须在执行之前、在释放点上存在,并且必须产生一个授权证据,从该证据可以独立重建判定结果。委托只是让这个要求更明显,但并没有改变它的结构。
这篇论文的价值在于把委托问题摆到了明处。它的局限在于留下了一个未指定的执行对象。这个缺口很重要——受监管的系统不仅需要知道谁委托了任务、任务是否后来完成了,还需要知道具体的产生效果的动作在执行前是否被授权。
论文中最有用的观点是把委托当作权力转移而不是任务路由。剩下的工程问题很具体:什么构件在释放前授权一个产生效果的动作?当这个构件无法产生时怎么办?在受监管系统中,可观测性和完成验证无法填补这个缺口。控制必须放在运行时授权边界上,并且失败时必须闭合。
当授权成为委托基础设施的原生部分——当协议携带意图、报价、合同和结算的同时也携带判定结果,并且当判定结果的缺失,通过架构而非策略期望,意味着执行不发生时——委托基础设施才能真正被治理。像本文这样的框架正在越来越精确地绘制地图,但边界仍然需要被建造。
参考文献
免费获取企业 AI 成熟度诊断报告,发现转型机会
关注公众号

扫码关注,获取最新 AI 资讯
3 步完成企业诊断,获取专属转型建议
已有 200+ 企业完成诊断