1. 代码库问答为什么总答偏从一次跨文件定位失败说起你在一个三十万行的 Java 单体仓库里问模型「订单超时关单的定时任务在哪触发」RAG 方案返回了三段看起来相关的代码一段是订单状态枚举、一段是支付回调、还有一段是两年前的旧定时任务。真正的那段逻辑藏在OrderTimeoutScheduler里而它调用的closeOrder()又被 AOP 切面包装过向量检索压根没把这条调用链捞出来。这不是模型笨是检索机制的问题。RAG 的典型链路是「离线切块 → 向量化 → 存索引 → 查询时按语义相似度召回 Top-K → 拼进上下文」。它假设知识是静态的、块与块之间相互独立。但代码库恰好相反文件天天改、依赖跨文件、语义相似不等于调用相关。一个closeOrder方法名和「关单」这两个字在向量空间里可能离得很远但它们在调用图上只隔一条边。Agentic Search 换了个思路不预先建索引让模型自己决定搜什么。它拿到问题后先 Glob 找文件路径、再 Grep 搜关键字符串、然后 Read 打开具体文件、发现线索后继续下一轮搜索。整个过程是「推理 → 行动 → 观察 → 再推理」的循环检索策略由模型动态生成而不是固定模板。这篇要交付的东西很具体一套可复制的检索链路配置骨架让你在同一个代码库上把 RAG 和 Agentic Search 都跑起来用同一批问题对比召回精度、上下文组织和工具调用开销。适合正在做代码问答、IDE 插件、Coding Agent 的开发者也适合想搞清楚「RAG 到底还值不值得用」的技术选型同学。2. 前置准备用 TaoToken 统一两种方案的模型调用入口不管走 RAG 还是 Agentic Search你都需要一个稳定的模型调用层。我习惯把模型访问统一收口到 TaoToken原因是它同时提供 OpenAI 兼容接口和 Anthropic 兼容接口RAG 链路里做 embedding、Agentic 链路里做工具调用都能用同一套 Key 管理省得在两个平台之间来回切。先拿到访问凭证。打开控制台创建 API Key# 控制台地址创建和管理 Key https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完 Key 之后把接入文档过一遍重点看 chat/completions 和 messages 两个端点的差异因为后面 RAG 用前者、Agentic 用后者会更顺手# 接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocAPI 基地址统一用这个注意它不带任何查询参数https://taotoken.net/api环境变量建议这样设后面所有脚本都读它export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你打算长期跑 Agentic Search 这种多轮工具调用Token 消耗会比单次 RAG 高不少可以顺手看下 Coding Plan 的额度策略避免跑到一半被限流# Coding Plan长期编码/Agent 场景 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan注意Agentic Search 的单次问答可能触发 5 到 15 轮工具调用每轮都要把历史上下文重新发一遍Token 成本是 RAG 的 3 到 8 倍。先用小仓库压测再决定要不要上生产。3. 可复制配置RAG 检索链路骨架RAG 链路的核心是把代码切成块、向量化、存起来、查询时召回。下面这套骨架用 Python 写向量库用本地 Chromaembedding 走 TaoToken 的兼容接口。先装依赖pip install openai chromadb tree-sitter tree-sitter-languages切块策略是 RAG 效果的分水岭。按固定行数切会把函数切碎按 AST 切能保证每个块是一个完整函数或类。这里用 tree-sitter 做语法感知切块import os from tree_sitter_languages import get_parser def chunk_by_ast(file_path, max_lines80): 按函数/类边界切块超长块再按行数二次切分 lang python if file_path.endswith(.py) else java parser get_parser(lang) with open(file_path, rb) as f: source f.read() tree parser.parse(source) chunks [] # 遍历顶层节点抓函数和类定义 for node in tree.root_node.children: if node.type in (function_definition, class_definition, method_declaration, class_declaration): text source[node.start_byte:node.end_byte].decode(utf-8, ignore) lines text.splitlines() if len(lines) max_lines: chunks.append({path: file_path, text: text, start: node.start_point[0]}) else: for i in range(0, len(lines), max_lines): chunks.append({path: file_path, text: \n.join(lines[i:imax_lines]), start: node.start_point[0] i}) return chunks向量化和入库embedding 走 TaoTokenfrom openai import OpenAI import chromadb client OpenAI(api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL]) chroma chromadb.PersistentClient(path./code_index) collection chroma.get_or_create_collection(repo) def embed(texts): resp client.embeddings.create(modeltext-embedding-3-small, inputtexts) return [d.embedding for d in resp.data] def index_repo(root): all_chunks [] for dirpath, _, files in os.walk(root): for fn in files: if fn.endswith((.py, .java)): all_chunks.extend(chunk_by_ast(os.path.join(dirpath, fn))) # 分批 embedding避免单次请求过大 for i in range(0, len(all_chunks), 64): batch all_chunks[i:i64] vecs embed([c[text] for c in batch]) collection.add( ids[f{c[path]}:{c[start]} for c in batch], embeddingsvecs, documents[c[text] for c in batch], metadatas[{path: c[path]} for c in batch], ) print(findexed {len(all_chunks)} chunks)查询时召回 Top-K 并拼上下文def rag_query(question, top_k6): qvec embed([question])[0] res collection.query(query_embeddings[qvec], n_resultstop_k) context \n\n.join( f// {m[path]}\n{d} for m, d in zip(res[metadatas][0], res[documents][0])) prompt f根据以下代码片段回答问题\n{context}\n\n问题{question} ans client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}]) return ans.choices[0].message.content这套骨架跑通后你会得到一个「一次检索、一次生成」的固定链路。它的优点是快、便宜、可控缺点是索引一旦过期就答偏跨文件调用链基本捞不全。4. 可复制配置Agentic Search 检索链路骨架Agentic Search 不建索引把 Glob、Grep、Read 三个工具暴露给模型让它自己决定搜什么。核心是一个工具调用循环。先定义工具用 Python 实现三个最基础的文件操作import subprocess, json, os def tool_glob(pattern, root.): 按通配符找文件路径 out subprocess.run([find, root, -name, pattern], capture_outputTrue, textTrue) return out.stdout.strip() or no match def tool_grep(pattern, root.): 全文搜索字符串或正则返回 文件:行号:内容 out subprocess.run( [grep, -rn, --include*.py, --include*.java, pattern, root], capture_outputTrue, textTrue) lines out.stdout.strip().splitlines()[:50] return \n.join(lines) or no match def tool_read(path, start1, end120): 读取文件指定行范围 with open(path) as f: lines f.readlines() return .join(lines[start-1:end])把工具描述成 OpenAI function calling 格式然后跑循环TOOLS [ {type: function, function: { name: glob, description: 按文件名通配符查找路径, parameters: {type: object, properties: { pattern: {type: string}}, required: [pattern]}}}, {type: function, function: { name: grep, description: 全文搜索字符串或正则, parameters: {type: object, properties: { pattern: {type: string}}, required: [pattern]}}}, {type: function, function: { name: read, description: 读取文件行范围, parameters: {type: object, properties: { path: {type: string}, start: {type: integer}, end: {type: integer}}, required: [path]}}}, ] def agentic_query(question, max_turns12): messages [ {role: system, content: 你是代码检索助手。用 glob/grep/read 工具定位代码 每轮只调一个工具找到答案后直接回答。}, {role: user, content: question}] for turn in range(max_turns): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: return msg.content for call in msg.tool_calls: args json.loads(call.function.arguments) fn {glob: tool_glob, grep: tool_grep, read: tool_read}[call.function.name] result fn(**args) messages.append({role: tool, tool_call_id: call.id, content: result[:4000]}) return 达到最大轮数仍未收敛这套骨架的关键差异在于检索路径是模型现场生成的。问「订单超时关单在哪触发」它可能先 grepcloseOrder发现被 AOP 包装再 grep 切面类名最后 read 到真正的调度器。整个过程没有预建索引代码改了立刻生效。5. 验证请求同一批问题跑两种方案对比配置写完必须验证。准备五个真实问题覆盖单文件定位、跨文件调用链、配置项查找三类场景questions [ 订单超时关单的定时任务在哪触发, 支付回调失败后的重试逻辑在哪个类, 数据库连接池的最大连接数配置在哪, 用户登录 token 的过期时间怎么设置, 订单状态从待支付到已支付经过哪些方法, ] for q in questions: print( * 60) print(Q:, q) print(--- RAG ---) print(rag_query(q)[:300]) print(--- Agentic ---) print(agentic_query(q)[:300])实测下来RAG 在「配置项查找」这类问题上表现不错因为配置字符串和问题关键词高度重合向量召回准。但在「订单状态流转经过哪些方法」这种需要追调用链的问题上RAG 经常只召回状态枚举定义漏掉中间的 service 方法。Agentic Search 会先 grep 状态枚举名找到引用它的方法再逐个 read能把链路串起来。成功结果的判断标准有三个一是答案里给出的文件路径和行号能对上真实代码二是跨文件问题能列出完整的调用顺序三是没有编造不存在的方法名。你可以写个简单脚本把两种方案的输出和人工标注的 ground truth 对比算一下命中率。# 简易命中率统计 def hit_rate(answer, expected_files): return sum(1 for f in expected_files if f in answer) / len(expected_files) # 示例期望答案涉及这三个文件 expected [OrderTimeoutScheduler.java, OrderService.java, OrderStatus.java] print(RAG hit:, hit_rate(rag_query(questions[4]), expected)) print(Agentic hit:, hit_rate(agentic_query(questions[4]), expected))跑完你会发现一个规律问题越依赖「语义相似」RAG 越占优问题越依赖「结构关联」Agentic 越占优。这也解释了为什么 Claude Code 团队会放弃 RAG——代码编辑场景里结构关联的需求远多于语义相似。6. 本篇常见错排查6.1 RAG 召回全是注释和测试文件向量检索对注释和测试代码特别敏感因为它们往往包含大量自然语言。解决办法是在 metadata 里加文件类型标记查询时过滤collection.add(..., metadatas[{path: c[path], is_test: test in c[path].lower()}]) # 查询时排除测试文件 res collection.query(query_embeddings[qvec], n_resultstop_k, where{is_test: False})6.2 Agentic Search 陷入死循环模型可能反复 grep 同一个词。两个办法一是设 max_turns 硬上限二是每轮把已搜过的 pattern 记下来在 system prompt 里提示「不要重复搜索相同关键词」。更稳的做法是在工具层做去重seen set() def tool_grep_dedup(pattern, root.): if pattern in seen: return 已搜索过该关键词请换一个 seen.add(pattern) return tool_grep(pattern, root)6.3 工具返回内容过长撑爆上下文grep 一个常见词可能返回几百行。必须在工具层截断并且优先返回行号靠前的结果。上面tool_grep里的[:50]和tool_read里的[:4000]就是干这个的。如果还是超可以把 read 的默认范围从 120 行降到 60 行。6.4 两种方案都答不对跨模块调用跨模块调用需要「先找接口定义、再找实现类」两步。RAG 单次召回做不到Agentic 需要模型自己想到这一步。可以在 system prompt 里加一句引导「如果找到接口继续搜索它的实现类」。这属于提示工程层面的优化不改检索机制也能提升不少。6.5 索引更新导致 RAG 结果漂移代码库一天推几次索引不更新就会答旧代码。最省事的做法是挂个 git hookpush 后触发增量索引# .git/hooks/post-commit #!/bin/bash python -c from indexer import index_repo; index_repo(.)但增量索引本身也有成本仓库大了每次全量重建要几分钟。这也是 Agentic Search 在动态场景下更省心的原因——它压根不需要索引这一步。7. 选型建议与下一步把两种方案跑通之后选型其实不复杂。知识基本固化、查询以语义匹配为主、对延迟敏感的场景RAG 更合适成本低、响应快、可控性强。代码库这种高频变更、需要追调用链、问题结构复杂的场景Agentic Search 的召回精度和实时性明显更好代价是 Token 和时间开销。两者也不是非此即彼。复杂 Agent 可以把 RAG 当成一个「外部记忆工具」需要查历史文档或固化知识时调用它需要探索当前代码时走 Agentic 搜索。记忆层和推理层分开各干各擅长的事。想先验证模型在工具调用上的表现可以直接在模型对话里试几轮 Glob/Grep 风格的提问# 模型对话验证工具调用与推理表现 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat准备把 Agentic Search 接进日常编码流程的话先把 API Key 和额度配好再按第 4 节的骨架搭最小闭环# API Keys 管理 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys如果你用的是 Claude Code 这类已经内置 Agentic Search 的工具重点反而不在检索本身而在怎么把仓库结构、忽略规则、工具权限配好让它搜得更准。这部分可以对照接入文档里的工具配置章节逐项调# 接入文档工具配置与端点说明 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后给个实操建议别一上来就全仓库上 Agentic。先挑一个模块用第 5 节的五个问题跑对比记录命中率和 Token 消耗。数据出来了选型自然就清楚了。
1. 代码库问答为什么总答偏从一次跨文件定位失败说起你在一个三十万行的 Java 单体仓库里问模型「订单超时关单的定时任务在哪触发」RAG 方案返回了三段看起来相关的代码一段是订单状态枚举、一段是支付回调、还有一段是两年前的旧定时任务。真正的那段逻辑藏在OrderTimeoutScheduler里而它调用的closeOrder()又被 AOP 切面包装过向量检索压根没把这条调用链捞出来。这不是模型笨是检索机制的问题。RAG 的典型链路是「离线切块 → 向量化 → 存索引 → 查询时按语义相似度召回 Top-K → 拼进上下文」。它假设知识是静态的、块与块之间相互独立。但代码库恰好相反文件天天改、依赖跨文件、语义相似不等于调用相关。一个closeOrder方法名和「关单」这两个字在向量空间里可能离得很远但它们在调用图上只隔一条边。Agentic Search 换了个思路不预先建索引让模型自己决定搜什么。它拿到问题后先 Glob 找文件路径、再 Grep 搜关键字符串、然后 Read 打开具体文件、发现线索后继续下一轮搜索。整个过程是「推理 → 行动 → 观察 → 再推理」的循环检索策略由模型动态生成而不是固定模板。这篇要交付的东西很具体一套可复制的检索链路配置骨架让你在同一个代码库上把 RAG 和 Agentic Search 都跑起来用同一批问题对比召回精度、上下文组织和工具调用开销。适合正在做代码问答、IDE 插件、Coding Agent 的开发者也适合想搞清楚「RAG 到底还值不值得用」的技术选型同学。2. 前置准备用 TaoToken 统一两种方案的模型调用入口不管走 RAG 还是 Agentic Search你都需要一个稳定的模型调用层。我习惯把模型访问统一收口到 TaoToken原因是它同时提供 OpenAI 兼容接口和 Anthropic 兼容接口RAG 链路里做 embedding、Agentic 链路里做工具调用都能用同一套 Key 管理省得在两个平台之间来回切。先拿到访问凭证。打开控制台创建 API Key# 控制台地址创建和管理 Key https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsole创建完 Key 之后把接入文档过一遍重点看 chat/completions 和 messages 两个端点的差异因为后面 RAG 用前者、Agentic 用后者会更顺手# 接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdocAPI 基地址统一用这个注意它不带任何查询参数https://taotoken.net/api环境变量建议这样设后面所有脚本都读它export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你打算长期跑 Agentic Search 这种多轮工具调用Token 消耗会比单次 RAG 高不少可以顺手看下 Coding Plan 的额度策略避免跑到一半被限流# Coding Plan长期编码/Agent 场景 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan注意Agentic Search 的单次问答可能触发 5 到 15 轮工具调用每轮都要把历史上下文重新发一遍Token 成本是 RAG 的 3 到 8 倍。先用小仓库压测再决定要不要上生产。3. 可复制配置RAG 检索链路骨架RAG 链路的核心是把代码切成块、向量化、存起来、查询时召回。下面这套骨架用 Python 写向量库用本地 Chromaembedding 走 TaoToken 的兼容接口。先装依赖pip install openai chromadb tree-sitter tree-sitter-languages切块策略是 RAG 效果的分水岭。按固定行数切会把函数切碎按 AST 切能保证每个块是一个完整函数或类。这里用 tree-sitter 做语法感知切块import os from tree_sitter_languages import get_parser def chunk_by_ast(file_path, max_lines80): 按函数/类边界切块超长块再按行数二次切分 lang python if file_path.endswith(.py) else java parser get_parser(lang) with open(file_path, rb) as f: source f.read() tree parser.parse(source) chunks [] # 遍历顶层节点抓函数和类定义 for node in tree.root_node.children: if node.type in (function_definition, class_definition, method_declaration, class_declaration): text source[node.start_byte:node.end_byte].decode(utf-8, ignore) lines text.splitlines() if len(lines) max_lines: chunks.append({path: file_path, text: text, start: node.start_point[0]}) else: for i in range(0, len(lines), max_lines): chunks.append({path: file_path, text: \n.join(lines[i:imax_lines]), start: node.start_point[0] i}) return chunks向量化和入库embedding 走 TaoTokenfrom openai import OpenAI import chromadb client OpenAI(api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL]) chroma chromadb.PersistentClient(path./code_index) collection chroma.get_or_create_collection(repo) def embed(texts): resp client.embeddings.create(modeltext-embedding-3-small, inputtexts) return [d.embedding for d in resp.data] def index_repo(root): all_chunks [] for dirpath, _, files in os.walk(root): for fn in files: if fn.endswith((.py, .java)): all_chunks.extend(chunk_by_ast(os.path.join(dirpath, fn))) # 分批 embedding避免单次请求过大 for i in range(0, len(all_chunks), 64): batch all_chunks[i:i64] vecs embed([c[text] for c in batch]) collection.add( ids[f{c[path]}:{c[start]} for c in batch], embeddingsvecs, documents[c[text] for c in batch], metadatas[{path: c[path]} for c in batch], ) print(findexed {len(all_chunks)} chunks)查询时召回 Top-K 并拼上下文def rag_query(question, top_k6): qvec embed([question])[0] res collection.query(query_embeddings[qvec], n_resultstop_k) context \n\n.join( f// {m[path]}\n{d} for m, d in zip(res[metadatas][0], res[documents][0])) prompt f根据以下代码片段回答问题\n{context}\n\n问题{question} ans client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}]) return ans.choices[0].message.content这套骨架跑通后你会得到一个「一次检索、一次生成」的固定链路。它的优点是快、便宜、可控缺点是索引一旦过期就答偏跨文件调用链基本捞不全。4. 可复制配置Agentic Search 检索链路骨架Agentic Search 不建索引把 Glob、Grep、Read 三个工具暴露给模型让它自己决定搜什么。核心是一个工具调用循环。先定义工具用 Python 实现三个最基础的文件操作import subprocess, json, os def tool_glob(pattern, root.): 按通配符找文件路径 out subprocess.run([find, root, -name, pattern], capture_outputTrue, textTrue) return out.stdout.strip() or no match def tool_grep(pattern, root.): 全文搜索字符串或正则返回 文件:行号:内容 out subprocess.run( [grep, -rn, --include*.py, --include*.java, pattern, root], capture_outputTrue, textTrue) lines out.stdout.strip().splitlines()[:50] return \n.join(lines) or no match def tool_read(path, start1, end120): 读取文件指定行范围 with open(path) as f: lines f.readlines() return .join(lines[start-1:end])把工具描述成 OpenAI function calling 格式然后跑循环TOOLS [ {type: function, function: { name: glob, description: 按文件名通配符查找路径, parameters: {type: object, properties: { pattern: {type: string}}, required: [pattern]}}}, {type: function, function: { name: grep, description: 全文搜索字符串或正则, parameters: {type: object, properties: { pattern: {type: string}}, required: [pattern]}}}, {type: function, function: { name: read, description: 读取文件行范围, parameters: {type: object, properties: { path: {type: string}, start: {type: integer}, end: {type: integer}}, required: [path]}}}, ] def agentic_query(question, max_turns12): messages [ {role: system, content: 你是代码检索助手。用 glob/grep/read 工具定位代码 每轮只调一个工具找到答案后直接回答。}, {role: user, content: question}] for turn in range(max_turns): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: return msg.content for call in msg.tool_calls: args json.loads(call.function.arguments) fn {glob: tool_glob, grep: tool_grep, read: tool_read}[call.function.name] result fn(**args) messages.append({role: tool, tool_call_id: call.id, content: result[:4000]}) return 达到最大轮数仍未收敛这套骨架的关键差异在于检索路径是模型现场生成的。问「订单超时关单在哪触发」它可能先 grepcloseOrder发现被 AOP 包装再 grep 切面类名最后 read 到真正的调度器。整个过程没有预建索引代码改了立刻生效。5. 验证请求同一批问题跑两种方案对比配置写完必须验证。准备五个真实问题覆盖单文件定位、跨文件调用链、配置项查找三类场景questions [ 订单超时关单的定时任务在哪触发, 支付回调失败后的重试逻辑在哪个类, 数据库连接池的最大连接数配置在哪, 用户登录 token 的过期时间怎么设置, 订单状态从待支付到已支付经过哪些方法, ] for q in questions: print( * 60) print(Q:, q) print(--- RAG ---) print(rag_query(q)[:300]) print(--- Agentic ---) print(agentic_query(q)[:300])实测下来RAG 在「配置项查找」这类问题上表现不错因为配置字符串和问题关键词高度重合向量召回准。但在「订单状态流转经过哪些方法」这种需要追调用链的问题上RAG 经常只召回状态枚举定义漏掉中间的 service 方法。Agentic Search 会先 grep 状态枚举名找到引用它的方法再逐个 read能把链路串起来。成功结果的判断标准有三个一是答案里给出的文件路径和行号能对上真实代码二是跨文件问题能列出完整的调用顺序三是没有编造不存在的方法名。你可以写个简单脚本把两种方案的输出和人工标注的 ground truth 对比算一下命中率。# 简易命中率统计 def hit_rate(answer, expected_files): return sum(1 for f in expected_files if f in answer) / len(expected_files) # 示例期望答案涉及这三个文件 expected [OrderTimeoutScheduler.java, OrderService.java, OrderStatus.java] print(RAG hit:, hit_rate(rag_query(questions[4]), expected)) print(Agentic hit:, hit_rate(agentic_query(questions[4]), expected))跑完你会发现一个规律问题越依赖「语义相似」RAG 越占优问题越依赖「结构关联」Agentic 越占优。这也解释了为什么 Claude Code 团队会放弃 RAG——代码编辑场景里结构关联的需求远多于语义相似。6. 本篇常见错排查6.1 RAG 召回全是注释和测试文件向量检索对注释和测试代码特别敏感因为它们往往包含大量自然语言。解决办法是在 metadata 里加文件类型标记查询时过滤collection.add(..., metadatas[{path: c[path], is_test: test in c[path].lower()}]) # 查询时排除测试文件 res collection.query(query_embeddings[qvec], n_resultstop_k, where{is_test: False})6.2 Agentic Search 陷入死循环模型可能反复 grep 同一个词。两个办法一是设 max_turns 硬上限二是每轮把已搜过的 pattern 记下来在 system prompt 里提示「不要重复搜索相同关键词」。更稳的做法是在工具层做去重seen set() def tool_grep_dedup(pattern, root.): if pattern in seen: return 已搜索过该关键词请换一个 seen.add(pattern) return tool_grep(pattern, root)6.3 工具返回内容过长撑爆上下文grep 一个常见词可能返回几百行。必须在工具层截断并且优先返回行号靠前的结果。上面tool_grep里的[:50]和tool_read里的[:4000]就是干这个的。如果还是超可以把 read 的默认范围从 120 行降到 60 行。6.4 两种方案都答不对跨模块调用跨模块调用需要「先找接口定义、再找实现类」两步。RAG 单次召回做不到Agentic 需要模型自己想到这一步。可以在 system prompt 里加一句引导「如果找到接口继续搜索它的实现类」。这属于提示工程层面的优化不改检索机制也能提升不少。6.5 索引更新导致 RAG 结果漂移代码库一天推几次索引不更新就会答旧代码。最省事的做法是挂个 git hookpush 后触发增量索引# .git/hooks/post-commit #!/bin/bash python -c from indexer import index_repo; index_repo(.)但增量索引本身也有成本仓库大了每次全量重建要几分钟。这也是 Agentic Search 在动态场景下更省心的原因——它压根不需要索引这一步。7. 选型建议与下一步把两种方案跑通之后选型其实不复杂。知识基本固化、查询以语义匹配为主、对延迟敏感的场景RAG 更合适成本低、响应快、可控性强。代码库这种高频变更、需要追调用链、问题结构复杂的场景Agentic Search 的召回精度和实时性明显更好代价是 Token 和时间开销。两者也不是非此即彼。复杂 Agent 可以把 RAG 当成一个「外部记忆工具」需要查历史文档或固化知识时调用它需要探索当前代码时走 Agentic 搜索。记忆层和推理层分开各干各擅长的事。想先验证模型在工具调用上的表现可以直接在模型对话里试几轮 Glob/Grep 风格的提问# 模型对话验证工具调用与推理表现 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentmodel-chat准备把 Agentic Search 接进日常编码流程的话先把 API Key 和额度配好再按第 4 节的骨架搭最小闭环# API Keys 管理 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys如果你用的是 Claude Code 这类已经内置 Agentic Search 的工具重点反而不在检索本身而在怎么把仓库结构、忽略规则、工具权限配好让它搜得更准。这部分可以对照接入文档里的工具配置章节逐项调# 接入文档工具配置与端点说明 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后给个实操建议别一上来就全仓库上 Agentic。先挑一个模块用第 5 节的五个问题跑对比记录命中率和 Token 消耗。数据出来了选型自然就清楚了。
