XERJ：一個會坦承自己數字灌水的程式代理搜尋引擎

很少有一個專案，最有趣的特色是它自己的坦白。

XERJ 是一個以 Rust 寫成的程式碼與文件搜尋引擎，為程式代理（coding agents）而做，採用與 Elasticsearch 相容的傳輸協定，Apache-2.0 授權。它有一張帶真實美元數字的基準測試表。它還有一則維護者註記，承認 GitHub 星數被一個合成群體灌水約十三倍，並請大家不要引用這個數字。

這兩件事都值得你花時間，而且彼此相關。

它想解決的問題

當一個程式代理需要理解一個程式碼庫時，預設動作是 grep。grep 很誠實：它找出符合某個樣式的行。但用 grep 的代理必須讀檔案，才能判斷這個相符是否有意義，而讀檔案正是把上下文視窗塞滿的元凶。一個大檔案耗掉的 token，可能比它帶來的答案還不值。

XERJ 的替代方案是本地索引。把它指向一個資料夾，autoindex 會嗅探檔案類型、推斷資料集、丟掉垃圾檔案，並為每個資料集建立獨立索引。儲存庫裡一次真實執行的紀錄長這樣：推斷出 593 個資料集，A 階段有 1,955 個垃圾或略過的檔案，接著 B 階段用八個 worker 索引 25,329 個檔案，158.1 秒完成，83,103 筆記錄上線。

程式碼用 tree-sitter 解析，保留符號與行號，而不是把所有東西壓平成文字。這就是為什麼 xerj def <symbol> 能回傳檔案、行號和簽名——跨儲存庫的跳到定義，而這正是代理一開始就需要的東西。

基準測試，得看仔細

專案跑了八個任務、四種語言，每條實驗臂十六次執行，而且實際測量 claude -p 的 token 消耗，而不是估算。三種設定：只靠記憶、grep 驅動、XERJ。

只靠記憶用了 260,916 個輸出 token，花費 $11.18，解出 16 題中的 11 題。grep 用了 26,477 個 token，花費 $3.27，16 題全解。XERJ 用了 9,982 個 token，花費 $1.58，同樣 16 題全解。

也就是說：輸出 token 比 grep 少約 2.7 倍，比依賴模型記憶少 26 倍，而解題率沒有改變。最佳單一案例——一個 Java 任務——省下 278 倍。使用者回報端到端大約 5 倍。

現在說那則讓這篇文章值得寫的但書。儲存庫的大標宣稱「比 grep 少 40 倍 token」。正文的對照實驗說 2.7 倍。這不是同一個說法，而兩者之間的落差，恰恰就是讓基準驅動的行銷不可信的那種模式。值得肯定的是，README 自己說要以正文的數字為準。一個誇大的標題配一條糾正它的註腳，是很奇怪的出貨方式，但至少那個糾正在。

發布文裡沒人提的那個限制

這是大多數「為代理做搜尋」的專案都會略過的一句話：效益取決於模型是否已經知道這段程式碼。

在私有、內部、小眾，或訓練截止之後的程式碼上，檢索能省很多，因為模型真的猜不出來。而在模型看過一萬遍的熱門開源函式庫上，索引要嘛沒用，要嘛有害——你花 token 去檢索模型早就知道的東西。

光是這一個限制，就改變了你該怎麼部署它。它不是普適的升級。它是對一種特定失效模式的修正：代理在啃那些沒有人寫過部落格的程式碼。

--insecure 旗標是一條真實的信任邊界

執行 xerj --insecure 會關掉 TLS 和 API 認證。任何能連到這個埠的人實際上就是超級使用者：讀、寫、刪除所有索引，包括 /_memory 底下的一切。在單一開發者的筆電上這沒問題，放在任何共享環境裡都是災難。

