在上一篇文章中,我們透過 HTTP Request Tool 成功讓 AI Agent 存取 GitLab 資料進行 Code Review。今天我們將更進一步,建立專屬的 MCP Server 並讓 MCP Client 連線,實現更完整且彈性的工具整合方案。
我們將使用與 Day 5 VSCode 版本相同的方式,採用 zereight 開發的 GitLab MCP Server。不過這次我們使用 streamable-http
模式,並透過 Docker 來啟動服務,確保部署的一致性和可靠性。
執行以下指令來啟動 MCP Server:
docker run -i --rm \
-e GITLAB_PERSONAL_ACCESS_TOKEN=your_gitlab_token \
-e GITLAB_API_URL="https://gitlab.com/api/v4" \
-e STREAMABLE_HTTP=true \
-p 3333:3002 \
iwakitakuma/gitlab-mcp
💡 提醒:請記得將
your_gitlab_token
替換為您的實際 GitLab Personal Access Token。
在 n8n 的 AI Agent 節點中,選擇 MCP Client Tool 作為我們的主要整合工具:
接下來進行 MCP Client 的詳細設定,確保與我們的 MCP Server 能夠正常通訊:
http://{輸入你的 host}:3333/mcp
Http Streamable
None
(因為我們未設定額外驗證)Selected
我們建議選擇 Selected
而非 All
的原因:
針對 Code Review 需求,我們選擇以下三個核心工具:
在正式使用前,我們需要驗證 MCP Tool 是否能正常運作:
Execute Step
按鈕get_merge_request_diffs
工具get_merge_request_diffs
所需的參數根據前面章節提到的 Webhook 資訊,設定以下參數:
"parallel"
(平行檢視模式)Execute Step
,確認能夠成功獲取 diff 資訊現在我們需要更新 AI Agent 的 Prompt,讓它能夠正確使用 GitLab-MCP 工具而非原本的 HTTP Request Tool。
## 自動化 Code Review 執行流程
### 第一步:獲取 Merge Request 差異資料
請使用 `GitLab-MCP:get_merge_request_diffs` 工具取得合併請求的詳細差異,參數設定如下:
- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- source_branch: {{ $json.body.object_attributes.source_branch }}
- view: "parallel"
### 第二步:進行全面性程式碼審查
讀取第一步的結果陣列,每筆資料代表一個檔案的 diff 資訊。請扮演資深軟體工程師的角色,針對每個檔案進行全面性的 Code Review。
#### 審查維度(必須涵蓋以下五個面向):
1. **✅ 邏輯正確性**:程式邏輯是否正確、是否有潛在錯誤或邊界條件未處理
2. **🧹 程式碼品質**:是否符合慣用寫法,例如錯誤處理、命名風格、簡潔性
3. **🔒 安全性考量**:是否有安全性問題,例如硬編碼、未處理的錯誤、資源洩漏等
4. **🚀 效能最佳化**:是否有效能瓶頸,例如不必要的記憶體分配、重複運算、goroutine 使用不當
5. **📚 可維護性**:是否具備良好的可讀性與可維護性,包括註解、結構清晰度、模組化程度
#### 評估流程(請嚴格遵循以下步驟):
1. **逐項分析**:針對每個面向分析問題,並列出具體證據
2. **風險評估**:綜合所有問題,決定 severity 等級
3. **證據導向**:只在有明確證據時提升 severity,避免過度評估
#### 風險等級定義(必須嚴格遵守):
- **high(高風險)**:問題可能導致系統崩潰、安全漏洞、資料洩漏、嚴重效能衰退,或在生產環境造成重大損失
- 例如:未處理的 nil 指標、SQL 注入風險、無限迴圈
- **medium(中風險)**:問題可能引起偶發錯誤、非最佳實踐,但不立即危險
- 例如:未優化的迴圈、缺少錯誤檢查、輕微資源浪費
- **low(低風險)**:小問題,不影響功能或效能
- 例如:命名不一致、缺少註解、多餘空白
- **no problem(無問題)**:所有面向皆符合最佳實踐,無任何可改進點
- 例如:測試程式碼中的 `req, _ := http.NewRequest("GET", "/ping", nil)` 使用底線是可接受的
- **注意**:此等級不需執行第四步留言動作
### 第三步:獲取 Merge Request 基本資訊
請使用 `GitLab-MCP:get_merge_request` 取得 commit SHA 相關資訊:
參數設定:
- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- source_branch: {{ $json.body.object_attributes.source_branch }}
目標欄位:
- **base_sha**:來源分支的 base commit SHA
- **head_sha**:來源分支的 HEAD commit SHA
- **start_sha**:來源分支的 start commit SHA
### 第四步:建立審查留言
僅對 medium 和 high 風險的問題使用 `GitLab-MCP:create_merge_request_thread` 建立留言:
參數設定:
- project_id: {{ $json.body.project.id }}
- merge_request_iid: {{ $json.body.object_attributes.iid }}
- body: 第二步的詳細 Code Review 內容
- position: 包含以下必填欄位
- base_sha: 來自第三步的資料
- head_sha: 來自第三步的資料
- start_sha: 來自第三步的資料
- position_type: 'text'
- new_path: 來自第一步的檔案路徑資料
- old_path: 來自第一步的檔案路徑資料
- new_line: 根據第一步的 diff 計算特定行號
- old_line: 根據第一步的 diff 計算特定行號
由於 create_merge_request_thread
工具需要較多參數,有一定的失敗機率,建議採用以下分階段測試策略:
經過 Part 1 到 Part 7 共七個章節的完整實作,我們成功建立了 AI Agent + MCP 的完整資料流。透過先前 VSCode MCP Tool 的體驗,以及這幾篇 GitLab MCP Tool 的深度整合,相信您對 MCP(Model Context Protocol)有了更深刻的理解和實際應用經驗。
我們已經完成了方法二的實作,但在使用 MCP Tool 執行 Code Review 的過程中,我發現了一些可以進一步優化改善的地方。基於這些發現,後續我開發了方法三的解決方案。
下一篇預告: 我們將分享在實際使用過程中發現的問題,以及如何透過方法三來解決這些挑戰,打造更加穩定且高效的自動化 Code Review 系統。