前言

RAG成默认

过去两年，做私有知识问答时，RAG 经常会成为那个默认答案：先建知识库，切 chunk，做 embedding，再把相关片段塞给模型。

这个思路在 Chatbot 时代非常自然。用户问一句话，系统从知识库里召回几个相关片段，把片段塞进 prompt，然后让模型回答。模型不知道外部知识，那就先把知识取回来。

Agent进终端

但 Agent 的工作方式，已经不是这么一回事了。

以 OpenAI Codex CLI、Claude Code、Gemini CLI 为代表的一类代码/终端 Agent，不再只是「问答系统」。它们会读文件、列目录、跑命令、改代码、看测试结果，然后继续下一步。在这种环境里，一个看起来很朴素的工具又变重要了：Grep，或者更常见的 rg。

不是 RAG 没用了，而是 Agent 把检索这件事本身改了。

任务差异

RAG擅长问答

RAG 的基本假设是，用户的问题可以先变成一个检索查询，然后系统找出最相关的几个 chunk。它的优势，通常体现在外部知识补充和语义召回上，尤其适合跨文档、跨知识库、表达模糊的问题。

比如：

• “我们公司报销制度里，差旅住宿标准是什么？”
• “把过去三个月客户反馈里和价格有关的抱怨总结一下。”
• “这批论文里有没有和多智能体协作相关的观点？”

这些问题不一定有明确关键词。用户也未必知道原文到底怎么写。RAG 用 embedding 把问题和文档映射到语义空间，再找相似内容，这时候确实有价值。

Agent要定位

但 Agent 经常面对的是另一类任务：

• “这个接口在哪里定义？”
• “谁调用了 createUser？”
• “错误日志里的 TimeoutError 是从哪条路径抛出来的？”
• “这个配置项有没有在测试里覆盖？”

这类问题不是「语义相似」优先，而是「定位证据」优先。答案经常就藏在一个符号、一个字符串、一个文件名、一段调用链里。这时候，更稳的第一步往往不是向量搜索，而是：

rg "createUser"rg "TimeoutError"rg "FEATURE_FLAG_X"

Grep 的优势不是显得聪明，而是确定。

工具循环

中间步骤要能追

传统 RAG 常常把检索过程封装起来：用户看见的是回答，模型看见的是几个召回片段。但为什么是这几个？有没有漏？chunk 有没有切断关键上下文？排序靠不靠谱？这些不是 RAG 一定会失败，而是检索系统在工程实现里绕不开的取舍。

Agent 不一样。它的能力来自一个循环：搜索、读取、推理、行动、验证。

Grep给路标

grep/rg 很适合这个循环。它返回的是文件路径、行号和命中的原文。Agent 可以马上打开文件，读上下文，扩大搜索范围，再根据证据修改代码或生成结论。它不是一次性把「可能相关」的内容送进上下文，而是给 Agent 一条可以继续走下去的路。

这也是为什么一些新一代 Agent 产品，会把自己放进终端、编辑器和文件系统里。OpenAI Codex CLI 的定位是「运行在本机的 coding agent」；Claude Code 文档明确描述它能读取代码库、编辑文件、运行命令；Gemini CLI 也强调终端优先，并提供文件和 shell 等工具能力。它们共同体现出一种设计取向：Agent 不只是模型，它还需要一组可调用、可观察、可重复的工具。

在这个工具栈里，Grep 不是完整的智能检索系统，但它是一个很轻的观察入口：几乎不需要预处理，返回结果也能立刻追到文件和行号。

压缩风险

RAG会先筛

RAG 的一个重要价值是压缩：把庞大的知识库筛成几个候选片段。对问答系统来说，这是必要能力；但对需要连续行动的 Agent 来说，过早压缩也可能带来新的风险。

在问答系统里，这种压缩是必要的。用户没有耐心看一百个文件，模型上下文也有限，系统必须替用户筛选。

Agent要保控制

但在 Agent 场景里，过早压缩反而可能伤害推理。因为 Agent 往往需要的是任务路径，不只是孤立片段。

代码尤其如此。一个函数的意义不只在定义处，也在调用处、测试处、配置处、错误处理处。向量检索当然可以帮助发现语义相近的内容，但如果任务目标是定位符号、调用点、字符串常量或异常名，精确搜索往往更适合作为第一步。chunk 切分和排序也不是不能解决，只是它们会把「如何保留上下文」变成额外的系统设计问题。

Grep 不理解语义，但它不会把精确命中变成“相似命中”。这对 Agent 很重要。Agent 可以自己决定下一步搜什么：

1. 先搜错误名。
2. 找到定义文件。
3. 再搜调用方。
4. 再读相关测试。
5. 再运行验证命令。

这个过程看起来笨，但它保留了控制权。Agent 的推理发生在循环里，而不是被一次召回结果提前锁死。

rg 的优势

默认更干净

今天大家说 Agent 用 Grep，很多时候实际指的是 ripgrep，也就是 rg。

它适合代码仓库，不只是因为快。更关键的是，它默认递归搜索当前目录，支持正则，并尊重 .gitignore，会自动跳过隐藏目录和二进制文件。这些默认规则，通常能帮工程仓库少很多噪声。

这件事对 Agent 来说很实际。

噪声成本更低

