1. 面试官的问题

在大模型智能体面试中，面试官突然抛出这样一个问题：“Claude Code 为什么放弃 RAG，转而使用 Grep？请分析其智能体架构。”这个问题很有攻击性——它不是在问“RAG 和 Grep 哪个更好”，而是在考察你对智能体认知模型、上下文处理策略和工程权衡的理解。

下面我们以系统架构师视角，从问题背后的技术动因、Claude Code 的智能体设计哲学、Agentic Search 与 RAG 的本质差异、以及 Grep 的具体落地方式，来系统地回答这个问题。

2. “放弃 RAG 改用 Grep” 的问题本质

首先要澄清一个常见的误读：Claude Code 并没有从 RAG 系统迁移到 Grep。RAG（检索增强生成）是一种通用模式——知识库拼接加载进入大模型上下文；而 Grep 是一个具体的工具（字符串/正则搜索）。问题真正的含义是：在智能体架构中，为什么能用精准的**工具调用（Grep）**替代传统 RAG 模式，并且效果更好。

很多面试者一听到“放弃 RAG”就会跳到“向量召回不准”之类的答案，但这题的关键在于智能体架构对上下文管理的范式升级。

3. Claude Code 智能体架构概览

要回答“为什么用 Grep”，必须先理解 Claude Code 的智能体架构。它本质是一个工具增强型智能体（Tool-Augmented Agent），运行在编辑器中，具有：

• 多步推理与计划能力（ReAct 风格）
• 文件系统工具集：Grep、Glob、Read、Write、Edit、Bash
• 明确的上下文预算感知（200K token 窗口）
• 反思与验证循环

与传统 RAG 流水线（跑在服务器上静态导入上下文）不同，Claude Code 作为智能体是主动与环境交互的。它不需要“喂进去”所有可能相关的知识，而是像人类工程师一样，在需要时去定位和读取文件。

为了更直观地理解 Claude Code 的内部构造，下面这张架构总览图展示了智能体的核心闭环——从环境感知、推理规划到工具调度与反思验证：

这张图揭示了一个关键设计：上下文获取不再是预处理阶段的一次性操作，而是推理循环中持续调度的工具调用。下面再通过两个并行子图对比传统 RAG 与 Agentic Search 在流程上的本质差异。

3.1 架构流程对比图

为了直观理解传统 RAG 与 Claude Code Agentic Search 在上下文获取模式上的本质区别，下面用两个 Mermaid 子图做并行对比：

核心差异：

• 传统 RAG：上下文在生成前通过静态流水线一次性注入。检索与生成解耦，LLM 被动接受预组装的“知识套餐”，缺乏对信息质量的实时判断。
• Claude Code Agentic Search：上下文获取由智能体在推理循环中按需驱动。每一步搜索都是基于当前认知状态的主动决策——可以追加搜索、调整策略、精准读取，直到收集到足够信息。这才是“主动采集”与“被动注入”的根本分野。

下面从五个关键维度将传统 RAG 与 Claude Code 的 Agentic Search 做系统对比：

对比维度	传统 RAG	Claude Code Agentic Search
检索模式	静态流水线：向量化 → 索引检索 → Top‑K 返回，一次性注入	智能体多步搜索：分析任务 → 构造 Grep → 精确 Read → 评估迭代，按需采集
上下文管理	携带大量冗余 chunk，粗暴消耗上下文预算，窗口利用率低	精准读取所需片段，每一字节预算都服务于当前推理，窗口利用效率极高
实时性	依赖预构建向量索引，无法感知未保存的修改或 Git 变更	直接搜索文件系统，所见即所得，实时反映代码最新状态
可解释性	黑盒召回，无法解释为何选择某个片段，调试困难	白盒匹配：返回文件名 + 行号 + 匹配行，完全可追溯、可审计
适用场景	非结构化知识库、长文档问答、语义模糊的探索性查询	结构化代码库、符号精确匹配、多步推理驱动的开发与代码分析任务

核心概念

在深入分析 Claude Code 的智能体架构之前，有必要厘清几个关键概念。它们是理解“为什么 Grep 比 RAG 更契合这类场景”的理论基础。

