运维智能体如何逐步获得生产操作权限

AI Agent 能调用 API、执行命令，不代表它已经适合接手生产运维。作者给出的路线是：先按任务风险分配权限，再从只读观察、提出建议，逐步走到审批后执行，以及限定范围内的自主操作。

这套思路值得程序员读，是因为它把「模型够不够聪明」换成了更容易落地的问题：它能改什么，结果怎么验证，出问题谁负责。不过，原文在「扩大自主权的准入条件」一节开头被截断，具体晋级标准没有给全。

先判断任务风险，再决定给多少权限

作者要求在委派操作前检查四件事：

• 可逆性：能否快速、完整地撤销操作。
• 影响范围：可能波及多少服务、用户或业务流程。
• 可验证性：人或自动化检查能否确认结果。
• 敏感性：是否涉及客户数据、安全设置、生产配置或资金。

这四项不能互相替代。一次重启可能很容易执行，也能确认进程重新启动，却仍可能影响依赖它的服务。删除数据的命令同样可以执行成功，但成功执行并不代表后果可以接受。

因此，作者主张把权限授予具体任务。同一个 Agent 可以负责健康检查，却未必适合修改生产配置；能分析事故，也不等于应该直接修复事故。

自主权应该跟着任务风险和证据走。

这里的「影响范围」尤其值得单独考虑。看起来只动了一个实例，是否会触发上游超时、下游重试或业务中断，还要结合依赖关系判断。

四级自主权，区别在于谁能决定执行

作者把运维 Agent 的自主程度分成四级：

级别	Agent 可以做什么	决策边界
Level 0: Observe	读取运行数据、汇总健康状态、关联信号	不修改环境
Level 1: Recommend	调查问题，附证据提出诊断或行动建议	人来决定
Level 2: Act with Approval	准备操作，并在获授权人员明确批准后执行	每次行动需要批准
Level 3: Act Within Defined Bounds	自主执行预先批准、可逆、低影响的操作	权限和策略强制限制范围

Level 2 与 Level 3 的差别，不是有没有人负责，而是授权发生在什么时候。前者针对一次具体行动批准，后者提前批准一类受约束的行动。

Level 3 也不是给 Agent 一套生产凭据后放手运行。作者强调，行动范围、监控、结果验证和责任归属都要明确，权限与策略还必须真正约束执行。

四个级别都需要看得见执行过程、管得住权限、验得了结果、找得到负责人。只读阶段也需要这些基础，因为错误的调查结论仍会影响人的后续判断。

第一批任务，优先选择只读和可复核的工作

作者建议从日常巡检、健康检查开始，放在 Observe；告警分类与关联、根因分析草稿放在 Recommend；日志和调用链调查可以处于 Observe 或 Recommend。

这些任务的共同点是：先让 Agent 整理信息，人可以对照证据检查它的结论。

涉及生产变更时，起点就更谨慎了。限定范围内的扩缩容、无状态服务重启，建议从 Act with Approval 开始。配置与部署变更，以及 Schema 变更、数据删除和安全设置变更，都需要人工审批。

但这张任务表只是示例，不是通用授权清单。作者明确提醒：一个环境中安全的重启，在另一个环境里可能造成故障。即便是无状态服务，也要先检查依赖关系和失败方式；扩缩容则需要验证边界与回滚。

至于积累多少次成功执行、满足哪些检查后才能晋级，现有原文没有说清。它在 Promotion Gates 一节刚开始时就中断，不能据此补出一套完整准入制度。

我的判断

我认同这套框架最有用的部分：把授权对象从「某个 Agent」缩小到「某类任务」。团队可以分别判断日志查询、重启服务和修改配置的风险，不必一次决定是否接受全自动运维。

但它目前更像设计原则，不能当成效果已经验证的方案。原文没有提供团队实测、事故率、节省时间或不同方案的对照数据。「分级能建立信任」是作者的主张，效果仍需在具体环境中验证。

与所有操作逐次审批相比，Level 3 给重复、低影响任务留下了减少审批的空间，前提是边界可以强制执行。文中没有解释策略如何实现，也没有给出撤销权限或异常中止的具体机制。这些问题会直接决定它能否落地。

能拿来做什么

• 给 Node 服务接入运维 Agent 时，可以先开放健康状态、日志和调用链的只读查询，让它输出摘要及对应证据，供值班人员复核。
• 把告警调查与生产操作拆成不同权限。允许 Agent 提交根因分析草稿，不必同时开放重启、部署或配置修改能力。
• 对准备交给 Agent 的重启和扩缩容任务，逐项确认可逆性、影响范围、可验证性与敏感性，再决定审批方式。
• 计划开放限定自主操作时，先明确允许执行的动作、范围、验证办法和负责人。不要仅凭此前几次建议正确，就扩大生产权限。