上下文工程：检索策略与搜索技术详解

HomyeeKing

Sun Apr 19 202615min

在构建 AI Agent 系统时，如何高效获取和注入上下文是决定性能和成本的关键因素。本文将详细解析三种核心的上下文检索策略，以及三种不同的搜索技术（AST、Grep、RAG）的适用场景。

第一部分：上下文获取策略

根据 Claude Mem 的最佳实践，上下文获取有三种主要策略，每种都有其特定的适用场景。

1. Pre-Inference Retrieval（预推理检索 / 传统 RAG）

核心思想：在模型推理前，通过 embedding-based 检索预先获取相关上下文。

用户查询 → 向量化 → 向量数据库检索 → Top-K 结果 → 注入上下文 → 模型推理

适用场景：

静态内容：不会随交互变化的知识库（如产品文档、技术规范）
大规模知识库：需要访问数万甚至数百万条记录
需要精确溯源：必须标注信息来源（如医疗、法律场景）
多租户隔离：不同用户/客户的数据需要严格隔离

优点：

检索成本低，向量查询速度快
可以处理海量数据，不受上下文窗口限制
支持精确溯源，每个结果附带元数据

缺点：

只能获取静态数据，无法动态探索
检索质量取决于 embedding 质量和分块策略
可能遗漏与查询语义相关但 embedding 不匹配的内容

2. Just-In-Time Context（动态上下文 / 运行时加载）

核心思想：保持轻量级标识符（文件路径、查询、链接），在运行时动态加载数据。

用户查询 → 返回标识符列表 → 按需读取详细内容 → 动态构建上下文 → 模型推理

适用场景：

代码库探索：需要递归探索文件结构、理解依赖关系
动态决策：根据中间结果决定下一步需要哪些信息
Agent 工作流：AI Agent 需要自主选择何时获取哪些数据
代码仓库分析：先找到文件，再读取内容，再分析依赖

优点：

避免上下文过载，只加载必要信息
支持渐进式信息揭示，按需深入
允许 Agent 自主决策获取哪些上下文

缺点：

需要多次工具调用，延迟较高
依赖 Agent 的决策质量
可能因多次往返而增加总 token 消耗

3. Hybrid Strategy（混合策略）

核心思想：结合预检索和动态加载，先获取一部分关键上下文，再根据需要进行探索。

用户查询 → 预检索关键信息 → 模型初步分析 → 按需动态加载 → 综合推理

适用场景：

复杂代码审查：先检索关键函数，再动态探索调用链
多步骤分析：需要既有知识库信息，又有代码仓库细节
平衡效率与深度：既想快速启动，又需要深度探索

最佳实践：

先简单后复杂：先用最简单的方法，不够再升级
分阶段加载：关键信息预加载，细节按需获取
智能缓存：已加载的内容缓存复用，避免重复读取

第二部分：向量数据库 vs 模型智能

在构建 AI 记忆系统时，一个关键决策是：**用向量数据库做外部检索，还是依赖 LLM 自带的上下文理解能力？**两者不是互斥的，但理解它们的边界能帮你做出更优的架构选择。

核心区别

维度	向量数据库 (Vector DB)	模型智能 (Model Intelligence)
知识来源	外部文档、历史记录	训练数据 + 当前上下文
更新方式	实时增删改查	无法修改（除非重新训练）
成本	查询成本低	长上下文成本高
准确度	精确匹配，可溯源	可能幻觉，不可溯源
灵活性	结构化、可控	黑盒、涌现能力
时效性	实时数据	训练截止知识

向量数据库适合的场景

1. 大量外部知识

场景: 客服机器人需要查询 10 万份产品文档
问题: 模型上下文装不下，训练数据不包含最新产品

方案: 向量数据库 + RAG
- 文档向量化存储
- 查询时检索 Top-5 相关段落
- 注入上下文生成回答

2. 需要精确溯源

场景: 医疗诊断助手引用研究论文
要求: 必须告知用户信息来源

