代理搜尋是執行環境問題

2026年5月14日的一篇 arXiv 論文，在 Chronos、Claude Code、Codex 與 Gemini CLI 上，針對 116 個 LongMemEval 問題測試 grep 與向量檢索。論文第一個實驗中，內嵌 grep 在每一組代理框架與模型配對上都勝過內嵌向量檢索。但更值得注意、也更反直覺的發現是：執行環境對結果的影響，幾乎和檢索器本身一樣大。¹

代理搜尋品質不只存在於「grep 對上向量」這個問題裡。它存在於完整的執行環境：提示、工具介面、shell 操作體驗、結果格式、上下文壓力、交付路徑、重試行為，以及模型完成工具迴圈的能力。

TL;DR

Sen、Kasturi、Lumer、Gulati 與 Subbiah 比較了詞彙搜尋與向量搜尋，測試對象包含一個名為 Chronos 的自訂代理框架，以及 3 個供應商原生 CLI 代理框架：Claude Code、Codex 與 Gemini CLI。¹研究使用 116 題 LongMemEval-S 子集，並同時測試內嵌工具結果與檔案式工具結果。¹在實驗 1 中，內嵌 grep 在每一組代理框架與模型配對上都優於內嵌向量檢索；其中 Codex CLI 搭配 GPT-5.4 時，內嵌 grep 達到 93.1%，內嵌向量檢索則為 75.9%。¹這篇論文並未證明 grep 普遍優於向量搜尋；作者明確把結論限縮在長期記憶對話式 QA 設定，因為這類答案經常取決於字面片段。¹對代理建構者來說，真正有用的結論更精準：檢索方法、代理執行環境與結果交付方式構成同一套系統。請把它們放在一起做基準測試。

重點摘要

• 給代理建構者：請把 grep 視為嚴肅的基準線。這篇論文的結果讓「預設用向量」在聊天紀錄的長期記憶 QA 中顯得草率，尤其當字面姓名、日期與使用者事實很重要時。¹
• 給 Codex 與 Claude Code 使用者：不要把供應商 CLI 當成包在搜尋基本操作外面的中立外殼。論文指出，即使用的是同一批底層對話資料，不同代理框架仍會造成明顯差異。¹
• 給 RAG 團隊：請回報交付路徑，而不只是檢索器。內嵌結果與檔案式結果會產生不同表現，因為檔案交付又增加了一項工具使用任務。¹
• 給遷移工作：請保留讓搜尋可靠的執行環境行為。從 Claude Code 遷移到 Codex 時，應先測試檢索、逐字稿形態與驗證迴圈，再宣稱已達同等效果。
• 給高度依賴引用的系統：最終引用不是完整的證據故事。另一篇 Agentic GraphRAG 論文主張，來源追溯可能取決於造訪過但未引用的圖脈絡，而不只是已引用節點。⁴

這篇 grep 論文實際測了什麼？

這篇論文問的是一個務實問題：當 LLM 代理必須根據很長的對話歷史回答問題時，檢索表現有多少取決於搜尋方法，又有多少取決於包在外面的代理系統？¹

作者比較了 2 種檢索家族：

他們也把這些檢索器放進 2 類執行環境中測試：

他們也改變了結果抵達模型的方式。內嵌交付會把搜尋命中直接插入對話；程式化交付則把結果寫入檔案，再要求模型找到、開啟並整合內容。¹這聽起來像實作細節。資料顯示，它其實是任務的一部分。

為什麼 grep 在這裡勝出？

這項量測任務偏好字面還原。LongMemEval 要求模型根據多個長對話階段回答問題。許多答案取決於姓名、時間表述、個人事實或過去的精確陳述。在這種設定下，高精準度的詞彙工具可能勝過語意檢索器，因為答案往往藏在一段具辨識度的字串後面。¹

論文的表 1 清楚呈現這個模式：

這張表不是在說「刪掉您的向量資料庫」。論文本身也提醒讀者不要如此解讀。作者指出，他們的結論限於長期記憶對話式 QA；在科學綜述、視覺文件或程式碼語意等場景中，密集檢索或混合式檢索可能有不同表現。¹

