裝了一堆 codebase 搜尋工具，agent 幾乎都不用

兩個月，一個工作 repo，我前後評估了 7 個程式碼搜尋 / 探索 MCP 工具。其中 3 個真的裝起來跑過，另外 4 個評估完就否決了。

裝起來的那幾個，索引都建好了、功能也正常。但 agent 幾乎都沒在用。它退回 grep（內建的關鍵字搜尋）的次數，比動用這些工具還多。

我一開始覺得是工具不行。後來才意識到，問題根本不在工具。

三戰三敗，然後我才搞清楚問題在哪

真的裝起來、不給任何提示裸測的，有三個：

claude-context（zilliztech/claude-context，走向量語意搜尋）：翻過 1206 個對話的紀錄，它的搜尋功能總共被呼叫 23 次，23 次全回「找不到結果」，命中率 0%。索引是完整的（489 個檔案、5566 個程式碼片段都建好了），問題不在索引，就是搜不到，後來直接清掉。

context-mode（mksglu/context-mode，沙盒執行 + 全文檢索 + 輸出壓縮）：裝了 5 天、132 個對話，真正被用到 0 次。還附帶一個事故：它留下 18 個沒收乾淨的背景行程，其中兩組卡進無窮迴圈、分別吃掉 98%、99% 的 CPU，整台機器負載飆高，移除之後系統負載直接砍半。工具沒裝成，倒是多除了一輪錯 🤣

codegraph（colbymchenry/codegraph，走 AST 語法樹圖譜路線）：不給任何提示時，3 個對話裡 64 次操作 0 次用它。後來我加了引導提示叫它優先用，最好的場景也只爬到大約 14%（8/55），ClojureScript 那邊仍是 0/16。

三戰三敗，沒一個真的派上用場。

這時候我的第一反應是：「演算法選錯了吧，換個範式試試？」

問題不是工具爛，是 agent 對不熟的工具天生保守

codegraph 加了引導還是只到 14% 天花板，而且仔細看它用了什麼：agent 只用了基本的符號搜尋，那些更進階的關係查詢（找呼叫者、被呼叫者、影響範圍）完全沒碰。

偏偏 codegraph 官方主打「省 92% 操作次數」，這個數字正好全部來自那些進階查詢，也就是被用了 0 次的那部分。能力指標跟實際採用，完全脫鉤。

三戰三敗是結構性結論，不是個案：agent 面對不熟的 MCP 工具，預設就是保守，看到工具清單也不主動選，永遠退回它熟悉的 grep 和直接讀檔。

剩下 4 個（code-review-graph、repomix、codebase-memory-mcp、repowise）我連裝都沒裝，評估階段就否決了。理由各不同（功能跟內建工具重疊、程式本身不穩、實際跑過但主打功能在這個 repo 根本沒資料），但共同點是：看完前三個的結果，沒理由相信換一套演算法範式就能逃出同一個結局。

7 個前作，沒一個被 agent 自然用起來。

採用率才是 agent 工具的真跑分，但主流跑分都沒在量

到這裡，我才發現自己其實量錯了東西。

主流的程式碼搜尋評測，像 CodeSearchNet、CoIR，比的是檢索品質（recall、MRR、NDCG 那些指標），看的是「找得準不準」；另一類 agent 工具呼叫的評測，像 BFCL、τ-bench，比的是「呼叫對不對、任務完不完成」。2026 年 5 月還有一篇論文叫 Is Grep All You Need?，比的也是 grep 跟向量搜尋的品質差距。

這兩類跑分，都不把「一個可選的工具，agent 到底會不會主動拿起來用」當成被評測的維度。連 semble 自己對外的標語都是「比 grep 省 98% token」，行銷講的還是 token 數字，不是採用率。

而「agent 對不熟的 MCP 工具保守、退回 grep」這件事，不是我一個專案的孤例。ast-grep 的維護者記錄過 Gemini 寧可自己編 CLI 指令、也不用它提供的 MCP 工具；Hacker News 上也吵過 MCP 跟 CLI 工具到底該怎麼選；上面那篇論文同樣談這件事。根因大致兩個：模型對 grep 這種老工具太熟，加上沒有明確指令叫它換工具（工具一多，光把每個工具的說明塞進對話，就開始拖累判斷）。

所以結論是：能力和採用，是兩件事。採用率才是 agent 工具的真跑分。這個維度，主流跑分裡幾乎沒在量。說白一點：搜尋品質的跑分回答的是「找不找得到」，但我真正卡住的，是「agent 會不會先想到要用它」。

第 8 個工具：semble 怎麼突破的

semble（MinishLab/semble，用一種輕量的靜態語意嵌入模型）是第 8 個工具，也是第一個真的被用起來的。

