GitLab Orbit：讓 AI Agent 查詢程式碼與 SDLC 關聯

大型軟體系統的上下文不只存在程式碼裡，也散落在 merge request、pipeline、deployment、issue 與 security finding。AI coding agent 若只靠文字搜尋，很難穩定回答「哪次變更造成故障、誰核准、哪些服務受影響」這類跨實體問題。

GitLab Orbit的方向，是把程式碼結構與軟體開發生命週期（SDLC）資料建成可查詢的知識圖譜。不過它仍處於快速演進期：Remote 已被 GitLab 稱為 public beta，部分 CLI 與 Local MCP 文件仍標示 Experiment。評估時應把「架構潛力」與「目前可承諾的正式環境能力」分開。

Remote 與 Local 是兩種產品路徑

面向	Orbit Remote	Orbit Local
資料範圍	GitLab 群組、專案及 SDLC 資料	本機工作目錄中的 repository
儲存與查詢	GitLab 服務端以 ClickHouse 建圖，使用圖譜查詢格式、REST、CLI 或整合介面	本機 DuckDB，可用 SQL、CLI 與 Local MCP
適合情境	跨專案依賴、事件調查、組織級脈絡	本機程式碼探索、離線或低延遲查詢
成熟度注意	Remote 功能仍有 Beta／feature flag 邊界	Local MCP 文件標示 Experiment

依GitLab 發布說明，Remote 透過 change-data-capture 將 SDLC 資料寫入 ClickHouse，並解析多種程式語言；對外提供 Cypher-like DSL、MCP、REST 與 CLI。這不等於使用者能在 Remote 任意執行標準 Cypher。

Local 則依官方 CLI 文件把圖譜放在本機 DuckDB，支援 orbit schema 與 orbit sql。因此「ClickHouse 或 DuckDB」不是部署時可互換的儲存選項，而是 Remote 與 Local 的產品邊界。

不要自行發明 Schema

Orbit 公開文件會持續更新可索引資料與 schema。實作時應用 CLI 或 MCP 的 schema 工具讀取當前表格、欄位與關係，而不是假設存在 CodeNode、ActionNode、IdentityNode 等固定類別。

一個安全的查詢流程是：

1. 確認 Local 或 Remote，以及目前索引涵蓋哪些 repository／branch。
2. 讀取 schema 或 Remote 查詢文件。
3. 用小範圍、可驗證的問題測試結果。
4. 回到 GitLab 原始物件核對 commit、merge request 與 pipeline 狀態。

圖譜能改善候選資料的召回與關聯，但不會讓資料變得「無可辯駁」；索引延遲、權限、未收錄分支與錯誤關係仍可能影響答案。

透過 MCP 接入 Cursor

Orbit Local MCP 文件列出的 Cursor 設定使用 stdio，不需要虛構的遠端 URL：

{
  "mcpServers": {
    "orbit-local": {
      "type": "stdio",
      "command": "orbit",
      "args": ["mcp", "serve"]
    }
  }
}

連線後，Agent 可看到 index、get_graph_schema 與 run_sql 等工具。run_sql 是唯讀查詢，且回傳量有限；正式使用時仍要限制可索引目錄、審查工具權限，並把查詢結果當成調查線索而非最終真相。

導入判斷

Orbit 最適合的早期試點，是答案可被 GitLab 原始物件驗證、但人工跨頁查找成本很高的任務，例如 incident triage、變更影響分析或大型 repository 導覽。若流程需要強 SLA、跨分支完整性或長期穩定 API，則應先確認目前版本與部署方案是否已達要求。

想先理解 Agent 如何選工具與控制工作流程，可看AI Agent 實戰指南；若要理解 MCP 的協議邊界，接著讀MCP 架構與安全限制。

主要來源

• GitLab：Introducing GitLab Orbit
• GitLab Docs：Orbit indexed data
• GitLab Docs：Orbit Local CLI
• GitLab Docs：Orbit Local MCP