更好的解讀是：精確搜尋在任何嚴肅的代理執行環境中，都應該有一席之地。如果代理能搜尋檔案系統、讀取記錄、檢查過去逐字稿，或還原字面使用者事實，詞彙搜尋可能就是工具箱裡成本最低、訊號最強的工具。

執行環境改變了結果

這篇論文最有用的一句，不是「grep 贏了」。而是：更換代理框架造成的上限位移，幅度大致可與更換檢索器相比。¹

舉例來說，Claude Opus 4.6 使用內嵌 grep 時，在 Chronos 下達到 93.1%，在 Claude Code 下則為 76.7%。¹模型家族相同，基準子集相同，執行環境不同。另一個例子是，Codex CLI 搭配 GPT-5.4 時，內嵌 grep 達到 93.1%；但 grep 結果改走程式化檔案交付路徑後，下降到 55.2%，而程式化向量檢索則為 67.2%。¹

這不只是檢索結果。這是執行環境結果。

模型不只要找到證據。它還必須理解工具合約、選擇搜尋詞、解讀 stdout、判斷何時重試、在結果不是內嵌時讀取檔案，並把證據整合成答案。每一步都屬於代理執行環境。只要其中任何一環變脆弱，再強的檢索器也可能產出弱答案。

為什麼檔案式交付是在測工具使用？

檔案式交付有明顯吸引力。它可以把大量搜尋結果留在即時逐字稿之外，直到模型要求讀取才載入，藉此降低上下文壓力。當內嵌向量結果大量塞滿視窗時，這本來應該有幫助。

論文呈現了取捨。程式化向量在多個列中勝過程式化 grep，這支持了上下文壓力的論點。¹但 Codex/GPT-5.4 那一列也顯示另一面：檔案交付可能把廉價檢索變成多步驟工作流程。代理必須找到產物、開啟它、擷取有用片段，並在第一次讀取不足時重試。¹

也就是說，程式化交付是用上下文頻寬交換工具迴圈能力。只有當執行環境能穩定完成這個迴圈，這筆交易才划算。

這對真實工作很重要。本地代理的搜尋失敗，不只因為索引錯了。它也可能失敗於 stdout 切塊不佳、結果檔案路徑太容易漏看、命令回傳過多雜訊、提示把任務框錯，或模型少讀一次就提前停下。

這對 Codex 遷移意味著什麼？

我自己的 Claude Code 到 Codex 遷移，重點一直放在移轉操作合約，而不是複製檔案樹。這篇論文強化了這個選擇。

如果搜尋品質取決於執行環境，那遷移品質就不只是在問「Codex 有沒有搜尋工具？」遷移必須保留那些讓搜尋有用的行為：

• 代理知道何時應先用精確搜尋，再用語意搜尋；
• 命令輸出維持在可閱讀的大小；
• 證據路徑能保留到最終答案；
• 檔案式產物容易定位與檢查；
• 搜尋失敗會觸發更好的查詢，而不是過早回答；
• 公開寫作使用來源驗證，而非看似合理的檢索結果。

這份清單刻意保持公開且通用。它不揭露私有掛鉤、私有提示或本地工作流程內部細節。重點在操作合約：讓代理證明它找到什麼，而不只是對自己做過的搜尋顯得很有信心。

這篇論文也解釋了為什麼遷移在每個明顯功能都存在時，仍可能感覺變差。Claude Code 與 Codex 也許都暴露 shell 工具。兩者也許都能讀檔、都能搜尋。但只要逐字稿格式、檔案結果處理、停止行為或重試模式不同，同一個搜尋基本操作就可能產出不同工作品質。

另外 3 個訊號也指向同一件事

同一批掃描中，2026年5月14日另外 3 篇論文也指向更大的模式：代理品質正在從孤立的模型呼叫，移到執行環境架構。

APWA 把高度平行的代理工作視為分散式執行問題。作者把工作流程拆成互不干擾的子問題，讓獨立資源在不跨通訊的情況下處理，並在先前系統失敗的大型任務上評估擴展能力。²這是執行環境主張，不是提示技巧。