Agentic Search（智能体驱动的搜索）

Agentic Search 是指由智能体自主规划、执行和调整的搜索过程，而非预先定义的静态检索流水线。在传统 RAG 中，检索策略是固定的（Embedding → 索引 → 相似度匹配 → Top-K 返回），而 Agentic Search 将搜索本身视为一个可编排的工具调用序列——智能体可以根据中间结果动态调整查询参数、过滤条件、搜索范围，甚至切换搜索工具。Claude Code 中的 Grep + Read 组合正是这一模式的典型实现。

Tool-Augmented Agent（工具增强型智能体）

工具增强型智能体 是一种能够主动调用外部工具（如文件系统、Shell 命令、API）来完成任务的 AI 系统，典型范式是 ReAct（Reasoning + Acting）循环。与传统 LLM 仅依赖内部参数化知识不同，工具增强型智能体将外部环境纳入认知闭环：它观察环境状态、选择合适工具、执行操作、根据反馈反思与修正。Claude Code 集成了 Grep、Glob、Read、Write、Edit、Bash 等工具，使模型具备了与真实代码库交互的能力，而非仅仅回答关于代码的问题。

Context Budget（上下文预算）

上下文预算 指大模型在一次推理中可容纳的 Token 总量上限（Claude Code 为 200K）。这不仅是技术参数，更是工程资源的硬约束。上下文预算一旦耗尽，模型将丢失窗口外的信息。RAG 为了保障召回率，常携带大量冗余片段，极大浪费预算；而 Agentic Search 按需检索、精准读取，将每一字节的预算都用在当前推理最需要的上下文上。这种“稀缺性思维”正是 Claude Code 架构设计的核心权衡之一。

4. RAG 的工程困境

尽管 RAG 在大模型应用中广泛使用，它在大型代码库这样动态且结构化的上下文中面临严重瓶颈：

4.1 语义与符号的撕裂

代码是高符号化的载体，函数调用链、类继承、变量引用依靠精确的符号匹配（如 UserService 这个类名）。向量嵌入关注语义相似度，却可能把 UserService 和 CustomerManager 视为高相关，而错过直接调用处的 UserService.login() 精确匹配。

4.2 上下文预算的粗暴消耗

RAG 为了召回率，常携带大量片段（top_k 个 chunk），很多 token 浪费在冗余或无关代码上，挤占了智能体的推理空间。200K token 的窗口看似很大，但对复杂工程任务依然珍贵。

4.3 静态索引与动态代码的异构

代码时刻在变（IDE 中未保存的修改、Git 未提交的变更）。而 RAG 依赖预先构建的向量索引，实时性与成本都难以保证。

4.4 相关性判定的失败

RAG 只能根据“问题-片段”相似性静态打分，而智能体可在推理中动态判断：我现在需要看这个模块的接口，还是需要追溯具体实现？

将上述四大困境汇总为一张根因分析图，能更清晰地看出 RAG 在代码场景下的系统性缺陷：

这四大困境指向同一个根因：RAG 将检索与推理拆分为两个独立环节，上下文由外部流水线预组装，智能体只能被动接受。而下一节要讨论的 Grep + Agentic Search 正是对这一根因的彻底重构。

5. Grep 在设计中的位置——Agentic Search

在 Claude Code 智能体架构中，Grep 不是简单地被“用来搜索”，而是作为Agentic Search 的核心工具。过程如下：

1. 分析任务：我需要理解用户提到的 PaymentController 如何创建订单。
2. 构造搜索：思考精确符号——类名 PaymentController、方法名 createOrder、或特殊模式 @PostMapping.*payment。
3. 调用 Grep：grep -rn "class PaymentController" src/ 定位文件/行号。
4. 读取上下文：用 Read 工具（或 cat 等效）精确读取目标文件、相关 import、调用栈代码。
5. 推理与归纳：综合这些精确信息形成回答或进一步代码操作。

下面是一段用 Python 模拟智能体多步搜索的伪代码，展示如何将自然语言任务拆解为具体的 Grep 命令序列，并逐步收集精确上下文进行分析：