全期被呼叫 33 次（其中 32 次是搜尋），跨 8 個對話。把刻意做的對照測試扣掉之後，真正日常工作裡自然用到的是 25 次、跨 6 個對話（5/22 到 5/28）。這 6 個對話裡，有 2 次它是 agent 第一個動手就拿的工具，而且沒有一個對話完全忽略它。這是前 7 個工具從來沒出現過的數字。

而且它真的進了生產：有一次靠它找到問題、改完上了一個合併進主線的 PR，處理的是一個橫跨前後端的篩選 bug。從「semble 找到檔案 → 讀進來 → 改好上線」整條鏈是通的，不是玩具用法。

它破關不是因為演算法突然碾壓前 7 個，而是兩個條件同時成立：

一個是工具本身夠好用：靜態語意嵌入，純 CPU 就能跑、不用另外架服務，檢索品質到了夠用的門檻。

另一個是採用槓桿：在這個 repo 的 CLAUDE.local.md（Claude Code 會自動讀、但不進版控的本機指令檔）裡寫一句話，叫 agent 優先用 semble 取代 grep 做概念搜尋。

我原本三招一起上（工具本身 + 指令 + 再包一層 subagent 子代理），結果 subagent 那條 0 次派工，砍了。真正有效的只有「工具 + 指令」。

誠實面對 token 數字

semble 自己的儀表板回報省了 96% token、累計大約 140 萬，但這是拿「把整個檔案讀進來」當對照的樂觀數字。

我早期做過一組對照實測：用 semble 的那組花 $4.06，沒用的那組 $5.93，真實省下來大約 32%。

它對外標語講的「比 grep 省 98%」又是第三個口徑（跟 grep 比）。三個數字基準都不同，不能混著看。

但更老實說——真正的價值其實不在省 token，是跨語言（polyglot）的概念橋接。

這個 repo 是後端 ClojureScript、前端 TypeScript 的混合 codebase。我用一句自然語言描述概念去查，semble 一次就撈到跨兩個語言的相關檔；換成 grep，得先知道確切的函式或變數名稱，還要分語言各搜一次。

舉幾個實際的：有一次要找一個「延遲後重試」的背景任務，它的檔名裡根本沒有「retry」這個字，grep 搜不到，semble 靠語意就命中了。還有一次問某個功能在哪，它直接同時點出前端的元件和後端的對應檔。連中英混著查都行（中文描述操作 + 英文 API 名混在一起）。

這是 grep 補不上的地方，也是我留下 semble 的理由。不是那幾個漂亮的 token 數字。

評這類工具，我現在會把三件事分開

評估過 7 個工具之後，現在再看這類工具，我會拆成三個獨立的軸：

採用軸：agent 會不會自發選用。槓桿是專案指令檔（CLAUDE.md / AGENTS.md）裡那句明確指令。不加，幾乎不會自動選。

脈絡效率軸：搜尋過程的中間結果會不會塞爆主對話。解法是用一個 subagent（子代理）包起來，中間結果留在子代理那邊，主對話只拿回一份摘要。

工具效能軸：檢索品質、速度、索引成本。槓桿是工具本身的設計。

最反直覺的一點：子代理只解脈絡效率，解不了採用。因為「要不要派一個子代理」跟「要不要用一個 MCP 工具」是同一種判斷：agent 看說明自己決定動不動手。對不熟的子代理它一樣保守，何況派出去就收不回來，門檻反而更高。semble 那條子代理 0 派工，正好印證這點。

看官方頁面那些檢索品質、省 token 的漂亮數字，量的都是工具效能軸，不代表採用軸會過關。這兩件事，前面 7 個工具已經示範得夠清楚了。

我自己設計這個實驗時，也犯了同一個錯

最後講個自打臉的。

我在設計 semble 這輪測試時，第一版的對照組本身就掉進了整篇在講的坑：我只「把工具裝著、開好」就開始測，沒有寫那句叫 agent 優先用它的指令。

問題是——「裝著但沒指令，agent 會不會自己用」這件事，前面三個工具已經用 0 採用率回答過三次了。等於我測了一個早就知道答案的問題，什麼也沒驗到。後來被提醒，才改成「裝好 + 加上明確指令」一起測，這時候才真正測到「指令」有沒有用。

連設計這個實驗的人都會這樣搞混，可見「工具有能力」跟「工具會被用」這兩件事，真的很容易被當成同一件。

收斂成兩件事

破關靠的就兩件：工具夠輕、檢索品質過得了關，再加一句明確的指令叫 agent 優先用它。演算法當然要先過門檻，但真正讓它被用起來的，是後面那句指令，不是演算法多強。

裝了工具就等 agent 自己去用，這事通常不會發生。

供大家參考。