MeMo 把記憶視為獨立模型元件。它固定執行用的 LLM，把新知識編碼到專用記憶模型中，並回報其對檢索雜訊的抗性，以及與開源和閉源 LLM 的隨插即用相容性。³這是記憶架構主張，不是更長上下文主張。

Agentic GraphRAG 來源追溯論文主張，最終引用可能必要但不足。準確答案可能取決於未引用的遍歷脈絡、圖結構，以及造訪過但未引用的實體。⁴這是來源追溯主張，不是引用格式主張。

把這些放在 grep 論文旁邊，輪廓就浮現了：

共同主題是：外層框架就是產品。執行環境決定模型能力是否能變成可用工作。

我會如何調整代理技術棧

從乏味但可靠的基準線開始。讓代理能對重要的檔案、記錄、逐字稿或筆記做精確搜尋。先量測這個，再加入語意檢索。

接著測試 4 種組合，而不是 2 種：

記錄每次執行的工具逐字稿。最終答案不夠。您需要知道代理是否搜尋了正確詞彙、開啟了正確檔案、注意到正確片段、在漏失後重試，並引用真正支持答案的證據。

當領域需要改寫語句還原、概念綜合或非字面證據時，再加入向量搜尋。當領域包含姓名、ID、檔名、日期、記錄行、命令輸出、使用者偏好或過去指示時，保留精確搜尋。任務同時混合兩者時，使用混合式路由。

對公開寫作而言，檢索路徑應更嚴格。引用文章應保留來源 URL、主張與來源對齊關係，以及仍未驗證事項的紀錄。如果系統使用圖、記憶層或中間檢索路徑，最終引用不應是唯一痕跡。來源追溯論文是針對 Agentic GraphRAG 提出這點，但產品層教訓更廣：證據應說明路徑，而不只是目的地。⁴

更好的基準問題

薄弱的基準問題是：

哪一個檢索器比較好？

更強的問題是：

在這個執行環境、這個模型、這個語料庫、這條交付路徑與這套重試政策下，哪一種搜尋行為能產出經驗證的答案？

這個問題回答起來比較慢。它也更有用。

代理工作總是不斷誘惑人們提出元件式主張：更好的模型、更好的檢索器、更好的提示、更好的記憶、更好的平行能力。實務現實卻不斷把方向推回另一邊。只有當執行環境把元件轉成從任務到證據再到行動的可靠路徑後，元件才真正重要。

這才是值得遷移的部分。

FAQ

這篇論文是否證明 grep 勝過向量搜尋？

沒有。作者明確把結果限縮在所研究的長期記憶對話式 QA 設定。他們也指出，在證據很少是字面形式的領域中，密集檢索與混合式路由可能有不同表現，包括科學綜述、重視視覺的文件與程式碼語意。¹

為什麼 grep 在實驗中表現這麼好？

LongMemEval 問題經常取決於過去對話中的字面片段：姓名、日期、個人事實與精確陳述。當代理能猜到具辨識度的詞時，grep 會回報高精準度模式。¹

為什麼代理框架這麼重要？

執行環境控制提示形狀、工具描述、逐字稿格式、shell 行為、上下文建構、結果交付與停止條件。論文指出，即使底層對話資料相同，Chronos、Claude Code、Codex CLI 與 Gemini CLI 之間仍出現大幅準確率差異。¹

Codex 使用者應該怎麼做？

把精確搜尋保留為基準線，檢查工具逐字稿，並在假設某種檢索方法較好之前，先測試內嵌與檔案式交付。論文中的 Codex 列很有參考價值，但它仍只是一種基準設定、一種語料庫類型，而且對供應商整體擴展表現而言仍是不完整圖像。¹

這和 RAG 引用有什麼關係？

Agentic GraphRAG 來源追溯論文主張，最終引用可以支持答案，但仍可能省略曾影響答案的檢索脈絡。對代理系統而言，引用品質應包含整條路徑的來源追溯，而不只是最終引用來源清單。⁴

從 Claude Code 遷移到 Codex 時應保留什麼？

請保留操作行為：代理何時搜尋、如何限制輸出、如何開啟證據、如何重試、如何記錄來源路徑，以及如何拒絕無根據主張。不要因為兩個環境都暴露 shell 與搜尋命令，就假設兩者已經等效。

參考資料