Deep Agentic Search未能超越向量检索：SWE-QA代码问答准确率65.2%对46.2%
Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study
在 AI 驱动的软件工程领域，代码智能体（Code Agent）的上下文工程（Context Engineering）正经历一场剧烈的范式转移。为了解决海量仓库代码撑爆模型上下文、引发所谓“上下文腐化”（Context Rot 或 Context Pollution）的问题，近期的主流工具（如 Claude Code、Gemini CLI、Codex 等）纷纷转向一种被称为 Deep Agentic Search（子智能体深层检索，或称为 Subagent Grep-Search）的新架构。其核心理念是：主规划智能体不直接执行检索，而是把脏活累活派发给工作在独立沙箱上下文中的“探索子智能体”，由其在终端里 grep 搜索后仅返回高度凝练的摘要，从而为主上下文“保鲜”。
ArXiv URL：https://arxiv.org/abs/2608.01507
这一看似极具工程直觉的优雅设计，在实际的代码库问答中真能带来更好的表现吗？来自土耳其伊斯坦布尔耶尔德兹技术大学（Yildiz Technical University）与 Intellica 商业智能的研究团队针对这一假设进行了严格的实证检验。他们在权威基准 SWE-QA 上系统比对了基于向量索引的经典 Semantic Search（语义检索 ReAct 架构） 与当前流行的 Deep Agentic Search（深层子智能体架构）。
实验得出了一个反直觉却极其扎实的结论：在 15 个主流 Python 开源仓库、跨 4 种主流大模型的 720 道真实问题评测中，传统的向量语义检索以 65.2% 的整体准确率大幅领先深层智能体检索的 46.2%；更关键的是，语义检索每次获得正确答案的综合成本不到深层智能体检索的一半。深入的错误根因归因显示，Deep Agentic Search 不仅没有消除失败，反而引入了全新的脆弱环节——高达 41.8% 的错误发生在主智能体与子智能体交接任务的缝隙中。
两种范式的本质分歧：上下文防腐的代价
在面对包含数十万甚至数百万行代码的复杂代码库时，代码问答任务的核心挑战在于“大海捞针”。大模型在处理非相关长上下文时，注意力和推理能力会出现明显的衰减（即 Context Rot）。为了对抗这种噪声干扰，业界分化为截然相反的两种路线。
第一种路线是依托向量索引的 ReAct 智能体（图 2 所示）。系统预先对仓库代码进行分块（Chunking）并向量化入库，智能体通过向量相似度匹配获取精简的片段，再辅以少量的目录树查询和文件读取工具。这种方式的特点是一次性索引、按需召回、单智能体循环，典型的代表如 Cursor 内部的检索实现。
第二种路线即 Deep Agentic Search（图 3 所示的动作空间设计）。它摒弃了预建向量索引，允许智能体直接以类似终端命令行的方式动态探索仓库。为了防止冗长嘈杂的 grep 输出把主智能体搞糊涂，系统引入分层机制：由 Orchestrator（规划主智能体）下发任务，由独立的 Sub-agent（探索子智能体）在完全隔离的上下文窗口中漫游、过滤，最后只向主智能体递交一份压缩后的汇报。
直觉上，Deep Agentic Search 既保全了代码的自然文件结构，又在物理层面隔绝了上下文污染，理应在复杂的跨文件推理中更胜一筹。然而，实证数据却给出了相反的答案。
准确率与成本全面倒挂：快、贵且更容易出错
研究团队选取了涵盖 Gemini 2.5 Flash、Gemini 2.5 Pro、Gemini 3 Flash 以及开源大模型 Qwen3-235B 的四种模型矩阵，在涵盖 1.3 万行至 80 余万行 Python 代码的 15 个 SWE-bench 真实项目中开展测试，使用与答题模型完全独立的 Claude Sonnet 4.6 依据标准规则打分。
测试结果呈现出系统性的差距：在全部 720 道代码问答中，基于向量检索的 ReAct 架构斩获了 65.2% 的及格率，而看似先进的 Deep Agentic Search 仅获得 46.2%。这一差距不仅跨越了不同的问题类型（涉及 What、Why、Where、How 四大类），在不同参数量、不同代际的推理模型上表现出高度的一致性。
更严峻的问题体现在系统成本与效率上。Deep Agentic Search 由于涉及双层智能体之间的多轮交互和终端工具链的漫游调用，带来了巨大的 Token 消耗。实验测算显示，语义检索每次成功回答一个问题的端到端平均成本不足 Deep Agentic Search 的一半；在响应延迟上，后者往往需要等待子智能体完成多次探索后汇总，交互延迟同样显著高于快速向量检索加局部精读的模式。
为什么会失败？交接缝隙中的“静默崩溃”
为了弄清为什么理论上更优雅的架构反而溃败，研究团队对所有失败样本的操作轨迹（Execution Traces）进行了系统性的归因编码，构建了一套完整的失败模式分类法。分析揭示了深层智能体架构致命的技术内耗：
第一，交接失效（Handoff Failure）构成了头号杀手，占比高达 41.8%。这是 Deep Agentic Search 独有的结构性风险。由于主智能体与子智能体运行在彼此隔离的上下文窗口中，二者唯一的连接纽带是 Prompt 派发与结果回传。在实际运转中，主智能体往往无法精确描述到底需要定位哪一类逻辑边界，而子智能体在孤立视界内搜索时容易误解意图，最终在回传给主智能体时进行了“过度总结”或“错误浓缩”。最危险的是，这种交接失败几乎都是静默的（Silent Failures）——主智能体基于子智能体残缺或歪曲的信息，以极其流畅、自信的口吻生成了一个完全错误的最终解答。
第二，信息有损压缩胜过了上下文污染的危害。Deep Agent 为了保护主上下文不被污染，强制要求子智能体提供凝练结果。但代码逻辑往往依赖细微的实现细节（如特定的异常分支、隐式的装饰器传参），这些关键线索在子智能体的二次转述中被无意抹去。反观 ReAct 语义检索，虽然偶尔检索到相似但不完全相关的代码块，但呈现在主模型面前的是真实的代码原文，模型强大的自注意力机制完全有能力直接甄别出准确的语法上下文。
第三，盲目漫游陷入死胡同。在缺少先验结构索引的情况下，子智能体在数十万行代码的大型代码库中依赖 grep 检索容易迷失方向，要么产生组合爆炸式的检索尝试，要么过早认定某些文件不存在，导致下游规划全盘踏空。
对工程落地的核心启示
这项评测并非否定智能体架构探索的价值，而是打破了当前代码智能体工程中盲目迷信“分层子智能体 + 上下文隔离”的教条主义。结合研究结论，给面向代码库的落地实践带来了极具参考价值的启发：
在静态或半静态的只读代码库场景下，预构建的高质量向量检索依然是性价比最高、最稳固的基石。它不仅在召回效率和 Token 成本上具有压倒性优势，更重要的是它避免了智能体多层转述带来的认知衰减。
此外，“上下文工程”并不等同于“上下文隔离”。为了防范上下文污染而引入子智能体，本质上是用高风险的“跨智能体通信信道”换取了局部的上下文洁净度。如果子智能体与主智能体之间缺乏精细的双向校验与原文透传机制，这种架构隔离带来的新失败模式，其危害性将远超上下文污染本身。对于构建终端开发助手或内部代码问答工具的团队而言，审慎评估是否真正需要 Deep Agentic 探索，或优先选择基于向量的紧凑检索方案，显然是当前更具性价比的工程抉择。