# 示例：智能体使用 Grep 工具进行多步搜索的模拟代码
# 任务：“请找出支付模块中处理退款逻辑的代码，并分析其异常处理方式”

def agentic_grep_search(task: str) -> dict:
    """
    模拟智能体将自然语言任务拆解为 Grep 命令序列并处理结果
    """
    # 步骤1：分析任务，提取关键词和可能的符号
    keywords = ["refund", "退款", "Refund", "processRefund", "refundPayment"]
    patterns = [f"grep -rn '{kw}' src/" for kw in keywords]

    # 步骤2：执行首轮 Grep，定位相关文件与行号
    all_matches = []
    for pattern in patterns:
        result = simulated_grep(pattern)  # 模拟grep工具调用
        all_matches.extend(result)

    # 步骤3：根据首轮结果，构造更精准的二次搜索
    # 例如，发现 refund 相关代码集中在 PaymentService.java，进一步搜索异常处理模式
    refine_pattern = "grep -rn 'catch|throw|@ExceptionHandler' src/payment/"
    error_matches = simulated_grep(refine_pattern)

    # 步骤4：对关键文件执行 Read 操作，获取精确的上下文
    target_files = {match.file for match in all_matches + error_matches}
    read_results = {}
    for file in target_files:
        read_results[file] = simulated_read(file, context_lines=20)

    # 步骤5：推理与归纳——将收集到的精确信息整合为最终分析
    analysis = summarize(task, keywords, all_matches, error_matches, read_results)
    return analysis

def simulated_grep(command: str) -> list:
    """
    模拟 Grep 工具返回匹配结果列表
    实际环境中会调用系统 grep 并解析输出，每条结果包含 {file, lineno, line}
    """
    pass  # 示例中略去具体模拟实现

def simulated_read(file: str, context_lines: int = 20) -> str:
    """
    模拟 Read 工具读取文件内容
    """
    pass

def summarize(task, keywords, matches, error_matches, files_content) -> dict:
    """
    综合所有检索结果生成最终分析
    """
    pass

这样一来，智能体不再依赖预构建的向量索引，而是通过步步为营的工具调用，自己“长”出所需的上下文。
下面是一个可直接运行的 Python 脚本，完整模拟了智能体使用 Grep 和 Read 工具进行多步搜索的流程，包括模拟文件系统（示例代码库）、执行 grep 命令（正则匹配）、读取文件内容、以及基于结果进行推理决策：

#!/usr/bin/env python3
"""
模拟 Claude Code 智能体的 Agentic Search：多步 Grep + Read 工具协同。
依赖：仅标准库。可直接运行。
"""

import re
from dataclasses import dataclass
from typing import List, Dict, Optional
from collections import defaultdict

# ---------- 模拟文件系统 ----------
@dataclass
class File:
    path: str
    content: str

class FakeFileSystem:
    """用字典模拟项目文件，key 为相对路径，value 为文件内容（按行分割的列表）。"""
    def __init__(self, files: Dict[str, str]):
        self._raw = files
        self.files: Dict[str, List[str]] = {
            path: content.splitlines(keepends=True) for path, content in files.items()
        }

    def list_files(self, pattern: str = "*") -> List[str]:
        return [p for p in self.files if re.fullmatch(pattern.replace("*", ".*"), p)]

    def read_file(self, path: str, start_line: int = 0, end_line: Optional[int] = None) -> str:
        lines = self.files.get(path, [])
        return "".join(lines[start_line:end_line])

# ---------- 工具实现 ----------
@dataclass
class GrepMatch:
    file: str
    lineno: int      # 1-based
    line: str

def grep(pattern: str, fs: FakeFileSystem, path_filter: str = "*") -> List[GrepMatch]:
    """在模拟文件系统中执行 grep（支持简单正则），返回匹配列表。"""
    results = []
    for path in fs.list_files(path_filter):
        for idx, line in enumerate(fs.files[path], start=1):
            if re.search(pattern, line):
                results.append(GrepMatch(path, idx, line.rstrip("\n")))
    return results

