效能基準 · codegraph 繁中教學站

結論先講

通用勝利：每個 repo、每個規模——88% 更少工具呼叫 · 53% 更快 · 62% 更少 token · 44% 更便宜 · 檔案讀取七個 repo 全歸零。

有索引時，agent 用 1–4 次 codegraph_explore 呼叫就答完並停止；沒有時，agent 把預算燒在 discovery——最多 43 次工具呼叫、19 次檔案讀取去重新推導圖譜早就知道的東西。每個 repo 都更快：最窄的問題快 35%，最寬的快 3.6×。

七個 repo 對照（中位數，WITH vs WITHOUT）

Codebase	語言	工具呼叫	時間	檔案讀取	Token	成本
VS Code	TypeScript · ~11k 檔	2 vs 28	2.2× 快（58s vs 2m10s）	0 vs 12	77% 少	71% 省
Excalidraw	TypeScript · ~640	2 vs 43	3.6× 快（45s vs 2m42s）	0 vs 18	84% 少	78% 省
Django	Python · ~3k	3 vs 14	35% 快	0 vs 8.5	41% 少	13% 省¹
Tokio	Rust · ~790	3 vs 29	2.6× 快	0 vs 19	65% 少	64% 省
OkHttp	Java · ~645	1 vs 6	43% 快	0 vs 2	54% 少	21% 省
Gin	Go · ~110	1 vs 7	39% 快	0 vs 4	52% 少	~even¹
Alamofire	Swift · ~110	4 vs 33	2.6× 快	0 vs 16.5	59% 少	57% 省

¹ 成本跟「問題需要多少 discovery」有關，比其它欄波動大：需 28–43 次工具呼叫的 repo 省 57–78%，Django 14 次、Gin 7 次就答到的只省 13% 或打平。WITH arm 仍只用 3 / 1 次呼叫、零檔案讀取。

方法論（誠實的部分）

每 arm 是 claude -p（Claude Opus 4.8）headless 跑，--strict-mcp-config：WITH = 啟用 CodeGraph MCP；WITHOUT = 空 MCP config。內建 Read/Grep/Bash 兩邊都有。同問題 4 runs/arm，取中位數。
codegraph CLI 兩邊都封鎖——sanitized PATH + PreToolUse hook 拒絕任何 Bash 呼叫 CLI（WITHOUT 也封）。沒封的話，WITHOUT agent 會自己找到 CLI 用 Bash 呼叫（28 次跑中 26 次），讓對照失真。本次 28 次 WITHOUT 全部被封、0 污染。
repo 以 --depth 1 clone，由同一份 CodeGraph build 索引。

但代價也是真的：殘留上下文佔用

誠實取捨：以上數字量的是 throughput（處理的 token、呼叫的工具、花的錢）。若量「session 結束後 context window 裡還剩下什麼」，CodeGraph 反而更多——同樣七 repo 多輪 session，CodeGraph 的回應在結束時留下約 80% 更多的 retrieval context（VS Code 上 67k vs 18k token）。機制正是它快的原因：CodeGraph 回傳一坨 dense、逐字的 payload，答完問題後就留在 window 裡；grep-and-read agent 則 churn 很多會被逐出的小結果。處理較少 token 與較大常駐 footprint 同時為真。小窗口跑長 session 時要把這個算進預算。

看完這頁你應該能說出：七 repo 的通用勝利數字、為什麼「成本」欄比其他欄波動大、CLI 封鎖對對照可信度的重要性、以及殘留上下文佔用的誠實取捨。