故障诊断 Agent：能查命令，也要知道不能乱改
一、诊断 Agent 的边界比能力更重要
故障诊断 Agent 可以自动查指标、看日志、执行 kubectl、分析变更和生成排障建议。它能大幅节省值班时间，但也可能带来新风险：误删 Pod、误改配置、泄露日志、执行高危命令。运维场景里，Agent 的边界比能力更重要。
一个靠谱的诊断 Agent，默认应该只读。先收集证据、生成判断、列出下一步命令，真正的变更动作需要人工确认。生产系统不是实验沙盒，Agent 不能因为模型自信就直接动手。
二、执行链路：只读诊断和变更动作分开
flowchart TD
A[故障告警] –> B[Agent 收集证据]
B –> C[执行只读命令]
C –> D[生成诊断报告]
D –> E[建议修复动作]
E –> F{是否高风险}
F –>|是| G[人工确认]
F –>|否| H[自动低风险处理]
只读命令包括查看 Pod、事件、日志、指标、配置和发布记录。高风险命令包括删除 Pod、扩缩容、切流、重启服务、修改 ConfigMap 和执行数据库操作。命令要分级，不能让 Agent 自由拼 shell。
还要限制作用域。Agent 在处理某个 namespace 的告警时，不应该能随便访问全集群敏感资源。RBAC、命令白名单和审计日志是底座。没有权限边界，Agent 就是一个会说话的高危脚本。
三、命令策略：明确允许和拒绝
下面是一份简化策略。
agent_policy:
allow_readonly:
– "kubectl get"
– "kubectl describe"
– "kubectl logs"
require_approval:
– "kubectl rollout restart"
– "kubectl scale"
deny:
– "kubectl delete namespace"
– "kubectl exec"
策略要按命令和参数检查。kubectl delete pod 和 kubectl delete namespace 风险完全不同，kubectl exec 可能访问敏感文件。白名单不能只看程序名，要看子命令、资源类型和 namespace。
Agent 输出也要可审计。每条命令的原因、执行时间、结果摘要和关联告警都要记录。排障后复盘时，能知道 Agent 查了什么、建议了什么、人确认了什么。
四、落地建议：先做助手，再做自动化
诊断 Agent 可以先以助手形态上线：自动收集证据，生成报告，不自动修复。等常见故障模式稳定后，再开放低风险动作，例如创建工单、通知 owner、重跑失败巡检。高风险修复一直保留人工确认。
知识库也要持续维护。Agent 如果引用过期 Runbook，会把人带偏。每次故障复盘后，应更新诊断步骤和禁用危险建议。AIOps 的质量来自运维知识沉淀，不只是模型能力。
最后，Agent 失败时要优雅退出。查不到日志、权限不足、API 超时，都应明确说明，而不是编一个结论。运维最怕假的确定性。
诊断 Agent 还要支持“只生成命令，不执行”。值班人员可以先审查它准备查什么，再选择执行。这个模式很适合刚上线阶段：既能减少手敲命令的负担，又能让团队观察 Agent 的思路是否靠谱。等信任建立后，再放开部分只读自动执行。
隐私也要考虑。日志中可能有用户信息、token 和内部地址。Agent 把证据发给模型前要脱敏，审计日志里也不要保存完整敏感内容。
五、总结
故障诊断 Agent 的设计重点是权限边界、命令分级、只读优先和审计可追溯。先做证据收集和诊断报告，再逐步开放低风险自动化。能查命令很有用，知道不能乱改更重要。
