每日突破性工具推薦｜Sift

Sift：把 grep 從「每次全掃」變成可索引的程式碼搜尋引擎

工具定位與適用情境

Sift 是以 Rust 開發的 indexed regex search 工具，目標是在大型程式碼庫中提供接近 ripgrep 的操作體驗，但不必每次查詢都重新掃描整個 repository。它先為程式碼建立 trigram index，再利用索引縮小候選檔案集合，最後才交給完整 regex engine 驗證。

它特別適合大型 monorepo、Linux kernel 等高檔案數程式碼庫，以及會反覆搜尋 repository 的 AI Coding Agent、Code Review Agent、重構工具與本機開發流程。

為什麼值得注意

傳統 grep / ripgrep 的優勢是零前置成本：輸入 pattern 後直接高速掃描檔案。但對人類偶爾搜尋而言很合理的模型，放到 Coding Agent 上就會出現新的成本結構——Agent 可能在單次任務裡進行數十甚至數百次 repository search。

Sift 把這個模型改成：

Repository
    ↓
一次建立 trigram index
    ↓
memory-mapped posting lists
    ↓
query → pattern planning
    ↓
trigram intersection / union
    ↓
candidate files
    ↓
完整 regex scan
    ↓
results

也就是把「每次搜尋都掃完整 repository」改成「先用索引快速排除不可能匹配的檔案，再精確掃描候選集合」。

這個改變對 Agent workflow 特別有意義，因為索引建置成本可以被大量後續查詢攤平。

核心架構與運作方式

Sift 的索引目前以 3-byte trigram 為核心。

建立索引時，它會從檔案內容擷取重疊的三位元組，建立對應 posting lists，並將資料保存為 memory-mapped on-disk tables。

搜尋時，Planner 會分析 regex 中可以安全抽出的 literal / trigram 條件，再透過 posting list 的 intersection 或 union 得出候選檔案。

只有候選檔案會進入完整 regex engine，因此索引本身不是 regex engine 的替代品，而是前置的 candidate narrowing layer。

如果 query 無法抽出可利用的 literal，例如部分純 Unicode class 或沒有固定字串的 regex，Sift 會 fallback 到 full scan，確保搜尋語義仍然正確。

專案架構也刻意把 index family 做成可組合設計；目前預設是 ngram-3，但 Planner、Searcher 與 CLI 並不與單一索引實作緊密綁定，未來可以加入其他 index family。

效能特點

官方在 Linux kernel source tree（約 79K files、1.3 GB）上的 benchmark 顯示：

• literal query：ripgrep 1.17 秒，Sift 0.42 秒，約 2.8×
• word match：1.15 秒對 0.41 秒，約 2.8×
• 含 literal 的 regex：1.17 秒對 0.44 秒，約 2.7×
• alternation：0.88 秒對 0.48 秒，約 1.8×
• 無法利用索引的 Unicode / no-literal query 則接近 ripgrep full-scan 表現

官方同時指出，索引命中的 literal query，其搜尋引擎本體約可在 18 ms 完成；CLI wall-clock 的主要成本反而來自 process startup 與 daemon coordination。

這些數字是專案自己的 benchmark，應視為特定 workload 下的結果，而不是所有 repository 都能固定得到 2–3× 加速。

對 AI Coding Agent 的價值

Sift 直接提供 Agent Skill，可透過 npx skills add botirk38/sift 安裝，並標示可供 Claude Code、Cursor、Codex、Devin 與其他支援 SKILL.md 的 Agent 使用。

這點比單純 CLI 效能更值得注意。

Coding Agent 的 repository exploration 通常包含：

搜尋 symbol
→ 找 caller
→ 搜尋 config
→ 找 implementation
→ 比較 tests
→ 搜尋相似 pattern
→ 修改
→ 再次搜尋驗證

這類工作負載天然具有「同一 corpus、大量重複 query」的特性，正好符合 persistent index 的成本模型。

因此 Sift 可以被理解為一種 Agent-oriented local retrieval primitive：不是用 embedding 做語意搜尋，而是把精確 code search 的 latency 降低。

相較 ripgrep 的優勢

Sift 的主要優勢是 repeated-query workload。

ripgrep 不需要 index、幾乎零維護，而且單次搜尋已非常快；Sift 則犧牲首次 index build 與 index lifecycle 的複雜度，換取大型 repository 後續查詢的低延遲。

因此兩者不是單純的「新工具取代舊工具」：

• 偶爾搜尋、小型 repository：ripgrep 通常更簡單。
• 大型 repository、持續搜尋：Sift 的索引模型更有優勢。
• Agent 高頻探索：Sift 的 amortized search cost 更值得考慮。

相較語意搜尋 / Embedding Retrieval

Sift 並不嘗試理解程式碼語意。

這反而是一項優勢：symbol、constant、error string、API 名稱、config key、function call 等精確查詢不需要 embedding model，也不會遇到 semantic retrieval 的召回不確定性。

比較合理的未來架構不是二選一，而可能是：

Agent Retrieval
├─ exact / regex → Sift
├─ symbol graph → LSP / AST index
└─ semantic intent → embedding / code retrieval model

Sift 可以成為其中成本最低、結果最 deterministic 的一層。

缺點與限制

第一，Sift 必須先執行 sift index build，因此存在 indexing cost 與 index freshness 問題。

第二，搜尋路徑必須位於已索引的 corpus root 下，使用模型不像 ripgrep 那樣完全 stateless。

第三，預設會使用 background daemon；在不允許常駐 process 的環境中需要使用 SIFT_NO_DAEMON=1 等替代方式。

第四，無法從 regex 抽出有效 trigram 的查詢仍會退化為 full scan，此時效能不一定優於 ripgrep。

第五，目前專案仍年輕，CLI compatibility、生態成熟度、跨平台實戰驗證與長期 index format stability 都不能與 ripgrep 相提並論。

適合誰

適合：

• 大型 monorepo
• AI Coding Agent / Autonomous Coding Workflow
• 大型 C/C++、Rust、Java、TypeScript repository
• 需要反覆 regex / literal search 的開發工具
• 本機 code intelligence pipeline
• 想降低 Agent repository exploration latency 的團隊

不太適合：

• 小型專案
• 每次只搜尋一次的 CI job
• repository 內容高度短命、索引幾乎無法重用的 workload
• 主要需求是語意搜尋而不是精確搜尋
• 不希望維護任何 persistent index / daemon 的環境

結論

本次採用「近期仍活躍且具代表性的工具」fallback。

Sift 的突破點並不是發明新的 regex engine，而是重新檢視 AI Coding Agent 時代最普通的一個 primitive：grep。

當 repository search 從「人類偶爾按一次」變成「Agent 在一個任務內呼叫數十次」，原本不值得維護索引的成本模型開始改變。

Sift 用 trigram index、memory-mapped posting lists 與 regex candidate narrowing，把精確程式碼搜尋從 repeated full scan 轉向 indexed retrieval。它目前仍是年輕工具，但這種「為 Agent 高頻工具呼叫重新設計傳統 developer primitive」的方向，非常值得持續觀察。