博客 · 指南 · 2026年10月28日
如何给编排器加上审批步骤:一个模式,以 AEGIS 为实际示例
声明:本指南的实际示例 AEGIS 由 100monkeys.ai 开发,因此请把涉及 AEGIS 的部分当作开发方的说明来读。模式本身是通用的,适用于任何编排器。本指南由我们的一个 AI 智能体根据公开的 AEGIS 文档(英文)起草,并经公司审阅;这个简体中文版是英文原版指南的译文。清单和命令保持原样。
审批步骤是自动化运行中的一个点:工作停下来,由一个人阅读即将发生的确切内容,只有凭这个人的回答,运行才会继续。大多数编排器都能暂停。能让暂停真正守住的要少一些。下面是我们使用的模式,一步一步,以 AEGIS by 100monkeys.ai, in beta 作为实际示例。
一段话说清这个模式
把关卡放在智能体准备好操作之后、操作发生之前。给审阅者看准备好的东西本身,而不是它的摘要。事先决定沉默意味着什么。为两种回答都明确安排去向。让审阅者在他们本来就在的地方回答,并把回答保存在运行的历史里。限制重试次数,让被拒绝的草稿不会无限循环。
第 1 步:列出需要人来把关的操作
不是每一步都需要关卡;什么都设关卡,只会教人一路点过去。给那些离开沙箱、无法撤回的操作设关卡:给外部的人发消息、合并到受保护的分支、花钱、删除数据、发布。其余的可以在事先写好的策略下运行。我们的论文 Red levers(英文)把它们称为两种停止:运行前设定、由运行时强制执行的限制,以及在操作发生时、绑定于这一次操作的审批。
第 2 步:在操作处拆分智能体的工作
在一步之内既起草又发送的智能体,中间无法设关卡。把它拆成一个负责准备的状态和一个负责执行的状态,让关卡有立足之处。在 AEGIS 中,工作流是声明式状态机,关卡本身就是一个状态,kind: Human:
spec:
initial_state: DRAFT
states:
DRAFT:
kind: Agent
agent: draft-agent
transitions:
- condition: on_success
target: APPROVE
APPROVE:
kind: Human
prompt: |
About to send:
{{DRAFT.output}}
Approve? (yes/no)
timeout: 86400s
transitions:
- condition: input_equals_yes
target: SEND
- condition: input_equals_no
target: DISCARD这个结构参照 AEGIS 文档的 Building Workflows 页面;draft-agent、SEND 和 DISCARD 代表你自己的智能体和状态。
第 3 步:把确切的内容摆在审阅者面前
提示就是审阅者看到的全部,所以要把准备好的输出渲染进去。AEGIS 的提示接受 Blackboard 模板:上面的 {{DRAFT.output}} 是前一个状态的输出,文档还展示了前面状态给出的分数,例如 {{QUALITY_CHECK.output.score}}。看到"智能体想发送一封邮件"的审阅者,批准的是一段描述;看到邮件本身的审阅者,批准的才是这封邮件。
第 4 步:决定沉默意味着什么
每个关卡都需要一个超时,以及超时之后的规则。在 Human Approvals 页面上,timeout_seconds 默认为 3600。在默认的 reject_on_timeout: false 下,无人回答的关卡会以 human_input_timeout 使运行失败。设为 reject_on_timeout: true 时,沉默被当作拒绝,运行走拒绝的路线。如果没有回答应当是一个干净的"不",而不是一个错误,就选第二种。永远不要让沉默等于同意。
关于字段的说明:Human Approvals 页面使用 timeout_seconds 以及条件 approved 和 rejected;Building Workflows 页面使用 timeout 以及 input_equals_yes 和 input_equals_no。始终只用一种形式,并查看你所运行版本的 Workflow Manifest Reference。
第 5 步:为两种回答都安排去向,并限制循环
"不"是一个回答,不是一个留到以后处理的失败。给它一个目标状态:丢弃,或者把草稿连同审阅者的反馈一起退回给智能体。如果你把拒绝路由回起草状态,运行里就有了循环。AEGIS 会限制它:每个状态的 max_state_visits(默认 5,上限 20)和每次运行的 max_total_transitions(默认 50,上限 100)。把它们设成审阅者能容忍的尝试次数。
第 6 步:让审阅者在自己所在的地方回答
没人看到的关卡只会超时。在 AEGIS 中,同一个关卡有三种回答方式:
- 在命令行:
aegis workflow signal <execution-id> --response yes。 - 在你自己的客户端:用
GET /v1/workflow-gates?status=pending列出等待中的关卡,再用POST /v1/workflows/executions/{id}/signal回答其中一个,请求体例如{ "response": "yes", "feedback": "Keep the flag name short." }。 - 在 Zaru Web:你发起的运行中的关卡会作为你的一条待审批事项出现,每个允许的词对应一个按钮。文档还说明,无论在哪种模式下,Zaru 的伙伴都没有能回答关卡的工具,所以准备操作的模型无法批准它。
最后这一点,是在任何编排器中都要寻找的特性:智能体绝不能握着自己关卡的钥匙。
第 7 步:保存回答
审批就是证据。关卡被回答或超时之后,AEGIS 仍会把它列出来:?status=answered 返回每个关卡所选的词、反馈、关闭时间以及运行随后做了什么。也要记录是谁回答的;Human Approvals 页面上的批准端点接受 approved_by 字段,拒绝则必须带 reason。
第 8 步:在信任关卡之前先测试它
把工作流运行三次:回答 yes,回答 no,再让它超时一次。确认每条路线都到达你想要的地方,并且在回答之前,关卡之后的任何东西都没有运行。然后在关卡发出之后修改草稿,确认审阅者看到的是实际将要运行的内容。如果你的编排器把审批绑定在描述上而不是内容上,你会在这里发现。
接下来
要在你自己的服务器上完整试一遍这个模式,请按照在全新的 Ubuntu VPS 上安装 AEGIS,并运行你的第一个经批准的任务操作。关于在每个关卡周围记录和签名什么,请阅读生产环境中 AI 智能体的可追溯性清单。个人助手中的同一审批思路,请看设置一个 Zaru 助手,在你批准的前提下处理你的邮件和日历。