当团队把 AI 协作跑顺后，下一步自然是“让它自动跑”。
但 Auto-Run 一上线，风险会指数上升：
- 同样的错误不再是“建议错误”，而是“执行错误”；
- 一次误判可能触发跨系统连锁动作；
- 没有审批与回滚设计时，修复成本会远高于人工模式。
所以这一章的核心不是“怎么更自动”，而是“怎么在自动化中保持控制权”。
学习目标
完成本章后，你将能够：
- 设计 Auto-Run 的风险分级与动作权限矩阵。
- 把审批图（Approval Graph）嵌入执行流程，而非外挂人工流程。
- 建立执行沙箱、幂等保护、超时熔断与补偿回滚机制。
- 用审计日志与回放能力实现可追责、可复盘、可改进。
一、Auto-Run 的最小原则：先定义“不能自动做什么”
很多团队先定义“AI 能做什么”，结果边界很快失控。
更稳的方式是先定义禁止清单：
- 涉及资金流转、权限提升、生产配置写入等动作默认禁止自动执行。
- 涉及跨租户数据读写默认禁止。
- 涉及不可逆动作（删除、封禁、清算）必须强制人工双签。
先有红线，再做能力开放。
二、动作分级：把“执行”拆成可治理的风险层
建议把动作分为四级：
L0-ReadOnly：只读查询、分析、摘要。L1-LowImpactWrite：低影响写操作（标签、注释、工单状态）。L2-HighImpactWrite：高影响写操作（规则更新、批量变更）。L3-Critical：关键动作（生产开关、权限策略、财务动作）。
2.1 执行策略矩阵
action_policy:
L0:
mode: auto
approval: none
L1:
mode: auto
approval: risk_based
L2:
mode: semi_auto
approval: single_sign
L3:
mode: manual_gate
approval: dual_sign这张矩阵必须由平台统一托管，禁止各 Agent 私自覆盖。
三、审批图（Approval Graph）：把组织职责写进系统
审批不应该是“@某人看一下”，而应是可执行图。
3.1 审批图节点
Requester：发起执行的 Agent/用户。PolicyChecker：策略引擎自动判定风险级别。DomainOwner：业务负责人审批。SecurityOwner：安全负责人审批（仅高风险动作）。Executor：通过后执行。
3.2 审批图示例
approval_graph:
trigger: action.level >= L2
steps:
- policy_check
- domain_owner_approve
- security_owner_approve_if(level == L3)
- execute审批图必须可追踪每一步决策来源与时间戳。
四、风险评分：不是“是否危险”，而是“危险有多大”
固定规则只能覆盖已知风险。Auto-Run 需要动态评分。
4.1 评分因子建议
- 动作级别（L0-L3）
- 目标系统敏感度（测试/预发/生产）
- 影响范围（单实体/批量）
- 历史失败率
- 当前告警状态（是否在事故窗口）
{
"riskScore": 0.82,
"riskBand": "high",
"reasons": [
"target_env=prod",
"batch_size=large",
"incident_window=true"
]
}根据风险带自动选择执行模式与审批链。
五、执行沙箱：所有自动动作先在受控环境演练
Auto-Run 不是“直接上生产”。应采用双阶段：
- Simulation Run：在沙箱模拟执行，输出影响报告。
- Commit Run：审批通过后在真实环境执行。
5.1 影响报告应包含
- 将修改的对象数量
- 预估副作用范围
- 可回滚路径
- 失败后补偿策略
没有影响报告的执行请求，一律不进入提交阶段。
六、执行控制：幂等、超时、熔断、补偿一个都不能少
6.1 幂等保护
每个自动动作必须有 idempotencyKey，防止重试导致重复执行。
6.2 超时与熔断
- 超时立即终止并标记不确定状态。
- 同类动作连续失败触发熔断，暂停 Auto-Run。
6.3 补偿机制
- 可逆动作自动回滚。
- 不可逆动作进入人工补偿工单，并冻结后续链路。
Auto-Run 的关键不是“零失败”，而是“失败时可控收敛”。
七、审计与回放：每次自动执行都要有“证据链”
审计最小字段：
who：哪个 Agent / 哪个用户触发why：决策依据（策略、评分、审批意见）what：执行动作与参数摘要when：时间与时序result：成功/失败/补偿/回滚
7.1 审计事件示例
{
"traceId": "trace_7ac1",
"actionId": "act_20251014_001",
"riskBand": "high",
"approval": ["domain_owner:approved", "security_owner:approved"],
"executionResult": "rolled_back",
"reason": "policy_violation_detected"
}有了完整证据链，事故复盘才能从“猜测”变成“定位”。
八、Foundation 接口建议：把 Auto-Run 设计成平台能力
public interface IRiskScorer
{
double Score(ExecutionRequest request);
}
public interface IApprovalEngine
{
ApprovalDecision Evaluate(ExecutionRequest request, double riskScore);
}
public interface IAutoRunExecutor
{
ExecutionResult Simulate(ExecutionRequest request);
ExecutionResult Commit(ExecutionRequest request);
}这三层职责分离后，模型替换、规则升级、审批策略调整都不会破坏主流程。
九、落地顺序（建议 3 周）
第 1 周：边界与分级
- 定义动作级别与禁止清单。
- 输出权限矩阵与审批图草案。
第 2 周：执行护栏
- 接入风险评分、审批引擎。
- 实现 Simulation Run 与影响报告。
第 3 周：审计与灰度
- 打通审计事件与回放。
- 在低风险动作上灰度 Auto-Run。
- 建立失败补偿 SOP。
常见坑
1) 先开自动执行，再补审批
顺序反了，事故概率会非常高。
2) 只做“同意/拒绝”，不记录审批理由
后续难以复盘，也无法持续优化策略。
3) 没有 simulation 阶段
直接 commit，等于放弃风险前置控制。
4) 失败后仍允许链路继续
应在关键失败后冻结后续动作，避免扩散。
下一章进入《Human-in-the-Loop 2.0：把人工介入从“救火”升级为“策略化编排”》，重点优化人工与 AI 的协同分工与效率上限。