夜雨聆风专注硬核工程实践 · 只写可投产的企业级方案 · 聚焦 SRE Agent · 大模型落地 · 分布式架构 · 拒绝拼凑式干货
前段时间参加一个内部技术评审，听一个团队汇报"基于大模型的智能告警降噪"方案。
PPT 翻到中间，我打断他们问了一个问题：
你们这件事，为什么非要用大模型？
汇报的同学愣了一下，回答："因为是 AI 项目啊。"
我说：告警降噪本质上是规则匹配 + 频率统计 + 同类聚合，传统方案十几年前就解决了。你们用 LLM 做这件事，效果上不会有质变——但成本完全是另一个量级。我给他们算了笔粗账：一条规则降噪几乎零成本，换成每条告警都过一次大模型，按当时的 Token 价格，一天几万条告警(业务足够大的时候，真的有，不夸张)光推理费就是一笔不小的开销，而且降噪准确率未必比成熟规则高。你们想清楚为什么要花这个钱吗？
会议室安静了好一会儿。
后来项目方案改了，把降噪那部分换成传统规则 + 聚类，把"告警分诊后的根因推理"那一段留给了大模型。这种切割之后，整个方案才在工程上立得住。
类似的场景这两年我看了不下二十次。绝大多数"AI 运维项目"翻车，不是技术不行，是从一开始就没想清楚自己要解决的是哪类问题。
这一篇想跟你聊清楚一件事：
AI 装进运维体系，到底是在解决什么问题？哪一类问题该用什么技术？
抛开"代"这个伪概念
写之前我得先吐槽一下行业里那个流传甚广的分代叙事——"先有智能运维，再有 AIOps，最后是 SRE Agent"。
这种叙事听起来顺，工程上不成立。理由很简单。
第一，这三个词不在同一个分类轴上。
"智能运维"是中文圈一个泛泛的翻译性叫法。 "AIOps"是 Gartner 在 2016 年造出来的市场分析师术语。 "SRE Agent"是这两年技术社区还在形成中的产品形态描述，连个权威定义都还没有。
让这三个词站在一起对比"本质区别"，相当于让"白领""管理岗""数字员工"三个词去对比——它们根本不在同一根轴上，强行对比就是为了凑章节而凑章节。
第二，真实工程史不是这么走的。
当年做规则引擎的工程师，并没觉得自己在做"智能运维 1.0"，等着被未来的 AIOps 取代。 做 LSTM 异常检测的也不会觉得自己等着被 LLM Agent 取代。每个时代的工程师都在解决当时手头最棘手的问题，用当时手头最合适的工具。
第三，分代叙事暗含一个错误结论：新一代取代旧一代。
工程现实恰恰相反——规则引擎、ML 模型、LLM 在生产环境里永远共存。每一种解决一类完全不同的问题。让 LLM 去做规则引擎能搞定的事，是过度工程；让规则引擎去做 LLM 才能干的事，是力不能及。
所以这一篇我们抛开"代"这个伪概念。换一个工程师的视角问问题：
一个 SRE 在日常工作里，AI 能帮上忙的位置到底有哪些？每个位置，用什么技术最合适？
从一个 SRE 的真实工作日开始
想象一个真实的 SRE 工作日。早上 9 点到岗，到下午 6 点下班，他会做这些事：
看监控大盘，扫一眼夜间告警
处理几个昨天没关掉的工单
收到一个业务方反馈"系统好像变慢了"，去定位
参加一个变更评审，看几条上线
处理午后的容量告警，决定要不要扩容
帮另一个团队排查一个奇怪的网络问题
下班前更新一下昨晚故障的复盘文档
把这一天的事拆开来看，每件事的本质都不一样。
有些是重复劳动——每天 9 点扫告警，规则非常固定。 有些是找规律——大盘上突然多了一个不寻常的尖峰，到底是不是真异常？ 有些是复杂推理——业务说慢了，可能是网络、可能是应用、可能是数据库、可能是缓存击穿，得综合上下文判断。 有些是串系统——排查一个网络问题要查监控、查日志、查变更、查 CMDB、查工单，每一步都在不同的系统里。
这就是 AI 能进入运维体系的 4 个位置，对应 4 类截然不同的工程问题。
第一类：重复劳动自动化
特征：任务高度结构化、规则可枚举、不需要任何"理解"。
典型场景：
每天定时巡检，把固定指标拉出来生成日报
告警进来后按规则路由到对应团队
工单按关键词归类
凌晨自动跑一次容量盘点
这一类问题的最优解是什么？
规则引擎 + 自动化脚本 + 定时任务。
不需要 AI、不需要 ML、不需要 LLM。
为什么强调这一点？因为这一类问题的边界非常容易扩张。一个规则系统跑了三年，最早只是每天发份日报，慢慢加上"异常自动告警"、再加上"自动扩容"、再加上"自动开工单"——很多团队会觉得"反正都已经做了，再上点 AI 是不是更智能"。
错。这一类问题的核心特征是"已知场景 + 已知动作"。已知场景上 LLM，等于雇了个博士去看大门——做得了，但贵、慢、过度设计。
我们自己平台的每日健康巡检最早是用 LLM 做的。后来发现 80% 的巡检项是固定的——查某个指标、判断是否超阈值、生成一段固定模板的描述。这部分跑 LLM 纯属浪费 Token。后来重构成 "规则引擎跑 80% 的常规检查 + LLM 只做 20% 的复杂诊断"，整体推理成本降了 70%，速度还快了。
判断标准很简单：如果一件事的所有可能输入和输出你都能用 if-else 写出来，就别上 AI。
第二类：数据规律识别
特征：输入是海量数据、输出是规律或异常、人没办法直接看过来。
典型场景：
监控指标的异常检测
日志聚类、找出异常模式
时序预测（容量预测、负载预测）
故障聚类（这一批告警背后是不是一个根因）
这一类该用什么？答案很干脆：传统机器学习。LSTM、孤立森林、KMeans、Prophet——这些算法在这一类场景里比 LLM 强一个数量级。
为什么？
第一，便宜。一个异常检测模型部署起来，一台普通机器每秒处理几千条指标毫无压力，边际成本几乎为零。同样的吞吐量让 LLM 扛，光推理集群的账单就能让老板找你喝茶。
第二，稳定。传统 ML 是确定性的数值计算，同样的输入永远给同样的输出，结果可复现、可回归测试。LLM 不是——即便把 temperature 压到 0，受浮点运算顺序、并发批处理、服务端版本变动等因素影响，同样的输入也可能给出措辞甚至结论不同的回答。这种不可复现性，放在每分钟刷过成千上万条的告警流上，是会出事的。
第三，专业。LLM 不擅长数值规律。让它对一段时序数据做异常检测，准确率远不如一个跑了三年的孤立森林。这是模型形态决定的，不是 prompt 工程能救的。
那 LLM 在这一类问题里完全没用吗？也不是。
有用的地方在于"让 ML 的结果变得人能看懂"。比如孤立森林告诉你"这个时间段的指标异常分数是 0.87"，SRE 看不懂这个 0.87 意味着什么。让 LLM 接在 ML 后面，把"异常分数 0.87"翻译成"在过去 14 天的同时段里，QPS 涨幅超过 95% 分位线，结合上下游变更记录，疑似上游服务 A 的发布导致"——这才是 LLM 该干的活，做"翻译官"，不是做"算法本体"。
日志分析也是同样的分工。海量日志先用聚类算法压成几十个模式簇，这一步是纯粹的数据处理，LLM 插不上手也不该插手；但聚类出来的簇是一堆机器看的特征，让 LLM 接在后面把"簇#7，出现 3 万次，特征是 connection reset"翻译成一句人能懂的"下游某服务大面积连接重置，疑似网络或对端过载"，这一步才是 LLM 的价值。底层找规律交给 ML，顶层讲人话交给 LLM，这是这一类问题里最稳的分工方式。
第三类：复杂场景推理
特征：输入是非结构化的、上下文跨多个领域、判断依赖经验和常识。
典型场景：
业务方说"系统慢了"，到底是哪儿慢了
一条告警进来，到底是真故障还是误报
一次故障涉及网络、应用、数据库三个域，根因在哪
这个工单该派给哪个团队
到了这一类，LLM 才终于站到了舞台中央——LLM Agent + 工具调用，这是它在运维领域最适合也最不可替代的位置。
为什么这一类问题别的技术做不了？
规则引擎做不了。因为这一类问题的可能性空间永远穷举不完。"系统慢了"背后的原因有几百种，你写不完所有 if-else。
传统 ML 做不了。因为这一类问题需要的不是"找规律"，是"做推理"——综合上下文、调用相关工具、根据中间结果决定下一步查什么。这是一个动态决策过程，不是一个分类任务。
人能做，但人贵且慢。一个有经验的 SRE 处理这种问题平均要 20~40 分钟，其中 80% 时间花在"把分散在不同系统里的信息拼凑起来"上。
LLM Agent 的价值就在这里——它有常识、能推理、能主动调工具去查信息、能把分散的上下文综合起来。它不需要 100% 准确（人也做不到），它需要的是把那 80% 的信息搬运工作干掉，让 SRE 专注在最后的决策上。
我们自己平台一个 K8s 排障 Agent，平均一次排障调 8~12 个工具——查 Pod 状态、查 Node 资源、查 Event、查相关变更、查依赖服务、查上下游告警……最后输出一份带依据的诊断报告。SRE 看完一眼就能判断"对，根因就是这个"或者"不对，再深一层"。原来要拉个群聊半小时才能拼完的信息，现在 30 秒就齐了。
这才是 LLM 真正该干的活。
第四类：跨系统协同
特征：任务本身不复杂，但需要跨多个工具/系统串联完成。
典型场景：
收到一个工单，要查 CMDB 找到对应业务、查监控看当前指标、查变更看是否近期有发布、查日志看错误码——最后回工单
处理一次扩容请求：查资源、申请配额、提变更单、走审批流、执行 kubectl
故障复盘：拉时序数据、拉调用链、拉相关工单、拉历史相似故障——拼成一份复盘文档
这一类用的技术跟第三类是同一套——LLM Agent + 工具调用 + 工作流编排。但跟第三类比，重点不一样。
第三类的难点在"推理"——下一步要查什么、怎么解读中间结果。 第四类的难点在"编排"——任务本身的步骤是固定的，但每一步要调不同系统的不同工具，参数要在工具间传递，错了要能回退。
这一类问题在传统 RPA / 工作流引擎里其实有解。但 RPA 的问题是写死的脚本不灵活——业务一变就要改脚本，每次变更都要重新发布，运维成本极高。
LLM Agent 在这一类问题里的优势是自然语言驱动 + 灵活适应。SRE 用一句话描述"帮我把这个工单走完"，Agent 会自动拆解、自动调工具、自动处理中间状态——业务变了不用重写脚本，改 prompt 就行。
但这一类应用有一个很容易掉的坑：很多团队会把"重复劳动自动化（第一类）"硬塞进这一类，套个 Agent 壳子就上生产。
举个例子。"每天 9 点拉一次集群健康指标，超阈值发企微告警"——这是第一类问题，规则脚本五行代码搞定。但有团队非要做成"Agent 自主巡检"——LLM 决定要拉哪些指标、LLM 判断是否超阈值、LLM 决定发不发告警。这套链路看起来高级，但每天烧的 Token 钱够请人手工巡检三个月。
记住一个朴素判断：如果一件事每次都按完全一样的步骤跑，就别上 Agent，写脚本就好。Agent 的价值在"每次步骤可能不一样，需要根据中间结果灵活决策"——只有这种动态性才值得为 LLM 那点 Token 付费。
一张选型对照表
把上面四类总结成一张表：
这张表本质上回答了一个问题：LLM 不是万能解药，它有自己的位置。
强行让 LLM 去做不属于它的事情，结果就是开篇那个团队——多花了几个数量级的成本，换来一个没有质变的结果。
那些"AI 秀花活"的，到底不合适在哪？
回到这篇开头那个反复出现的问题：那 95% 在秀花活的 AI 运维内容，到底错在哪？
复盘下来，错的从来不是技术，是根本没在第一步问自己"我要解决的是哪一类问题"。
他们的真实流程通常是这样的：
看到 LLM 火了，老板说要做 AI 项目
找一个看起来"AI 一点"的运维场景
把这个场景包装成 LLM 能干的事
上线后发现没人用，或者成本爆炸
他们没问的是：
我要解决的是 4 类问题里的哪一类？
这一类问题，最便宜最稳定的方案是什么？
我用 LLM 是因为它最合适，还是因为它最时髦？
这三个问题问完，至少 60% 的 AI 运维项目根本不应该立项——它们要做的事，根本不需要 LLM。
对你下一个项目的实用建议
如果你最近在准备一个 AI 运维项目，立项前可以尝试把下面这三步走完。
第一步，把项目要做的所有事情列出来，逐项归类。是第一类、第二类、第三类还是第四类？很多项目你写到一半就会发现"这玩意儿其实就是个定时脚本"——那就坦诚做个定时脚本，别硬包成 AI 项目。
第二步，对每一类挑最合适的技术。第一类的部分用规则引擎，第二类的部分用传统 ML，第三类、第四类的部分才上 LLM Agent。让每一种技术干自己擅长的事，整体方案的成本和稳定性会比"全栈 LLM"好一个数量级。
第三步，在方案里明确写出"我们为什么不用 LLM 做 X 这部分。
这一步很重要。不写出来，团队后续做着做着就会"为了统一架构方便"把所有事都揉到 LLM 里——然后慢慢就回到了那个又贵又慢又不稳的状态。
这一步本质上是在白板上把"工程边界"画清楚。AI 落地最难的从来不是把 LLM 塞进去，而是知道在哪儿停下。
写在最后
这一篇的核心想法只有一个：别再被那些花里胡哨的概念词带歪节奏了。
智能运维也好，AIOps 也好，SRE Agent 也好——这些词代表的不是"技术代际"，是"市场叙事"。
工程师该问的问题永远只有一个：我要解决的这件事，最合适的技术是什么。
把这件事想清楚，比追十个新概念都管用。
AI不过是放大能力的杠杆，而真正撬动效率的支点，永远是人的硬核实力(想了想，还是写了这句话，最近感触颇深)
下一篇会进入正题——企业级 SRE Agent 完整架构拆解。我会把我们自己平台的分层架构画出来，每一层是干什么的、为什么这么分、踩过哪些坑才定下来这套结构。看完那一篇，你应该能直接拿来对照自己的设计了。
每周固定更新1篇，随机性1篇
关于作者
阿菜——深耕 AI 工程与 SRE 基建，只分享可投产的企业级方案。
公众号：阿菜说技术
承蒙关注，执笔相酬
