2026年10月，AWS 在 Amazon Quick 的 What’s New 公告中宣布上线 smart approvals 功能。Amazon Quick 是 AWS 面向企业的商业智能与数据分析产品，目前已扩展至代理式 AI 能力。公告原文给出了一个直白的因果判断：当代理代替用户执行越来越多操作——发邮件、更新记录、创建工单——”asking a person to approve every step leads to approval fatigue and weaker oversight over time”（要求用户逐步审批会导致审批疲劳，并随时间推移削弱监督效果）。这句话把一个在企业 AI 代理部署中正在浮现的治理问题摆上了台面：human-in-the-loop 的初衷是安全网，但当审批请求的数量超过人类注意力的带宽，安全网就会变成噪音源，甚至变成虚假的安全感。

Smart approvals 的解决方案是在”全部放行”和”全部拦截”之间插入一个独立的分类器（classifier），对每个符合条件的操作进行逐一评估，自动放行常规动作、仅将高影响操作交由用户审核。这个功能默认对所有用户开启，管理员可通过自定义权限控制谁能使用，用户也可以在聊天选项中为自己的对话和定时任务关闭它。AWS CloudTrail 会记录每一次通过 smart approvals 完成的操作审查，以及用户对 smart approvals 设置的每一次变更。

本文聚焦 AWS 这一单一产品的公告内容，拆解 smart approvals 的机制设计、它的硬约束边界、它对企业代理治理的含义，以及它在 Amazon Quick 产品演进中的位置。其他企业 AI 代理平台（如 Microsoft Copilot Studio、Salesforce Agentforce、ServiceNow）在类似治理问题上是否有可比机制，不在本文讨论范围内。

审批疲劳：代理规模化后的真实治理风险

审批疲劳并非 AI 代理独有的问题。在信息安全领域，安全告警疲劳（alert fatigue）早已是一个被广泛讨论的现象——当安全运营中心（SOC）每天面对大量告警时，分析师会逐渐对告警脱敏，真正的威胁信号被淹没在误报噪音中。AWS 在 Amazon Quick 公告中描述的审批疲劳，是同一类认知过载问题在人机协作场景中的翻版。

区别在于，AI 代理的操作频率和操作种类正在快速扩展。Amazon Quick 公告列举的代理操作类型包括发送邮件（sending email）、更新记录（updating records）和创建工单（creating tickets）。这些操作中的每一类，在企业日常工作流中都可能以极高频率出现。如果一个代理每天代替用户执行数十甚至上百个操作，而每个操作都需要用户点击”批准”，那么审批行为本身就会退化为一种机械性的点击——用户不再真正审查操作内容，而是形成”看到弹窗就点批准”的肌肉记忆。

AWS 公告对此的描述非常精确：审批疲劳的后果是”weaker oversight over time”——监督效果随时间推移而减弱。这里的关键词是”over time”。审批疲劳不是一个瞬时事件，而是一个渐进过程。在代理刚部署的初期，用户可能还会认真阅读每一条审批请求；但随着时间推移和操作量的累积，审批行为的认知成本会促使用户寻找捷径，最终导致人类监督名存实亡。

AWS 公告本身对审批疲劳问题的直接描述，是目前关于这一功能最具权威性的一手来源。公告将审批疲劳定性为代理规模化后的必然伴生问题，而 smart approvals 正是对这一问题的直接回应。这一判断的底层逻辑指向一个更普遍的认知：human-in-the-loop 机制的有效性取决于人类审批者的注意力质量，而注意力是一种有限且会衰减的资源。

笔者判断，审批疲劳问题的严重程度会随着代理能力的提升而加速恶化。原因很简单：代理越能干，它能执行的操作种类越多，产生的审批请求也就越多；而用户的注意力带宽并不会因为代理变强而同步扩展。这是一个结构性的不对称——代理的操作吞吐量可以线性甚至指数增长，但人类的认知处理能力基本恒定。

Smart Approvals 的机制拆解：分类器做了什么、不做什么

根据 AWS 公告，smart approvals 的核心是一个被称为”classifier”的独立审查模型（separate review model）。这个分类器对每个符合条件的操作（eligible action）进行评估，评估的依据是该操作与用户原始请求（the user’s request）之间的匹配关系。评估结果分为两类：常规操作（routine actions）被自动放行，高影响操作（consequential actions）被转交给用户审核。

公告明确列出了分类器会标记为高影响并交由用户审核的操作类型，共5类：

  1. 发送内容到组织外部（sending content outside the organization）
  2. 更改权限（changing permissions）
  3. 删除内容（deleting content）
  4. 执行支付（making payments）
  5. 超出用户原始请求范围的操作（actions that go beyond what the user asked for）

