判断 Agent 操作是否需要人工确认，可以先看三件事：现有授权有没有覆盖这次动作，结果能否低成本撤销，影响是否会越过当前用户或团队。任何一项说不清，Agent 都应停在执行前，展示对象、关键参数和影响范围。确认通过后如果参数发生变化，原确认随之失效。
ZGI 的 Workflow 可以把人工审批放进执行链。运行到审批节点时暂停，审批人选择通过、退回或拒绝，流程再沿对应路径继续；超过等待时间，也可以进入单独的超时路径。团队仍需提前写清谁能批准、批准哪些内容，以及一次确认能覆盖多长时间。
概念示意图：执行对象、关键参数和影响范围经过人工确认后，分别进入批准执行、退回修改或超时停止路径。
同一种动作，影响范围会改变
“发消息”三个字无法直接决定是否审批。保存成个人草稿、发送到项目内部群、批量通知外部客户，动作名称相同，授权范围和影响对象差别很大。查询一条库存记录与批量覆盖库存，也不能共用一条放行规则。
确认规则更适合围绕具体边界编写。动作会触达外部对象、修改共享数据、产生资金或合同责任、调整账号权限，或在结果不确定时继续写入，这些情况应保留人工确认。只读查询、可撤销草稿和已经获得明确范围授权的低影响动作，可以直接执行或抽样复核。
确认点贴着副作用放
Agent 可以先检索资料、生成草稿、整理目标名单并计算变更范围，真正调用发送、删除、提交或发布接口前再暂停。这样审批人看到的是即将执行的内容，判断不会停留在一句宽泛的任务描述上。
确认发生得太早，后续参数仍可能变化。审批时有十个收件人，执行前增加到一千个；审批时只改标题，执行时又覆盖正文。参数摘要、目标范围和内容版本应与确认记录绑定，任何关键字段变化都重新发起确认。
一张确认卡要让人看懂后果
确认卡至少写清六项：执行对象、动作名称、关键参数、影响范围、撤回方式、有效时间。
审批人还需要看见资料来源、预计生成的结果，以及哪些字段仍然缺失。没有必要展示模型的完整推理过程，真正影响决定的输入必须能核对。只有“继续”和“取消”两个按钮，却看不到要向谁发送、要改多少条数据，这种确认很难承担责任边界。
拒绝、超时和改参数都要有去处
人工拒绝后，流程可以回到修改环节，也可以直接结束；等待超时后，任务进入停止或待处理状态，不能静默放行。审批通过后若关键参数改变，应生成新的确认请求，避免拿旧授权执行新动作。
在 ZGI 中，可以把批准、退回和超时连接到不同的 Workflow 分支。工具调用需要等待审批时，运行层还能保留待处理动作和关联信息。落地时要检查每条分支最后会执行什么，尤其要确认拒绝和超时路径不会绕回原来的写入节点。
减少确认疲劳，也保留越界拦截
每次小动作都弹确认框，审批人很快会形成机械点击。可以按对象、渠道、数量、期限和动作类型授予有限范围：某个 Agent 只能向内部测试群发送，每次不超过二十人，授权当天有效。任何一项超出范围，执行链再次暂停。
上线前抽查十个会写入外部系统的动作，逐个补齐授权来源、撤回方式和超时去向。缺少其中一项，就先保留人工确认。
GitHub：https://github.com/zgiai/zgi
Gitee：https://gitee.com/zgiai/zgi
)
