AI 智能体审批工作流：如何在自动化的同时保留控制权

在演示中，AI 智能体看起来可能无害。给它一个工单，连接几个工具，它就能起草回复或更新记录。但当同一个智能体能够发送消息、更改客户记录、创建云资源或转移资金时，风险就会发生变化。此时，问题不再是模型能否推理出任务，而是谁有权批准由此产生的后果。

审批工作流在智能体的提议行动和实际行动之间设置了一个故意的检查点。智能体收集上下文，生成结构化请求，然后等待。由人员或范围狭窄的策略来决定该请求是否可以继续。这听起来很简单，但实用的版本不仅仅是一个标有“批准”的按钮。它需要明确的职责、证据、过期规则以及事后能讲得通的审计追踪。

本指南解释了团队如何为客户运营、云管理、安全和内部自动化设计 AI 智能体的审批工作流。它还展示了在哪里值得为了延迟而进行审批，在哪里不值得，以及如何构建流程，以免人们无法理解队列而机械地点击批准。

为什么 AI 智能体需要审批边界

大多数智能体故障并非戏剧性的模型失败。模型可能会总结错误的文档、选择过时的策略，或对模糊指令的解释过于宽泛。如果输出仅限于草稿，成本通常很小。但如果它改变了生产系统，同样的错误就会变成运营事故。

NIST 的 AI 风险管理框架将治理、映射、测量和管理视为持续的活动，而不是一次性的模型审查。这对于智能体自动化来说是一个有用的框架。工作流应涵盖决策、工具调用、用于证明其合理性的数据以及允许它的个人或策略。OWASP 关于大型语言模型应用程序的指导也指出了过度代理的问题：赋予 LLM 广泛的权限可能会将误导性指令或薄弱的控制转化为意外操作。

审批边界承担三项实际工作。它限制爆炸半径。它给操作员一个捕捉缺失上下文的机会。并且它创建了为什么发生重要操作的记录。即使智能体大部分时候都是准确的，这些工作仍然很重要。准确性不能替代问责制。

从行动类别开始，而不是单一的审批规则

不要让每个行动都等待人员批准。这会创建一个缓慢且嘈杂的系统，并教导审查者以反射方式批准。相反，根据可逆性、数据敏感性、财务影响和外部影响对行动进行分类。同一个智能体可以对一类行动自动运行，而对另一类行动要求审批。

这些只是起点，而非普遍规则。客户支持团队可能安全地自动发送密码重置指南，而受监管的支持团队可能需要审查任何讨论账户状态的邮件。正确的控制措施应遵循错误行动可能造成的危害。

审查者需要看到什么

审查者不应被迫从零散的日志中重建智能体的推理过程。将决策包放在一个地方。该包应以通俗语言说明请求的行动，显示确切的工具调用或更改集，识别受影响的系统，并链接智能体使用的来源。它还应该说明智能体在哪些方面不确定。隐藏不确定性会使审查变慢，因为人们只有在打开请求后才会发现它。

• 请求的行动和人类可读的摘要
• 受影响的目標系统、账户、项目或客户
• 使用的输入和来源，以及相关的时间戳
• 预期结果和回滚路径
• 风险信号、策略匹配和置信度限制
• 审批所有者、过期时间和升级路线

例如，请求生产配置更改的云操作智能体应显示差异、环境、更改窗口、授权工作的工单以及它将执行的命令。“应用推荐修复”不是一个可审查的请求。它迫使人类猜测系统的意图。

将审批请求设计为状态机

当审批逻辑具有显式状态时，审计变得容易得多。请求始于“提议”。它可以移动到“等待审查”、“已批准”、“已拒绝”、“已过期”、“已执行”、“失败”或“已回滚”。批准后保持请求不变。如果智能体更改了有效载荷，请创建新请求并重新发送审查。

这防止了一种微妙但严重的故障：批准一个行动并执行另一个行动。将审批绑定到结构化有效载荷的哈希值、策略版本和目标环境。当执行器收到审批令牌时，它会验证这三者是否仍然匹配。过期的令牌不能用于不同的命令。

与审批一起使用受限权限

如果智能体的服务账户可以绕过工作流，仅靠审批是不够的。执行器应仅拥有执行批准行动所需的权限。尽可能将规划身份与执行身份分开。规划者可以读取上下文并创建请求。执行者只能在验证审批令牌后执行 narrowly defined（狭窄定义）的操作。

这种安排也有助于防止提示注入。不受信任的文档可能会说服智能体尝试危险命令，但它不应能够授予新权限或跳过审批要求。将外部文本视为数据，而不是具有权威性的指令。

常见的审批工作流错误

最常见的错误是模糊的审批卡片。审查者只看到简短的摘要而没有实际行动，然后因为队列增长而批准。解决方法是提供具体的证据和可预测的布局。第二个错误是审批疲劳。如果每个低风险任务都需要相同的点击，该流程将无法检测风险。将常规、可逆的工作移至策略通道，并将人员保留用于例外情况。

另一个问题是永远不会过期的审批。在维护窗口期间提出的请求不应在下周环境改变后仍然有效。根据行动设置短生命周期。生产部署可能需要三十分钟的时间窗口。如果记录发生更改，删除记录的请求可能需要新的审查。

