把检索从主模型手里拆出来：Search Agent 让超大型仓库省下三成 Token

核心洞察

这篇文章最有意思的点，是它把“检索”这件事从主模型手里拆出来了。我们平时用 AI 写代码，总觉得模型不够聪明，其实有时候是它把太多精力花在了“找东西”上，真正用来“想问题”的注意力反而被挤掉了。文中的 A/B 数据也印证了这一点：仓库越大，省下的 Token 越多，超大型仓库能省三成，这个数字挺实在的。

核心结论

1. 将检索职责从主模型拆分为独立的 Search Agent独立于主模型的检索子智能体，只负责检索不参与推理生成，拥有独立上下文和多种检索工具，输出摘要加文件路径与行号索引。，可实现职责解耦：主模型专注意图理解与代码生成，Search Agent 在独立上下文中规划策略、并行搜索、迭代收敛并返回精炼结果。

2. 线上 A/B 实验显示，Search Agent 方案的主模型 Token 消耗主模型在推理过程中消耗的Token数量，是衡量检索方案效率的关键指标。引入Search Agent后主模型Token消耗显著降低。降低幅度随代码仓库规模扩大而递增：小型仓库（0-1k 文件）降低 1.61%，中大型仓库（1k-100k 文件）降低 12.57%，超大型仓库（100k+ 文件）降低 30.46%。

3. 在 Agent Bench线下测评集，包含45个真实任务，覆盖多语言，用于评估Search Agent的效果。 线下测评集（45 个真实任务、多语言）中，极致模型分数提升 2.3%、主模型 Token 消耗降低 10.4%；性能模型分数提升 0.5%、主模型 Token 消耗降低 11%。

4. Search Agent 配备语义搜索、图谱搜索、正则匹配、文件检索、目录浏览、文件读取、Wiki 搜索七类互补工具，覆盖从“发现”到“定位”再到“验证”的完整检索闭环。

5. 效果演示案例表明，同等基座模型下引入 Search Agent 后，主模型异步分发任务并直接使用精炼检索结果做代码生成，推理轮次大幅压缩，主模型 Token 消耗降低 30.2%。

为什么需要 Agentic Search智能代理搜索，一种具备自主规划与多步骤执行能力的搜索模式，能够将信息查找与实际操作结合，实现复杂任务的自动化处理。

传统检索范式的困境

现在做 AI Coding Agent，代码检索基本都是以工具调用的形式塞进主 Agent 的推理循环里。主模型根据用户意图生成检索请求，调一下搜索工具，拿到代码片段，拼进上下文接着推理。这套“主模型直接检索”的做法看着挺自然，但任务一复杂，短板就藏不住了。

• 检索策略太单一：主模型单次调用往往只覆盖一种检索模态，要么向量搜索，要么符号跳转。碰上“找到鉴权模块的所有中间件实现及其调用链路”这种复合需求，它只能在多个推理轮次里反复调不同工具，推理效率掉得厉害。

• 上下文窗口被浪费：每次检索返回的原始结果直接灌进主模型上下文，里面一大半是低相关性的代码片段。主模型得在“理解用户意图”和“筛选检索噪声”之间分注意力，又做推理又做过滤，两头都做不好。

• 启发式检索收敛太慢：单次检索很难命中散在多个文件、多个层次里的关键信息。主模型只能靠反复的“检索—分析—再检索”循环，一点点拼出完整的信息拼图，每一轮都在烧 Token 和用户等待时间。

• 角色错配：主模型的核心能力是逻辑推理和代码生成，不是检索策略的规划优化。让一个通用推理模型去决定“先搜什么、再搜什么、怎么组合多路结果”，等于拿高成本的推理能力干低层次的信息调度。

Agentic Search 的核心思想

把检索从“单次工具调用”升级成专属子智能体的自主探索。引入独立的 Search Agent：主模型只给目标和约束，Search Agent 在独立上下文里规划策略、并行搜索、迭代收敛、过滤精炼，最后返回高密度结果。这么做的价值在三点：

• 职责解耦：高阶逻辑推理和低阶信息检索分开，主模型聚焦意图理解和代码生成，Search Agent 垂直深耕检索的广度和深度。

• Token 更省：先用更小、更便宜的模型做筛选，精炼完再喂给主模型。

• 能力更强：可以并行、多轮迭代、组合策略，覆盖得更深更广。

技术方案设计

整体架构（三层）

• 意图层（What）：主模型给检索目标、范围、产物形式，不指定步骤和工具。

• 策略层（How）：转成可执行计划，包括工具组合、并行还是串行、由粗到细，同时控制迭代和压缩。

