在軟體開發的 AI 浪潮中，大部分人的第一印象是 AI 能幫我們寫程式碼（Code Generation）。但對於企業級開發來說，寫出程式碼只是第一步，如何確保這些代碼安全、符合規範並順利合併到主分支，才是最耗時且高風險的環節。GitLab 19.0 的核心更新方向，就是將 AI 從單純的生成能力，轉化為具有執行能力的 Agentic AI（代理式 AI）。
所謂的 Agentic AI，是指 AI 不再只是回答問題的聊天機器人，而是能理解目標、規劃步驟並在特定環境中執行任務的代理人。GitLab 這次將其應用範圍從編寫代碼擴展到了秘密管理、合併請求（Merge Request, MR）處理以及供應鏈安全這三大維度。
強化秘密管理與權限追蹤
在開發實務中，API 金鑰或資料庫密碼等敏感資訊（Secrets）的管理一直很頭痛。如果將其直接寫在代碼中會導致嚴重漏洞，而使用外部管理工具則會增加權限設定的複雜度。
GitLab 19.0 推出的 GitLab Secrets Manager 旨在將秘密管理直接整合進開發平台。它的核心價值在於讓秘密的存取權限與 GitLab 現有的群組與專案層級同步，不需要額外建立一套權限模型。更重要的是，當某個金鑰意外外洩時，工程師可以透過審計日誌（Audit Trail）快速追溯哪些 Job 使用過該金鑰，大幅縮短應變時間。此外，它採取的是互補而非取代策略，依然支援 HashiCorp Vault 或 AWS Secrets Manager 等主流工具。
將 AI 導入合併請求的生命週期
對於 Junior 工程師來說，處理 Merge Request 的衝突或回應 Reviewer 的修改建議往往是最挫折的過程。GitLab 引入的 Developer Flow 旨在將 AI 變成一名協作助手。
現在的 AI 代理人可以根據專案中定義的 AGENTS.md 檔案來學習團隊的編碼標準，這解決了 AI 產出過於通用、不符合團隊風格的痛點。具體功能包括自動處理 Reviewer 的反饋、將過大的 MR 拆分成小塊以便審查，以及透過 Resolve with Duo 按鈕自動評估分支差異並提交修復方案。
值得注意的是，為了確保安全性，AI 代理人會遵守分支保護規則（Branch Protection），不會強行推送到受保護的分支，這確保了自動化不會破壞生產環境的穩定性。
供應鏈安全與 SBOM 的普及化
現代軟體開發高度依賴第三方套件，這帶來了供應鏈攻擊的風險。為了應對此問題，GitLab 19.0 正式將基於 SBOM（Software Bill of Materials，軟體物料清單）的依賴掃描功能全面開放。
SBOM 就像是一份軟體成分表，詳細記錄了專案中使用了哪些第三方庫及其版本。GitLab 現在能自動為 Maven、npm、PyPI 等主流生態系生成依賴圖表，即使開發者沒有提交 lockfile，系統也會嘗試自動解析。透過安全配置設定檔（Security Configuration Profiles），團隊可以用統一的政策來開啟 SAST（靜態應用程式安全測試）和秘密檢測，而不需要在每個專案的 CI 腳本中重複設定。
基礎設施與計費模式的轉型
在技術底層，GitLab Duo Core 轉向了基於用量的計費模式（Usage-based billing），並引入了 GitLab Credits。對於需要高度隱私、處於物理隔離環境（Air-gapped）的企業，GitLab 提供了對開源模型（如 Mistral Devstral 2）的支持，讓企業可以在不將數據傳送到雲端的情況下使用 AI 能力。
在環境要求上，GitLab 19.0 提升了最低要求，必須使用 PostgreSQL 17，並停止支援 Redis 6 以及較舊的 Ubuntu 20.04 版本，這提醒平台工程師在升級前需先檢查基礎設施的相容性。
總結
GitLab 19.0 的邏輯很明確：AI 讓寫代碼變快了，但並沒有讓代碼變得更容易被信任或更容易在大規模環境下維護。透過將 AI 代理人嵌入到安全治理、審核流程與供應鏈管理中，GitLab 試圖將 AI 從一個編寫工具提升為一個治理工具，讓開發團隊在追求速度的同時，不會失去對交付品質的控制。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。