前4类是基于操作本身的性质进行分类——这些操作具有不可逆性或外部影响，一旦执行错误，纠正成本较高。第5类则更加微妙：它要求分类器理解用户的原始意图，并判断代理的某个具体操作是否超出了这个意图的边界。这意味着分类器需要具备一定程度的语义理解能力，而非仅仅基于操作类型的规则匹配。

从技术架构的角度看，公告将分类器描述为”separate review model”——一个独立于执行代理的审查模型。这种架构设计意味着执行代理和审查模型之间存在分离：执行代理负责规划和执行操作，分类器负责在操作执行前进行独立评估。这种分离降低了单点故障的风险——如果执行代理本身被误导或出现幻觉，分类器作为一个独立的检查点，可以提供额外的安全层。

公告还明确了一个关键的技术细节：每次自动批准仅覆盖被审查的那个具体操作（each automatic approval covers only the exact action that was reviewed）。这意味着分类器的批准是逐操作的、非传递性的——批准操作 A 不意味着批准后续的操作 B，即使 B 与 A 类似。这种设计防止了”批准链”的形成，即一个初始批准被不当扩展到后续一系列操作。

此外，公告提到了故障处理机制：如果审查失败或超时（if a review fails or times out），操作会被转交给用户。这是一个保守的故障模式设计——在不确定的情况下，系统默认回退到人类审批，而非默认放行。

3条硬约束：分类器的权限边界

Smart approvals 的设计中最值得拆解的部分，是公告明确列出的3条硬约束。这3条约束定义了分类器的权限边界，决定了它能做什么、不能做什么。

第1条：只作用于设置为”ask”的操作。 公告原文写道：”Smart approvals only reviews actions where the user’s setting is ‘ask’ each time.” Amazon Quick 的权限系统中，用户对代理操作的设置至少包含3种状态：允许（allow）、拒绝（deny）和询问（ask）。Smart approvals 的分类器只在”ask”这个灰色地带中工作。如果用户或管理员已经将某类操作设置为”allow”，该操作会直接执行，不经过分类器；如果设置为”deny”，该操作会被直接拒绝，同样不经过分类器。分类器的作用域被严格限定在”需要询问用户”的操作中——它的角色是帮助用户过滤这些询问，而非替代用户的权限决策。

第2条：已拒绝的操作仍然被拒绝。 公告原文：”Denied actions stay denied.” 这条约束看似简单，但它传递了一个重要的设计原则：分类器没有权力推翻已有的安全策略。如果企业管理员已经通过策略禁止了某类操作，分类器不会也不能绕过这个禁令。这意味着 smart approvals 是一个叠加在现有权限体系之上的辅助层，而非一个可以独立做出权限决策的新权限层。

第3条：分类器永远不授予新的访问权限。 公告原文：”smart approvals never grants new access.” 这是3条约束中最关键的一条。它意味着分类器的功能是”减少不必要的询问”，而非”扩展代理的能力范围”。分类器可以决定某个已经在用户”ask”列表中的操作不需要打扰用户，但它不能让代理执行用户从未授权过的操作类型。

这3条约束共同构成了最小权限原则（principle of least privilege）在代理审批场景中的具体实现。分类器是一个减噪器，不是一个决策者。它减少的是人类审批者面对的噪音量，而非人类审批者的决策权。企业现有的安全策略（deny/allow）构成硬边界，分类器只在这些硬边界之间的弹性空间（ask）中工作。

审计留痕：合规层面的设计考量

公告中提到的另一个关键设计要素是审计留痕。AWS CloudTrail 会记录两类事件：(1) 每一次通过 smart approvals 完成的操作审查（each action review made through smart approvals），(2) 用户对 smart approvals 设置的每一次变更（each change to a user’s smart approvals setting）。

这意味着企业的安全团队和合规团队可以事后追溯：哪些操作是被分类器自动批准的，哪些是被转交给用户审核的，以及谁在什么时间修改了自己的 smart approvals 设置。这种全链路的审计能力对于受监管行业（金融、医疗、政府）的企业尤为重要——即使操作是被自动批准的，审计记录也能证明该批准是基于分类器的评估做出的，而非完全无人监督。

从企业 IT 治理的角度看，审计留痕还提供了一个反馈回路：如果事后发现分类器自动批准了某个不应该被批准的操作，企业可以通过审计日志定位问题、调整策略（例如将该类操作从”ask”改为”deny”），从而持续优化权限配置。这种”事后可追溯+策略可调整”的模式，比”事前全部拦截”或”事后无法追溯”都更适合代理操作量快速增长的场景。