最后，不要将审计日志与一堆遥测数据混淆。有用的日志回答谁请求了行动、谁批准了它、什么运行了、什么发生了更改以及回滚是否成功。将原始技术痕迹单独存储，然后从事件记录中链接它们。

SmaugBrain 在工作流中的定位

SmaugBrain 可以作为智能体计划与执行工作系统之间的编排层。一个实用的工作流始于一个事件：一个新的服务工单、部署请求、安全警报或表单提交。智能体收集批准的上下文，准备结构化提案，并将其路由到正确的人员或策略。批准后，受限行动运行并将结果写回同一案例。

价值不在于声称每个流程都应该是自主的。而在于交接可以保持连贯。批准更改的人可以看到智能体打算做什么，后来调查的人可以在一个工作流中看到决策和结果。从一个狭窄的流程开始，例如分类访问请求或起草在经理释放之前不能发送的回复。

探索 SmaugBrain 以评估围绕团队已经使用的工具和审批点的智能体工作流。

实施指南：首先构建一条安全的路径

1. 选择一个有边界的用例

选择一个具有清晰输入、所有者和可衡量结果的工作流。“帮助运营”太宽泛了。“读取批准的事故工单，提议状态更新，并在发布之前等待事故指挥官”足够狭窄以便测试。避免让第一个版本一次性访问许多系统。

2. 定义行动契约

为每个行动编写模式。模式应包括行动类型、目标、参数、理由、来源引用、风险级别和回滚说明。在向审查者展示之前对其进行验证。结构化请求使策略检查可靠，并防止智能体将未经审查的散文滑入执行路径。

3. 按风险和所有权路由

将每种行动类型映射到审批人或策略。系统所有者批准基础设施更改。支持主管批准面向客户的例外。财务拥有退款权限。当主要所有者不在时，使用明确的升级规则，而不是将所有请求发送到共享收件箱。

4. 执行前的新鲜检查

在执行之前，确认请求仍然获得批准、未过期且未更改。当状态很重要时，检查目标的当前状态。智能体可能提议将工单分配给队列，但人类可能已经解决了该问题。执行器应停止，而不是覆盖更新的决策。

5. 衡量覆盖和拒绝

拒绝是有用的数据。跟踪审查者拒绝或编辑智能体提案的原因。源文档不完整吗？智能体选择了错误的风险等级吗？请求太长难以扫描吗？每周审查这些模式，然后改进策略、提示、集成或源数据。不要仅针对批准率进行调整。一个获得所有请求批准的系统可能掩盖了薄弱的审查流程。

按团队分类的示例

客户运营：智能体读取支持案例，收集账户历史，并起草回复。常规故障排除草稿可以发送到内部队列。退款、账户关闭和关于法律义务的声明等待指定审批人。最终消息和审批事件仍附加在案例上。

云运营：智能体将警报与最近的部署相关联，并提出回滚或扩展更改。审批视图包括受影响的环境、命令、预期影响和回滚。紧急策略可能允许预定义的运行手册在严格限制内自动执行，然后通知值班工程师。

安全：智能体可以使用已知指标丰富警报并建议遏制。禁用用户、轮换凭证或阻止网络访问应通过负责任的事故所有者进行，除非适用预定义的紧急策略。证据的记录很重要，因为该行动可能会影响员工或客户。

常见问题解答

所有 AI 智能体行动都需要人工审批吗？

不。只读工作和可逆的内部任务通常可以在记录的策略下运行。在行动具有重大外部影响、更改敏感数据、创建财务或法律承诺或难以撤销时要求审批。

审批应保持有效多长时间？

只要提议的行动执行起来仍然安全，就保持有效。对生产更改和依赖于变化记录的行动使用短有效期。当有效载荷、目标、策略或相关系统状态发生变化时，要求新请求。

什么防止智能体更改已批准的请求？

将审批绑定到不可变的行动有效载荷。执行器在运行之前检查有效载荷哈希、策略版本、过期时间和目标。任何更改都会创建一个需要自己审查的新请求。

审批工作流如何降低提示注入风险？

它们本身并不能解决提示注入，但它们降低了恶意指令立即成为高影响行动的机会。将审批与最小特权凭据、可信源边界、工具白名单和执行时验证相结合。

AI 智能体审计日志应包含什么？

记录请求、受影响的目标、证据、策略决策、审批人、时间戳、执行的命令或 API 调用、结果和回滚结果。链接详细痕迹，而不是使主要事件记录难以阅读。

让人工检查点变得有用

最好的审批工作流不是自动化之前的仪式性暂停。它为正确的人提供足够的上下文以做出快速、明智的决定，同时让常规工作远离他们的视线。围绕显式的行动类别、狭窄的权限、不可变的请求和审查者可以快速扫描的证据来构建流程。然后在第一个工作流在实际运营中获得信任后再扩展。

对于构建实用智能体自动化的团队，工作始于一条小而受控的路径。决定智能体可以提议什么、可以执行什么，以及人在哪里必须承担责任。这些边界使得当风险升高时，自动化更容易操作。