Zapier 将 AI 代理治理重新设计为基于资源的规则

Zapier 最近发布了一篇技术回顾，详细说明了其如何重新设计 Sidekick（其 AI 工作区代理）的权限和批准架构。公司摒弃了脆弱的工具中心提示，转而采用确定性的、基于资源的安全引擎，以消除批准疲劳并防止意外的执行副作用。

发生了什么

根据 Zapier 博客，Sidekick 最初的权限系统按工具类型对操作进行分类——对只读操作自动执行，而对写入、编辑或删除操作则暂停并请求用户批准。然而，这一早期实现存在重大架构缺陷。权限请求绑定在打开的浏览器标签页上，若标签页关闭或刷新，请求即消失；失败的操作会反复触发冗余提示。常规的读取操作也会生成卡片，导致重要提示淹没在噪音中。

更关键的是，Zapier 发现了内部系统的分裂：Sidekick 的内置功能和其为与应用交互而编写的自定义代码脚本分别运行在两个权限引擎上，规则不一致。此外，规则是附加在工具上而非对象上——请求使用通用的“写入工具”，而不是对特定文档、账户或目录路径进行保护。

为了解决这些问题，Zapier 重新构建了 Sidekick 的安全体系，采用基于资源的权限。规则现在直接关联到文件、已连接的应用、网站或自动化，无论代理如何尝试执行操作，都能保持强制执行。Zapier 建立了严格的确定性评估逻辑：显式的“永不”规则始终覆盖所有操作，其次是“先询问”提示，仅在不存在阻塞规则时才允许静默执行。此外，Zapier 将批准提示从线性的聊天记录中移至专用输入面板和持久化的全局收件箱，并硬编码防护措施，阻止代理提出全局权限授予。

为什么这对代理构建者和运营负责人重要

对于将 AI 代理投入生产的小团队而言，Zapier 的技术回顾凸显了一个根本性的基础设施挑战：人机交互（HITL）治理不能仅视为聊天层面的提示，而必须构建为有状态、感知资源的后端规则引擎。工具级权限提供的操作边界较弱，因为风险取决于目标资源——例如向全局 Slack 频道发送消息与私聊单个用户的风险不同。

过度提示用户会导致机械式的盲目批准，而零提示架构则在一次错误执行后可能彻底失去信任。通过将批准状态与活跃的对话线程解耦，并强制刚性、确定性的覆盖——拒绝操作始终优先——编排者可以在不危及关键公司数据的前提下，赋予代理操作自主权。

本周行动指南

1. 将权限评估从工具转向目标资源： 重构你的代理编排层，使安全边界评估目标资产（例如特定的数据库表或文件夹路径），而不是函数调用本身。
2. 强制硬编码的确定性策略覆盖： 在模型上下文窗口之外实现显式规则引擎，使阻止规则在任何 LLM 工具调用之前无条件拒绝执行。
3. 将人机交互状态与聊天界面解耦： 将批准请求存储在持久化的服务器队列中，使待执行的门控在浏览器标签关闭或长时间后台任务期间仍然有效。

来源

• How much should an AI decide without asking you first? — Zapier Blog