{"notes":[{"id":"retrieval-augmented-generation/deep-agentic-search","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Deep Agentic Search","subtitle":"傳話遊戲","author":"Z. Yuan","paperDate":"2026-08-02","publishedOn":"2026-09-27","paperTitle":"Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study","paperUrl":"https://arxiv.org/abs/2608.01507","bibliography":{"title":"Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study","authors":["Amirkia Rafiei Oskooei","Bora Ilci","Alperen Kayim","Mehmet Egemen Uzun","Berat Can","Kaan Emre Kara","Ozan Orhan","Mehmet S. Aktas"],"url":"https://arxiv.org/abs/2608.01507","pdfUrl":"https://arxiv.org/pdf/2608.01507v1","codeUrl":null,"preprint":{"id":"2608.01507","submittedOn":"2026-08-02","url":"https://arxiv.org/abs/2608.01507"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationdeepagenticsearch2026,\n  title = {{Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study}},\n  author = {Amirkia Rafiei Oskooei and Bora Ilci and Alperen Kayim and Mehmet Egemen Uzun and Berat Can and Kaan Emre Kara and Ozan Orhan and Mehmet S. Aktas},\n  year = {2026},\n  eprint = {2608.01507},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2608.01507}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/deep-agentic-search.1f8bfd9bac55.bib"},"thumbnail":{"src":"/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png","width":944,"height":427},"locale":"zh-hant","path":"/content/papers/zh-hant/retrieval-augmented-generation/deep-agentic-search.5fed6eafb865.md","headings":[{"id":"定義問題","text":"定義問題","depth":2},{"id":"解決問題","text":"解決問題","depth":2},{"id":"兩種架構","text":"兩種架構","depth":3},{"id":"實作細節","text":"實作細節","depth":3},{"id":"模型資料與評分","text":"模型、資料與評分","depth":3},{"id":"討論","text":"討論","depth":2},{"id":"準確度每個模型都是-semantic-贏","text":"準確度：每個模型都是 Semantic 贏","depth":3},{"id":"成本多花的錢沒有換到準確度","text":"成本：多花的錢沒有換到準確度","depth":3},{"id":"deep-的工作多半發生在主-agent-看不到的地方","text":"Deep 的工作，多半發生在主 agent 看不到的地方","depth":3},{"id":"失敗分析交接的地方最容易出事","text":"失敗分析：交接的地方最容易出事","depth":3},{"id":"作者自己劃的界線","text":"作者自己劃的界線","depth":3},{"id":"結論","text":"結論","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"現在的 coding agent，在回答「這個功能寫在哪裡」之前，常常會先派出一個小幫手。\n\n主 agent 不自己翻檔案，而是交代一個**子代理**（subagent）去探索：列目錄、grep、讀檔，一路找下去。子代理在自己獨立的上下文裡工作，最後只把整理好的結論交回來。主 agent 的上下文保持乾淨，只看到精簡的結果。\n\n這種設計被稱為 **Deep Agentic Search**，也有人叫它「由子代理執行的 grep 搜尋」。論文提到，Claude Code、Codex、Antigravity 這些 coding agent 都很快採用了它。\n\n但它真的比較準嗎？\n\n這篇來自土耳其伊斯坦堡的 Yildiz 技術大學與 Intellica 商業智慧公司的實證研究，2026 年 8 月發表於 arXiv。作者拿它和比較傳統的做法，也就是事先建好向量索引、讓 agent 直接檢索，放在同一組程式碼問答上比較。\n\n結果很出乎意料：傳統做法答對 65.2%，Deep Agentic Search 只有 46.2%，而且每答對一題的成本是兩倍多。\n\n\n> [!TIP]\n> \n> **為什麼要把搜尋交給子代理？**\n> \n> 這個設計想解決的是**上下文汙染**（context pollution），也常被叫做 context rot：agent 一路搜尋、讀檔，上下文裡塞滿了不相關的程式碼和搜尋結果，模型的判斷就會越來越不準。\n> \n> 把雜亂的探索丟給子代理，主 agent 只收精簡的結論，被認為是好的**上下文工程**（context engineering）實務。這篇論文要檢驗的，就是這個做法在答題準確度上的實際效果。\n\n\n## 定義問題\n\n作者的研究問題有三個：\n\n1. **準確度**：在整個程式碼庫範圍的問答上，哪一種做法答得比較好？\n2. **成本**：各自要花多少？多花的錢有沒有換到準確度？\n3. **行為與失敗**：兩種做法怎麼運作？失敗的時候，是怎麼失敗的？\n\n## 解決問題\n\n### 兩種架構\n\n[![兩種搜尋範式：上方的 ReAct agent 從事先建好的向量索引取回程式碼片段；下方的 Deep Agent 不建索引，把探索交給子代理在獨立上下文中進行](/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png)](/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png)\n\n*原論文 Fig. 1，取自 [**v1 PDF 第 2 頁**](https://arxiv.org/pdf/2608.01507v1#page=2)。(a) 以 ReAct agent 實作的 Semantic search；(b) 以 Deep Agent 實作的 Deep Agentic search。*\n\n**上半部 (a)：Semantic search**。程式碼庫事先切塊、轉成向量，存進向量資料庫。問題進來時，ReAct agent 把問題轉成查詢向量，從資料庫取回相關的程式碼片段，再自己整理成答案。\n\n**下半部 (b)：Deep Agentic search**。沒有任何索引。Deep Agent 收到問題後，派出 Explorer Subagent 去程式碼庫裡探索。圖中的子代理在一個資料夾裡喊「Not here」，換到另一個資料夾才說「Found it!」，最後把結果交回主 agent，由主 agent 回答。\n\n注意圖上兩邊的虛線箭頭都寫著「Waiting」：主 agent 在等的時候，看不到子代理實際做了什麼。\n\n### 實作細節\n\n兩種架構都用 LangChain 實作。\n\n**Semantic search** 使用 LangChain 的 ReAct agent，只給它 SWE-QA 原始評測協定的三個工具：查看程式庫結構、向量檢索、讀檔。沒有 shell，不能寫檔，也沒有規劃工具。\n\n向量索引的設定寫在附錄：\n\n- 用針對程式碼的 `RecursiveCharacterTextSplitter` 切塊，每塊 500 token，重疊 50 token。\n- embedding 用 OpenAI 的 `text-embedding-3-small`（1,536 維）。\n- 存進 Chroma 向量資料庫，每個程式庫各一個，用 cosine 相似度，每次檢索取前 10 塊。\n\n**Deep Agentic search** 使用 LangChain 的 Deep Agents 框架，保留它的預設工具：寫待辦清單（`write_todos`）、派子代理（`task`）、`grep`、`ls`、`glob`、讀檔。主 agent 和子代理使用同一個模型。\n\n\n> [!NOTE]\n> \n> **兩邊的工具不一樣，這樣比公平嗎？**\n> \n> 作者正面回答了這個問題：工具的差異本身就是兩種範式的定義。給 ReAct agent 加上規劃和子代理，它就變成 Deep Agent；把 Deep Agent 的這些工具拿掉、換成向量索引，它就變回 ReAct agent。\n> \n> 所以作者比較的是兩套「完整的範式」，而不是只差一個因素的消融實驗。真正固定的是其他所有東西：同樣的 15 個程式庫、720 題、4 個模型、同一個評審與評分規準，而且每個模型都和自己比。\n\n\n這也代表，這篇論文比的不是單純的「向量檢索對 grep」。Semantic 這一邊也能讀檔、看目錄結構；Deep 這一邊的關鍵差異，在於多了規劃與委派子代理。\n\n### 模型、資料與評分\n\n**模型**有四個：Gemini 2.5 Flash、Gemini 2.5 Pro、Gemini 3 Flash，以及另一家的開放權重模型 Qwen3-235B。四個模型乘上兩種架構，共八種條件。溫度都設為 0，每題限時 900 秒、最多 80 步，超過就記為失敗，不重跑。\n\n**資料**是 SWE-QA，一個針對整個程式碼庫的問答評測。作者用了其中 15 個 Python 程式庫，每個 48 題，共 720 題。12 個程式庫來自 SWE-bench，3 個來自較新的 SWE-bench-Live；規模從約 1.3 萬行到超過 80 萬行。題目大致平均分成 What、Why、Where、How 四類。\n\n**評分**由 Claude Sonnet 4.6 擔任評審，和所有受測模型都來自不同廠商。它依 SWE-QA 的五個面向打分：正確性、完整性、相關性、清晰度、推理，合成 0 到 100 分。70 分以上算 Pass，50 到 70 算 Partial，50 以下算 Fail。\n\n作者也驗證了這個評審靠不靠得住：請三位至少有兩年經驗、不是本文作者的軟體工程師，在不知道條件的情況下評 800 個答案。三位工程師之間的一致性 Fleiss' κ 為 0.81；工程師多數決和 LLM 評審之間的 Cohen's κ 為 0.74，分數的平均絕對差 5.2 分。在 Deep 的答案上，一致性稍低（κ 0.69，Semantic 是 0.78），作者認為和 Deep 的答案較長、較複雜有關。\n\n## 討論\n\n### 準確度：每個模型都是 Semantic 贏\n\n| 模型 | Pass（S） | Pass（D） | 差距 | 每次答對（S） | 每次答對（D） |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Gemini 2.5 Flash | 48.4% | 42.8% | 5.6 | $0.213 | $0.436 |\n| Gemini 2.5 Pro | 54.2% | 44.2% | 10.0 | $1.048 | $1.526 |\n| Gemini 3 Flash | 89.3% | 39.7% | 49.6 | $0.179 | $0.858 |\n| Qwen3-235B | 68.8% | 58.2% | 10.6 | $0.012 | $0.291 |\n\n*整理自原論文 Table 3 與 Table 4。S 為 Semantic，D 為 Deep；差距單位為百分點；最後兩欄是每答對一題的成本（美元），依論文採用的單一價目表，由實測 token 數換算。*\n\n四個模型都是 Semantic 的 Pass 率較高。把四個模型的 Pass 率平均起來：\n\n$$\n\\frac{48.4+54.2+89.3+68.8}{4}\\approx65.2\\%,\\qquad\n\\frac{42.8+44.2+39.7+58.2}{4}\\approx46.2\\%\n$$\n\n這就是摘要裡的 65.2% 對 46.2%。Fail 率則是 21.9% 對 34.4%：Deep 不只是把 Pass 變成 Partial，完全答錯的也比較多。\n\n但差距的大小，在模型之間差很多。Gemini 2.5 Flash 只差 5.6 個百分點，Gemini 3 Flash 卻差到 49.6。四個模型的配對檢定在多重比較校正後都達到顯著，但效果量（Cliff's δ）在兩個 Gemini 2.5 模型上只有約 0.14，Qwen3-235B 約 0.24，只有 Gemini 3 Flash 的 0.76 算得上大。作者的描述也很節制：方向一致，Gemini 2.5 上幅度不大，只有 Gemini 3 Flash 上差距很大。\n\nPass 的門檻是 70 分，會不會剛好切在某個對 Semantic 有利的位置？作者把門檻從 50 掃到 90，Semantic 在每個模型、每個門檻都領先，最小的差距是 3.8 個百分點。\n\n### 成本：多花的錢沒有換到準確度\n\nDeep 在每個模型上都用了更多的輸入 token。差距最大的是 Qwen3-235B：Semantic 每題約 3.4 萬 token，Deep 約 76.1 萬，是 22 倍。\n\n換成「每答對一題要花多少錢」，四個模型合計是 0.32 美元對 0.74 美元，Deep 約貴 2.3 倍。\n\n作者另外看了每一題的分數和花費之間的關係：不論是輸入 token 還是工具呼叫次數，兩種架構的擬合斜率都是平的甚至向下，**花得越多，分數並沒有越高**。作者也提醒這是相關性，部分原因是難題本來就需要更多探索，也比較容易答錯。\n\n延遲則沒有一致的方向：Gemini 2.5 兩個模型上 Deep 比較快，Gemini 3 Flash 和 Qwen3-235B 上 Semantic 比較快。作者認為延遲受執行環境影響大，不拿來下結論。\n\n那程式庫越大，Deep 的額外成本會不會越高？15 個程式庫的資料裡看不到顯著關係，但作者也承認樣本太少，只能說「尚無定論」。\n\n### Deep 的工作，多半發生在主 agent 看不到的地方\n\n把子代理的動作也算進來，Deep 的工具呼叫大部分還是很普通的讀檔（41.6%）和文字搜尋（29.1%），其次是寫待辦清單、列目錄、派子代理。\n\n但「派子代理」這一個動作，會開啟一整段子代理的探索。2,878 次 Deep 執行中，有 2,395 次至少派了一次子代理，平均每次執行派 2.1 次，每次子代理再做約 10 次呼叫。合計起來，**68.8% 的工具呼叫發生在子代理裡**，主 agent 從頭到尾沒有直接看到。\n\nGemini 3 Flash 是個明顯的例子：Semantic 平均每題 8.6 次工具呼叫，Deep 是 44.6 次。\n\n### 失敗分析：交接的地方最容易出事\n\n作者把所有 Fail 的執行紀錄，從兩個互相獨立的面向分類：**失敗的機制**（為什麼失敗），以及**答案的症狀**（答案錯成什麼樣子）。分類由 Claude Sonnet 4.6 完成，再由兩位作者人工標註 400 筆來驗證：兩位作者之間的一致性在機制上 κ 為 0.78、症狀上 0.86；他們的共識和自動分類之間為 0.82。\n\n[![兩種架構的失敗機制分布：Semantic 以檢索或定位失誤為主，Deep Agentic 以協調失敗為主](/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png)](/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png)\n\n*原論文 Fig. 19，取自 [**v1 PDF 第 27 頁**](https://arxiv.org/pdf/2608.01507v1#page=27)。左側藍色為 Semantic，右側橘色為 Deep Agentic；數字為各自失敗案例中的百分比。*\n\n共 1,621 個失敗案例，Semantic 631 個，Deep 990 個。兩邊的失敗方式完全不同。\n\n**Semantic 的失敗，多半是「找不到」**。最大的一塊是左下角的檢索或定位失誤，佔 53.6%：花了平均 12.6 次工具呼叫，還是沒找到正確的檔案。另外 18.1% 是讀得太少就有把握地作答，17.1% 是讀到了正確的檔案卻理解錯。\n\n**Deep 的失敗，多半發生在「交接」**。最上面那條橘色，**協調失敗**（coordination breakdown）佔 41.8%：主 agent 和子代理之間的交接，沒能產生或整合出可用的結果。這種失敗只可能發生在有子代理的架構，所以 Semantic 那邊是 0。\n\n更麻煩的是，這些協調失敗大多是**無聲的**。在 91% 的協調失敗案例裡，agent 仍然交出一段流暢、語氣肯定的答案，看不出任何地方出了問題。\n\nDeep 還有 13.5% 是陷入迴圈、停不下來；整體上有 24.2% 的失敗根本沒有交出答案，Semantic 是 12.7%。\n\n作者的結論是：Deep Agentic Search 沒有消除失敗，而是**多加了一種新的失敗**，而且是最難從輸出察覺的那種。\n\n### 作者自己劃的界線\n\n這篇論文對自己的適用範圍說得很仔細。\n\n**第一，每題都是獨立、唯讀的單一問題**。子代理的真正價值，在於長時間、跨多個任務的工作階段中保持主 agent 的上下文乾淨。這篇的實驗每題都開新對話，這個好處沒機會表現成準確度。在長工作階段裡平衡會不會改變，作者明說這是他們的設計回答不了的問題。\n\n**第二，Semantic 的前提是能事先建索引**。檔案系統太大、變化太快、或結構太雜亂時，就只能即時探索。索引是程式庫某個時間點的快照；分支一直在改，索引就得不斷更新，否則答案會在不容易察覺的地方過時。作者提到，把 15 個程式庫全部做 embedding 的費用不到 1 美元，真正的成本在偵測變更、失效與重建這些維運工作。這篇用的是固定快照，正好是對索引最有利的情況。\n\n**第三，每種範式只用了一套 harness**。系統提示怎麼寫、子代理的結果怎麼摘要、允許幾步，都會影響結果。作者沒有比較其他 Deep Agent 框架，不宣稱差距的大小在不同實作下不變。\n\n另外，評測只有 SWE-QA 一個、只有 Python、四個模型，而且這些熱門程式庫很可能出現在模型的訓練資料裡。\n\n## 結論\n\n在這篇論文的設定下，也就是**可以建索引、內容固定的 Python 程式庫，一次問一個唯讀問題**：\n\n1. **Semantic search 比較準**。四個模型都是 Semantic 的 Pass 率較高，平均 65.2% 對 46.2%；差距從 5.6 到 49.6 個百分點不等。\n2. **Semantic search 也比較便宜**。每答對一題，平均 0.32 美元對 0.74 美元；Deep 多花的 token 沒有換到更高的分數。\n3. **Deep 的主要失敗來自交接**。41.8% 的失敗是主 agent 與子代理之間的協調失敗，而且 91% 的協調失敗仍交出流暢、肯定的錯誤答案。\n\n作者給的建議很務實：唯讀問答、程式庫可以建索引時，用有索引的檢索 agent 當預設；比較重的子代理編排，應該留給單題準確度量不到的需求，像是長工作階段的上下文整潔、無法建索引的環境，或需要寫程式、執行程式的任務。合理的下一步，是建一個路由器：平常用便宜的語意索引，真正需要時才派子代理出去。\n\n把事情交代下去，主 agent 的上下文確實乾淨了。只是交回來的那句話對不對，主 agent 也看不出來。\n","imageSizes":{"/content/papers/assets/44afeaa4b2a8e82e998b7d93f70c43ca555a0c6588ac386081af2aedc5612536.png":{"width":1258,"height":1083},"/content/papers/assets/61ecd2fcf8409a060dc66b99123841b7e1bceff328c5f1ee011397bb73773c74.png":{"width":944,"height":427}}}