{"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-hans","path":"/content/papers/zh-hans/retrieval-augmented-generation/deep-agentic-search.60f6ccb8d2b9.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}}}