Agent 部署时「人工审批」按钮只是仪式

An AI agent 准备了一次生产部署。

它改了十二个文件，运行了若干检查，并生成了一份自信满满的总结。界面上现在显示一个绿色按钮：

Human approval required

操作员点击了 Approve。

这看起来像是人类仍然在掌控之中。但这次点击实际上意味着什么？

操作员是否看到了确切的补丁？所有必需的检查是否都执行了？Agent 是否披露了它无法测量的事项？部署在点击之前是否仍被阻止？操作员是否可以拒绝或收窄操作？事后是否有人能够证明是哪个人在什么权限下批准了哪个版本？

如果这些问题没有可靠答案，那个按钮就不是控制边界。它是一场仪式。

随着 AI Agent 从生成文本转向修改代码、发送消息、购买服务、操作业务系统，这个区别变得至关重要：

按钮是界面。Authority（授权）是系统的属性。

Human oversight（人类监督）的复选框版本

许多 Agent 产品在关键操作附近增加了人类审批步骤。这通常是有用的，但设计可能流于表面。

这种弱模式的结构如下：

Agent 选择操作并构建自己的解释；

系统呈现一份压缩后的摘要；

一个人点击 approve 或 reject；

应用程序存储一条普通的事件日志；

人在场，但仅凭在场并不能建立控制。

审批可能捆绑在不相干的操作中。摘要可能遗漏不确定性。审批人可能不是承担风险的授权方。操作可能已经开始了。审计日志可能由生成它的同一系统编辑。审批可能没有绑定到实际执行的具体请求。

这产生了一种危险的模糊性：组织可以说人类批准了操作，而人类无法证明他们被要求批准的是什么。

Human authority（人类授权）需要五个属性

只有当系统保留以下五个属性时，Human control（人类控制）才能变为可运行的。

"人类"不是一个角色。

系统应该识别谁有权授权一个能力，谁可以执行工作，谁验证证据，谁接受结果。这些可以是不同的人或系统。

这很重要，因为构建 Agent 的开发者不应自动成为接受其交付的客户。同样，Agent 不应仅仅因为三个步骤都可以自动化就被允许执行、验证和接受自己的工作。

NIST 的 AI Risk Management Framework 要求组织为人类和 AI 配置定义和区分角色与职责。这种区分不是文书工作。它决定了当风险真实存在时，谁的决定是有效的。

2. 执行前的决策

在不可逆操作之后到来的审批是解释，不是授权。

控制必须在受保护操作开始前被评估。如果一个操作保留给人类判断，处理程序在所需决策存在之前应收到零次调用。

这听起来显而易见，但异步队列、重试、缓存权限和竞态条件可能悄悄地把"执行前审批"变成"执行附近审批"。

真正的边界必须能承受并发。如果一个人在 Agent 准备操作时撤销了权限，系统不能使用更早的授权检查来穿越新关闭的边界。

3. 足够做出有意义决策的证据

审批屏幕不应仅仅显示 Agent 声称发生的事。它应该揭示：请求了什么，观察到了什么，哪些检查运行了，哪些检查没有运行，以及什么仍不确定。

这与本系列前一篇文章直接相关：一份签收单仍然可能描述了错误的测量。如果"未测量"被显示为"没有问题"，人类就无法行使有意义的判断。

人需要一个证据面，而不是一个置信度面。

4. 可执行的拒绝、收窄或停止能力

Human authority 不是观看自动化系统的权利。它是改变接下来发生的事的能力。

根据上下文，这可能包括：

拒绝提议的操作；

将一类决策保留给人类审查；

收窄 Agent 可使用的工具或范围；

撤销一个活跃的委托；

用更严格的委托替换它；

安全地中断执行；

即使技术验证通过也拒绝最终接受。

EU AI Act 第 14 条用类似的操作性术语描述了高风险系统的人类监督。它包括理解系统局限性、保持对自动化偏差的意识、忽略或推翻输出、干预以及停止系统。本文不是法律分析，协议实现也不构成合规。有用的设计教训是：监督必须影响系统行为。

5. 可被独立检查的记录

当争议发生时，审批页面的截图是弱证据。

更强的记录将决策绑定到确切的工作令、请求、证据、执行者、权限和时间。另一方应该能够在不信任执行工作的 Agent 或显示按钮的平台的情况下验证该记录。

这在跨组织场景中尤为重要。客户、承包商、市场平台、保险公司或审计员可能不使用同一数据库或不信任同一运营方。