def read_file(fs: FakeFileSystem, path: str, context: int = 5) -> str:
    """读取全文，通常配合 grep 命中行号获取上下文。"""
    return fs.read_file(path)

def read_context_around(fs: FakeFileSystem, match: GrepMatch, context: int = 5) -> str:
    """读取匹配行前后各 context 行的内容。"""
    start = max(match.lineno - context - 1, 0)
    end = match.lineno + context
    return fs.read_file(match.file, start, end)

# ---------- 智能体主循环 ----------
class AgenticSearcher:
    """模拟智能体使用 Grep + Read 多步搜索的推理过程。"""

    def __init__(self, fs: FakeFileSystem):
        self.fs = fs
        self.trace = []          # 记录每一步操作
        self.context_store = []  # 收集到的上下文片段

    def log(self, msg: str):
        self.trace.append(msg)
        print(f"[Agent] {msg}")

    def run(self, task: str):
        self.log(f"任务：{task}")
        # Step 1: 分析任务，提取关键词
        keywords = self._extract_keywords(task)
        self.log(f"提取关键词：{keywords}")

        # Step 2: 首轮 Grep 搜索
        all_matches: List[GrepMatch] = []
        for kw in keywords:
            matches = grep(kw, self.fs)
            self.log(f"  grep '{kw}' → {len(matches)} 匹配")
            all_matches.extend(matches)

        # 去重
        seen = set()
        unique_matches = []
        for m in all_matches:
            key = (m.file, m.lineno)
            if key not in seen:
                seen.add(key)
                unique_matches.append(m)
        all_matches = unique_matches

        if not all_matches:
            self.log("未找到任何匹配，任务结束。")
            return {"status": "no_results", "context": []}

        self.log(f"首轮共找到 {len(all_matches)} 个不重复匹配")

        # Step 3: 根据首轮结果，进行针对性二次搜索（例如搜索异常处理）
        # 这里模拟智能体“推理”决定再搜异常模式
        self.log("智能体推理：需要进一步了解异常处理方式，搜索异常模式...")
        error_matches = grep(r"(catch|throw|try\s*\{|@ExceptionHandler)", self.fs)
        self.log(f"  二次 grep 异常模式 → {len(error_matches)} 匹配")

        # Step 4: 对匹配到的关键文件执行 Read 操作，收集精确上下文
        candidate_files = set(m.file for m in all_matches + error_matches)
        self.log(f"决定读取以下文件的上下文（共 {len(candidate_files)} 个）：")
        for f in sorted(candidate_files):
            self.log(f"  Read: {f}")
            content = read_file(self.fs, f)
            self.context_store.append({"file": f, "content": content, "role": "full_file"})

        # 额外：对每个匹配行读取精确上下文（前后各5行）
        for m in all_matches:
            ctx = read_context_around(self.fs, m, context=5)
            self.context_store.append({"file": m.file, "line": m.lineno, "context": ctx, "role": "match_context"})

        # Step 5: 推理与归纳
        self.log("基于收集的上下文进行推理归纳...")
        analysis = self._summarize(task, keywords, all_matches, error_matches)
        self.log("分析完成。")
        return {"status": "success", "analysis": analysis, "context": self.context_store}

    def _extract_keywords(self, task: str) -> List[str]:
        # 简单模拟：从任务中提取可能的关键词（实际由 LLM 生成）
        # 这里假设任务描述包含退款相关，直接返回预定义列表
        if "退款" in task or "refund" in task:
            return ["refund", "Refund", "processRefund", "refundPayment"]
        # 回退：提取大写开头的单词或驼峰词
        return re.findall(r'\b[A-Z][a-zA-Z0-9]*\b', task)

    def _summarize(self, task, keywords, matches, error_matches) -> str:
        # 模拟 LLM 做归纳：这里简单地用规则生成摘要
        files_found = {m.file for m in matches}
        summary_lines = [
            f"任务摘要：{task}",
            f"通过关键词 {keywords} 进行 grep 搜索，共命中 {len(matches)} 行，涉及 {len(files_found)} 个文件。",
            f"进一步搜索异常处理模式，发现 {len(error_matches)} 处相关代码。",
            "涉及的异常处理包括 try-catch、throw 及 @ExceptionHandler 注解。",
            "结论：退款逻辑主要位于 PaymentService.java 中，异常通过 try-catch 捕获并记录日志，",
            "同时全局异常处理器负责统一返回错误响应。"
        ]
        return "\n".join(summary_lines)

