从架构设计的角度聊聊我对 AI Ops 未来技术路线的一些思考。为什么我要写这篇文章过去几年AI Ops 已经不是一个陌生的词。很多企业都在做 AI Ops。很多厂商也在宣传 AI Ops。但如果仔细去看大部分所谓的 AI Ops本质上仍然停留在日志分析异常检测告警聚合规则推荐根因分析RCA这些能力大多数依赖于机器学习Machine Learning、统计分析和规则引擎Rule Engine。虽然能够提升一定效率但距离真正意义上的智能运维仍然有很大的差距。而 2024 年以后大语言模型LLM的出现我认为真正改变了 AI Ops 的发展方向。今天想结合自己的学习和实践聊聊我理解的下一代 AI Ops 技术架构。一、传统 AI Ops 为什么一直没有真正普及如果把时间往前推几年。很多公司都会建设类似这样的平台Prometheus │ AlertManager │ 告警平台 │ 规则引擎 │ 短信 / 企业微信整个流程其实很成熟。但是仍然存在几个问题。例如凌晨两点。Prometheus 连续发送十几个告警。CPU 90%Memory 95%Disk IO HighPod RestartJava GCNginx 502Redis Timeout对于值班工程师来说。第一件事情不是解决问题。而是登录服务器。top free -h df -h docker ps kubectl get pod journalctl tail -f jps netstat真正耗费时间的并不是分析。而是收集信息。很多企业每天都有几十甚至几百次这样的重复劳动。所以传统 AI Ops 更多解决的是告诉你哪里出了问题。却没有真正解决帮你定位为什么出了问题。更谈不上自动完成修复。二、大模型真正改变了什么很多人认为ChatGPT 可以聊天。Claude 可以写代码。DeepSeek 可以回答问题。其实这些都只是表现形式。真正改变行业的是LLM 第一次拥有了理解上下文和推理能力。举个最简单的例子。传统规则引擎。CPU 90% 发送告警。机器学习。CPU 最近一周异常。 发送告警。而 LLM 可以做到CPU 90% Java Full GC Redis连接正常 MySQL正常 Docker正常 日志出现OutOfMemoryError 综合判断 JVM堆内存不足导致CPU持续升高。这已经不是规则判断。而是在做推理Reasoning。这也是为什么越来越多的人开始说LLM 才是真正意义上的 AI Ops 大脑。但是。如果只有大模型。事情并没有结束。三、LLM 为什么不能直接做 AI Ops很多人第一次接触 GPT。都会有一个误区。认为GPT AI Ops实际上完全不是。举一个例子。你问 GPT帮我看看生产服务器 CPU 为什么这么高GPT 根本不知道你的服务器 IP。Prometheus 数据。Grafana 指标。Docker 容器。Kubernetes 集群。日志文件。数据库连接数。甚至不知道你的 Linux 是 Ubuntu 还是 CentOS。换句话说。LLM 没有企业运行时上下文Runtime Context。它只能回答应该怎么排查。却不能真正参与排查。因此一个真正可落地的 AI Ops 系统仅靠 LLM 是远远不够的。它需要能够获取数据、理解数据并进一步执行操作。这也引出了后续几个关键能力RAG、Agent 和 MCP。四、RAG让 AI 拥有企业知识而不是只会通用答案很多人把 RAG 理解成知识库。实际上我更倾向于把它理解为让 LLM 获得企业私有上下文的一种能力。例如一个运维工程师每天都会接触到大量企业内部信息CMDB 资产信息Kubernetes 集群配置Docker 镜像规范Jenkins 发布流程历史故障处理记录Nginx 配置模板Prometheus 告警规则企业 Wiki运维手册标准操作流程SOP这些内容大模型本身并不知道。如果没有这些上下文它给出的回答往往只是通用建议。而 RAG 的价值就在于当用户提出问题时系统会先从企业知识库中检索相关内容再将这些内容作为上下文提供给 LLM让模型基于企业真实环境进行分析而不是凭借公开知识猜测答案。例如用户 为什么订单服务一直重启RAG 检索到的信息可能包括该服务部署在 KubernetesJVM 最大堆内存配置为 2G上周出现过同类故障历史处理方式为调整 Heap 参数并优化缓存配置此时大模型的回答就不再是泛泛而谈而是能够结合企业历史经验给出更具针对性的分析。五、AgentAI Ops 不只是会回答而是会完成任务很多人第一次接触 AI Agent 时会认为它只是一个更聪明的聊天机器人。实际上我认为Agent 才是真正让 AI Ops 从辅助工具迈向智能系统的关键。我们可以先看一个最简单的场景。凌晨两点监控平台突然推送一条告警订单服务 CPU 持续 95%响应时间超过 3 秒。如果是传统运维流程大多数工程师会这样处理① 登录堡垒机 ↓ ② SSH 到目标服务器 ↓ ③ top 查看 CPU ↓ ④ free -h 查看内存 ↓ ⑤ docker ps / kubectl get pod ↓ ⑥ 查看应用日志 ↓ ⑦ 查看 JVM ↓ ⑧ 判断问题原因 ↓ ⑨ 重启服务 ↓ ⑩ 写故障报告整个流程需要人工不断切换工具、收集信息再依靠经验完成判断。如果把这些步骤拆开来看会发现真正需要人决策的其实只有最后两三步。前面的工作几乎都是固定流程。而 Agent 的价值就是把这些流程组织起来。它不是简单回答一句建议执行 top 命令查看 CPU。而是能够主动规划任务。例如用户 分析订单服务为什么 CPU 持续过高。 Agent ✓ 获取服务器信息 ✓ 获取 Prometheus 指标 ✓ 获取 Grafana 最近一小时趋势 ✓ 查看 Kubernetes Pod 状态 ✓ 查看 JVM GC 日志 ✓ 分析应用日志 ✓ 判断异常原因 ✓ 输出处理建议注意这里有一个非常重要的区别。以前LLM Thinking思考现在Agent Thinking Planning思考 规划很多人把 Agent 理解成大模型。其实它更像一个项目经理。LLM 负责分析。Agent 负责组织整个执行流程。所以我更喜欢一句话LLM 决定怎么想Agent 决定怎么做。六、MCP为什么它正在成为 AI Ops 的基础协议如果说 Agent 决定做什么。那么 MCP 决定怎么去做。很多人第一次看到 MCP都觉得它和 API 没区别。其实并不是。我们先看看以前 AI 调用工具是什么样的。例如AI 要查询服务器 CPU。开发者需要自己写Python ↓ SSH ↓ Linux ↓ 返回结果 ↓ 解析 JSON ↓ 交给 GPT如果今天要查询 Docker。再写一套。查询 Kubernetes。继续写。查询 Jenkins。继续写。查询 MySQL。继续写。查询 Redis。继续写。每增加一种能力就意味着增加一套接口。对于 AI 来说这些工具都是彼此孤立的。而 MCPModel Context Protocol的出现就是为了统一这种调用方式。你可以把它理解成AI 世界里的 USB 接口。过去每个工具都有自己的插头。现在只要支持 MCPAgent 就能够按照统一协议发现、调用和组合这些工具。这意味着未来的 AI Ops 平台不需要为每一种运维能力单独适配一套逻辑而是可以通过 MCP 将 SSH、Kubernetes、Prometheus、Jenkins、CMDB、工单系统等能力统一接入。对于开发者来说最大的变化不是少写几个接口而是整个系统开始具备可扩展性。今天接入一个 Kubernetes MCP Server。明天接入一个 Prometheus MCP Server。后天接入企业内部 CMDB。Agent 不需要重新学习只需要知道这里有一个新的工具我可以调用。这就是 MCP 真正的意义。七、真正的 AI Ops不是一个模型而是一套协同架构很多文章都会画这样一张图用户 │ LLM │ 回答但如果真的把 AI Ops 落地我认为真正的架构应该更像下面这样。用户 │ Web / Chat UI │ AI Orchestrator Agent 调度中心 ┌──────────────┐ │ Prompt Engine │ │ Memory │ │ Planner │ │ Workflow │ └──────────────┘ │ LLM 推理分析 │ ┌────────────┼────────────┐ │ │ │ RAG MCP Tools │ │ │ 知识库 Prometheus SSH CMDB Kubernetes Docker SOP Jenkins MySQL 历史故障 Grafana Redis │ 执行结果返回 │ AI 总结分析 建议 │ 用户很多人会问为什么这里没有把 LLM 放在最中心因为真正决定 AI Ops 能力上限的不是模型本身而是模型能够接触到多少真实世界的信息以及能够完成多少真实世界的操作。一个再强的大模型如果无法访问监控、日志、配置、知识库它依然只能给出理论上的建议。反过来一个具备完善上下文、工具调用能力和执行能力的系统即使底层模型不是最强也能够完成大量实际工作。所以在我看来未来 AI Ops 的竞争不只是模型之间的竞争更是架构设计能力的竞争。八、从Copilot到Autopilot才是 AI Ops 的真正方向过去两年我们听到最多的一个词是AI Copilot智能助手。Copilot 的特点是帮你写命令。帮你分析日志。帮你解释报错。帮你生成脚本。它提高了效率但最终仍然需要工程师自己执行。而我更期待的是下一阶段Autopilot自动驾驶式运维。例如Prometheus 检测到异常。↓Agent 自动启动故障分析流程。↓调用 MCP 获取日志、监控和配置。↓RAG 检索历史故障。↓LLM 综合推理。↓执行预定义的修复策略。↓验证恢复结果。↓自动生成故障复盘。↓通知相关负责人。整个过程人更多扮演的是审核者而不是执行者。当然这并不意味着所有操作都应该自动完成。对于涉及生产环境的重要变更我认为仍然应该保留人工确认机制让 AI 成为可靠的执行助手而不是完全脱离监管的操作者。九、为什么我认为未来的运维工程师都会成为 AI 工程师很多人最近都在讨论一个问题AI 会不会取代运维我的答案一直都是不会。但我认为AI 会重新定义运维。过去十几年运维工程师的发展轨迹其实很清晰。最早我们维护的是物理服务器。后来进入虚拟化时代。再后来进入云计算时代。随后是 Docker。然后是 Kubernetes。现在大模型开始成为新的基础设施。回头看会发现每一次技术变革都没有让运维消失而是不断提高了运维工程师的能力上限。以前一个运维可能每天登录几十台服务器。后来通过 Shell 脚本批量执行。再后来Ansible、SaltStack、Terraform 等自动化工具让我们开始用代码管理基础设施。今天Agent 和大模型则开始帮助我们管理自动化本身。变化的不是运维这个岗位而是工程师解决问题的方式。以前我们需要记住大量 Linux 命令。后来我们开始封装脚本。现在我们更需要思考如何设计一个 Agent如何组织一个自动化工作流如何让 AI 理解企业知识如何保证 AI 执行操作时安全、可追溯、可回滚这些问题本质上已经不是传统运维的问题而是系统设计的问题。未来优秀的运维工程师我认为会越来越像平台工程师Platform Engineer和 AI 应用工程师。他们关注的不再只是机器有没有问题而是系统是否具备持续自我优化的能力。十、为什么我开始尝试构建自己的 AI Ops 平台写这篇文章并不是因为我已经做出了一个成熟的 AI Ops 产品。恰恰相反我还在不断学习、实践和验证。但在这个过程中我越来越确信一件事AI Ops 不应该只是一个聊天窗口。我希望它能够真正参与到运维工作中。例如当用户输入一句话帮我分析为什么订单服务一直重启。系统不应该立即把这个问题丢给大模型。而应该先完成一系列上下文收集① 获取服务信息 ↓ ② 查询 Kubernetes Pod ↓ ③ 获取最近一小时监控指标 ↓ ④ 获取容器日志 ↓ ⑤ 检索历史故障知识库 ↓ ⑥ 获取最近发布记录 ↓ ⑦ 综合分析 ↓ ⑧ 输出故障原因 ↓ ⑨ 给出修复建议 ↓ ⑩ 根据权限执行修复对于用户来说他看到的是一句自然语言。而在系统内部其实已经完成了一次完整的自动化工作流。这也是我目前正在尝试实现的平台方向。在我的设想中它不会局限于某一种模型而是采用可插拔的架构让模型、知识库和工具能力都能够独立演进。例如模型层支持 OpenAI、Claude、GLM、Qwen、DeepSeek 等不同 LLM。知识层接入企业 Wiki、CMDB、运维手册、历史故障库实现 RAG 检索。工具层通过 MCP 接入 Kubernetes、Docker、Prometheus、Grafana、Jenkins、数据库等能力。工作流层负责规划、调度、权限控制和异常处理。应用层提供巡检、故障分析、发布辅助、智能问答、自动修复等场景能力。这样的设计不是为了追求技术栈的新而是为了让整个系统具备持续扩展能力。今天新增一个监控系统不需要重构整个平台。明天更换一个大模型也不需要推翻已有架构。这才是真正面向未来的平台设计。十一、AI Ops 的价值不只是提高效率很多人在谈 AI 时都会强调降本增效。这当然没有错。但如果只把 AI 看成一个效率工具我认为还是低估了它。对于运维来说更重要的是把经验沉淀下来。一个企业里总会有几位经验丰富的工程师。他们知道哪个服务最容易出问题。哪个告警可以忽略。哪个日志意味着数据库异常。哪个错误通常是网络导致。但这些经验大多数都存在人的脑子里。新人需要一年甚至几年才能逐渐积累。而 AI Ops 最大的价值之一就是把这些经验逐渐沉淀成可检索、可推理、可复用的知识体系。它不会替代经验丰富的工程师。却可以让整个团队共享这些经验。这也是为什么我认为未来企业真正重要的不只是拥有一个先进的大模型而是拥有属于自己的运维知识资产。写在最后如果把 AI 看成一个时代。那么我认为现在可能只是开始。过去几年我们经历了云计算、容器化、DevOps、Kubernetes 的快速发展。今天大模型正在成为新的基础设施。未来几年我们或许会看到越来越多的软件不再以功能作为核心而是以Agent作为核心。越来越多的平台也不再只是提供界面而是提供能够自主完成任务的智能体。对于运维来说这既是挑战也是机会。我们需要学习的不再只是 Linux、Docker、Kubernetes。还需要理解 LLM、RAG、Agent、MCP、Workflow以及如何把这些能力真正落地到企业场景中。这也是我最近一直在学习和实践的方向。希望未来能够通过自己的项目把 AI 从一个回答问题的工具真正变成一个能够参与运维工作的伙伴。如果你也在关注 AI Ops、Agent、MCP 或企业 AI 应用欢迎一起交流。技术的发展从来不是一蹴而就但每一次认真思考和实践都会让我们离未来更近一步。