• 执行层（Do）：调用语义、正则、图谱、文件、目录、读取、Wiki 等工具，输出摘要加文件路径与行号索引。

多路混合检索Search Agent 组合使用语义搜索、图谱搜索、正则匹配、文件检索、目录浏览、文件读取和Wiki搜索等多种工具，覆盖不同检索维度。

Search Agent 只负责检索，不参与推理和生成，所以它的上下文更“干净”，目标也更单一：围绕“找到信息”展开。这样一来，我们可以在 prompt 里加入更强的检索指令和高质量的工具调用轨迹，让每一步搜索更可控、可复用、可评估。

Search Agent 配了一套覆盖不同检索维度的工具：

• 语义搜索：理解自然语言意图，做模糊匹配和概念检索。适合概念性搜索、初始探索、同义表达或命名不一致的场景。

• 图谱搜索：沿调用链、继承关系、引用关系做图遍历。适合追踪函数调用链、定位影响面、理解类继承和依赖结构。

• 正则匹配：按精确模式在全代码库搜索。适合错误信息定位、特定配置项或常量或关键字的精准落点。

• 文件检索：按文件名或路径模式查找。适合快速定位入口文件、配置文件、模块边界。

• 目录浏览：查看项目结构和目录层级。适合理解工程布局、识别模块划分和代码组织方式。

• 文件读取：读取已定位文件的具体内容。适合精读实现细节、确认参数或边界条件或真实调用方式。

• Wiki 搜索：检索项目文档、开发规范、架构说明。适合补齐背景知识、对齐术语、理解约定和整体架构。

这些工具互补，构成了 Search Agent 的检索基础：语义搜索负责捕捉“意图相关”，正则匹配负责锁定“精确出现”，图谱搜索负责追踪“结构关联”，再结合目录和文件级工具完成从“发现”到“定位”再到“验证”的闭环。子 Agent 不承载推理任务，prompt 就能更聚焦地约束搜索顺序、结果格式和证据产出，检索质量和可追溯性都能明显提升。

效果数据

效果演示

下面这个示例 case 说明，同等基座模型下，引入 Search Agent 实现了检索职责的解耦。主模型异步分发任务，直接拿精炼后的检索结果做代码生成。推理轮次被大幅压缩，主模型 Token 消耗降低 30.2%。

线下评测

• 线下测评集：Agent Bench（45 个真实任务，多语言）：
  • 极致模型：分数提升 2.3%，主模型 Token 消耗降低 10.4%
  • 性能模型：分数提升 0.5%，主模型 Token 消耗降低 11%

以性能模型作为 Baseline，效果提升如下。

线上 AB 实验

针对需要深度工程上下文感知的复杂任务，我们上线了 Search Agent 并做了 A/B 对照实验。数据表明，这套方案在降低主模型 Token 推理开销上表现不错，而且优化幅度随代码仓库规模扩大明显递增：

• 测评数据：
  • 小型仓库（0-1k 文件）：Token 消耗降低 1.61%
  • 中大型仓库（1k-100k 文件）：Token 消耗降低 12.57%
  • 超大型仓库（100k+ 文件）：Token 消耗降低 30.46%

结语

检索质量决定了 AI 智能体的认知上限。从“主模型亲自检索”到“Search Agent 代理探索”，实现了从被动单次检索到主动多轮探索的跃迁：完成质量提升的同时成本还降了。根本原因是检索和推理是两种不同的任务，应该由不同的智能体来承担。后面我们会继续强化自适应策略、自评估和多级协作，让 Agentic Search 从“能用”走向“好用”。

常见问题（FAQ）

Agentic Search 和传统 AI 编程助手的检索方式有什么区别？

传统方式由主模型直接调用检索工具，策略单一且上下文易被噪声占用。Agentic Search 将检索职责解耦给独立 Search Agent，在独立上下文中规划策略、并行搜索、迭代收敛，主模型只负责推理和生成。

Agentic Search 能省多少 Token？效果数据如何？

线上 A/B 实验显示，小型仓库 Token 消耗降低 1.61%，中大型仓库降低 12.57%，超大型仓库降低 30.46%。线下 Agent Bench 评测中，极致模型分数提升 2.3%，主模型 Token 消耗降低 10.4%。

Search Agent 用了哪些检索工具？怎么配合？

Search Agent 配备语义搜索、图谱搜索、正则匹配、文件检索、目录浏览、文件读取和 Wiki 搜索七类工具。语义搜索捕捉意图相关，正则锁定精确出现，图谱追踪结构关联，再结合目录和文件工具完成从发现到验证的闭环。