聊《我用运维经验做了次 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, le=60, ge=5, 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大模型里的哪类内容。