AI

Graphify：把整個 Codebase 變成 AI Agent 可查詢的知識圖譜

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

AI Coding Agent 面對大型專案時，最常做的事其實是「grep → 讀檔 → 再 grep」，一路把 context window 塞滿，卻還是看不清模組之間的關係。Graphify（Graphify-Labs/graphify）走的是另一條路：在 Agent 動手之前，先把整個 codebase 連同文件、設定檔、SQL schema 和 PDF 建成一張知識圖譜，讓 Agent 直接問「這個函式被誰呼叫」、「A 和 B 之間的最短路徑是什麼」。專案目前已累積約 125k stars、12k forks，是近期 AI 開源趨勢榜上的常客。

1. 專案背景與定位

Graphify 是一個 Python 實作的 CLI 工具加 Agent Skill，授權為 Apache-2.0 與 MIT 雙授權。在 Claude Code 裡只要執行 /graphify .，就會產生三份成果：互動式的 graph.html、一份 GRAPH_REPORT.md（列出核心節點、意外的關聯與建議提問），以及完整的 graph.json。

它刻意強調自己不是向量索引：沒有 embedding、沒有向量資料庫。定位上更接近「給 Agent 用的程式碼地圖」，而不是另一套 RAG。

2. 技術架構與核心設計

  • 確定性的程式碼解析：程式碼部分用 tree-sitter AST 在本機解析，不經過 LLM。README 列出 37 種程式語言的 grammar，跨檔案連結約可涵蓋 40 種語言。
  • 邊的可信度標記：每條邊都會標註為 EXTRACTED（原始碼中明確存在）或 INFERRED（由 Graphify 推斷），持久化的圖中另有 AMBIGUOUS。這讓 Agent 和人類都能分辨「事實」與「推測」。
  • 語意層交給模型：文件、PDF、圖片、影片才會送去 Agent 本身的模型或你設定的 API（影音轉錄用本機的 faster-whisper）。
  • 社群偵測：用 Leiden 演算法分群，群組標籤的產生同樣不依賴 LLM。
  • MCP Server：提供 query_graph、get_neighbors、shortest_path、get_pr_impact、triage_prs 等工具，支援 stdio 與 HTTP。
  • 決策脈絡萃取：會擷取 # NOTE:、# WHY: 註解與 ADR/RFC 引用，把「為什麼這樣寫」也收進圖裡。
  • 多格式匯出：Neo4j、FalkorDB、GraphML、Obsidian、wiki 等。

3. 社群熱度與生態採用

約 125k stars、12k forks、2,100+ commits，README 宣稱支援 Claude Code、Codex、Cursor、Gemini CLI、GitHub Copilot 等 20 多種 Agent，並提供 32 種語言的翻譯。

README 中的 benchmark 頗有意思：在 LOCOMO 的 recall@10 上 Graphify 拿到 0.497（mem0 為 0.048），但在 QA 準確率上 45.3% 反而輸給 supermemory 的 49.7%；在 ERPNext 跨工具任務中，關鍵事實涵蓋率 82.0%，高於 grep/read 基準的 70.8%。願意把輸的數字也放出來，算是加分。不過注意部分 benchmark 樣本數很小（ERPNext 只有 n=6）。

4. 局限性與潛在風險

  • 非程式碼內容會離開本機：文件、PDF、圖片要送到模型供應商處理；README 也特別註明 Kimi 後端會路由到中國的 Moonshot AI 伺服器，企業使用前務必確認資料落地政策。
  • 查詢日誌預設開啟：查詢會以 JSON Lines 記錄在 ~/.cache/graphify-queries.log，需設定 GRAPHIFY_QUERY_LOG_DISABLE=1 才會關閉。
  • 共享 HTTP Server 的暴露面：預設綁定 127.0.0.1，若改成 0.0.0.0 一定要搭配 --api-key，否則等於把整個 codebase 結構對內網公開。
  • 套件名稱陷阱：PyPI 上的正確套件是 graphifyy（兩個 y），README 明說其他 graphify* 套件與專案無關——典型的 typosquatting 風險。
  • 維護負擔：703 個 open issues、847 個 open PR，社群熱度高，但也代表 issue 回應與品質控管可能跟不上。
  • 商業化走向：README 已在推廣 graphify Enterprise，開源版與商業版的功能邊界未來可能變動。

5. 應用價值與適用場景

接手陌生的大型 codebase、做跨模組重構、或評估一個 PR 的影響範圍時，Graphify 的價值最明顯——get_pr_impact 與 triage_prs 對 code review 特別實用。純程式碼的專案可以用 --code-only 完全離線建圖，資安敏感的團隊也能放心試用。

如果專案很小、或 Agent 本來就能在一兩次讀檔內掌握全貌，額外建圖的成本就不一定划算。

Monday 的觀點與架構建議

  • 「確定性解析 + 可信度標記」是最值得借鏡的設計：讓 Agent 知道哪些關係是事實、哪些是推測，比單純把更多 context 塞進 prompt 更能降低幻覺。
  • 導入時建議一律先用 --code-only 模式，確認效果後再決定要不要讓文件與 PDF 走雲端模型，並明確指定後端供應商。
  • 把 graphify-out/ 的共享策略寫進團隊規範：哪些檔案入版控、哪些只留在本機，避免圖譜過期或洩漏內部架構。
  • 從趨勢看，「Agent 的程式碼理解層」正在從向量檢索轉向結構化圖譜，這和 MCP 生態結合後，很可能成為 Coding Agent 的標準基礎設施之一。

參考來源