預設值比這個旗標好。新節點會綁定到 127.0.0.1，而明文綁定到非回送位址會拒絕啟動，除非你明確設定 server.allow_insecure_network_bind = true。專案還記錄了：在 0.0.0.0 上以不安全模式執行曾是一個真實漏洞——區域網路用戶端可以未經授權寫入——而且已經修好。替自己過去的漏洞取名字，是個好習慣。

那份該被當成範本的公開說明

在一次 instrumentation 提交裡，維護者寫道：儲存庫的星數與分支數被一個合成群體放大了約十三倍；真實安裝資料很單薄——大約 145 次 release 附件下載、約 28 次完成的安裝；而 Cloudflare RUM 在七月就停止記錄了，所以網站上那張零流量圖表只是個假象。

對一個聲稱相容 Elasticsearch、通過 1,371 項一致性測試（零失敗、三次略過）的專案來說，公開這些很不容易。它也順便告訴你當前開源訊號的狀態：星數是一個行銷面，任何跑成長迴圈的人都能推動它。唯一值得相信的數字，是作者違背自身利益主動交代的那些。

你還會遇到的其他東西

安裝方式是 curl 管線接到 shell，它會驗證 SHA256，找不到校驗工具就拒絕繼續——對這種模式來說，這是異常清醒的一道防護。建置是靜態 musl 加 jemalloc，Linux 優先，Windows 需手動安裝。有一個 MCP 伺服器提供十三個工具，包括 xerj_plan 和 xerj_map，而 xerj init 一條指令就能接上 Claude Code 或 Cursor。支援帶 scalar8 量化的 kNN。多節點部署附 Helm chart 和一個 compose 檔。

版本是 1.0.0-rc.x，CLI 還在變。CLA 改編自 Apache 的版本，並附一則維護者註記：沒有律師審過，還留著兩個佔位欄位。很多提交由程式代理撰寫並加以標註，這很透明，也是你該讀一讀自己所依賴的程式碼的理由。

參考式編程，沒人做基準測試的那個用法

README 裡埋著最有趣的應用：把索引指向與你正在解決的問題最接近的開源專案，然後在參考程式碼在上下文裡的情況下寫自己的版本。

很多真實的工程就是這樣做的——找到已經解決過它的函式庫，讀一遍，然後實作一個更窄的東西。做得差的方式是把半個儲存庫貼進 prompt。做得好的方式，是能夠問「這個專案在哪裡處理背壓」，然後拿到一個檔案、一行和一個函式簽名。

它也暴露了上面那個基準的侷限。參考式編程需要下載並索引別人的儲存庫，這要花時間、磁碟和網路。省下來的東西在第二次、第三次查詢時才出現，不是第一次。要評估它的人應該測整個工作階段，而不是單一任務。

關於 Elasticsearch 相容性的說法

XERJ 說 Elasticsearch 的傳輸協定，專案報告 1,371 項一致性測試通過，零失敗、三次略過。如果這站得住，那些已經針對 Elasticsearch 寫好的工具稍作修改就能指過來，而那些一直花錢養叢集來存幾百萬份文件的團隊，就有了退路。

針對 Elasticsearch 的 SSPL 授權提出的批評是公道的：SSPL 在 OSI 意義上不是開源，這對想在搜尋引擎之上做產品的公司很重要。但「相容」是一個光譜。Query DSL 的覆蓋度、聚合、分析器行為，才是差異顯現的地方，而一致性測試套件是唯一能知道你到底站在線哪一邊的辦法。

你該用它嗎

如果你的代理處理的是內部程式碼、大型私有儲存庫，或者沒有任何模型看過的日誌和文件，那理由相當充分：一個本地的、Apache-2.0 的、相容 ES 的索引，懂 tree-sitter 符號，還配一份誠實的基準。如果你的工作主要圍繞公開函式庫，你大概會發現 grep 加一份好的 ripgrep 設定同樣有效，而且維護成本低得多。

如果你要從這個專案裡帶走一樣東西，帶走那種公開說明的習慣，而不是這個搜尋引擎。一個會告訴你自己數字被灌水的工具，比一個告訴你它好四十倍的工具更值得關注。