9 月 17 日，GitLab 发布 19.4 版本。如果只看更新日志的排版，MCP server 工具公测只是一条中等篇幅的条目；但把它放进 DevSecOps 平台的演进脉络里看，这是一个信号更浓的动作：智能体从此可以作为一个外部客户端，端到端地在 GitLab 里干活——触发一条流水线并读取失败任务的日志，把一个合并请求从打开推进到评审再到合并，检索和更新工作项，给安全漏洞做分诊。覆盖面横跨 CI/CD、合并请求、工作项、漏洞与项目五类对象。
比「能做什么」更值得注意的是「怎么管」。GitLab 没有为智能体另起一套权限体系：这些 MCP 工具直接受 GitLab Duo Agent Platform 已有的工具级规则约束，配置入口就在既有的群组与项目设置里。默认策略分了两档——只读工具默认放行，让日常查询不打扰团队；写与删工具默认先问人，评审者有机会在智能体改动任何东西之前按下暂停。官方的表述相当直白：管代码的那套权限同时管智能体，每一笔算力消耗都能追溯到发起它的用户账户，不存在第二套权限模型，也不存在另一条独立的审计轨迹。
同一批更新里的 /goal 命令，解决的是另一个瓶颈。智能体擅长处理单个任务，但把目标拆成任务、逐个验收的工作仍然压在开发者身上；而把整个目标直接交给智能体，又意味着没人独立检查它的判断。/goal 的设计是把这两件事一起解决：开发者在终端里给出一个开放式目标，一个模型负责实现，另一个独立的模型在每一轮迭代里对照目标验证结果，直到达成或触达迭代上限；流程在本地运行，受组织既有的项目护栏约束，开发者随时可以中止、改写目标再重启。办不到的事，它会明说办不到。
成本侧的变化同样务实。GitLab Duo Agent Platform 现在托管三个开放权重模型——Kimi K3、MiniMax M3 和 GLM 5.3，官方口径是同等积分下可比许多前沿模型多用至 4 倍的调用量，质量对齐前沿模型水平；群组所有者可以为不同功能设定默认模型、裁剪团队可用的模型清单。配套的用量可视化正式可用：平台所有者能看到按人归因的积分消耗，导出到计费事件粒度，为每个部门算清智能体自动化的账。另外，Duo Agent Platform 的 Slack 集成以实验特性面向 Premium 与 Ultimate 客户开放。
需要冷静看的部分有三点。其一，两项核心能力都还挂着公测标签，生产环境慎入，官方自己也在文档里强调治理先行——先在沙箱项目里量一量误触发合并请求与权限越界的频率。其二，智能体生成的代码依然要走既有的静态扫描、依赖审查与密钥检测，平台把动作管住了，不等于把产物质量管住了。其三，写操作默认先问人的策略在企业大规模推广时会遇到摩擦：确认次数多了，团队会倾向于批量放行——信任的边界可能被运营压力慢慢推宽。
把这一版和 GitLab 9 月初的另一条智能体动态放在一起看，方向更清楚：那次是 Agent Sandbox 的允许清单与包代理信任链，这次是 MCP 工具与目标级自动化。CI/CD 平台正在从「跑脚本的地方」变成「智能体的宿主」，而 GitLab 的差异化押注在于统一——代码、流水线、智能体和钱（积分消耗）都在同一个治理平面里。竞争对手在平行推进各自的智能体编排能力，开发平台这一仗的胜负手，可能不在谁的智能体更聪明，而在谁让企业安全团队更容易说「行」。