夜雨聆风用 MCP + Jenkins 打造 AI 自动发布助手
前言
最近 MCP（Model Context Protocol）越来越火。
很多开发者讨论 MCP 时，关注点往往是：
• AI 能不能访问数据库？ • AI 能不能调用企业内部系统？ • AI 能不能连接知识库？
但对于大多数研发团队来说，MCP 最有价值的场景其实并不复杂：
把每天重复执行的工作流，变成 AI 可以调用的能力。
例如：
• 打包客户端 • 编译服务端 • 部署测试环境 • 发布预发布环境 • 回滚线上版本 • 查询构建日志
这些工作几乎每天都在发生。
而 Jenkins 本身已经具备完整的自动化能力，我们缺少的只是：
一座连接 AI 与 Jenkins 的桥梁。
MCP 正好可以承担这个角色。
MCP + Jenkins 的整体架构
整个系统结构非常简单：
Claude / ChatGPT / Gemini / Cursor │ ▼ MCP Server │ Jenkins REST API │ Build / Deploy / Rollback在这种模式下，研发人员不再需要：
• 登录 Jenkins • 找到对应 Job • 选择参数 • 点击 Build
而是直接告诉 AI：
帮我把最新代码部署到测试环境
或者：
回滚生产环境到昨天的稳定版本
AI 会自动调用 MCP Tool，完成整个流程。
为什么值得做？
以一个 50 人规模的游戏研发团队为例。
每天可能发生：
这些工作本身没有技术含量。
但会占用大量时间。
如果能够让 AI 自动处理：
开发人员 ↓一句自然语言 ↓AI Agent ↓MCP Tool ↓Jenkins就能显著降低日常运维成本。
MCP Tool 应该如何设计？
很多团队的第一反应是：
把 Jenkins API 全部暴露出去。
其实并不推荐。
更好的方式是：
将业务语义封装成工具。
Tool 1：查询项目
listProjects()返回：
[ "game-client", "game-server", "payment-service"]Tool 2：触发构建
buildProject({ project: "game-server", branch: "develop"})AI 可以理解：
构建 develop 分支服务端
无需用户了解 Jenkins Job。
Tool 3：查询构建状态
getBuildStatus({ project: "game-server", buildNumber: 123})返回：
{ "status": "SUCCESS"}Tool 4：部署环境
deploy({ project: "game-server", buildNumber: 123, env: "test"})Tool 5：回滚
rollback({ project: "game-server", buildNumber: 120, env: "prod"})核心代码实现
下面给出一个基于 FastMCP 的简单代码实现。
安装依赖
npm install fastmcp axios zodMCP Server 初始化
import { FastMCP } from "fastmcp";const server = new FastMCP({ name: "jenkins-mcp", version: "1.0.0"});Jenkins API 封装
import axios from "axios";const client = axios.create({ baseURL: process.env.JENKINS_URL, auth: { username: process.env.JENKINS_USER!, password: process.env.JENKINS_TOKEN! }});构建 Tool
import { z } from "zod";server.addTool({ name: "build_project", parameters: z.object({ project: z.string(), branch: z.string() }), execute: async ({ project, branch }) => { await client.post( `/job/${project}/buildWithParameters`, null, { params: { branch } } ); return { success: true, message: `${project} 已开始构建` }; }});查询构建状态
server.addTool({ name: "build_status", parameters: z.object({ project: z.string(), buildNumber: z.number() }), execute: async ({ project, buildNumber }) => { const { data } = await client.get( `/job/${project}/${buildNumber}/api/json` ); return { building: data.building, result: data.result }; }});获取日志
server.addTool({ name: "build_log", parameters: z.object({ project: z.string(), buildNumber: z.number() }), execute: async ({ project, buildNumber }) => { const { data } = await client.get( `/job/${project}/${buildNumber}/consoleText` ); return data.slice(-5000); }});更高级的玩法
如果只是简单封装 Jenkins API，其实价值有限。
真正有价值的是：
MCP 帮用户隐藏 Jenkins 的复杂性。
场景一：部署最新成功版本
用户：
把测试服更新到最新稳定版本AI 调用：
deployLatestSuccess({ project: "game-server", env: "test"})内部流程：
查询构建历史 ↓找到最近成功版本 ↓触发部署 ↓返回结果用户完全无需知道：
• Build Number • Jenkins Job • Pipeline 参数
场景二：分析构建失败
用户：
刚才为什么打包失败？MCP：
获取日志 ↓交给 LLM 分析 ↓生成总结返回：
构建失败原因：1. Addressables 打包失败2. 缺失资源： Assets/UI/Login.prefab建议：重新执行资源构建后再次打包。这比让开发人员自己翻几千行日志高效得多。
场景三：自动发布流程
未来甚至可以把整个发版流程串起来：
发布 1.3.5 版本 │ ▼检查 Git Tag │ ▼触发 Jenkins Build │ ▼等待完成 │ ▼部署预发布环境 │ ▼执行自动化测试 │ ▼生成 Release Notes │ ▼通知飞书群研发人员只需一句话：
发布 1.3.5 到预发布环境
剩余步骤全部自动完成。
研发团队的最佳实践
对于研发团队，建议将 MCP 作为统一自动化入口。
除了 Jenkins，还可以继续扩展：
• GitLab • Gitea • 飞书 • 企业微信 • Jira • Tapd • 禅道
最终形成：
研发人员 │ ▼ AI Agent │ ▼ MCP Server │ ┌──┼───────────┐ ▼ ▼ ▼GitLab Jenkins Kubernetes ▼ ▼ ▼代码 构建 部署这样 AI 不再只是一个聊天机器人。
而是真正成为研发团队的自动化操作入口。
结语
MCP 的真正价值，并不在于构建一个“无所不能”的超级智能体。
它最大的价值在于：
将企业内部已经存在的能力，封装成 AI 可以理解和调用的工具。
对于研发团队来说：
• Jenkins 负责执行 • MCP 负责连接 • 大模型负责理解用户意图
三者结合后，很多原本需要人工点击、切换页面、填写参数的工作，都可以被一句自然语言取代。
当团队积累越来越多的 MCP Tool 后，最终形成的将不是一个简单的聊天机器人，而是一个真正能够参与研发流程的 AI 工程助手。
补充
截止发稿时间，Jenkins已经推出了官方MCP插件，官方MCP插件的功能更加全面和完善，建议直接使用。本文的目的是通过按步骤实现一个MCP服务，让读者对如何从零构建MCP服务有一个初步的认识。
