用户只说了一句话运维闭环就在背后完成了意图识别、工具调度、API 调用、数据格式化四件事。我是韩先超51CTO 学堂 K8s、Python 教学总监、AIOps 实战训练营讲师云计算架构师具有 8 年项目实战经验5 年教学经验线上学员已达 300w。最近一直在折腾一件事能不能让运维这件事变得像跟同事聊天一样自然不用记 Jenkins 的 API 地址不用翻 Prometheus 的查询语法不用在五六个监控面板之间来回切。打开一个对话框说一句 帮我看看现在有哪些构建任务结果就出来了。听起来有点像科幻片其实用大模型MCPDevOps 工具链已经能跑通一个完整的闭环了。这篇文章我把这段时间的实践拆解一下聊透从思路到架构到代码层面的关键点。先说说运维人的日常困境做运维的朋友应该都有这种体验凌晨两点告警响了爬起来打开电脑先登 Jenkins 看构建状态再切到 Prometheus 查指标又跑到 Grafana 看趋势图最后还得去 K8s 里 describe 一下 Pod。一套操作下来人清醒了但排查效率其实不高 ——大量时间花在 切换工具 和 回忆命令 上。更头疼的是团队协作。新人来了光熟悉这一整套工具链就得一两个月。老员工脑子里装着各种 经验性操作但这些知识没法沉淀成可复用的操作手册。所以我一直在想能不能把运维操作的入口统一成 自然语言对话你想做什么直接说系统帮你调对应的工具、执行对应的操作、把结果整理好返回给你。对话式运维换个思路做运维所谓 对话式运维核心就一句话用自然语言作为运维操作的统一入口。你不需要知道 列出 Jenkins 任务 对应的 API 是哪个、参数怎么传你只需要说 列出所有任务。大模型负责理解你的意图然后通过 MCP 协议调用后端的 DevOps 工具去执行最后把结果用人类能看懂的方式返回。这背后其实是三个层面的联动AI 大模型负责意图理解、任务规划、结果总结。相当于你的 运维翻译官。MCPModel Context Protocol负责大模型和外部工具之间的通信协议。相当于 标准插座让大模型能安全、规范地调用各种运维工具。DevOps 工具链Jenkins、K8s、Prometheus、Zabbix 这些真正干活的工具。相当于 手和脚。三者配合就形成了一个大脑理解意图 → 协议调度工具 → 工具执行操作 → 结果反馈给大脑的完整闭环。技术架构拆解大模型MCPDevOps 三层联动架构整个架构从上到下分为三层第一层大模型层。我用的是 DeepSeek 大模型成本低、响应快对中文的理解也不错。这一层负责两件事理解用户的自然语言输入判断用户想做什么把工具返回的原始数据比如 JSON 格式的任务列表整理成人类可读的回复。第二层MCP 协议层。这是整个架构的 交通枢纽。MCP 定义了大模型如何发现工具、如何调用工具、如何接收工具返回结果的标准格式。有了它大模型不需要硬编码每个工具的调用逻辑而是通过标准化的接口去动态发现和调用。新增一个运维工具只需要写一个 MCP Server 接入大模型就能自动学会使用它。第三层DevOps 工具层。目前我接入的是 Jenkins支持列出任务、触发构建、查询构建状态这几个核心操作。后续可以扩展到 K8s查询 Pod、查看日志、扩缩容、Prometheus查询指标、告警分析、Zabbix告警确认、主机状态等。前端用 Streamlit 快速搭建了一个对话界面左侧配置连接信息右侧是对话窗口。原型阶段用 Streamlit 特别香几十行代码就能出一个能用的界面。闭环流程是怎么跑起来的对话式运维五步闭环以 列出所有 Jenkins 任务 为例整个流程是这样的第一步用户提问用户在 Streamlit 对话框里输入自然语言例如「列出所有任务」「帮我看看现在 Jenkins 上有啥」界面层用 st.chat_input 接收输入交给 handle_user_message 处理# 用户输入框 —— 支持任意口语化表达 user_input st.chat_input(请输入运维指令例如列出所有 Jenkins 任务...) if user_input: handle_user_message(user_input, jenkins_cfg, llm_cfg)handle_user_message 会把用户消息写入对话历史并启动编排器def handle_user_message(user_input: str, jenkins_cfg, llm_cfg): st.session_state.messages.append({role: user, content: user_input}) with st.spinner(正在理解您的指令并调用 Jenkins...): jenkins_svc JenkinsService(jenkins_cfg) llm DeepSeekClient(llm_cfg) orchestrator DevOpsOrchestrator(jenkins_svc, llm) history [ {role: m[role], content: m[content]} for m in st.session_state.messages[:-1] ] reply, debug orchestrator.execute(user_input, history)要点用户只需说人话不用记 API 地址或命令格式。第二步AI 理解意图大模型把口语指令解析成结构化 JSON相当于 MCP 里的「选哪个 Tool、传什么参数」。System Prompt 里预先定义了支持的动作INTENT_SYSTEM_PROMPT 你是一个 DevOps 运维助手负责将用户的自然语言指令解析为结构化 JSON。 ## 支持的动作 (action) - list_jobs: 列出所有 Jenkins 任务、统计任务数量 - trigger_build: 触发/启动某个 Job 的构建流水线需要 job_name ... ## 输出格式严格 JSON不要 markdown 代码块 { action: 动作类型, job_name: 任务名称或 null, build_number: 数字或 null, limit: 数字或 null, reason: 简短说明为何选择此动作 } ## 示例 用户: 帮我列出所有 jenkins 任务一共有多少个 输出: {action: list_jobs, job_name: null, build_number: null, limit: null, reason: 用户要求列出全部任务并统计数量} 意图解析核心逻辑def parse_intent(self, user_input: str, history: list) - IntentResult: messages history [{role: user, content: user_input}] raw self.chat(messages, INTENT_SYSTEM_PROMPT, temperature0.1) data _extract_json(raw) # 兼容 LLM 偶尔输出的 markdown 代码块 intent IntentResult.from_dict(data) return intent用户说「帮我看看 Jenkins 上有啥」模型会输出类似{ action: list_jobs, job_name: null, build_number: null, limit: null, reason: 用户想查看 Jenkins 上现有的全部任务 }要点Prompt 里写清动作清单和 JSON 格式意图识别才稳定temperature0.1 让输出更可控。第三步MCP 调用工具在完整 MCP 架构里这一步是大模型通过 MCP 协议调用 Jenkins MCP Server。在当前原型里由 DevOpsOrchestrator 充当「工具路由器」—— 根据 action 分发到对应 Jenkins 操作职责与 MCP Tool 调用一致_dispatch 就是「工具注册表 路由表」def _dispatch(self, intent: IntentResult): action intent.action if action list_jobs: return self.jenkins.list_jobs() # 调用「列出任务」工具 if action trigger_build: return self.jenkins.trigger_build(intent.job_name) if action get_build_status: return self.jenkins.get_build_status(intent.job_name, intent.build_number) if action get_alerts: return self.jenkins.get_alerts() ...第四步执行运维操作Jenkins MCP Server当前原型里是 JenkinsService收到 list_jobs 后调用 Jenkins REST API 拿真实数据def list_jobs(self) - dict: server self.connect() # 用户名 API Token 认证 jobs server.get_all_jobs(folder_depth3) job_list [] for job in jobs: job_list.append({ name: job.get(name), url: job.get(url), color: job.get(color), # blue成功, red失败, yellow不稳定 full_name: job.get(fullname, job.get(name)), }) return { total_count: len(job_list), jobs: job_list, queried_at: datetime.now().isoformat(), }连接认证Jenkins 标准做法用户名API Tokendef connect(self) - jenkins.Jenkins: server jenkins.Jenkins( self.config.url.rstrip(/), usernameself.config.username, passwordself.config.api_token, # Token 传给 password 参数 timeout30, ) server.get_version() # 连通性校验 return serverAPI 返回的原始 JSON大致如下{ total_count: 3, jobs: [ {name: my-go-app, color: blue, full_name: my-go-app}, {name: frontend-build, color: red, full_name: frontend-build}, {name: deploy-prod, color: blue_anime, full_name: deploy-prod} ], queried_at: 2026-08-18T16:30:00 }要点color 字段直接反映任务健康状态 —— blue 成功、red 失败、blue_anime 构建中后面整理回复时会翻译成中文。第五步结果反馈大模型拿到原始的 JSON 数据后整理成清晰的表格格式返回给用户包括任务名称、当前状态等关键信息。整个过程用户只说了一句话背后完成了意图识别、工具调度、API 调用、数据格式化四件事。这就是闭环的威力。我的原型长什么样基于 Streamlit 的对话式运维原型界面上面这张图就是我目前跑通的原型。左侧是配置区填 Jenkins 的服务地址、用户名、API Token以及 DeepSeek 大模型的密钥。点一下 测试 Jenkins 连接就能验证连通性。右侧是对话区顶部显示连接状态和大模型状态。用户输入指令后AI 会以对话的形式回复并且支持以表格等富文本格式展示结果。比如我输入 列出所有任务它就返回了当前 Jenkins 上的 3 个任务包括任务名称和当前状态还附带了一段状态说明。这个体验已经很接近 跟一个懂运维的助手聊天 了。几个关键实现细节做的过程中我踩了一些坑这里分享几个关键点1. Jenkins API Token 的获取在 Jenkins 里进入「用户 → 设置 → API Token」生成一个新的 Token 即可。注意这个 Token 只在创建时显示一次要及时保存。认证方式用「用户名 API Token」做 Basic Auth比用密码安全得多。2. MCP Server 的设计每个 DevOps 工具对应一个 MCP Server暴露一组标准化的工具Tools。大模型通过 MCP 协议动态发现这些工具并根据用户意图选择调用。这样做的好处是解耦 —— 加新工具不用改大模型的代码写个新 Server 接入就行。3. Prompt 工程是关键大模型能不能准确调用工具很大程度上取决于 System Prompt 怎么写。需要明确告诉它你有哪些工具可用、每个工具的参数含义、什么时候该调用哪个工具、返回结果应该用什么格式展示。这部分我迭代了好几版才让输出稳定下来。4.安全边界要划清对话式运维意味着 AI 能直接操作你的基础设施安全问题必须前置考虑。目前我的做法是查询类操作直接执行变更类操作比如触发构建、删除资源需要用户二次确认。后续还可以加权限控制、操作审计日志等。这件事的价值在哪对话式运维让运维工作更高效可能有人会说这不就是个聊天机器人吗能有多大价值我觉得价值主要在三个层面第一降低运维门槛新人不需要记一堆命令和 API用自然语言就能完成大部分日常操作。团队的 onboarding 周期可以大幅缩短。第二提升排查效率故障发生时不用在多个工具之间切换一句话就能同时拉取多个系统的数据。大模型还能帮你做初步的关联分析给出排查建议。第三沉淀运维知识常用的排查思路、操作 SOP可以通过 Prompt 和工具定义固化下来。相当于把老运维的经验 编码 进了系统里不会因为人走了就丢失。写在最后目前这个原型还比较初级只接入了 Jenkins 的几个基础操作。但我觉得方向是对的 ——大模型不会取代运维人但善用大模型的运维人效率会甩开同行一大截。接下来计划接入 K8s 和 Prometheus让对话式运维覆盖更多场景。也在考虑加入 RAG把团队的运维文档、历史故障案例喂给大模型这样它不仅能执行操作还能基于历史经验给出诊断建议。AIOps 不是新概念但大模型和 MCP 的成熟让它第一次有了真正 能用 的落地形态。如果你也在做类似的尝试欢迎交流一起踩坑一起进步。希望能对你的选择有些许帮助。欢迎留言聊聊你碰到的技术疑问、职业困惑资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
用户只说了一句话运维闭环就在背后完成了意图识别、工具调度、API 调用、数据格式化四件事。我是韩先超51CTO 学堂 K8s、Python 教学总监、AIOps 实战训练营讲师云计算架构师具有 8 年项目实战经验5 年教学经验线上学员已达 300w。最近一直在折腾一件事能不能让运维这件事变得像跟同事聊天一样自然不用记 Jenkins 的 API 地址不用翻 Prometheus 的查询语法不用在五六个监控面板之间来回切。打开一个对话框说一句 帮我看看现在有哪些构建任务结果就出来了。听起来有点像科幻片其实用大模型MCPDevOps 工具链已经能跑通一个完整的闭环了。这篇文章我把这段时间的实践拆解一下聊透从思路到架构到代码层面的关键点。先说说运维人的日常困境做运维的朋友应该都有这种体验凌晨两点告警响了爬起来打开电脑先登 Jenkins 看构建状态再切到 Prometheus 查指标又跑到 Grafana 看趋势图最后还得去 K8s 里 describe 一下 Pod。一套操作下来人清醒了但排查效率其实不高 ——大量时间花在 切换工具 和 回忆命令 上。更头疼的是团队协作。新人来了光熟悉这一整套工具链就得一两个月。老员工脑子里装着各种 经验性操作但这些知识没法沉淀成可复用的操作手册。所以我一直在想能不能把运维操作的入口统一成 自然语言对话你想做什么直接说系统帮你调对应的工具、执行对应的操作、把结果整理好返回给你。对话式运维换个思路做运维所谓 对话式运维核心就一句话用自然语言作为运维操作的统一入口。你不需要知道 列出 Jenkins 任务 对应的 API 是哪个、参数怎么传你只需要说 列出所有任务。大模型负责理解你的意图然后通过 MCP 协议调用后端的 DevOps 工具去执行最后把结果用人类能看懂的方式返回。这背后其实是三个层面的联动AI 大模型负责意图理解、任务规划、结果总结。相当于你的 运维翻译官。MCPModel Context Protocol负责大模型和外部工具之间的通信协议。相当于 标准插座让大模型能安全、规范地调用各种运维工具。DevOps 工具链Jenkins、K8s、Prometheus、Zabbix 这些真正干活的工具。相当于 手和脚。三者配合就形成了一个大脑理解意图 → 协议调度工具 → 工具执行操作 → 结果反馈给大脑的完整闭环。技术架构拆解大模型MCPDevOps 三层联动架构整个架构从上到下分为三层第一层大模型层。我用的是 DeepSeek 大模型成本低、响应快对中文的理解也不错。这一层负责两件事理解用户的自然语言输入判断用户想做什么把工具返回的原始数据比如 JSON 格式的任务列表整理成人类可读的回复。第二层MCP 协议层。这是整个架构的 交通枢纽。MCP 定义了大模型如何发现工具、如何调用工具、如何接收工具返回结果的标准格式。有了它大模型不需要硬编码每个工具的调用逻辑而是通过标准化的接口去动态发现和调用。新增一个运维工具只需要写一个 MCP Server 接入大模型就能自动学会使用它。第三层DevOps 工具层。目前我接入的是 Jenkins支持列出任务、触发构建、查询构建状态这几个核心操作。后续可以扩展到 K8s查询 Pod、查看日志、扩缩容、Prometheus查询指标、告警分析、Zabbix告警确认、主机状态等。前端用 Streamlit 快速搭建了一个对话界面左侧配置连接信息右侧是对话窗口。原型阶段用 Streamlit 特别香几十行代码就能出一个能用的界面。闭环流程是怎么跑起来的对话式运维五步闭环以 列出所有 Jenkins 任务 为例整个流程是这样的第一步用户提问用户在 Streamlit 对话框里输入自然语言例如「列出所有任务」「帮我看看现在 Jenkins 上有啥」界面层用 st.chat_input 接收输入交给 handle_user_message 处理# 用户输入框 —— 支持任意口语化表达 user_input st.chat_input(请输入运维指令例如列出所有 Jenkins 任务...) if user_input: handle_user_message(user_input, jenkins_cfg, llm_cfg)handle_user_message 会把用户消息写入对话历史并启动编排器def handle_user_message(user_input: str, jenkins_cfg, llm_cfg): st.session_state.messages.append({role: user, content: user_input}) with st.spinner(正在理解您的指令并调用 Jenkins...): jenkins_svc JenkinsService(jenkins_cfg) llm DeepSeekClient(llm_cfg) orchestrator DevOpsOrchestrator(jenkins_svc, llm) history [ {role: m[role], content: m[content]} for m in st.session_state.messages[:-1] ] reply, debug orchestrator.execute(user_input, history)要点用户只需说人话不用记 API 地址或命令格式。第二步AI 理解意图大模型把口语指令解析成结构化 JSON相当于 MCP 里的「选哪个 Tool、传什么参数」。System Prompt 里预先定义了支持的动作INTENT_SYSTEM_PROMPT 你是一个 DevOps 运维助手负责将用户的自然语言指令解析为结构化 JSON。 ## 支持的动作 (action) - list_jobs: 列出所有 Jenkins 任务、统计任务数量 - trigger_build: 触发/启动某个 Job 的构建流水线需要 job_name ... ## 输出格式严格 JSON不要 markdown 代码块 { action: 动作类型, job_name: 任务名称或 null, build_number: 数字或 null, limit: 数字或 null, reason: 简短说明为何选择此动作 } ## 示例 用户: 帮我列出所有 jenkins 任务一共有多少个 输出: {action: list_jobs, job_name: null, build_number: null, limit: null, reason: 用户要求列出全部任务并统计数量} 意图解析核心逻辑def parse_intent(self, user_input: str, history: list) - IntentResult: messages history [{role: user, content: user_input}] raw self.chat(messages, INTENT_SYSTEM_PROMPT, temperature0.1) data _extract_json(raw) # 兼容 LLM 偶尔输出的 markdown 代码块 intent IntentResult.from_dict(data) return intent用户说「帮我看看 Jenkins 上有啥」模型会输出类似{ action: list_jobs, job_name: null, build_number: null, limit: null, reason: 用户想查看 Jenkins 上现有的全部任务 }要点Prompt 里写清动作清单和 JSON 格式意图识别才稳定temperature0.1 让输出更可控。第三步MCP 调用工具在完整 MCP 架构里这一步是大模型通过 MCP 协议调用 Jenkins MCP Server。在当前原型里由 DevOpsOrchestrator 充当「工具路由器」—— 根据 action 分发到对应 Jenkins 操作职责与 MCP Tool 调用一致_dispatch 就是「工具注册表 路由表」def _dispatch(self, intent: IntentResult): action intent.action if action list_jobs: return self.jenkins.list_jobs() # 调用「列出任务」工具 if action trigger_build: return self.jenkins.trigger_build(intent.job_name) if action get_build_status: return self.jenkins.get_build_status(intent.job_name, intent.build_number) if action get_alerts: return self.jenkins.get_alerts() ...第四步执行运维操作Jenkins MCP Server当前原型里是 JenkinsService收到 list_jobs 后调用 Jenkins REST API 拿真实数据def list_jobs(self) - dict: server self.connect() # 用户名 API Token 认证 jobs server.get_all_jobs(folder_depth3) job_list [] for job in jobs: job_list.append({ name: job.get(name), url: job.get(url), color: job.get(color), # blue成功, red失败, yellow不稳定 full_name: job.get(fullname, job.get(name)), }) return { total_count: len(job_list), jobs: job_list, queried_at: datetime.now().isoformat(), }连接认证Jenkins 标准做法用户名API Tokendef connect(self) - jenkins.Jenkins: server jenkins.Jenkins( self.config.url.rstrip(/), usernameself.config.username, passwordself.config.api_token, # Token 传给 password 参数 timeout30, ) server.get_version() # 连通性校验 return serverAPI 返回的原始 JSON大致如下{ total_count: 3, jobs: [ {name: my-go-app, color: blue, full_name: my-go-app}, {name: frontend-build, color: red, full_name: frontend-build}, {name: deploy-prod, color: blue_anime, full_name: deploy-prod} ], queried_at: 2026-08-18T16:30:00 }要点color 字段直接反映任务健康状态 —— blue 成功、red 失败、blue_anime 构建中后面整理回复时会翻译成中文。第五步结果反馈大模型拿到原始的 JSON 数据后整理成清晰的表格格式返回给用户包括任务名称、当前状态等关键信息。整个过程用户只说了一句话背后完成了意图识别、工具调度、API 调用、数据格式化四件事。这就是闭环的威力。我的原型长什么样基于 Streamlit 的对话式运维原型界面上面这张图就是我目前跑通的原型。左侧是配置区填 Jenkins 的服务地址、用户名、API Token以及 DeepSeek 大模型的密钥。点一下 测试 Jenkins 连接就能验证连通性。右侧是对话区顶部显示连接状态和大模型状态。用户输入指令后AI 会以对话的形式回复并且支持以表格等富文本格式展示结果。比如我输入 列出所有任务它就返回了当前 Jenkins 上的 3 个任务包括任务名称和当前状态还附带了一段状态说明。这个体验已经很接近 跟一个懂运维的助手聊天 了。几个关键实现细节做的过程中我踩了一些坑这里分享几个关键点1. Jenkins API Token 的获取在 Jenkins 里进入「用户 → 设置 → API Token」生成一个新的 Token 即可。注意这个 Token 只在创建时显示一次要及时保存。认证方式用「用户名 API Token」做 Basic Auth比用密码安全得多。2. MCP Server 的设计每个 DevOps 工具对应一个 MCP Server暴露一组标准化的工具Tools。大模型通过 MCP 协议动态发现这些工具并根据用户意图选择调用。这样做的好处是解耦 —— 加新工具不用改大模型的代码写个新 Server 接入就行。3. Prompt 工程是关键大模型能不能准确调用工具很大程度上取决于 System Prompt 怎么写。需要明确告诉它你有哪些工具可用、每个工具的参数含义、什么时候该调用哪个工具、返回结果应该用什么格式展示。这部分我迭代了好几版才让输出稳定下来。4.安全边界要划清对话式运维意味着 AI 能直接操作你的基础设施安全问题必须前置考虑。目前我的做法是查询类操作直接执行变更类操作比如触发构建、删除资源需要用户二次确认。后续还可以加权限控制、操作审计日志等。这件事的价值在哪对话式运维让运维工作更高效可能有人会说这不就是个聊天机器人吗能有多大价值我觉得价值主要在三个层面第一降低运维门槛新人不需要记一堆命令和 API用自然语言就能完成大部分日常操作。团队的 onboarding 周期可以大幅缩短。第二提升排查效率故障发生时不用在多个工具之间切换一句话就能同时拉取多个系统的数据。大模型还能帮你做初步的关联分析给出排查建议。第三沉淀运维知识常用的排查思路、操作 SOP可以通过 Prompt 和工具定义固化下来。相当于把老运维的经验 编码 进了系统里不会因为人走了就丢失。写在最后目前这个原型还比较初级只接入了 Jenkins 的几个基础操作。但我觉得方向是对的 ——大模型不会取代运维人但善用大模型的运维人效率会甩开同行一大截。接下来计划接入 K8s 和 Prometheus让对话式运维覆盖更多场景。也在考虑加入 RAG把团队的运维文档、历史故障案例喂给大模型这样它不仅能执行操作还能基于历史经验给出诊断建议。AIOps 不是新概念但大模型和 MCP 的成熟让它第一次有了真正 能用 的落地形态。如果你也在做类似的尝试欢迎交流一起踩坑一起进步。希望能对你的选择有些许帮助。欢迎留言聊聊你碰到的技术疑问、职业困惑资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
