聊《做过运维的人学大模型哪些经验可以直接迁移》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要做过运维的都知道写脚本和建平台是两码事。以前我们搞自动化逻辑是线性的if 告警A then 执行B。出了问题看日志找根因手动或脚本恢复。整个过程是确定性的权限也是明确的——用户有 sudo 权限或者应用有特定的 API Token。现在转做 AIOps Agent很多人以为就是把这套逻辑换成 LLM 调用。我一开始也是这么想的结果第一个 Demo 跑通后真正让我头疼的不是模型选哪个而是谁授权了这个 Agent 执行命令执行了什么有没有审计这也是为什么最近行业风向变了——从比拼 Demo 的多功能转向比拼权限控制、日志可观测和审批流程。对于运维背景的同学这其实是你的主场。目录运维能力的迁移从“确定性脚本”到“概率性 Agent”日志分析从“关键词匹配”到“语义归因”告警归因让 Agent 做“初级 SRE”自动处置 Agent最危险也最有价值的环节安全与审批Agent 上线的生死线总结运维能力的迁移从“确定性脚本”到“概率性 Agent”运维转大模型最大的优势不是会写 Python而是对“系统稳定性”和“边界条件”的直觉。在传统的 Ansible 或 Shell 脚本里你很清楚每一步的输出是什么失败会返回什么错误码。但 Agent 不同它是基于概率的。你给 LLM 一个工具定义它可能会1. 正确调用工具并解析结果。2. 幻觉出一个不存在的工具。3. 调用了正确的工具但参数格式错误。4. 成功执行但返回的结果超出了你的预期范围。我的观点 不要试图让 Agent 变得“聪明”首先要让它变得“可控”。运维工程师的思维模型应该是把 Agent 当作一个不可信的外部服务通过严格的权限和日志来约束它。日志分析从“关键词匹配”到“语义归因”以前分析日志我们靠 grep 关键字或者 ELK 的可视化面板。现在我们可以让 Agent 去读日志。但这里有个坑不要直接把整个日志文件丢给 LLM。生产环境的日志量是巨大的既贵又慢还容易超出上下文窗口。实战建议1. 预过滤先用传统规则如 Promtail Loki 的标签查询缩小范围只把最近 5 分钟的 ERROR 级别日志喂给模型。2. 结构化输出要求 Agent 返回 JSON 格式的分析结果包括异常类型、可能原因、建议操作。3. 可观测性优先在 Agent 内部埋点记录“它读了什么日志”、“它得出了什么结论”。这比模型本身更重要因为你需要复盘它的推理过程。# 简单的日志分析 Agent 片段示例 def analyze_logs(log_entries: List[str], context: str) - dict: # 1. 预过滤只取 ERROR/WARN filtered [l for l in log_entries if ERROR in l or WARN in l] # 2. 构造 Prompt强调基于证据 prompt f 请分析以下系统日志找出根本原因。 上下文{context} 日志片段 {filtered[-10:]} # 只取最近10条 请以 JSON 格式返回 {{ root_cause: 简要描述, evidence: [引用的日志行], confidence: 高/中/低 }} return llm_call(prompt)告警归因让 Agent 做“初级 SRE”告警风暴是运维的噩梦。以前我们用 PagerDuty 或自研平台做告警聚合现在可以让 Agent 参与归因。关键取舍不要让 Agent 直接决定“是否抑制告警”。要让 Agent 生成“归因报告”由人或规则引擎做最终决策。我见过一个案例团队让 Agent 自动抑制重复告警结果模型误判把真正的 P0 故障当成了噪音导致故障持续时间延长了 20 分钟。教训是Agent 适合做“助手”不适合做“守门员”除非你有极强的兜底机制。自动处置 Agent最危险也最有价值的环节这是运维转大模型最核心的战场。以前我们用脚本自动重启服务、扩容、回滚配置。现在我们可以让 Agent 根据告警内容自动执行处置流程。但这里有一个巨大的鸿沟Demo 能跑通生产不敢用。为什么因为权限。在 Demo 里你可能给了 Agentsudo权限或者一个拥有所有资源写权限的 K8s ServiceAccount。在生产环境你必须遵循最小权限原则。我的实践1. 工具白名单Agent 只能调用预定义的工具如restart_service,scale_pod不能执行任意命令。2. 权限隔离每个工具对应一个独立的、权限最小的凭证。例如重启服务的凭证只能重启特定命名空间下的 Pod。3. 审批流程对于高危操作如删除资源、修改核心配置Agent 必须触发人工审批。# 工具定义示例只允许重启不允许删除 TOOLS [ { name: restart_service, description: 重启指定服务, parameters: { service_name: {type: string, enum: [api-gateway, user-service, payment-service]} }, permission: revoke_on_failure # 失败后撤销权限 }, # 没有 delete_service 工具防止模型幻觉执行删除 ]安全与审批Agent 上线的生死线这也是我最近踩坑最多的地方。问题 1Prompt 注入如果 Agent 的输入来自用户如运维工单恶意用户可能通过 Prompt 注入让 Agent 执行非预期操作。对策 对用户输入进行严格过滤使用系统提示词System Prompt明确边界并记录所有输入输出。问题 2执行审计Agent 执行了什么命令谁授权的结果如何对策 建立统一的审计日志平台记录 Agent 的每一次工具调用、参数、返回值。这不仅是安全要求也是故障复盘的依据。问题 3回滚机制如果 Agent 执行错误如何快速回滚对策 所有自动处置操作都必须有对应的回滚脚本或 API。Agent 执行后必须触发一个“验证”步骤确认系统状态正常。总结运维转大模型不是从零开始而是经验迁移。你已有的运维知识——对系统稳定性的理解、对权限的敏感、对日志的可观测性要求——正是当前大模型应用从 Demo 走向生产所最缺的。给想转型的同事几点建议1. 不要只学 LangChain/LlamaIndex要深入理解权限模型和审计日志。2. 从小场景入手先做一个“只读”的日志分析 Agent再逐步扩展到“受限执行”的处置 Agent。3. 把安全当第一优先级Demo 跑通只是开始生产环境能稳定运行、可审计、可回滚才是真正的能力。大模型不会取代运维但会用大模型且懂安全规范的运维会取代只会写脚本的运维。这趟路我还在走坑也还在踩。但方向是清晰的从自动化脚本走向可控的 AIOps Agent。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。