公告还提到，smart approvals 默认对所有用户开启（on for all users by default），但管理员可以通过自定义权限（custom permissions）控制谁能使用，用户也可以在聊天选项中为自己的对话和定时任务（scheduled runs）关闭它。这种”默认开启+可关闭”的设计选择本身就传递了 AWS 对这个功能的定位判断：它认为对大多数用户来说，smart approvals 带来的审批噪音减少是净正面的，但同时保留了管理员和用户的控制权。

笔者注意到，公告中”定时任务”（scheduled runs）这个措辞暗示 Amazon Quick 的代理已经支持某种形式的异步或定时执行——用户可以设置代理在特定时间自动执行任务。在这种异步执行场景中，用户可能不在线，无法及时响应审批请求，审批疲劳的问题可能更加突出。Smart approvals 在这种场景下的价值尤为明显：它可以自动放行常规操作，仅在遇到高影响操作时暂停并等待用户上线审核。需要说明的是，公告并未详细描述定时任务的完整机制，上述判断是基于公告措辞的推断，存在不确定性。

从 BI 助手到代理平台：Amazon Quick 的产品演进

Smart approvals 的上线需要放在 Amazon Quick 更大的产品演进脉络中理解。2026年10月，AWS 官方在 press.aboutamazon.com 发布了一篇标题为”Scaling agentic AI across the enterprise with Amazon Quick”的博文。这个标题本身就标志着 Amazon Quick 的产品定位已经从传统的 BI（商业智能）工具向企业级代理平台扩展——”scaling agentic AI across the enterprise”（在企业范围内扩展代理式 AI）是一个明确的平台级定位声明。

从 AWS 公告的措辞来看，smart approvals 功能上线时，Amazon Quick 已经具备了相当丰富的代理操作能力——公告提到的操作类型包括发送邮件、更新记录、创建工单、发送内容到组织外部、更改权限、删除内容和执行支付。这些操作覆盖了企业日常工作流中的多个核心环节，远超传统 BI 工具”查询数据-生成图表”的功能范围。

笔者判断，smart approvals 在 Amazon Quick 的产品路线图中扮演的角色是”治理能力补课”。当一个产品从”只读”（查询和分析数据）扩展到”读写”（代替用户执行操作）时，治理机制必须同步升级。只读操作的风险相对可控——最坏的情况是用户看到了不应该看到的数据；但读写操作的风险则大得多——代理可能发送了不应该发送的邮件、删除了不应该删除的记录、或者向错误的对象支付了款项。Smart approvals 正是为这种”读写”场景提供的治理层。

从 AWS 公告中可以看到，smart approvals 在所有支持 Amazon Quick agentic capabilities 的 AWS Region 中可用（”available in Amazon Quick in all AWS Regions where Amazon Quick agentic capabilities are supported”）。这意味着它是一个全局性的功能发布，而非区域性的试点。结合默认开启的设计选择，AWS 显然认为这个功能已经足够成熟，可以面向所有企业用户推出。

分类器审查的技术边界与未解问题

尽管 AWS 公告对 smart approvals 的机制描述相当详细，但基于公告已披露的信息，有几个技术边界值得进一步推敲。

分类器的误判风险。 公告没有提供任何关于分类器准确率的数据。但基于公告已披露的机制，笔者可以做出以下推断：分类器误判的风险被3条硬约束和故障处理机制部分对冲了。首先，分类器只作用于”ask”状态的操作，企业已通过”deny”策略拦截的高风险操作根本不会进入分类器的评估范围；其次，审查失败或超时时操作会回退到人类审批，这覆盖了分类器本身出错的情况；再次，CloudTrail 的全链路记录使得即使分类器做出了错误的自动批准，企业也可以事后发现并调整策略。但这些机制无法完全消除一种特定风险：分类器”自信地做出错误判断”——即将一个本应交由用户审核的高影响操作判定为常规操作并自动放行。公告中”each automatic approval covers only the exact action that was reviewed”的逐操作设计限制了这种误判的影响范围，但无法从根本上消除误判本身。笔者预计，分类器在真实企业环境中的误判率将是决定 smart approvals 长期可信度的关键指标。

