权限、审批和 Human-in-the-loop 是 Agent 进入真实系统的前提。一个只能回答问题的模型，最多给出错误建议；一个能删除数据、发布内容、修改配置、发送消息的 Agent，如果没有审批机制，就可能造成真实损失。
因此，Agent 的安全设计不是上线前补一个提示词，而是要贯穿工具、工作流和执行环境。
授权和审批的区别
授权解决的是“Agent 有没有权限访问某个系统”。例如通过 OAuth 授权访问任务、日历、文档或代码仓库。
审批解决的是“这一次具体操作是否允许执行”。即使 Agent 已经有写入权限，也不代表每次写操作都可以自动执行。
例如 Agent 拥有任务写权限，可以创建待办。但如果它要批量删除任务，仍然需要用户确认。
风险分级
可以把工具分成几个风险等级。
低风险操作通常是读取和查询，例如查看标签、读取文章、搜索资料。
中风险操作会创建或修改资源，例如创建草稿、上传素材、更新文章内容。
高风险操作可能造成不可逆影响，例如删除数据、发布内容、修改权限、部署生产服务、发送外部消息。
不同风险等级对应不同执行策略：低风险可自动执行，中风险视上下文确认，高风险必须确认。
操作预览
审批前应该展示操作预览，而不是只问“是否继续”。预览应包括：
- 操作类型；
- 目标资源；
- 关键参数；
- 影响范围；
- 是否可回滚；
- 执行后如何验证。
例如发布文章前，应该展示标题、short、标签、状态变化；删除资源前，应该展示 ID、名称和不可恢复风险。
确认的粒度
确认粒度不能太粗。用户说“帮我整理这些文章”，不等于同意删除文章。用户说“创建一个教程”，可以创建资源，但如果需要覆盖已有 tutorial，就应该再次确认。
确认应该绑定具体操作和参数，避免确认 A 操作后执行 B 操作。
审批记录
审批必须可审计。系统应记录用户看到的预览、确认时间、确认人、执行参数和执行结果。
当 Agent 行为有争议时，审计记录可以说明系统是否按用户确认执行。
沙箱与审批配合
沙箱限制 Agent 能访问什么，审批限制 Agent 能执行什么。两者配合才能形成完整边界。
例如文件系统沙箱限制 Agent 只能写工作区；审批机制要求删除文件前确认。即使模型误判，也无法越权执行。
小结
Human-in-the-loop 不是反自动化，而是让自动化可控。真正可靠的 Agent 应该自动处理低风险任务，在高风险节点停下来，把决定权交还给用户。
实战案例：发布内容前的审批
以内容发布 Agent 为例，创建草稿可以自动执行，但发布到线上应该进入确认流程。确认信息不能只写“是否发布”，而应该展示文章标题、short、标签、封面、摘要，以及发布后用户会看到的入口。
如果用户确认，系统再执行发布操作；如果用户拒绝，任务进入 cancelled 或 waiting_revision 状态。这个过程还应该写入审计日志，记录用户确认的具体版本，避免后续内容被悄悄修改后仍复用旧确认。
审批机制还可以支持 dry-run。Agent 先生成将要执行的请求和影响范围，让用户预览。用户确认后，再使用同一份参数执行真实写入。这样可以降低误操作风险。
审批体验设计
审批流程还要关注用户体验。频繁弹出确认会让用户疲劳，完全不确认又不安全。实践中可以把确认做成分层机制：低风险自动执行，中风险展示简短确认，高风险展示详细预览。
对于重复性操作，可以支持“本次任务内信任”。例如用户确认批量创建 8 篇文章后，Agent 可以在这个任务范围内继续创建，但不能把这个授权扩展到删除或发布操作。审批的作用域越清晰，系统越安全。