當程式設計代理收到提示時，為了給出正確答案，必須透過閱讀檔案與搜尋相關資訊來建立對程式碼庫的理解。

Cursor 的 Agent 使用的工具之一是語意搜尋。除了像 grep 這類工具提供的正規表示式搜尋之外，它還能根據自然語言查詢（例如：「我們在哪裡處理驗證？」）找出相符的程式碼片段。

為了支援語意搜尋，我們訓練了自家的嵌入模型，並打造了索引處理管線，以便快速擷取。雖然你可以完全依賴 grep 與類似的命令列工具來搜尋，但我們發現語意搜尋能大幅提升 Agent 的效能，特別是在大型程式碼庫中：

• 在回答問題的準確度平均提升 12.5%（依模型不同介於 6.5%–23.5%）。
• 產生更有可能被保留於程式碼庫中的程式碼變更。
• 讓使用者以更少的反覆迭代即可得到正確的解決方案。
• 在我們測試的所有模型上提升準確度，包括所有最先進的程式設計模型。

離線評估

我們維護一套名為 Cursor Context Bench 的評估資料集，專注於在具有已知正確答案的程式碼庫中進行資訊擷取。此評估涵蓋 Cursor 中最常用的各模型，包括我們自家的Composer。

本比較針對兩組可用工具的效能進行評估：一組包含語意搜尋，另一組則不包含。在所有設定下，語意搜尋都能顯著改善成果。

線上 A/B 測試

我們也想了解對最終使用者體驗的影響。我們進行了一次 A/B 測試，兩個群組都使用相同的模型，但其中一個群組的 Agent 可使用語意搜尋，另一個則僅依賴像 grep 這樣的傳統搜尋工具。我們觀察了兩項指標：

• 程式碼保留率：由高效代理所撰寫的程式碼更可能留存在使用者的程式碼庫中。我們觀察到，當提供語意搜尋時，代理產生的程式碼保留率提升 0.3%。在包含 1,000 個以上檔案的大型程式碼庫中，此效果提升至 2.6%。
• 不滿意的使用者請求：由表現良好的代理撰寫的程式碼不需要後續追問或更正。我們觀察到，在無法使用語意搜尋時，不滿意的後續使用者請求增加了 2.2%。

此處的效果量較低，因為這次 A/B 測試涵蓋所有代理查詢，但並非所有請求都需要搜尋。

自訂檢索模型

促成這些成果的關鍵之一是我們的自訂嵌入模型。我們的方法以 Agent 會話作為訓練資料：當 Agent 執行任務時，通常會在找到正確的程式碼之前進行多次搜尋並開啟多個檔案。透過分析這些操作軌跡，我們可以事後判斷，在對話的較早階段本應先擷取到哪些內容。

我們會將這些追蹤資料提供給 LLM，讓它在每個步驟評估並排序哪些內容最有幫助。接著我們訓練嵌入模型，讓其相似度分數與這些由 LLM 產生的排序對齊。如此形成回饋迴圈，模型便能從 Agent 實際處理程式開發任務的方式中學習，而不是依賴一般化的程式碼相似度。

結論

要獲得最佳效果，目前必須使用語意搜尋，特別是在大型程式碼庫中。

我們的 Agent 充分運用 grep 與語意搜尋，兩者結合能帶來最佳結果。隨著模型持續進步，我們會持續測試與評估提供給 Agent 執行架構的所有工具。