“超出原始请求”的判断边界。 5类高影响操作中，前4类（发送外部内容、更改权限、删除内容、支付）可以基于操作类型做相对明确的规则判断。但第5类——”actions that go beyond what the user asked for”——要求分类器理解用户的原始意图并判断代理行为是否越界。这类语义层面的判断比操作类型层面的判断更容易出现模糊地带。例如，用户要求”帮我整理这份报告并发给团队”，代理在整理过程中修改了报告中的某个数据字段——这算”超出原始请求”还是”整理”的合理延伸？公告没有说明分类器如何处理这类边界情况。基于公告将分类器描述为”separate review model”而非规则引擎，笔者推测它可能依赖模型的语义理解能力来做出这类判断，但这一推测的确定性较低——公告未披露分类器的内部判断依据，这种判断的准确性在不同业务场景中可能差异显著。

企业自定义高影响操作的空间。 公告列出了5类高影响操作，但不同企业、不同行业对”高影响”的定义可能差异很大。公告没有说明分类器是否支持企业自定义高影响操作的类型。基于公告中”administrators control who can use it with custom permissions”的描述，管理员目前的控制权集中在”谁能使用 smart approvals”这个层面，而非”分类器如何定义高影响操作”这个层面。笔者判断，如果 smart approvals 要在不同行业的企业中广泛适用，支持企业自定义分类规则可能是后续迭代的方向之一。

这套范式的局限性

基于 AWS 公告已披露的机制，笔者认为 smart approvals 这套范式存在几个需要正视的局限。首先，分类器只作用于用户设为”每次询问”（ask）的操作，这意味着它的减噪效果完全取决于企业权限配置的精细度——如果企业将大量操作笼统地设为”ask”而非逐类做出”allow”或”deny”的明确决策，分类器实际上承担了本应由企业安全策略承担的分类工作，而公告未披露分类器的误判率和具体判断依据，这使得企业难以事前评估将多大比例的决策权委托给分类器是合理的。其次，smart approvals 默认对所有用户开启，这意味着在用户主动关闭之前，分类器的误判代价由用户默认承担——对于不了解这一功能存在或不理解其机制的用户而言，”默认开启”可能恰恰制造了公告试图解决的那种虚假安全感。笔者判断，这套范式在减轻审批疲劳方面的收益是真实的，但它同时引入了一个新的信任问题：用户需要信任一个他们无法审查其判断逻辑的分类器，而公告目前没有提供足够的信息让企业对这种信任做出知情评估。

代理时代的人机分工重新划线

Amazon Quick smart approvals 的上线，标志着企业 AI 代理的讨论焦点正在从”代理能做什么”转向”代理做的事情怎么管”。AWS 在2026年10月发布的”Scaling agentic AI across the enterprise with Amazon Quick”博文标题中的”scaling”一词，暗示 Amazon Quick 的代理能力已经度过了功能验证阶段，进入了规模化部署阶段。而规模化部署必然带来治理挑战——smart approvals 是 AWS 针对这些挑战给出的一种系统性回应。

从公告的设计细节中可以提炼出几个对整个企业代理行业具有参考价值的原则：

策略优先于分类器。 企业已有的安全策略（deny/allow）构成硬边界，分类器只在弹性空间（ask）中工作。企业不需要为了使用 smart approvals 而重新设计权限体系——它是一个叠加层，而非替代层。

逐操作评估，非传递性批准。 每次自动批准仅覆盖被审查的那个具体操作。这防止了权限蔓延（permission creep）——分类器批准了操作 A，不意味着后续类似的操作 B 也被自动批准。

保守的故障模式。 审查失败或超时时，操作回退到人类审批。系统在不确定的情况下选择安全而非效率。

全链路审计。 CloudTrail 记录每一次操作审查和每一次设置变更，为事后追溯和策略优化提供数据基础。

这些原则共同描绘了一种代理治理的设计范式：让机器处理可以标准化判断的部分，让人类聚焦于需要上下文理解和价值判断的部分，同时确保每一个决策——无论是机器做的还是人做的——都可追溯、可审计。

审批疲劳问题的浮现和 smart approvals 这类功能的出现，标志着企业 AI 代理正在进入一个新的发展阶段。在这个阶段，技术能力不再是唯一的竞争维度——治理能力、合规能力和人机协作的精细度，将成为决定哪些代理产品能真正在企业环境中规模化落地的关键因素。Amazon Quick 用一个分类器在”全部放行”和”全部拦截”之间划出了第3条路，这条路是否走得通，最终要看分类器在真实企业环境中的表现——而这正是公告中没有提供、但市场最终会给出答案的部分。

参考资料

  1. Quick now supports smart approvals for agentic actions — AWS, 2026-10-01
  2. Scaling agentic AI across the enterprise with Amazon Quick — AWS / About Amazon, 2026-10-21

主题分类：企业AI落地