AI coding tools
Ripwire 0.4 以程式圖替代理縮小搜尋範圍，但省 token 未必降低任務成本
Ripwire 用 tree-sitter、符號關係圖與 Personalized PageRank，為程式代理產生可重現的檔案排名及變更影響範圍。首方測試顯示定位率優於五種比較工具，獨立檢視卻指出壓縮上下文後的答案品質與整體代理成本仍可能倒退。
Ripwire 0.4.0 於 9 月 7 日發布，試圖解決程式代理反覆搜尋、讀取大量原始碼才能理解儲存庫的成本。它是零執行期相依的 C++23 CLI，亦可作為 MCP server；本機以 tree-sitter 解析程式，抽取符號、呼叫及匯入關係，再用 Personalized PageRank 依任務描述排序。輸出不只列出候選檔案，還可附上函式簽章、呼叫者、複雜度、Git 變更頻率、變更放大範圍及建議測試，且不需要 embedding、API key 或託管向量索引。
[專案的評測](https://github.com/redhat-et/ripwire)在 60 個以 Python 為主的 LocBench 樣本上，strict file@10 為 58.3%，亦即所有標準答案檔案均進入前十名；最佳比較工具為 40.0%。但這只是「找到檔案」，不是產生正確修補。其 Django 實驗把上下文 token 壓至直接 grep-and-read 的約 5%，嚴格答案通過數卻只有 5／12，後者為 11／12。
更值得注意的是專案公開的六次 Codex 代理實驗：Ripwire 三次都把標準修補檔排在第一，加入它的流程卻使輸出 token 中位數增加約 80.2%，牆鐘時間增加約 40.7%。[獨立技術檢視](https://wavect.io/blog/ripwire-ai-repo-context-review-2026/)認為問題主要來自代理載入過多技能說明及例行呼叫，而非排名器本身。工程團隊因此應把它當成範圍不明時才啟用的定位器，保留直接搜尋與測試路徑；評估指標也應是通過驗收的修補成本，而不是單次查詢節省多少 token。