CI/CD AI Agent 部署前需加人工审批门

CI/CD AI Agent 引入人工审核机制，在部署机器人自行合并代码、应用基础设施变更或回滚生产环境之前，设置一道真实的审批关卡。

为什么 CI/CD Agent 需要一种不同的关卡

CI/CD Agent 不同于在起草博客文章——它一次 terraform apply 或 kubectl rollout 就可能引发真正的生产故障。传统流水线已经有了一道人工关卡：GitHub Actions 里那个"Deploy to production"按钮，或者 GitLab CI 中的手动审批步骤。问题在于，一旦你把决策权本身交给 Agent——"这条 PR 应不应该合并"、"这次回滚是否安全"、"这次迁移是否需要审核"——你就取消了在糟糕判断进入流水线之前唯一能拦截它的检查点。

解决方案不是撤掉 Agent，而是在"Agent 判断这是安全的"和"流水线执行它"之间设置一道真实的人工审批步骤，且这套机制必须独立于 CI Runner 运行器存在，这样即使 Agent 被入侵或陷入混乱，也无法直接绕过这道关卡。

关卡应该放在流水线的哪个位置

Agent 步骤执行后，生成一份计划（一个 diff、一条 rollout 描述、一份迁移摘要），然后不直接执行，而是将这份计划作为待处理操作推送出去，并阻塞当前 Job 直至人工做出决定。这个方案可以无缝作为普通步骤嵌入任何 CI 系统，因为它本质上只是一个 HTTP 调用加轮询——不需要特殊的 Runner 权限。

# .github/workflows/agent-deploy.yml
jobs:
  agent-plan-and-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Agent generates deploy plan
        run: python ci/agent_plan.py > plan.json
      - name: Request human approval before applying
        env:
          IMPRI_API_KEY: ${{ secrets.IMPRI_API_KEY }}
        run: python ci/request_approval.py plan.json
      - name: Apply only if approved
        env:
          IMPRI_API_KEY: ${{ secrets.IMPRI_API_KEY }}
        run: python ci/apply_if_approved.py

request_approval.py 和 apply_if_approved.py 是同一个 Impri Action 的两端：

# ci/request_approval.py
import json, os, sys, requests

plan = json.load(open(sys.argv[1]))
resp = requests.post(
    "https://api.impri.dev/v1/actions",
    headers={"Authorization": f"Bearer {os.environ['IMPRI_API_KEY']}"},
    json={
        "kind": "infra.apply",
        "title": f"Deploy: {plan['service']} — {plan['summary']}",
        "preview": {"format": "markdown", "body": plan["diff_markdown"]},
        "idempotent": False,
        "undo": f"Roll back to previous release: {plan['previous_release_id']}",
        "expires_in": 3600,
    },
)
action = resp.json()
open("action_id.txt", "w").write(action["id"])
print(f"Waiting for approval: {action['inbox_url']}")

# ci/apply_if_approved.py — poll then gate the real apply step
import os, time, requests

action_id = open("action_id.txt").read().strip()
headers = {"Authorization": f"Bearer {os.environ['IMPRI_API_KEY']}"}
while True:
    status = requests.get(f"https://api.impri.dev/v1/actions/{action_id}", headers=headers).json()
    if status["status"] != "pending":
        break
    time.sleep(10)

if status["status"] != "approved":
    print(f"Not approved (status={status['status']}), stopping.")
    exit(1)  # fails the job, blocks the rest of the pipeline

# only reached if approved — actual terraform apply / kubectl rollout goes here
os.system("terraform apply -auto-approve tfplan")
requests.post(f"https://api.impri.dev/v1/actions/{action_id}/result",
              headers=headers, json={"status": "executed"})

如果审核者拒绝或操作过期，exit(1) 会导致 CI Job 失败，后续步骤一个都不会跑——Agent 没有任何独立的凭证路径可以绕过去。

什么该卡，什么不该卡

把这道关卡留给那些真正有外部影响的操作。如果对 CI 里的每个步骤都加拦截，流水线就会变成一张工单队列，而审核者也会被训练成橡皮图章——这就把原本的目的给颠覆了。

需要明确说清的边界

Impri 负责存储被提案的操作、通知审核者并持有决策结果——它不解析 Terraform Plan，也不理解 Kubernetes Manifest，更不运行你的流水线。它要成为一道真实的关卡，前提是 CI Job 中 terraform apply 或 kubectl 的凭证只有在先检查了 status == "approved" 的代码路径中才能被调用。如果 Agent 步骤在同一 Job 里也拥有直接的云凭证，那它就可以绕过关卡——所以要把应用凭证的权限范围限制在那个被Gate的步骤上。

这也不是用来替代 GitHub 或 GitLab 内置的环境保护规则的——它是对后者的补充，能为你提供一个移动端友好的收件箱、一个独立于 CI 提供商的审计日志，以及让审核者在审批前直接编辑计划文案的能力。

从 Quickstart 开始获取 API Key，然后如果你想让流水线本身（而非仅仅是 Agent）在外部事件（如健康检查失败）触发时也能推动操作，可以进一步了解 Webhooks。