方案: 向量数据库
- 每个向量附带 source 元数据
- 检索时返回文档标题、页码、段落
- 回答中标注引用

3. 实时变化的数据

场景: 股票价格、天气、新闻
特点: 每分钟都在变

方案: 向量数据库
- 新数据实时向量化入库
- 旧数据 TTL 过期自动删除
- 查询总是最新信息

4. 多租户隔离

场景: SaaS 服务，每个客户有自己的知识库
要求: 数据不能互相泄露

方案: 向量数据库
- 按 tenant_id 过滤
- 物理或逻辑隔离
- 权限控制精确到集合

模型智能适合的场景

1. 推理和联想

场景: "这道题和昨天的类似，但条件变了"
需求: 理解相似性，灵活迁移解法

优势: 模型智能
- 不需要显式存储"昨天的问题"
- 从上下文中理解模式
- 自动调整推理策略

2. 创意生成

场景: 写小说、头脑风暴、设计文案
需求: 发散思维，不拘泥于已有资料

优势: 模型智能
- 不依赖外部检索
- 涌现创意能力
- 长上下文保持连贯性

3. 少量但复杂的上下文

场景: 代码审查，需要理解整个文件结构
数据量: 几千行代码，不算大但关系复杂

优势: 模型智能
- 一次性加载到上下文
- 理解代码间的调用关系
- 不需要分块检索

4. 快速原型

场景: 验证一个想法，快速上线
资源: 没有运维向量数据库的人力

优势: 模型智能
- 零基础设施
- 直接调 API
- 后期再迁移到 RAG

第三部分：搜索技术对比

在代码库和知识库搜索方面，有三种主要技术：AST 搜索（Smart Explore）、常规搜索（Grep/Glob/Read）、RAG。根据 Claude Mem 的 benchmark，它们的性能差异显著。

性能对比数据

指标	AST 搜索 (Smart Explore)	常规搜索 (Glob/Grep/Read)	RAG
Token 消耗	~14,200	~252,500	~5,000-10,000
相对成本	1x (基准)	17.8x	0.35x
响应时间	< 2 秒	5-66 秒	< 1 秒
完整性	5/5 完整源码	4/5 (最长方法被截断)	依赖分块质量
适用精度	精确符号匹配	文本模式匹配	语义相似度

1. AST 搜索（Smart Explore）

技术原理：使用 tree-sitter AST 解析，提供结构化代码导航，直接定位函数、类、方法等符号。

// 示例：使用 Smart Search 查找函数定义
const result = await smartSearch({
  query: "function handleUserLogin",
  path: "src/auth"
});
// 返回精确的函数定义位置和完整源码

适用场景：

✅ 精确定位：你知道要找什么（具体的函数名、类名）
✅ 获取源码：需要完整的源代码，而非解释说明
✅ 符号导航：理解代码结构、继承关系、调用链
✅ 成本敏感：希望 token 消耗可控、响应快速

不适合场景：

❌ 开放性问题（"这个模块是做什么的？"）
❌ 跨文件概念理解（"项目中如何处理错误？"）
❌ 需要综合多文件信息的问题

使用建议：

✓ "找到 AuthService 类的 login 方法"
✓ "获取 handleError 函数的完整实现"
✓ "列出 src/utils 目录下所有导出的函数"
✗ "解释认证流程的设计思路"
✗ "项目中错误处理的最佳实践是什么"

2. 常规搜索（Glob + Grep + Read）

技术原理：通过文件模式匹配（Glob）、文本搜索（Grep）和文件读取（Read）组合探索代码库。

// 示例：探索性查询
const files = await glob("**/*.service.ts");
const matches = await grep("async.*save", files);
const content = await read(matches);
// Agent 综合分析后给出答案

适用场景：

✅ 探索性查询：你不确定要找什么，需要 Agent 帮你分析
✅ 跨文件理解：需要综合多个文件理解概念或模式
✅ ** onboard 新代码库**：快速了解项目结构和设计模式
✅ 生成总结："这段代码的功能是什么"、"数据流如何工作"

