GitLab 19.5 发布：MCP 服务器转正，外部智能体纳入治理

GitLab 19.5 在 10 月 15 日上线。这一版把智能体的软件开发与治理摆到平台核心位置：GitLab MCP 服务器转为正式可用，外部 AI 智能体与 GitLab 打交道的方式也随之拓宽。

Claude Code、Cursor 这类兼容 MCP 的工具，如今能触达更多 GitLab 工具目录，还能调用 GitLab Duo Agent Platform 里的智能体和工作流。另一头，GitLab 给外部智能体加上了治理开关，安全团队可以查到哪些智能体在被用、用的人是谁、落在哪些项目上。

正式可用的 GitLab MCP 服务器基于 Model Context Protocol，把 GitLab 平台能力开放给智能体。新加的工具让智能体能发现群组、查看单个 CI/CD 构件文件，也能启动或监控 GitLab Duo 的智能体和工作流。管理员可以自行决定开放哪些 MCP 工具集，用不上的工具及其占用的上下文就此减少。

把所有可用工具都塞给智能体，上下文消耗会涨，模型能执行的动作数量也会变多。用工具集做筛选，是一种轻量的最小权限代理设计思路。

GitLab.com 还上了 MCP 速率限制：免费版每分钟 60 次请求，Premium 和 Ultimate 用户每分钟 600 次，重连和重试的请求也算在限额里。

这次更值得关注的新能力之一，是把外部连接的智能体收进 GitLab 的 AI 治理范围。

过去 AI 治理仪表盘盯的主要是 GitLab Duo Agent Platform 的智能体。GitLab 19.5 支持通过 GitLab CLI 接入 Claude Code、Cursor、Codex 等工具。配置好之后，组织可以记录符合条件的智能体会话，涵盖用户、智能体、项目和时间信息，这些活动会和 GitLab 自家智能体并列显示。审计事件还能流式推送到 SIEM 系统。

这不只是多了一个 MCP 端点。连通性负责把能力交出去，治理则决定这种能力在组织规模上能不能安全地用起来。

GitLab Duo CLI 加了自动模式，智能体执行工具时不必为每条 Shell 命令、Git 操作或 MCP 调用逐一申请批准。该功能默认关闭，可在实例、群组和项目三个层级控制，被明确标为“始终拒绝”（Always Deny）的工具照样会被拦住。

/goal命令功能也转为正式可用。开发者只要描述一个开放式目标，GitLab Duo 就会交给受治理的流程去完成代码实现并核验结果。

这些能力合在一起，把 GitLab 往智能体驱动开发的方向推：开发者表达意图即可，多步任务由智能体在开发环境里自动跑完。

智能体越自主，治理控制的分量就越重。每个单独操作都等人批准，已经不太现实。

同一版本里，GitLab Secrets Manager 正式发布。它构建在 OpenBao 之上，与 GitLab 现有的群组和项目权限打通，把密钥的作用范围收束到真正需要它的任务里，密钥操作也会产生审计事件。

安全配置模板的能力也做了扩展。企业可以统一设定密钥检测（Secret Detection）、静态应用安全检测（SAST）的参数，比如排除路径、分析器镜像、全历史扫描，不必在每个项目的 CI/CD 文件里重复写一遍。

智能体可能接触到的代码库、凭证和流水线，由此多了一层控制，与智能体功能互为补充。

GitLab 的路数和 GitHub 越来越像：都把代码智能体当成软件生命周期的参与方。差别在于，GitLab 更侧重把外部智能体接进自己现有的 DevSecOps 治理体系。

GitHub 的生态靠 GitHub Copilot 和编码智能体的广泛覆盖吃饭，Cursor、Claude Code 这类工具则更偏向开发者的本地环境。GitLab 的 MCP 方案想做的，是让 DevOps 平台本身可被智能体访问，包括代码库、议题、流水线、构件以及 GitLab 原生智能体。

GitLab 所在的竞争焦点也在挪位：从“哪个编码助手生成的代码更好”，转向“哪个平台能为自主智能体执行工程工作提供最安全、最有用的环境”。