# ---------- 运行示例 ----------
if __name__ == "__main__":
    # 构造模拟代码库（简化版支付模块）
    fake_code = {
        "src/main/java/com/example/payment/PaymentService.java": """
public class PaymentService {
    public void processRefund(String orderId) {
        try {
            // 调用退款接口
            refundGateway.refund(orderId);
            logger.info("退款成功");
        } catch (RefundException e) {
            logger.error("退款失败", e);
            throw new RuntimeException("退款处理异常", e);
        }
    }
}
""",
        "src/main/java/com/example/payment/RefundGateway.java": """
public interface RefundGateway {
    void refund(String orderId) throws RefundException;
}
""",
        "src/main/java/com/example/payment/exception/RefundException.java": """
public class RefundException extends Exception {
    public RefundException(String message) { super(message); }
}
""",
        "src/main/java/com/example/exception/GlobalExceptionHandler.java": """
@RestControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(RefundException.class)
    public ResponseEntity<?> handleRefundException(RefundException ex) {
        return ResponseEntity.status(500).body("退款服务异常");
    }

    @ExceptionHandler(RuntimeException.class)
    public ResponseEntity<?> handleRuntime(RuntimeException ex) {
        return ResponseEntity.status(500).body("内部错误");
    }
}
""",
    }

    fs = FakeFileSystem(fake_code)
    agent = AgenticSearcher(fs)
    result = agent.run("请找出支付模块中处理退款逻辑的代码，并分析其异常处理方式")
    print("\n=== 最终分析 ===")
    print(result.get("analysis", "无结果"))

这个脚本展示了智能体如何自主识别关键词、执行多轮 Grep、动态调整搜索范围，并通过 Read 精确提取上下文，最终给出可解释的分析结果。整个过程没有依赖任何外部索引或向量库，完全由工具链驱动。

这意味着检索被降级为一个工具调用，与思考、读取、编辑融为一体，而非预处理流水线的一环。

6. 为什么 Grep 是对的问题？

面试题背后的技术红利是：确定性检索优于概率性召回，在结构化领域更有优势。

6.1 代码本身就是高度可检索的文本

代码有明确的命名规范、语法结构、文件路径，这些是天然的“索引”。Grep 可以在几毫秒内定位一个具名符号的全部引用，而 RAG 需要耗时的向量化、索引、相似度计算。

6.2 智能体的推理驱动检索

智能体不是“一个 query 返回固定上下文”的静态机器人。它可以：

• 先搜类定义
• 再搜所有引用
• 结合时间/路径过滤（grep "function" *.ts）
• 根据中间结果动态调整查询策略

这是 RAG 的“一次召回”模式做不到的。

6.3 透明、可调试

Grep 给出的结果（文件名+行号+匹配行）完全可解释，智能体可以精确决策。而向量检索的黑盒使得调试变得困难。

下面以 10 万行代码库为例，给出 Grep 与 RAG 在三个关键工程指标上的量化对比（数据基于典型中大型项目实测估算）：

对比指标	Grep（工具调用）	传统 RAG（向量检索）
检索延迟	< 10 ms（单次 grep -rn 在 SSD 上完成）	200–500 ms（向量化 + 索引查询 + 重排序）
上下文占用（每次检索）	50–300 Token（精确匹配行 + 上下文片段）	3,000–8,000 Token（Top‑K chunk 拼接，含大量无关代码）
精确召回率（符号级别）	≈ 100%（UserService.login 全量准确命中）	60–85%（语义召回可能遗漏非语义近似但直接引用的 UserService.login()）

解读：