不适合场景：

❌ 已知确切符号位置的精确查找（AST 更高效）
❌ 成本敏感的大规模代码库扫描
❌ 需要快速响应的交互式场景

使用建议：

✓ "这个项目的错误处理模式是怎样的？"
✓ "解释认证模块的数据流"
✓ "找出所有使用 Redis 的地方"
✗ "getUserById 函数在哪里定义"
✗ "读取 src/auth.ts 第 42 行的函数"

3. RAG（检索增强生成）

技术原理：将文档向量化存储，查询时通过语义相似度检索最相关的文本块。

# 示例：RAG 检索流程
query_embedding = embed("如何处理用户认证？")
candidates = vector_db.search(query_embedding, top_k=5)
context = rerank(candidates, query)[:3]  # 重排序后取 Top-3
response = llm.generate(query, context)

适用场景：

✅ 文档问答：基于外部文档回答问题（产品手册、API 文档）
✅ 大量知识：数据量超过上下文窗口限制（>100K tokens）
✅ 需要溯源：必须标注信息来源（引用文档、页码、段落）
✅ 实时更新：知识库频繁变化（新闻、股价、日志）
✅ 多租户：不同用户访问不同数据子集

不适合场景：

❌ 代码结构导航（AST 更精确）
❌ 探索性分析（需要 Agent 动态决策）
❌ 小数据集（<1000 条，直接加载更高效）

使用建议：

✓ "根据产品文档，如何配置 SSO？"
✓ "最新的 API 变更有哪些？"
✓ "查询文档中关于错误码的说明"
✗ "找到 authenticate 函数的实现"
✗ "解释这段代码的逻辑"

第三部分：决策框架

搜索技术选择指南

开始
  ↓
需要精确符号定位（函数/类/方法）？
  ↓ 是                              ↓ 否
AST 搜索                         需要跨文件综合分析？
  ↓ 是                              ↓ 否
常规搜索（Explore Agent）        知识库 > 1万条 或 需要溯源？
                                    ↓ 是
                                    RAG
                                    ↓ 否
                                    直接用 LLM 上下文

上下文策略选择指南

开始
  ↓
内容是静态的还是动态的？
  ↓ 静态                          ↓ 动态（代码库、需要探索）
数据量 > 上下文窗口？              Just-In-Time Context
  ↓ 是                              ↓
Pre-Inference RAG              Agent 需要自主选择？
  ↓ 否                              ↓ 是
直接用 LLM 上下文                Hybrid Strategy

第四部分：混合工作流最佳实践

推荐工作流：智能搜索 + Agent 探索

最佳实践：先用 Smart Explore 进行快速发现，仅在需要深度分析时升级到 Explore Agent。

用户查询: "修复登录模块的 bug"
    ↓
Step 1: Smart Explore (AST)
  - 快速定位 login、authenticate 函数
  - Token 成本: ~14,200 (17.8x 节省)
    ↓
Step 2: 初步分析
  - 判断是否需要跨文件理解
    ↓
Step 3: 按需升级 (如需要)
  - 使用 Explore Agent 进行深度分析
  - 理解调用链、数据流
    ↓
Step 4: 实施修复

实际收益：

查找函数：14x token 节省
大文件导航：8x token 节省
响应时间：从 5-66 秒降至 < 2 秒

RAG + 关键词搜索混合

对于文档检索，推荐三层过滤：

┌─────────────────────────────────────────┐
│  Step 1: 快速过滤 (Grep/关键词)          │
│  - 找精确匹配（文件名、ID）              │
│  - 低成本，快速排除无关数据              │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────────────────────────────┐
│  Step 2: 向量语义检索                    │
│  - 理解查询意图                          │
│  - 召回语义相关但关键词不同的内容        │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────────────────────────────┐
│  Step 3: 重排序 (Cross-encoder)          │
│  - 精确计算查询与候选的相关性            │
│  - 选出最优的 Top-K                      │
└─────────────────┬───────────────────────┘
                  ↓