一个实际例子：一个准备部署的 Agent

考虑一个被分配修复生产缺陷的 Agent。

工作令允许四个操作：

部署已批准的版本。

技术能力授权也包括这四个操作。传统权限系统可能得出结论：Agent 可以执行所有这些操作。

但负责任的人可能希望更窄的安排：

仓库读取和测试可以自主运行；

应用补丁需要审查；

生产部署始终保留为人类决策。

这意味着有效权限不应等于可用的最广泛能力。它应该等于三层边界的交集：

WorkOrder permission
AND CapabilityGrant delegation
AND the active human authority profile

如果任何一层拒绝操作，操作就不执行。

这个模型避免了两个常见错误。

第一个是将一次审批视为对所有后续操作的永久同意。第二个是强迫一个人审批每一个无害的步骤，这会产生告警疲劳并将监督变成习惯性点击。

良好的人类控制是有选择性的。它给予 Agent 在定义边界内运作的空间，并在关键转换处保留人类判断。

为什么更多的审批提示可能造成更少的控制

对 Agent 风险的明显回应是添加更多提示。但一个请求审批过于频繁的系统会训练人们不经阅读就批准。

问题不仅仅是人类交互的数量。而是每次交互是否携带真正的决策。

一个有用的审批应该回答：

提议的具体操作是什么？

它属于哪个工作令和权限？

什么证据支持它？

什么仍不确定？

如果我拒绝它会发生什么？

Agent 能绕过我的决定吗？

这个决策以后可以验证吗？

如果界面无法回答这些问题，添加另一个复选框不会增加另一层治理。

OpenWorkProof 如何处理这个边界

OpenWorkProof 1.3.0 包含 Human Agency Profile v0.1。它是一个开放协议能力，用于表达 Agent 可以自主采取哪些操作，哪些决策保留给人类。

当前设计有几条具体规则：

配置文件绑定到一个冻结的工作令；

指定的 Acceptor 签署配置文件；

配置文件可以收窄现有权限，但不能扩展工作令或能力授权；

保留的操作在处理程序运行前失败，并带有 AGENCY_HUMAN_DECISION_REQUIRED；

签名转换可以撤销或替换活跃配置文件；

申诉记录审查请求，但本身从不恢复权限；

无需私钥的捆绑包可以离线验证。

验证和接受也保持分离。Verifier 可能建立证据满足定义的技术判断的证据。工作令绑定的 Acceptor 仍然决定是否接受或拒绝交付。

这故意比通用策略引擎或"Agent OS"更窄。它不对员工评分、不转移法律责任、不持有资金或证明监管合规。仓库也不证明客户采用或支付。那些是独立的事实，需要独立的证据。

目标更简单：使人类边界足够明确，以便软件可以强制执行，另一方可以验证。

商业后果是更便宜的委托

公司不需要为了加密技术本身而需要它。他们需要在不失去理解、限制、拒绝和审计已做事的能力的情况下委托重要工作。

弱的人类监督以多种方式增加委托成本：

高级员工必须手动重建 Agent 活动；

客户对他们批准的内容提出争议；

团队无法区分技术验证和业务接受；

供应商和买家保持独立的、不兼容的审计记录；

组织将 Agent 限制在低价值任务，因为更高价值的委托感觉不安全。

可验证的权限边界不能消除这些风险。它使底层决策可被审查。这可以降低审查成本，并使跨组织 Agent 工作更容易被接受。

这是 human agency 属于协议而非仅仅属于用户界面的商业原因。

以人为中心的 AI 需要机器可读的边界

Fei-Fei Li 将 AI 描述为一种责任，并警告："如果我们放弃 agency，那将是自由落体。"

当 Agent 可以行动时，这一原则变得更高要求。

让人类处于中心不能意味着在自动化管道中添加一个人形图标。它必须意味着保留一个人定义边界、理解证据、拒绝操作、修改委托以及稍后独立证明决策的能力。

下一代 Agent 系统将不仅由 Agent 能做什么来评判。它也将由人们是否仍能说：

你可以做这个，但不能做那个。

给我看证据。

我不接受这个结果。

这是我做出的确切决策。

那不是复选框。那是 authority。

如果你构建 Agent 运行时、审批工作流、MCP 服务器或企业自动化，我对两个问题感兴趣你的看法：

哪些 Agent 操作应始终保留给指定的人类授权？

在人类批准可以被视为真正的控制边界之前，你需要什么证据？