审批式 DevOps 的四个设计原则
对象要准确
授权必须绑定具体项目、供应商、资源、环境和当前计划版本。不能把“允许部署测试环境”解释成“允许修改生产 DNS”。
影响要可见
批准前展示预计费用、数据风险、停机窗口、外部收件人、生产域名和回滚路径，而不是只显示一条内部命令。
授权要有时效
一次批准只适用于当前任务和当前对象。计划、Commit、资源或预算变化后，需要重新确认。
结果要能对账
动作前写 Intent，动作后写 Receipt。中断后先读取供应商事实，确定动作是否已经发生，再决定继续还是恢复。
哪些动作可以自动，哪些必须停下
| 动作 | 默认策略 | 批准前至少展示 |
|---|---|---|
| 只读分析仓库 | 可自动执行 | 仓库路径、Commit、读取范围 |
| 生成计划与预检 | 可自动执行 | 发现的问题、依赖、缺失配置 |
| 创建隔离候选资源 | 按预算和 Sandbox Profile 执行 | 供应商、资源类型、预计费用、清理方式 |
| 数据库迁移 | 必须单独批准 | 迁移版本、备份、锁表与回滚风险 |
| 正式 DNS 与生产切流 | 必须单独批准 | 域名、旧目标、新目标、传播与回滚 |
| 发送真实邮件 | 必须单独批准 | 收件人范围、模板、数量和发件域名 |
| 购买或升级付费资源 | 必须单独批准 | 供应商、价格、周期与取消方式 |
| 删除资源 | 必须单独批准 | 准确对象、依赖、备份与不可恢复影响 |
审批的单位是具体动作，不是 Agent 身份。“我信任这个 Agent”不等于“它可以在未来任何时间对任何生产资源执行任何操作”。
批准生产变更前，证据至少覆盖这些内容
- 即将上线的准确 Git Commit 与构建产物摘要。
- 候选环境是否通过真实页面、API 和关键消费者验证。
- 数据库备份能否被识别，迁移版本与回滚命令是否明确。
- DNS 旧值、新值、TTL、传播检查和恢复目标。
- 第三方费用、配额、资源生命周期和清理责任。
- 本次计划未包含哪些动作，避免用户把局部批准误解为完整上线。
- 中断后如何对账，哪些动作可以安全重试，哪些必须先读取供应商事实。
关于从仓库分析到候选部署的整体过程，请阅读 AI 部署 Agent 指南。
常见问题
为什么不能用一次授权完成所有部署动作？
不同动作的影响、费用和可恢复性不同。创建候选、迁移数据库、改正式 DNS 和发真实邮件不应共享模糊授权。
审批会不会让自动化失去意义？
不会。Agent 仍可自动完成分析、计划、预检、候选部署、证据收集和低风险操作，人工只在高影响决策点介入。
凭证如何避免进入日志与计划？
持久计划只保存 Secret Ref，真实值在执行时由受限解析器取得，不写进 Plan、Run、Receipt 或日志。