Agent 的上下文预算有限，工具调用也有成本。一次粗糙搜索如果把 node_modules、构建产物、缓存文件、二进制文件全扫出来，模型很快就会被噪音淹没。rg 的默认行为把大量工程噪音挡在外面，让搜索结果更接近开发者真正关心的代码和文档。

这不是智能检索意义上的「语义相关」，而是工程检索意义上的「干净可用」。

论文证据

工具环境影响结果

这个现象也不只是开发者体感。

2026 年 5 月的一篇论文《Is Grep All You Need? How Agent Harnesses Reshape Agentic Search》把问题说得更直接：在 Agent harness 中，检索器本身不是唯一变量，工具输出方式和 Agent 如何继续使用中间结果，也会显著影响最终表现。论文比较了 grep 与向量检索在 agentic search 里的表现，但它的价值不在于给出「谁永远更强」的结论，而在于提醒我们：Agent 的检索质量和工作环境绑定在一起。

不是谁赢

这个结论不应该被简化成「Grep 永远赢 RAG」。更准确的读法是：当模型可以反复调用工具、读取文件、利用中间结果继续行动时，检索器本身就不再是唯一变量。工具输出怎么呈现，Agent 能不能追踪上下文，能不能继续搜索，都会改变最终效果。

也就是说，Agentic Search 的核心不只是「召回最相似的 chunk」，还包括「让模型能用工具逐步逼近答案」。

发生原因

这股变化不是突然冒出来的，而是几个条件碰到了一起。

工具环境变了

第一，Agent 产品开始把模型放进真实工具环境。重点不只是模型本身变强，而是模型可以通过 shell、文件读取、编辑器和测试命令拿到反馈。哪怕底层模型不变，工具 harness 的设计也会改变检索策略。

召回不必一次完成

第二，Agent 不必一次性完成召回。传统 RAG 常常在回答前完成压缩；Agent 可以先用精确搜索找到候选，再读取原文，再二次搜索调用方或测试文件。这样一来，它对「第一次召回必须足够好」的依赖就没那么重了。

第三，Agent 的运行环境更贴近开发者工具。终端、IDE、文件系统、shell 命令，本来就是工程师完成任务的地方。Agent 进入这些环境后，自然会继承这些环境里最可靠的那批工具。

默认成本不同

第四，工程成本会影响默认选择。RAG 系统通常要处理切分、embedding、索引、更新、权限、重排和评测；这些能力很有价值，但对一个本地代码仓库或小型文档集来说，未必总是值得放在第一层。rg 几乎没有预处理成本，随用随搜，结果立即可验证。

分层使用

RAG仍有位置

把 Grep 和 RAG 写成你死我活，是最容易误导人的地方。

RAG 仍然适合很多场景：

• 语料太大，不能每次现场遍历。
• 用户不知道关键词，只能表达语义意图。
• 数据来自多个系统，不在同一个文件树里。
• 内容是长文、报告、客服记录、会议纪要，而不是代码符号。
• 需要跨语言、跨表达方式召回相似概念。

更现实的架构不是「Grep 或 RAG 二选一」，而是分层。

更实际的链路

在代码和本地文档任务里，可以先用 rg 做精确定位，用文件读取拿上下文，用 shell 或测试命令验证结论。遇到跨文档语义搜索、历史记录搜索、海量知识库问答时，再引入 RAG。复杂一点的产品，也可以把两者组合起来：关键词搜索负责高精度入口，向量检索负责语义扩展，重排器负责最终排序，Agent 负责多轮决策。

一个更实际的 Agent 检索链路，可能长这样：

1. 先用 rg 搜错误名、函数名、配置项或日志片段。
2. 打开命中的文件，读取定义、调用方和附近上下文。
3. 如果命中太少，再用语义检索扩展相近概念或历史资料。
4. 把候选结果交给模型判断下一步，而不是直接把召回片段当答案。
5. 用测试、命令或人工可检查的证据验证结论。

在这类可遍历环境中，RAG 不必承担「默认入口」的全部责任，它更适合作为特定场景的强工具。这不是失败，而是归位。

工作方式

从知识库到工作台

过去做知识型 AI 应用，常见第一步是建知识库。把资料整理好，切 chunk，做 embedding，然后等用户来问。

面对 Agent 应用，我觉得更合理的第一反应是：给模型一个工作台。

这个工作台里有文件系统，有搜索，有命令行，有编辑器，有测试，有日志。模型不再只是从知识库里拿答案，而是在环境里行动。它要能找到证据、验证假设、修正错误，并把结果落回真实系统。

在知识库思维里，RAG 很容易成为核心，因为系统的目标是把外部知识送进回答里。

Grep是入口

在工作台思维里，Grep 更像入口，因为系统的目标是让 Agent 先找到一个可检查的位置，再决定下一步怎么做。

这也是为什么这类 Agent 会重新使用 Grep。不是因为行业倒退到了命令行时代，而是因为 Agent 进入了命令行一直擅长的世界：可定位、可组合、可验证、可重复。

最后

所以，一个代码 Agent 面对报错时，最有用的第一步往往不是「理解整个知识库」，而是搜到那行错误、打开那个文件、沿着调用链走下去，然后用测试证明自己没有猜错。RAG 仍然可以在旁边提供语义扩展，但任务的锚点，常常来自一次朴素而准确的命中。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】