┌─────────────────────────────────────────┐
│  Step 4: 注入 LLM 上下文                 │
│  - 模型理解检索结果                      │
│  - 生成最终回答                          │
└─────────────────────────────────────────┘

第五部分：常见误区与真相

误区	真相
"AST 搜索能取代所有搜索"	AST 适合精确查找，不适合探索性分析，两者互补
"RAG 能消除幻觉"	只能减少，不能消除。模型仍会编造检索内容之外的信息
"大上下文窗口不需要 RAG"	100K 上下文成本高、速度慢，且模型会"遗忘"中间内容
"向量检索一定比关键词好"	精确查找（如 ID、手机号）关键词更快更准确
"一个方案走天下"	不同场景应该用不同策略，灵活组合才是最佳

总结

黄金法则

场景	推荐技术
精确代码定位	AST 搜索 (Smart Explore)
代码探索/Onboarding	常规搜索 (Explore Agent)
大量文档问答	RAG
静态知识 + 实时更新	Pre-Inference RAG
代码库动态探索	Just-In-Time Context
复杂多步分析	Hybrid Strategy

性能优化要点

分层检索：先用低成本方法过滤，再升级
缓存复用：已读取的内容避免重复获取
按需加载：不要一次性加载所有可能需要的上下文
智能降级：如果 AST 不够，再启用 Explore Agent

通过合理选择上下文获取策略和搜索技术，可以实现 17.8x 的 token 成本节省 和 10x+ 的响应速度提升，同时保持甚至提高回答质量。

参考链接：

←Jobs Over Skills Hermes Agent：会自我进化的 AI Agent→

上下文工程：检索策略与搜索技术详解

第一部分：上下文获取策略 #

1. Pre-Inference Retrieval（预推理检索 / 传统 RAG） #

2. Just-In-Time Context（动态上下文 / 运行时加载） #

3. Hybrid Strategy（混合策略） #

第二部分：向量数据库 vs 模型智能 #

核心区别 #

向量数据库适合的场景 #

1. 大量外部知识 #

2. 需要精确溯源 #

3. 实时变化的数据 #

4. 多租户隔离 #

模型智能适合的场景 #

1. 推理和联想 #

2. 创意生成 #

3. 少量但复杂的上下文 #

4. 快速原型 #

第三部分：搜索技术对比 #

性能对比数据 #

1. AST 搜索（Smart Explore） #

2. 常规搜索（Glob + Grep + Read） #

3. RAG（检索增强生成） #

第三部分：决策框架 #

搜索技术选择指南 #

上下文策略选择指南 #

第四部分：混合工作流最佳实践 #

推荐工作流：智能搜索 + Agent 探索 #

RAG + 关键词搜索混合 #

第五部分：常见误区与真相 #

总结 #

黄金法则 #

性能优化要点 #

第一部分：上下文获取策略

1. Pre-Inference Retrieval（预推理检索 / 传统 RAG）

2. Just-In-Time Context（动态上下文 / 运行时加载）

3. Hybrid Strategy（混合策略）

第二部分：向量数据库 vs 模型智能

核心区别

向量数据库适合的场景

1. 大量外部知识

2. 需要精确溯源

3. 实时变化的数据

4. 多租户隔离

模型智能适合的场景

1. 推理和联想

2. 创意生成

3. 少量但复杂的上下文

4. 快速原型

第三部分：搜索技术对比

性能对比数据

1. AST 搜索（Smart Explore）

2. 常规搜索（Glob + Grep + Read）

3. RAG（检索增强生成）

第三部分：决策框架

搜索技术选择指南

上下文策略选择指南

第四部分：混合工作流最佳实践

推荐工作流：智能搜索 + Agent 探索

RAG + 关键词搜索混合

第五部分：常见误区与真相

总结

黄金法则

性能优化要点