运维转大模型：把脚本换成 Agent，我踩过的坑都在权限和日志里

聊《我用运维经验做了次 AI 项目最先失效的是旧方法》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。摘要很多 SRE 转型做 AIOps 时习惯把旧版 Shell 脚本直接扔给大模型重写结果上线即崩。本文复盘一次从自动化脚本转向 Agent 的实际过程重点拆解日志预处理、告警归因的边界、执行权限隔离以及回滚兜底策略。不讲概念只讲生产环境里真正能跑通的工程取舍。目录运维能力的迁移从确定性脚本到概率型决策日志分析大模型不是预言机需要结构化投喂告警归因RAG 接历史工单别让它靠直觉猜自动处置 Agent工具定义里的权限硬约束安全与审批上线前的回滚、监控与异常兜底总结给运维工程师的几条实在建议---运维能力的迁移从确定性脚本到概率型决策以前做自动化逻辑是树状的如果 CPU 85%重启 Nginx如果磁盘满清理/var/log。写 Bash 或 Python 脚本时每一步都确定出错直接抛异常回滚靠 Git 或版本控制。换成大模型后逻辑变成了图。Agent 不再按固定分支走而是基于观察、推理、调用工具、再观察的循环。我第一次把旧版巡检脚本改造成 ReAct 模式时以为只要把命令列表喂给模型就行。结果测试环境跑得很顺一上预发环境就开始“自由发挥”该查端口时去查了内存该拉取配置时发了个ping。这不是模型蠢是执行范式变了。确定性脚本追求的是“不犯错”概率型 Agent 追求的是“在噪声中找最优路径”。转型第一步不是学 Prompt而是重新设计状态机明确哪些动作必须人工确认哪些可以自动重试哪些失败后直接熔断。把模糊的“智能”拆成可度量的阈值Agent 才能进生产。日志分析大模型不是预言机需要结构化投喂线上出问题时老运维第一反应是拉 Nginx access_log 或应用 error.log。直接把这些几十 MB 的文本丢进上下文窗口是大模型最容易翻车的地方。模型会迷失在无关请求里要么抓不住重点要么编造根本不存在的错误栈。我的做法是前置清洗层。日志还没进 Agent先过一遍正则提取和关键词过滤。保留时间戳、模块名、错误码、堆栈片段剔除心跳包、健康检查、重复刷新的行。处理后的 JSON 结构直接作为 Tool Input模型只需要做语义匹配和关联分析。下面是一个我在实际项目中用的日志预处理片段配合 LangChain 的工具调用import re import json from datetime import datetime def parse_and_filter_logs(raw_log_line: str) - dict | None: pattern r(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w)\] (\w) (.) match re.match(pattern, raw_log_line) if not match: return None timestamp, level, component, message match.groups() # 只保留 ERROR/WARN 级别且排除已知误报关键字 if level.upper() not in (ERROR, WARN): return None if any(kw in message.lower() for kw in [healthcheck, heartbeat, retry]): return None return { ts: timestamp, level: level, component: component, message: message.strip() }把脏数据挡在模型外面你的 Agent 推理延迟能降一半幻觉率也会明显下降。运维转大模型第一步其实是补齐数据工程的基本功。告警归因RAG 接历史工单别让它靠直觉猜Prometheus 报警响了Agent 怎么知道是不是最近那次灰度发布导致的纯靠 Prompt 写规则太脆弱换个依赖关系就失效。我引入了向量检索接历史故障复盘文档和临时工单但很快发现一个问题相似度匹配出来的文档往往包含大量无效信息模型注意力被分散归因结论越来越飘。后来加了置信度校验和路由层。向量库返回 Top-5 相关文档后先让一个轻量级分类器判断“是否强相关”。如果相关性得分低于阈值或者触发时间离现在超过 30 天直接降级为“未知原因转人工”。同时归因结果必须附带证据链哪条告警对应哪个变更记录哪个指标曲线出现了跳变。没有证据的结论运维不敢用。RAG 在运维场景里不是用来替代排查经验的它是记忆外挂。别指望它一次猜中根因它能做的是把散落各处的线索拼成一张可验证的网。自动处置 Agent工具定义里的权限硬约束Demo 阶段最舒服跑在本地容器里权限随便开随便删文件随便重启服务。一上生产权限黑洞就会让你付出代价。大模型天生倾向于“用最少的话完成任务”如果你给它留了 sudo 或者全量读写权限它大概率会踩线。我现在的规范是所有 Action 必须通过严格的 Schema 定义工具调用前强制 Dry-Run 校验。下面是我在实际架构里定义执行工具的约束写法from pydantic import BaseModel, Field from typing import Literal class ExecuteCommandInput(BaseModel): command: str Field(..., description待执行的运维命令) run_as: Literal[svc_user, root] Field(svc_user, description执行身份生产环境默认非特权用户) timeout_sec: int Field(30, le60, ge5, description命令超时上限) dry_run: bool Field(True, description是否仅预览不实际执行) def validate_command(cmd: str, user: str) - bool: whitelist [systemctl, journalctl, kubectl, curl, grep, awk] cmd_name cmd.split()[0] if cmd else if cmd_name not in whitelist: return False if user svc_user and any(bad in cmd for bad in [rm -rf, dd , chmod 777]): return False return True工具入口只做白名单放行和参数越界拦截。模型可以生成复杂命令但底层执行器负责把关。权限隔离不是限制 AI 的能力是保护基础设施不被随机应变的逻辑拖垮。安全与审批上线前的回滚、监控与异常兜底Agent 上线前我最先砍掉的是“全自动”的幻想。任何涉及写操作的流程默认必须经过二次确认或审批流。对于低风险操作比如拉取日志、查询 Pod 状态可以配置免审通道但依然要记录完整审计轨迹。兜底方案我做了三层1. 状态快照执行变更动作前自动保存当前配置或数据副本。一旦后续步骤报错立即触发回滚脚本。2. 熔断器连续两次调用同一工具失败或 Token 消耗超出预期预算直接切断该 Agent 的执行权推送告警到钉钉/企业微信。3. 可观测性埋点每个 Step 的输入输出、耗时、模型版本、Prompt 指纹全部入库。不是为了解决当前问题是为了下次迭代时能精准定位是逻辑错了、参数偏了还是数据脏了。运维的老本行是求稳AIOps 的核心竞争力也是稳。能把不稳定因素关在笼子里Agent 才有进生产的机会。总结给运维工程师的几条实在建议从传统自动化转到 AIOps技术栈的跨度其实没那么大。你熟悉的服务治理、指标监控、故障演练、权限管控都是搭建可靠 Agent 的基石。真正拉开差距的是思维模式从“我要让机器按我的指令走”变成“我要给机器划定边界让它自己找路”。如果你正在准备转型或面试简历里少写“精通 Prompt 调优”多写你如何设计工具契约、如何做权限分级、如何搭建日志清洗管道、如何配置熔断与回滚策略。企业现在不缺能跑通 Demo 的人缺的是能把概率型系统塞进确定性基建里的工程师。大模型应用早就过了拼跑分的热潮期。回到权限、日志和可观测这三个词把基本功打扎实你的运维经验不仅不会过时反而会成为 AGI 时代最硬的护城河。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。