75ms 找到三輪 grep 才看到的程式碼：實測 XERJ，給 AI Agent 的本地搜尋引擎

前言：一段我寫的程式碼，我找不到它

前陣子我修了一個 GA4 埋點的 bug：分享按鈕的事件在 dataLayer 裡靜默擱淺，修法是把 dataLayer.push 換成 gtag() 直呼。程式碼是我改的，commit 是我推的。

三天後我想回頭看那段修復，腦中只剩「好像在某個元件裡」。grep 了字串、翻了元件目錄、換了關鍵字再來一輪——三輪之後才命中。

同一週，我在 GitHub 上撞見一個 17,326 星的專案：XERJ。宣稱是一個 27MB 的 Rust 執行檔，索引你的 code、docs、logs，講 Elasticsearch 協議，專為 AI agent 設計。

半信半疑地下載來測。第一個查詢，75ms，直接命中那段修復所在的檔案。

XERJ 是什麼

一句話：本地版的 Elasticsearch，縮到一個執行檔，然後把客群換成 AI agent。

它的幾個關鍵決定：

• 單一 Rust 執行檔，27MB，零依賴，checksum 驗證後即用
• 講 Elasticsearch wire protocol——回報自己是 ES 8.13，標準 ES 工具鏈可以直接接
• autoindex 模式：指一個資料夾，它自己掃描、自己判斷檔案類型（code/prose/JSONL/PDF）、自己分段索引，零配置
• 為 agent 設計：官方文件直接寫著怎麼讓 Claude/Cursor 這類工具查詢它，甚至內建 MCP server 模式

17,326 顆星，release 節奏是「每天有新版、每天有 agent 實測回報」，這不是玩具專案。

實測：索引我的部落格 repo

安裝是工程師最愛的那種：下載、驗 sha256、丟進 PATH，結束。

# 節點先起來（ES 相容服務，預設 localhost:9200）
xerj --insecure --data-dir ./.xerj-data &

# 旗艦模式：指著資料夾，零配置
cd ~/Github/calpa-2023-website
xerj autoindex .

結果一行 summary：

xerj-done ok=true wall=32.0s files=637 records=3854
datasets=7 code_files_indexed=132 code_files_junked=0

637 個檔案、3,854 筆記錄，32 秒。全程 CPU 只吃 2.7 秒，其他在 I/O。

三發實測：我知道答案的問題

測搜尋品質最誠實的方法，是拿「我知道答案在哪」的問題去問。三發：

第一發：找那段 share_click 修復。

xerj search --prefix ax "share_click dataLayer stuck fix"
→ src/components/EveryPageComponent.astro (score 11.03)

檔案正確。分數是三發中最低的，因為我的關鍵字混了意圖描述而非實際代碼用詞。

第二發：找 sitemap 的工具頁列舉邏輯。

xerj search --prefix ax "sitemap tools import.meta.glob"
→ src/pages/sitemap.xml.ts:39 (score 20.40)

正確檔案、正確函式。

第三發：日文內容檢索。我的工具頁最近加了日文說明區，試試日文查詢能不能命中日文內容：

xerj search --prefix ax "ja-guide 日本語ガイド 画像メーカー"
→ src/pages/tools/image/aoyamagosho.astro (score 44.96)

直接命中日文指南區塊本身，而且是三發中分數最高的。跨語言檢索對內容型 repo 是真的有用——這對經營多語言內容的人來說，比 code search 更值錢。

符號定位：強項與盲區

xerj def 是符號定義查找（類似 IDE 的 go-to-definition）：

xerj def --prefix ax "setAoyamaLang"
→ src/utils/aoyamaI18n.ts:75 [function]
  export function setAoyamaLang(lang: AoyamaLang): void

精準命中，連型別簽名都帶出來，還附上同檔案的相關型別。

但盲區也在此：我把同一個符號換到 .astro 檔案的內嵌 <script> 裡測，def 回報「no definition」。Astro/Vue/Svelte 這類框架混合檔的內嵌 script，符號沒進 def 索引——fallback 是 ranked search，找得到但不是定義級精度。前端框架用戶要有這個預期。

限制清單（誠實版）

• 節點要常駐：autoindex 需要一個跑在 9200 端口的 XERJ 節點，背景服務自己管
• 一個資料夾一個 prefix：第二個 repo 索引時要換 --prefix mb 之類，跨 repo 查詢要指定 prefix
• def 的框架盲區：如上，.astro 內嵌 script 符號不在定義索引
• rc 階段：版本還在 1.0.0-rc.97，release 筆記裡還有 wire-compat 的修補，拿去接正式 ES 叢集前要測

給 AI Agent 的記憶體

真正讓我留下這個工具的原因，不是它取代 grep——grep 很好，永遠會在。

是它的定位：agent 的本地記憶體。文件裡直接寫了 “Agent memory”、“Semantic search & RAG” 的 playbook，MCP server 模式讓 Claude 這類工具可以直接查詢索引。

想像一下這個工作流：你的每個 repo 都 autoindex 進 XERJ，AI agent 開始任何任務前先查詢「這件事之前做過嗎、當時怎麼做的」。不是向量資料庫那種要先 embedding 的重工程，是一個執行檔加一條 HTTP 查詢。

我的三輪 grep，就是沒有這層記憶體的樣子。

結語

XERJ 不完美：rc 版本、def 有框架盲區、節點要自己管。但「75ms、單檔、ES 相容、為 agent 設計」這四個詞放在一起，在 2026 年的工具市場上是站得住的。

它已經成為我工作流的常駐服務。兩個 repo 索引好了，查詢一行：

xerj search --prefix ax "你的問題"

至於那段我找不到的 share_click 修復——現在它離我只有 75ms。