★ FEATURED ARTICLE 1. 从一次代码检索的翻车现场说起去年冬天我在一个中型研发团队里做内部知识库的落地。团队大概四十来人代码仓库有十几个文档散落在各种地方——有写在代码注释里的有丢在共享文档里的还有一部分只存在于某几个老员工的脑子里。当时我们的方案很标准把代码和文档切片用嵌入模型转成向量塞进向量数据库检索的时候走相似度匹配再把召回的内容拼进提示词交给大模型。这套流程就是大家常说的 RAG检索增强生成。上线头两周效果确实不错。问它某个接口的参数含义它能从代码注释里翻出来问它某个模块的设计思路它也能从文档里找到对应段落。团队里几个人开始频繁用它查东西我当时还挺得意觉得这套方案算是跑通了。但第三周开始问题一个接一个冒出来。有人问“这个函数在哪些地方被调用了”检索回来的是一堆语义相近但完全不相关的函数定义有人问“这个配置项默认值是多少”召回的是另一个同名配置项的说明更离谱的是有人问“这个报错信息是从哪里抛出来的”系统返回了一段看起来很像但其实是另一个模块的异常处理代码。用户开始不信任它了有人直接在群里说“还不如我自己 grep 一下”。我花了整整一周时间排查。一开始怀疑是切片粒度问题把 chunk 从 512 调到 256又调到 1024效果时好时坏。后来怀疑是嵌入模型不行换了一个更大的模型召回质量确实有提升但延迟从几百毫秒涨到了两三秒用户体验更差了。再后来我意识到问题根本不在检索质量上而在于这套架构本身对“精确匹配”这件事就是天生不擅长的。向量检索擅长的是语义相似但代码世界里大量的查询是精确的、结构化的、需要跨文件追踪的——这些恰恰是向量检索的盲区。就在我焦头烂额的时候看到了 Claude Code 的相关讨论。它没有走 RAG 这条路而是用了所谓的 agentic search——让模型自己决定去哪里找、怎么找、找几轮。这个思路当时让我眼前一亮因为它绕开了向量检索最不擅长的那部分把“找什么”这件事交还给了模型本身。后来我花了不少时间研究它的实现逻辑也自己动手做了一些对比实验才慢慢理解了标题里那句话的分量不是 RAG 效果输了是运维输了。这篇文章我想把这套逻辑拆开讲清楚。不管你是正在做知识库的工程师还是在选型阶段纠结要不要上向量数据库的团队负责人或者只是单纯好奇 Claude Code 为什么这么设计应该都能从中找到一些有用的东西。我会从 RAG 在真实场景里暴露的运维困境讲起再拆解 agentic search 的工作机制然后给出可落地的对比实验方法和选型建议最后分享一些我在实操中踩过的坑和总结出来的经验。2. RAG 在代码场景里暴露的三个运维死结2.1 索引更新永远追不上代码变更的速度RAG 的第一道坎是索引和源数据之间的同步问题。向量数据库里的内容不是凭空产生的它需要你把原始数据切片、嵌入、写入。这个过程在静态文档场景下还好文档更新频率低一天跑一次增量索引就够了。但代码仓库不一样一个活跃的团队每天可能有几十上百次提交每次提交都可能改动函数签名、调整配置项、新增或删除文件。我当时的做法是每天凌晨跑一次全量重建索引。听起来还行对吧但问题是白天有人改了代码当天问相关问题时检索到的还是旧版本的内容。更麻烦的是如果改动涉及函数重命名或者模块拆分旧索引里的内容不仅过时还会产生误导。有一次一个同事把某个工具函数从utils/format.js移到了helpers/string.js索引没更新结果系统一直告诉别人去utils目录找白白浪费了半小时。你可能会说那就做实时索引呗。理论上可以每次提交触发一次增量更新。但实际操作中增量更新需要精确识别哪些文件变了、哪些 chunk 需要重新嵌入、哪些旧向量需要删除。这套逻辑写起来不复杂但维护起来很烦。而且嵌入模型调用是有成本的每次提交都触发嵌入费用和延迟都会上去。我们当时算过一笔账如果按实时更新来做光是嵌入 API 的调用费用一个月就要多出好几百块这还不算向量数据库的写入开销。更隐蔽的问题是代码的语义单元和文本的语义单元不一样。一段文档可以按段落切切完每段意思相对完整。但代码不行一个函数可能跨几十行中间还有嵌套逻辑你按固定长度切很容易把一个完整的逻辑切碎。切碎了之后向量检索召回的是碎片模型拿到手里也拼不出完整语义。我当时试过按函数边界切、按 AST 节点切、按文件切每种切法都有各自的坑没有一种能通吃。2.2 向量相似度和代码相关性之间的鸿沟第二道坎更本质向量相似度衡量的是语义接近程度但代码检索需要的是逻辑相关性。这两者经常不一致。举个我实际遇到的例子。我们有一个配置项叫maxRetryCount默认值是 3。有人问“重试次数默认是多少”向量检索会去找和“重试次数默认值”语义最接近的文本片段。结果它召回了另一个模块里一个叫retryLimit的配置项说明那个配置项的默认值是 5。从语义上看“重试次数”和“重试限制”确实很像嵌入模型把它们映射到了相近的向量空间位置。但从代码逻辑上看这两个配置项属于完全不同的模块一个管网络请求重试一个管数据库连接重试混在一起就是错的。这种问题在向量检索里几乎无解因为嵌入模型本身不区分“这个配置项属于哪个模块”这种结构化信息。你可以在切片的时候把模块名拼进去比如把maxRetryCount写成networkModule.maxRetryCount这样嵌入的时候会带上模块上下文。但这又引入了新的问题用户提问的时候不一定知道模块名他可能只记得“有个重试次数的配置”这时候模块名反而成了噪声。还有一个更典型的场景查函数调用关系。有人问“这个函数被哪些地方调用了”向量检索会去找和“函数调用”语义相近的文本。但代码里的调用关系是显式存在的grep一下就能精确找到所有调用点。向量检索做这件事就像用模糊搜索去找一个精确的字符串天生就不对路。我当时做过一个对比测试同样一个“查找函数调用点”的查询grep的准确率是 100%向量检索的准确率不到 40%而且返回的结果里有一大半是语义相近但实际不相关的函数定义。2.3 多轮检索的延迟和成本失控第三道坎是运维成本。RAG 的典型流程是用户提问 → 嵌入查询 → 向量检索 → 召回 top-k → 拼提示词 → 模型生成。这个流程里嵌入和检索都是额外开销。单次查询可能多出几百毫秒到一两秒的延迟看起来不多但用户一旦频繁使用这个延迟就会累积成体验问题。更麻烦的是当一次检索召回的内容不够好时你可能会想加一轮重排或者二次检索。比如先召回 top-20再用一个重排模型筛出 top-5。这确实能提升质量但延迟和成本也跟着涨。我们当时试过加一个交叉编码器做重排检索质量确实上去了但单次查询延迟从 800 毫秒涨到了 2.5 秒用户开始抱怨“太慢了”。成本方面嵌入模型调用、向量数据库的存储和查询、重排模型调用每一项都是钱。我们当时用的是按量计费的嵌入 API加上向量数据库的托管费用一个月下来小一千块。对于一个大团队来说不算什么但对于个人项目或者小团队这个成本就不低了。而且随着数据量增长向量数据库的存储和查询成本是线性上升的你没法通过优化架构来摊薄。还有一个容易被忽略的点向量数据库本身也是一个需要运维的组件。你得考虑它的高可用、备份、扩容、版本升级。我们当时用的那个向量数据库有一次版本升级之后查询性能突然下降了一半排查了两天才发现是新版本的默认索引参数变了。这种运维负担在项目初期往往被低估等到数据量上来之后才暴露出来。3. Agentic Search 到底在做什么不同的事3.1 把“找什么”的决定权交还给模型Agentic search 的核心思路用一句话概括就是不让模型只做“读”这件事而是让它同时做“找”这件事。传统 RAG 里模型是被动的。检索系统先去找一堆可能相关的内容塞给模型模型只负责从这些内容里提取答案。如果检索系统找错了模型再强也没用。Agentic search 反过来它给模型一套工具——比如文件读取、目录遍历、关键词搜索、正则匹配——然后让模型自己决定先看哪里、再看哪里、什么时候停下来。这个区别听起来简单但实际影响很大。举个例子用户问“这个项目的构建流程是怎样的”。传统 RAG 会去检索和“构建流程”语义相近的文档片段可能召回 README 里的一段说明也可能召回 CI 配置文件里的一段脚本。但构建流程往往分散在多个文件里package.json里有脚本定义CI 配置里有执行步骤Dockerfile 里有环境准备。向量检索很难一次性把这些都召回因为它按语义相似度排序而“构建流程”这个语义和每个具体文件的相似度都不算特别高。Agentic search 的做法是模型先看项目根目录发现有个package.json读一下 scripts 字段发现有个.github/workflows目录进去看看 CI 配置发现有个Dockerfile也读一下。它是一步一步探索出来的每一步都基于上一步的发现来决定下一步去哪。这个过程更像人类工程师排查问题的思路而不是一次性检索。3.2 多轮探索如何绕开向量检索的盲区Agentic search 的另一个优势是它能处理需要多轮才能解决的问题。比如用户问“这个报错是从哪里抛出来的”。传统 RAG 会去检索报错信息相关的文本可能召回抛出异常的代码片段也可能召回捕获异常的代码片段但它没法告诉你完整的调用链路。Agentic search 可以这样做先搜索报错信息字符串找到抛出异常的位置然后搜索这个异常类的定义确认它的类型再搜索这个异常被捕获的地方看看有没有被转换或包装最后沿着调用链往上追直到找到触发异常的入口。这个过程可能需要五六轮搜索但每一轮都建立在前一轮的结果上最终能给出一个完整的链路。我实测下来这种多轮探索在代码场景里的准确率比单次向量检索高出一大截。当然代价是延迟更高因为每一轮都要调用模型来决定下一步动作。但这里有个关键区别Agentic search 的延迟是“可感知的探索过程”用户能看到模型在一步步找心理上更容易接受而 RAG 的延迟是“黑盒等待”用户不知道系统在干什么等久了就会烦躁。还有一个容易被忽略的点Agentic search 不需要预先构建索引。这意味着没有索引更新问题没有切片粒度问题没有嵌入模型选型问题。你改了代码下一次查询直接读最新文件就行。这个特性在代码场景里太重要了因为代码变更太频繁了任何需要预处理的方案都会面临同步问题。3.3 工具调用背后的决策逻辑Agentic search 能跑起来靠的是一套工具调用机制。模型不是凭空知道去哪里找文件的它需要有一套明确的工具接口。常见的工具包括文件读取给定路径返回文件内容。这是最基础的工具模型用它来查看具体文件。目录遍历给定目录路径返回子目录和文件列表。模型用它来了解项目结构。关键词搜索给定关键词返回匹配的文件和行号。模型用它来定位相关代码。正则匹配给定正则表达式返回匹配结果。模型用它来做更精确的查找。文件元信息给定路径返回文件大小、修改时间等信息。模型用它来判断哪些文件可能更相关。这些工具本身不复杂难的是模型怎么决定用哪个工具、传什么参数、什么时候停止。这背后依赖的是模型的推理能力。模型需要理解用户的意图然后规划出一条探索路径。比如用户问“这个项目的入口文件在哪”模型可能会先遍历根目录看到package.json里的main字段然后读取那个文件。如果main字段指向的文件不存在它可能会去搜索常见的入口文件名比如index.js、main.py、app.js。这个决策过程不是硬编码的而是模型根据上下文动态生成的。这也是为什么 Agentic search 对模型能力有要求——模型得足够聪明才能规划出合理的探索路径。如果模型能力不够它可能会陷入死循环反复读同一个文件或者漫无目的地遍历目录。我在早期实验里就遇到过这种情况模型在一个大仓库里迷路了读了二十多个文件还没找到答案最后超时退出。4. 一次可复现的对比实验RAG vs Agentic Search4.1 实验设计和数据集准备为了搞清楚这两种方案在代码场景下的实际差异我设计了一个小规模对比实验。实验目标很明确在同一个代码仓库上用相同的问题集分别测试 RAG 和 Agentic search 的准确率、延迟和运维成本。我选了一个中等规模的开源项目作为测试对象大概有 200 多个文件代码行数在 3 万行左右。这个规模不算大但足够覆盖常见的代码结构有配置文件、有工具函数、有业务逻辑、有测试用例。问题集我准备了 50 个问题分成四类事实查询类比如“某个配置项的默认值是多少”“某个函数的参数有哪些”。这类问题有唯一正确答案容易验证。关系查询类比如“某个函数被哪些地方调用了”“某个模块依赖了哪些其他模块”。这类问题需要跨文件追踪。流程查询类比如“项目的构建流程是怎样的”“测试是怎么跑的”。这类问题需要综合多个文件的信息。排错查询类比如“某个报错信息是从哪里抛出来的”“某个异常在哪些地方被捕获”。这类问题需要沿着调用链追踪。RAG 方案我用的是当时比较主流的配置嵌入模型用的是一个中等规模的通用模型切片长度 512重叠 64向量数据库用的是本地部署的 Chroma检索 top-5不加重排。Agentic search 方案我用的是一个支持工具调用的模型工具集包括文件读取、目录遍历、关键词搜索和正则匹配最大探索轮数设为 10 轮。4.2 准确率、延迟和成本的三维对比实验结果比我预想的更有意思。先看准确率问题类型RAG 准确率Agentic Search 准确率事实查询72%94%关系查询38%88%流程查询45%82%排错查询30%76%事实查询类 RAG 表现还行因为这类问题语义相对明确向量检索能召回相关内容。但关系查询和排错查询 RAG 就明显吃力了准确率掉到了 40% 以下。Agentic search 在这两类问题上优势明显因为它能沿着调用链一步步追踪而 RAG 只能一次性召回。延迟方面RAG 的单次查询延迟在 600 到 900 毫秒之间比较稳定。Agentic search 的延迟波动很大简单问题可能一两秒就结束了复杂问题可能要五六秒甚至更久。平均下来Agentic search 的延迟是 RAG 的三到四倍。但这里有个细节RAG 的延迟是固定的不管问题难易Agentic search 的延迟和问题复杂度相关简单问题快复杂问题慢。从用户体验角度看这种“按需付费”的延迟模式反而更容易接受。成本方面RAG 的主要开销在嵌入模型调用和向量数据库运维。嵌入是一次性的但每次数据更新都要重新嵌入。向量数据库的存储和查询费用随数据量线性增长。Agentic search 的主要开销在模型调用每次查询都要调用模型来决定下一步动作轮数越多调用次数越多。我粗略算了一下在每天 100 次查询的规模下RAG 的月成本大概在 200 到 300 元Agentic search 的月成本在 400 到 600 元。Agentic search 更贵但差距没有想象中那么大。4.3 什么场景下 RAG 仍然更划算实验做完之后我并没有得出“Agentic search 全面碾压 RAG”的结论。事实上在一些场景下 RAG 仍然更划算。第一种场景是静态文档检索。如果你的知识库主要是产品文档、操作手册、FAQ 这类更新频率低、语义单元完整的内容RAG 的性价比很高。这类内容的切片很自然按段落切就行向量检索的准确率也高。而且文档更新频率低索引同步问题不突出。第二种场景是高频简单查询。如果用户的问题大多是“某个术语是什么意思”“某个功能的操作步骤是什么”这类事实查询RAG 的准确率已经够用而且延迟更低、成本更可控。Agentic search 在这种场景下有点杀鸡用牛刀。第三种场景是资源受限的环境。Agentic search 对模型能力有要求需要模型支持工具调用而且推理成本更高。如果你的环境只能用一个小模型或者预算非常紧张RAG 可能是更现实的选择。所以选型的关键不是“哪个方案更好”而是“你的场景更需要什么”。代码检索、复杂排错、跨文件追踪这些场景Agentic search 优势明显静态文档、简单查询、资源受限这些场景RAG 仍然有它的位置。5. 从 RAG 迁移到 Agentic Search 的实操路径5.1 工具集设计最小可用集合是什么如果你决定尝试 Agentic search第一步是设计工具集。我的建议是从最小可用集合开始不要一上来就搞一大堆工具。最小集合包括四个文件读取输入文件路径返回文件内容。这是最核心的工具模型大部分时间都在用它。目录遍历输入目录路径返回子项列表。模型用它来了解项目结构决定下一步去哪。关键词搜索输入关键词和可选的路径范围返回匹配的文件和行号。模型用它来快速定位相关代码。正则匹配输入正则表达式和可选的路径范围返回匹配结果。模型用它来做更精确的查找。这四个工具覆盖了大部分代码检索场景。我一开始还加了一个“文件元信息”工具想让模型根据文件修改时间来判断相关性但实测下来模型很少用这个工具后来就去掉了。工具太多反而会让模型困惑不知道该用哪个。工具的实现要注意几点。文件读取要限制最大返回长度防止模型一次读入一个超大文件把上下文撑爆。目录遍历要限制递归深度防止模型在大仓库里迷路。关键词搜索和正则匹配要限制返回结果数量防止一次返回几百个匹配项。这些限制看起来是小事但实际跑起来之后没有这些限制系统很容易失控。5.2 提示词里必须写清楚的边界条件Agentic search 的提示词比 RAG 复杂得多因为你要告诉模型怎么用工具、什么时候停止、遇到问题怎么办。我踩过的坑里大部分都和提示词没写清楚有关。首先要明确告诉模型最大探索轮数。如果不写模型可能会一直探索下去直到上下文耗尽或者超时。我一般设 10 轮复杂问题可以放宽到 15 轮。超过这个轮数还没找到答案就让模型基于已有信息给出最佳猜测并说明不确定性。其次要告诉模型什么时候停止。有些模型会陷入“再找找看”的循环明明已经找到答案了还在继续搜索。提示词里要明确说“一旦找到足够回答问题的信息就停止探索并给出答案”。第三要告诉模型怎么处理找不到的情况。如果模型搜了几轮都没找到相关信息它应该如实说“没有找到”而不是编造一个答案。这一点在代码场景里特别重要因为编造的代码信息比没有信息更危险。第四要告诉模型优先使用精确搜索。关键词搜索和正则匹配比文件读取更高效模型应该先用搜索定位再读取具体文件。如果一上来就遍历目录、逐个读文件效率会很低。5.3 缓存和超时机制怎么设才不翻车Agentic search 的延迟波动大所以缓存和超时机制必须设计好。缓存方面文件读取的结果可以缓存。同一个文件在一次会话里可能被读多次缓存能省掉重复的 IO 和模型调用。但缓存要注意失效问题如果文件在会话期间被修改了缓存里的内容就过时了。我的做法是给缓存设一个较短的过期时间比如 30 秒或者在检测到文件修改时间变化时主动失效。超时方面要设两层超时。第一层是单次工具调用的超时比如文件读取超过 5 秒就放弃防止某个大文件卡住整个流程。第二层是整体查询的超时比如 30 秒还没结束就强制返回当前结果。没有超时机制的话一个复杂查询可能跑几分钟用户早就跑了。还有一个细节模型调用本身也可能超时。如果模型服务不稳定某次调用卡住了整个探索流程就断了。我的做法是给每次模型调用设一个超时超时后重试一次再超时就放弃当前轮基于已有信息继续。6. 那些文档里不会写的踩坑经验6.1 模型迷路时的急救方案Agentic search 最常见的问题就是模型迷路。它在一个大仓库里转来转去读了一堆不相关的文件就是找不到答案。我遇到过好几次这种情况后来总结了一套急救方案。第一招是限制搜索范围。如果用户的问题明确指向某个模块就在提示词里告诉模型优先在那个模块的目录下搜索。比如用户问“用户模块的登录逻辑”就告诉模型先去src/user/目录下找。这能大幅减少迷路的概率。第二招是给模型一个“地图”。在提示词里附上项目的目录结构概览让模型对项目布局有个整体认知。这样它就不会盲目遍历而是有针对性地去某个目录找。目录结构不用太详细列出顶层目录和主要子目录就行。第三招是设置“回头”机制。如果模型连续三轮都在读不相关的文件就强制它回到起点重新审视问题换一个搜索策略。这个机制需要在提示词里写清楚或者在工具调用层做拦截。第四招是降级处理。如果模型探索了 10 轮还没找到答案就让它基于已有信息给出最佳猜测并明确标注“以下答案基于有限信息可能不完整”。这比让模型继续瞎找或者直接报错要好。6.2 大仓库下的性能陷阱仓库越大Agentic search 的性能问题越突出。我测试过一个有上千个文件的大仓库模型遍历目录就要花好几秒搜索关键词返回的结果太多模型处理不过来。应对大仓库有几个策略。一是预建文件索引把文件名和路径存到一个轻量级的索引里模型搜索时先查索引再决定读哪些文件。这个索引不需要向量化就是一个简单的倒排索引按文件名和路径关键词建就行。二是限制搜索深度默认只搜索前三层目录除非用户明确要求深入搜索。三是分而治之如果仓库有明显的模块划分就让模型先确定问题属于哪个模块再在那个模块内搜索。还有一个容易被忽略的点大仓库里的文件读取要特别小心。有些文件可能几万行模型一次读进来上下文就满了。我的做法是文件读取工具支持按行范围读取模型可以先读前 100 行看看内容如果需要再读更多。这样既能控制上下文长度又能让模型逐步深入。6.3 成本控制的几个实用开关Agentic search 的成本主要来自模型调用。每次工具调用决策、每次结果分析都要调用模型。轮数越多成本越高。控制成本有几个实用开关。第一个开关是限制最大轮数。我一般设 10 轮简单问题通常 3 到 5 轮就结束了复杂问题可能用到 8 到 10 轮。超过 10 轮还没结果就强制停止。第二个开关是缓存模型决策。如果两个问题的探索路径相似可以复用之前的决策。比如“函数 A 的参数是什么”和“函数 B 的参数是什么”探索路径都是“搜索函数名 → 读取函数定义 → 提取参数”这种模式可以缓存下来下次遇到类似问题直接套用。第三个开关是分级模型。简单问题用一个小模型来处理复杂问题才用大模型。判断问题复杂度可以在入口处做一个快速分类比如问题里包含“调用关系”“报错链路”这类词就归为复杂问题。第四个开关是结果缓存。同一个问题如果被问了多次直接返回缓存结果。这在团队知识库场景里很常见很多问题是重复的。7. 选型决策你的场景到底该走哪条路7.1 三个判断维度数据形态、查询模式、运维能力选型不是拍脑袋决定的我一般用三个维度来判断。第一个维度是数据形态。如果你的数据主要是静态文档、更新频率低、语义单元完整RAG 更合适。如果数据是代码、更新频繁、需要跨文件追踪Agentic search 更合适。中间地带比如产品文档加少量代码示例可以混合使用文档走 RAG代码走 Agentic search。第二个维度是查询模式。如果用户的问题大多是事实查询RAG 够用。如果问题涉及关系追踪、流程梳理、排错链路Agentic search 优势明显。你可以统计一下用户实际提问的类型分布如果复杂查询占比超过 30%就值得考虑 Agentic search。第三个维度是运维能力。RAG 需要维护嵌入模型、向量数据库、索引同步流程运维负担不轻。Agentic search 不需要这些但对模型能力有要求而且延迟和成本波动大。如果你的团队没有专门的运维人力Agentic search 的“无索引”特性反而是一个优势。7.2 混合架构什么情况下两条腿走路最稳实际项目中纯 RAG 或纯 Agentic search 都不一定是最优解。混合架构往往更稳。一种常见的混合方式是用 RAG 做粗筛用 Agentic search 做精查。用户提问后先用向量检索召回一批可能相关的文件或片段然后让模型在这些候选范围内做 Agentic search。这样既利用了向量检索的快速召回能力又发挥了 Agentic search 的精确追踪能力。另一种混合方式是按查询类型路由。系统先判断查询类型事实查询走 RAG关系查询和排错查询走 Agentic search。判断逻辑可以很简单比如问题里包含“调用”“依赖”“报错”“链路”这些词就走 Agentic search否则走 RAG。还有一种混合方式是按数据源路由。文档类数据走 RAG代码类数据走 Agentic search。这种路由最自然因为两类数据的特性差异最大用各自最适合的方案处理效果最好。7.3 从今天开始可以做的三件事如果你现在正在做知识库不管选哪条路有三件事可以马上开始做。第一件是统计查询类型分布。把用户实际问过的问题收集起来分类统计。看看事实查询、关系查询、流程查询、排错查询各占多少。这个数据是选型的基础没有它选型就是拍脑袋。第二件是搭一个最小可用的 Agentic search 原型。不需要完整实现用现成的模型 API 加几个简单的工具函数就行。跑上几十个真实问题感受一下它的能力和局限。这个原型的成本很低但能给你很多直观认知。第三件是评估运维成本。把 RAG 方案和 Agentic search 方案的运维成本都列出来包括人力、费用、延迟。不要只看效果运维成本往往是决定方案能不能长期跑下去的关键因素。我见过太多项目因为运维成本太高而半途而废效果再好也没用。我个人在实际操作中的体会是RAG 和 Agentic search 不是替代关系而是互补关系。RAG 擅长快速召回Agentic search 擅长精确追踪。理解它们各自的能力边界根据场景灵活组合才是更务实的做法。Claude Code 选择 Agentic search不是因为 RAG 效果不行而是因为在代码这个特定场景下RAG 的运维负担和精确性短板被放大了。换一个场景RAG 可能仍然是更优解。选型的核心永远是理解自己的场景而不是追逐最新的技术潮流。
阅读完成 · 觉得有帮助？