• 延迟：Grep 的毫秒级响应使智能体可以在一次推理循环中执行多轮搜索，而 RAG 的高延迟会拖累交互体验，甚至阻塞思考流。
• 上下文占用：Grep 的精准输出让 200K token 窗口真正用于推理，而非被冗余片段填充。RAG 即使只召回 5 个 chunk，每个 800 token，也轻松占用 4,000 token，大幅压缩推理空间。
• 精确召回率：代码是符号化的，一个类名、方法名的精确匹配决定了是否能定位到关键实现。Grep 凭借逐字匹配可达 100% 召回；向量召回在语义上近似但不保证精确，常常漏掉看似“不相关”的函数调用。

这就是为什么在这一轮架构选择中，确定性检索用极小的成本换来了工程回报的质变。

7. 从 RAG 到智能体：架构范式的跃迁

更宏观地看，Claude Code 的架构反映出 AI 工程的一个范式转移：

• 第一代辅助：人写代码，AI 补全（Copilot 风格）。
• 第二代检索：AI 从文档/代码库中 RAG，回答问题。
• 第三代智能体：AI 主动使用工具（Grep、Read、Bash）与代码库交互，自主规划、执行、验证。

Grep 在这里只是冰山一角；真正变革的是上下文获取模式从“被动注入”变为“主动采集”。智能体的能力边界不再受限于向量库和 chunk 质量，而是工具集和推理深度。

下面这张图将三代进化路径可视化，直观对比每一代 AI 辅助编程的核心模式差异：

从"被动注入"到"主动采集"，不是工具链的简单替换，而是智能体认知模型的根本升级。理解这一点，才能在面试中站到系统架构师的高度。

8. 深层思考：Grep 真的能完全替代 RAG 吗？

在探讨局限性之前，先看一个更先进的混合检索架构：智能体并非在 Grep 与 RAG 之间做非此即彼的选择，而是根据查询类型动态调度最合适的检索工具。下图展示这种自适应路由的核心逻辑：

架构要点：

• 路由决策是核心：智能体不再固定走某一条流水线，而是像调度器一样判断“这个问题该用确定性匹配还是语义探索”——这与前文 Agentic Search 的多步推理一脉相承，只是工具选择范围从单一的 Grep 扩展为可编排的工具矩阵。
• 两种路径可互补：精确路径保证符号级全量命中（100% 召回），语义路径覆盖跨语言/跨概念的隐含关联。两条路径并行或串行，由智能体根据中间结果动态编排。
• 反馈闭环：如果合并后的上下文仍然不足以支撑可靠推理（比如 Grep 命中的代码过于分散、语义召回的相关性偏低），智能体会回环——调整查询词、更换搜索路径、或扩大上下文窗口——直到信息充分。这正是 Agentic Search “搜索即推理”理念的延伸。

有了这个混合调度视角，我们再来看 Grep 单独应用时的局限性，以及它和 RAG 各自的擅长域，会更加清晰。

面试时，如果能辩证地回答，会更加出彩：

8.1 Grep 的局限性

• 高维度语义查询：比如“查找所有关于用户隐私处理的代码”，如果一个变量叫 dataPrivacy，另一个叫 userConsent，Grep 很难同时命中。
• 跨语言/跨仓库语义匹配：多语言项目中同一个概念可能完全不同命名。
• 自然语言需求：对于无精确符号的模糊需求，纯 Grep 退化。

8.2 可能的融合方向

更先进的智能体可能采用混合检索（Hyde + Grep，或 code search engines (如 Sourcegraph)），由智能体根据需要选择工具：精确匹配用 Grep，概念性探索用语义搜索或 RAG。但这一切都由智能体调度，而非静态嵌入。

8.3 混合检索实战示例

下面是一个可直接运行的 Python 脚本，实现了智能体根据查询意图在 Grep（精确匹配）和 RAG（语义搜索）之间动态路由的决策逻辑。它对应前文 Mermaid 图中的“智能体路由层”——先用简单的启发式分类器判断查询是精确符号匹配还是语义概念探索，然后调用相应的模拟工具，最后合并结果供智能体推理。

#!/usr/bin/env python3
"""
混合检索路由器：智能体根据查询意图，动态选择 Grep（精确匹配）或 RAG（语义搜索）。
仅使用标准库，可直接运行。
"""

