故障诊断 Agent 权限：能查很多，不代表能改很多

一、诊断 Agent 最怕权限过大

故障诊断 Agent 可以自动查日志、看指标、读 Kubernetes 资源、分析变更记录，甚至执行修复动作。能力越强，风险也越大。如果 Agent 拿着集群管理员权限到处跑，一次误判就可能扩大故障。

生产环境里，诊断和修复应该分权。能查很多，不代表能改很多。尤其是删除 Pod、扩缩容、修改配置、回滚发布等动作，都必须有明确审批和审计。

二、权限要按动作分级

flowchart TD A[诊断 Agent] --> B[只读查询] A --> C[低风险修复] A --> D[高风险变更] B --> E[自动执行] C --> F[规则确认后执行] D --> G[人工审批]

只读查询可以自动执行，比如读取事件、日志、指标和资源状态。低风险修复可以在规则确认后执行，比如重启无状态任务的失败副本。高风险变更则必须人工确认。

权限还要按命名空间、服务等级和环境隔离。测试环境可以宽一点，生产核心命名空间必须收紧。

三、RBAC 要最小化

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: diagnosis-reader rules: - apiGroups: [""] resources: ["pods", "events", "services"] verbs: ["get", "list", "watch"]

Agent 的 ServiceAccount 不应该默认拥有写权限。需要写操作时，可以通过独立执行器、审批系统或短期令牌完成。

type AgentAction = { action: string risk: "read" | "low_write" | "high_write" approvedBy?: string reason: string }

每个动作都要记录理由和执行结果。审计日志不是事后装饰，而是自动化能力能否被信任的基础。

四、修复动作要可回滚

如果 Agent 执行扩容、回滚、切流量，必须能撤销。动作前保存当前状态，动作后监控指标变化。如果指标没有改善，应自动停止进一步动作，并升级人工。

还要防止 Agent 循环执行。同一个故障窗口内，多次重启同一服务可能掩盖根因，也可能让系统更不稳定。需要设置动作次数上限和冷却时间。

权限系统还要能解释拒绝原因。Agent 请求执行某个动作时，如果因为风险过高被拒绝，平台应返回“需要人工审批”“当前命名空间禁止写操作”“超过本事件动作次数上限”等明确原因。否则使用者会绕过平台，重新回到手工高权限操作。

agent_action_guard: max_restart_per_service: 1 require_approval_for_scale: true deny_core_namespace_write: true cooldown_minutes: 10

还要把 Agent 的提示词和工具版本纳入审计。同一个故障输入，在不同版本下可能得出不同动作建议。生产自动化只记录命令不够，还要记录为什么当时会选择这条命令。

如果要逐步开放写权限，建议从只读诊断开始，再开放低风险动作，最后才考虑高风险动作审批执行。权限扩张应基于复盘数据，而不是基于对模型的主观信任。

五、总结

故障诊断 Agent 的权限设计要遵守最小权限、动作分级、人工审批和完整审计。

自动化运维不是让机器随便改生产，而是让机器在清楚边界内完成可验证的动作。