工具-用知識圖譜幫agent找對context

🎯 什麼情境該想到我

當你「的 agent 明明讀過整個 repo 和文件，卻答不出跨檔案、跨文件的問題，或者老是抓錯相關的程式碼」的時候。

核心想法：agent 最容易壞在「找 context」這一步。與其每次查詢時才 grep 原始檔，不如先把 repo、文件、需求建成一張圖（實體加上關係），讓 agent 沿著關係找，並且知道每條關係有多可信。

	grep／關鍵字	知識圖譜
找什麼	字串在哪	誰跟誰有關
擅長	function name、error code、config key	跨檔案的因果鏈、影響範圍、A 怎麼連到 B
弱點	分不出哪筆是核心，看不到關聯	建圖要時間；推論的關係可能錯

兩者互補：精確查字串用 grep，問「為什麼相關、會影響誰」用圖。

實作工具：Graphify（/graphify . 建圖、--update 增量更新）→ 收藏卡。只看程式碼的話，codegraph、codebase-memory 也能做。

另外，AST 也看不到動態派發、runtime 設定、feature flag、外部服務呼叫，這幾種要特別人工確認。圖是用來縮小探索範圍的，不取代原始碼。

query：一個問題，答案沿著關係串起 module、文件、test、config。例如「auth flow 怎麼運作」「改 auth 會影響哪些 module、config 和 test」。
path：兩個概念之間的最短路徑（「Login Page」到「Auth Service」）。中間經過的節點，通常就是討論時最有價值的 context。
explain：一個節點跟誰有關，哪些關係是明確的、哪些是推論的。

降噪：排除測試 fixture、產生的程式碼、migration、locales、vendor、大型資料檔。圖太密通常代表雜訊太多。
多 repo 補 bridge doc：架構（誰呼叫誰）、資料流（一筆資料怎麼穿過各服務）、通用語言（同一概念在各 repo 的命名對照）。多 repo 的難點通常是缺這層描述關係的文件。
從小開始：一個產品功能、一個主要 repo、對應的 spec，加少量架構文件。先做一張會被用的圖，不是最大的圖。
在 AGENTS.md 寫明「查 context 先用圖」：工作坊的圖專案就在 AGENTS.md 設定「任何任務都優先使用 graphify」；不寫的話 agent 可能不會主動用（推測）。

需求在圖上找不到對應程式碼，不等於沒實作。它是 PM 和 RD 要一起確認的落差候選；圖不準常常是在提醒「這段關係從來沒被寫成文件」，補文件就是改善。

文件會送到模型：程式碼可以全在本機，但文件的語意抽取要呼叫模型。公司文件先確認可以送；只想看程式碼就用純 AST 模式（Graphify 的 --code-only；出自 Graphify README，查證 2026-10-14）。
小 repo 不值得（我的判斷）：幾十個檔案以內，直接讓 agent 讀或 grep 就好，建圖的成本換不回來。
圖會過時：程式碼一直在改，要接上增量更新（--update）或定期重建，否則 agent 會依舊的關係做判斷。
推論出來的邊錯了，agent 可能會很有信心地走錯路（推測）。要求 agent 回答時標出依據的是哪一種可信度。