import re
from typing import List, Dict, Literal

# ----- 1. 查询意图分类器 -----
class QueryClassifier:
    """启发式分类器：判断查询是精确符号匹配还是语义模糊搜索。"""
    
    # 精确模式示例
    PRECISE_PATTERNS = [
        r'\b[A-Z][a-zA-Z0-9]*\.[a-zA-Z_][a-zA-Z0-9_]*\(\)',  # Class.method()
        r'\b[A-Z][a-zA-Z0-9]{2,}\b',                          # PascalCase 类名
        r'[a-z][a-zA-Z0-9]*\(',                               # 函数调用
        r'\bdef\s+[a-zA-Z_]+\b',                              # 函数定义
        r'\bclass\s+[A-Z]',                                   # 类定义
        r'grep\s+',                                            # 显式 grep 命令
    ]
    SEMANTIC_KEYWORDS = ['如何', '为什么', '什么', '解释', '概念', '设计', '模式', '思路', '需求']
    
    @staticmethod
    def classify(query: str) -> Literal["precise", "semantic"]:
        for pattern in QueryClassifier.PRECISE_PATTERNS:
            if re.search(pattern, query):
                return "precise"
        for kw in QueryClassifier.SEMANTIC_KEYWORDS:
            if kw in query:
                return "semantic"
        # 兜底：有大写标识符 => 精确，否则 => 语义
        if re.search(r'\b[A-Z][a-zA-Z0-9]{2,}\b', query):
            return "precise"
        return "semantic"


# ----- 2. 模拟文件系统与两种检索工具 -----
class FakeFileSystem:
    def __init__(self, files: Dict[str, str]):
        self._files = files
        self._lines = {path: content.splitlines() for path, content in files.items()}
    
    def grep(self, pattern: str) -> List[Dict]:
        """精确匹配：返回包含模式的行。"""
        results = []
        for path, lines in self._lines.items():
            for idx, line in enumerate(lines):
                if pattern in line:
                    results.append({
                        "file": path,
                        "line_num": idx + 1,
                        "content": line.strip(),
                        "match": pattern
                    })
        return results
    
    def semantic_search(self, query: str, top_k: int = 3) -> List[Dict]:
        """模拟语义搜索：用关键词重叠度模拟向量相似度。"""
        scores = {}
        query_words = set(query.lower().split())
        for path, lines in self._lines.items():
            content_words = set(' '.join(lines).lower().split())
            overlap = len(query_words & content_words)
            if overlap > 0:
                scores[path] = overlap
        sorted_files = sorted(scores, key=scores.get, reverse=True)[:top_k]
        results = []
        for file_path in sorted_files:
            snippet = '\n'.join(self._lines[file_path][:20])  # 模拟 chunk
            results.append({
                "file": file_path,
                "score": scores[file_path],
                "snippet": snippet
            })
        return results


# ----- 3. 智能体路由主函数 -----
class HybridRetriever:
    def __init__(self, fs: FakeFileSystem):
        self.fs = fs
        self.classifier = QueryClassifier()
    
    def route_and_retrieve(self, query: str) -> Dict:
        category = self.classifier.classify(query)
        print(f"[Router] 查询分类: {category}")
        
        grep_results = []
        semantic_results = []
        
        if category == "precise":
            grep_results = self.fs.grep(query)
            # 若精确无结果，降级语义搜索
            if not grep_results:
                print("[Router] 精确搜索无结果，降级到语义搜索...")
                semantic_results = self.fs.semantic_search(query)
        else:
            semantic_results = self.fs.semantic_search(query)
            # 补充关键词 Grep 作为辅助
            keywords = re.findall(r'\b[a-zA-Z_]+\b', query)
            for kw in keywords:
                grep_results.extend(self.fs.grep(kw))
        
        # 合并去重
        seen = set()
        merged = []
        for item in grep_results:
            key = (item['file'], item['line_num'])
            if key not in seen:
                seen.add(key)
                merged.append({'type': 'grep', 'source': item})
        for item in semantic_results:
            key = (item['file'], item.get('score', 0))
            if key not in seen:
                seen.add(key)
                merged.append({'type': 'semantic', 'source': item})
        
        return {"category": category, "results": merged, "count": len(merged)}


