Graft：開源上下文層將 Claude Code Token 使用量降低 42% 並提升 SWE‑bench 準確度

TL;DR

Graft 構建了一個持久的、基於 Markdown 的程式碼圖譜，讓 Agent 可以進行查詢，而不是重複對儲存庫進行 grep；這將 Claude Code 的 Token 使用量降低了 42%，減少了 46% 的工具調用，提升了 60% 的執行速度，並將 SWE‑bench 的正確率從 54% 提高到 66%。

Graft 的主張

效率提升 – 在受控的 162 次運行基準測試中，與每次任務都重新探索儲存庫的「冷啟動」Claude Code 會話相比，Graft 節省了 42% 的 Token、46% 的工具調用和 60% 的延遲。
正確性改進 – 在業界標準的 SWE‑bench Verified 套件（50 個真實 GitHub issue）上，Graft 解決了 33 個案例，而基準測試為 27 個，提升了 12 個百分點。
成本降低 – 同一基準測試顯示，實際耗時減少了 32%，貨幣成本降低了 19%。
語言支援 – 對 TypeScript/JavaScript、Python、Go、Java 進行高保真解析；對另外 20 種語言提供更廣泛的 tree-sitter 支援；為 Rust、C/C++ 等提供選用的基於 LSP 的邊（edges）。
零執行開銷 – 結構化圖譜 (graft build) 在本地運行，無需 API 金鑰；只有選用的 LLM 摘要功能 (--deep) 會連接供應商。

Graft 如何運作

兩階段圖譜構建

檔案摘要 – 每個原始檔案會傳送給 LLM（選用）一次，以產生簡短的英文描述。
節點聚合 – 摘要被分組成精選的 Markdown 節點（子系統、關鍵檔案、概念），並帶有類型化的 wikilinks ([[node]])。

生成的 graft/ 目錄是一個純檔案快取，與程式碼並存，並可以提交到 Git。

節點內容

部分	描述
Summary	由 LLM 生成並快取的程式碼用途單句英文解釋。
Crux	實現核心邏輯的最少原始碼行，逐字儲存。
Sources	支持該節點的檔案路徑與內容雜湊值，實現精確的過時檢查檢測。
Links	以 `[[wikilinks]]` 形式表達的類型化關係 (`depends_on`, `part_of`, `uses` 等)。
Notes	使用者撰寫的自由文本，在重新生成時會保留。

增量更新

圖譜重建會根據內容雜湊進行快取；只有變動的檔案會觸發 LLM 調用。
在每個 graft ask/grep/callers 命令之前，會運行輕量級的 $0 結構化更新，確保圖譜反映未提交的編輯，且無需網路調用。

與編碼 Agent 的整合

graft init 會檢測受支援的 Agent（Claude Code, Cursor, Gemini, Codex, Copilot 等）並寫入必要的指令或技能檔案。Claude Code 會收到即時狀態行、自動同步鉤子以及與匹配節點的每會話導入。
MCP server – 註冊六個工具端點 (graft_find_code, graft_file_api, graft_trace_calls, graft_find_all, graft_repo_map, graft_check_freshness) 供 Agent 直接調用。
無需守護進程 (No daemon) – 圖譜以常規檔案形式存在；除非使用者選擇選用的 MCP server，否則不需要背景服務。

基準測試

受控 162 次運行掃描

指標	冷啟動 Claude Code	Claude Code + Graft
成本節省 ($)	0.0429	0.0292 (+32%)
Token 節省	8,070	4,650 (+42%)
工具調用節省	4.2	2.3 (+46%)
延遲 (s)	39.8	15.8 (+60%)
正確性	93%	93%

「拉取 (pull)」變體（按需使用 graft 工具）達到了最高的正確性 (98%)，但犧牲了大部分的速度優勢。

SWE‑bench Verified (50 個真實問題)

指標	冷啟動 Claude Code	Claude Code + Graft
正確性	27/50 (54%)	33/50 (66%)
Token 節省	142 M	109.4 M (+23%)
成本節省	$52.34	$42.43 (+19%)
工具調用節省	1,370	1,031 (+25%)
實際耗時	13,094 s	8,922 s (+32%)

正確性的提升源於更好的跨檔案推理；基準測試通常只修補單個檔案而忽略了依賴檔案。

Hacker News 上的社群回饋

@seizethecheese – “這部分基準測試讀起來像是 Claude/Codex 寫的；50 個任務的 SWE‑bench 樣本太小，且 p 值 (0.22) 很弱。挑選任務很容易。”
該評論指出，發布的結果是基於有限的樣本和單次運行，這限制了統計信心。

@icodestuff – “我擔心長會話中的圖譜過時問題。增量更新可能會靜默漂移，且 graft/ 中的合併衝突可能會很痛苦。”
這指出了一個實際風險：長時間運行的會話可能會依賴過時的摘要，且當多個開發者編輯相同的概念時，可能會出現版本控制衝突。

@xhrpost – “Claude 的 LSP 整合是否已經減少了 grep 的使用？Graft 是否在解決重複的問題？”
該問題澄清了 Graft 的價值主張是獨特的：它提供的是持久的、人類可讀的知識圖譜，而不是一次性的基於 LSP 的符號查找。

@gabosarmiento – “與 Graphify 相比的基準測試是什麼？”
儲存庫中未提供直接對比；該主張仍待驗證。

總體而言，評論者認可這個想法，但要求進行更嚴謹、更大規模的評估以及衝突解決工具。

實際用法

快速開始 (npm)

npm install -g @nanonets/graft   # 安裝 CLI
graft init                       # 選擇 Agent，構建 `graft/`，連接 Claude Code

graft init --dry-run 顯示將要寫入的檔案。
graft build 在不進行 LLM 調用的情況下創建圖譜；graft build --deep 會添加 LLM 生成的摘要（需要 API 金鑰）。

核心 CLI 命令

命令	用途
`graft ask "<task>"`	對於自然語言查詢進行節點排序（無需 LLM）。
`graft grep "<regex>"`	詳盡的 regex 搜尋，按包含的符號分組。
`graft map`	受 Token 預算限制的儲存庫導航（目錄集群、樞紐、熱點）。
`graft callers <symbol>`	顯示符號的入站/出站調用圖譜。
`graft viz`	啟動 Markdown 和程式碼圖譜的互動式網頁檢視器。

所有命令都接受 --no-refresh 來跳過自動結構更新，環境變數 GRAFT_NO_REFRESH=1 可全局禁用它。

限制與開放問題

統計穩健性 – 基準測試基於 162 次運行和 50 個 SWE‑bench 實例；更大規模、多種隨機種子的研究將強化其主張。
圖譜過時 – 增量更新僅限結構層面；如果原始碼在未重新構建的情況下發生變化，LLM 生成的摘要可能會過時。
合併衝突 – graft/ 存在於儲存庫中；同時編輯同一個節點可能會導致需要手動解決的 Git 衝突。
對比基準 – 未提供與其他程式碼圖譜工具（如 Graphify, Repowise）的公開對比。

結論

Graft 證明了確定性的、基於 Markdown 的程式碼圖譜可以大幅降低 LLM 驅動的編碼 Agent 的 Token 和工具調用開銷，同時提高在 SWE‑bench 上的實際正確性。這種方法非常有吸引力，因為它不需要守護進程，適用於任何 LLM 供應商，並透過簡單的 CLI 與多個 Agent 整合。然而，目前的證據建立在規模有限的基準測試之上，生成知識圖譜的長期穩定性仍是一個開放的工程挑戰。