# ----- 4. 运行示例 -----
if __name__ == "__main__":
    fake_code = {
        "src/user_service.py": """
class UserService:
    def register(self, username, password):
        # 注册逻辑
        pass
    def login(self, username, password):
        # 登录逻辑
        if self.verify(username, password):
            return True
        return False
    def verify(self, username, password):
        # 验证用户凭据
        pass
""",
        "src/auth_utils.py": """
def hash_password(password):
    import hashlib
    return hashlib.sha256(password.encode()).hexdigest()

def check_rate_limit(user_id):
    pass
""",
        "docs/design.md": """
## 用户认证设计
系统采用 SHA-256 哈希存储密码。登录流程通过 UserService.login() 处理。
会话管理使用 JWT，过期时间可配置。
"""
    }
    
    fs = FakeFileSystem(fake_code)
    hybrid = HybridRetriever(fs)
    
    # 示例 1：精确查询
    print("===== 测试 1: 精确符号查询 =====")
    res1 = hybrid.route_and_retrieve("UserService.login()")
    print(f"检索到 {res1['count']} 条结果:")
    for r in res1['results']:
        print(f"  [{r['type']}] {r['source']}")
    
    # 示例 2：语义查询
    print("\n===== 测试 2: 语义概念查询 =====")
    res2 = hybrid.route_and_retrieve("密码哈希处理和认证机制")
    print(f"检索到 {res2['count']} 条结果:")
    for r in res2['results']:
        print(f"  [{r['type']}] {r['source']}")

代码要点：

• 分类器（QueryClassifier）基于正则和关键词判断查询意图，可在生产环境中替换为 LLM 驱动的意图识别。
• Grep 工具（FakeFileSystem.grep）精确匹配字符串，返回文件名、行号和内容，对应前文的确定性检索。
• 语义搜索（FakeFileSystem.semantic_search）用关键词重叠度模拟向量检索，实际系统中可接入 Embedding 模型和向量数据库。
• 路由函数（HybridRetriever.route_and_retrieve）实现了分类→调用→合并的完整流水线，并内建了降级策略（精确无结果时自动切换语义）和补充策略（语义搜索时仍用 Grep 提取精确符号），最大化召回率和信息密度。

这个示例完整展示了前文 Mermaid 混合检索架构的落地逻辑：智能体作为调度中心，根据查询特征动态编排 Grep 与 RAG，最终合并结果驱动推理。

9. 实战回答框架（面试参考）

如果你在面试中遇到这个问题，可以按以下结构回答：

• 澄清问题：“您指的是 Claude Code 用 Grep 工具代替传统的 RAG 流水线吗？这背后是智能体架构的上下文管理变化。”
• 架构描述：“Claude Code 是工具增强型智能体，拥有 Grep/Read/Write 等系统工具，它通过主动检索精确上下文，而不是预先注入。”
• 工程优势：“代码是结构化文本，Grep 确定性高、延迟极低、不浪费上下文预算，且支持智能体多步推理驱动搜索。”
• 辩证补充：“当然，Grep 不处理语义深度查询，未来可能是智能体调度混合检索，但核心是让 Agent 自主决定何时、如何获取上下文。”

这样回答既展示了深度，又体现了系统设计的权衡思维。

将上述回答框架提炼为一张结构图，方便面试前快速回顾：

记住这条主线：你不是在回答"哪个工具更好"，而是在展示你对智能体架构中上下文获取范式升级的深刻理解。

10. 总结

Claude Code 并没有简单地“放弃 RAG 改用 Grep”，而是通过智能体架构重新定义了上下文获取流程。它把检索变成一个可编排、可验证的工具，让模型像高级工程师一样在代码库中导航与思考。这一变化标志着大模型应用从“被动回答者”向“主动执行者”的深刻进化。

理解这一点，你就抓住了下一代 AI 工程智能体的核心逻辑。