"早期版本的 Claude Code 采用了 RAG + 本地向量数据库的方案，但我们很快发现智能体搜索（Agentic search）的效果通常更好。" —— Boris Cherny, Claude Code 之父
序：正确的努力，错误的方向
2025 年底，我的知识库出了问题。
2400 多份文档，涵盖产品文档、技术笔记、内部 Wiki。问题不是"存不下"，而是"找不到"。
用户问"MCP 怎么配置"，系统返回的是 CNB 平台的文档，而不是 CodeBuddy 的配置指南。明明答案就在库里，但向量检索就是找不准。
于是我做了所有"正确"的事：分析瓶颈、设计管道、规划迭代。五步优化方案，预估 3-5 天实施，复杂但看起来很"专业"。
然后，Boris Cherny 发了一条推文。
这条推文没有指出技术错误，却让我意识到一件事——复杂度不是价值，是成本。
第一章：迷雾中的正确——RAG 的诱惑
问题的表象
先说 RAG 是什么。RAG（Retrieval-Augmented Generation）是一种让 AI 更聪明的技术：先用向量检索找到相关文档，再让大模型基于这些文档回答问题。
听起来很合理对吧？文档太多，AI 不可能全部读完，那就先筛选再阅读。
我的知识库用的就是这套方案。但问题来了：
向量相似度不等于语义相关性。
"MCP 配置"和"CNB 配置"在向量空间里可能很近（都是"配置"），但用户要的是 CodeBuddy 的 MCP，不是 CNB 平台的配置。向量检索是个黑盒，它不理解"用户到底在问什么"。
我的解决方案
作为工程师，遇到问题的本能反应是"优化它"。于是我设计了一套五步管道：
用户提问 → 意图识别 → Query 增强 → 向量检索 → Path 过滤 → LLM Rerank → 返回结果
第一步：意图识别。 判断用户在问哪个产品——CodeBuddy 还是 CNB？
第二步：Query 增强。 把"MCP 怎么配"扩展成"MCP 配置 Claude Code settings.json"，增加检索命中率。
第三步：向量检索。 从 2400 份文档中召回 Top 50。
第四步：Path 过滤。 根据意图过滤路径，只保留 codebuddy/ 目录下的文档。
第五步：LLM Rerank。 让大模型对 Top 50 重新排序，选出最相关的 5 份。
流程图画得很漂亮，每一步都有理有据。预估 3-5 天实施，复杂但"正确"。
没说出口的担忧
但我心里有个声音一直在问：我是不是在给一个有结构性缺陷的系统打补丁？
向量检索的核心假设是"语义相近的文本在向量空间里距离也近"。但这个假设并不总是成立——尤其在专业领域，同一个词在不同上下文里意思完全不同。
我能优化管道，但优化不了这个根本假设。
带着这个疑问，我继续推进方案。直到看到那条推文。
第二章：降维打击——Boris 的一条推文
推翻认知的 280 个字
2026 年 1 月，Claude Code 核心开发者 Boris Cherny 在 X 上分享了一条设计经验，直接击中了我：
"早期版本的 Claude Code 采用了 RAG + 本地向量数据库的方案，但我们很快发现智能体搜索（agentic search）的效果通常更好。这种方式不仅更简洁，还避免了 RAG 在安全、隐私、时效性和可靠性方面存在的固有问题。"
等等，Claude Code 团队放弃了 RAG？
他们有全世界最强的 AI 能力，有一流的工程团队，如果 RAG 真的是最优解，没人比他们更有资源把它做好。但他们选择了另一条路。
RAG 的四个固有问题
Boris 在后续的讨论中解释了为什么：
1. 安全问题。 文档需要上传到向量数据库，这意味着敏感数据离开了你的控制。
2. 隐私风险。 向量嵌入（embedding）在理论上可以被逆向还原出原始文本。你以为数据被"向量化"后就安全了？不一定。
3. 时效性困境。 每次文档更新，都需要重新计算向量并更新索引。知识库越大，这个成本越高。
4. 可靠性黑盒。 为什么这份文档排在前面？向量相似度无法解释。当检索出错时，你很难定位问题。
这四个问题不是实现细节，是 RAG 的结构性缺陷——优化管道解决不了。
Agentic Search：让 AI 自己找
那 Claude Code 用的是什么方案？
Agentic Search（智能体搜索）。
核心思路极其简单：不要替 AI 做决定，让它自己读、自己想、自己选。
具体来说：
给 Claude 一份索引文件（包含所有文档的标题和摘要） Claude 根据用户问题，自己判断哪些文档可能相关 Claude 主动读取它认为需要的文档 Claude 基于读到的内容回答问题
没有向量计算，没有相似度排序，没有五步管道。就是让 AI 像人一样思考和查找。
第三章：回到原点——最简单的方案
4 小时 vs 3-5 天
看完 Boris 的思路，我重新审视了自己的方案。
RAG 方案：5 步管道，预估 3-5 天实施，后续还需要维护向量索引。
Agentic Search 方案：一份 JSON 索引 + 让 Claude 自己搜，预估 4 小时实施，几乎零维护成本。
对比一下：
简单方案不是偷懒，是更高级的工程判断。
JSON 索引长什么样
核心就是一个 50KB 左右的 JSON 文件：
{
"documents": [
{
"path": "codebuddy/mcp-configuration.md",
"title": "MCP 配置指南",
"summary": "如何在 Claude Code 中配置 Model Context Protocol",
"tags": ["mcp", "configuration", "claude-code"]
},
{
"path": "cnb-docs/getting-started.md",
"title": "CNB 平台入门",
"summary": "CNB 云开发平台的基础使用教程",
"tags": ["cnb", "cloud", "tutorial"]
}
// ... 更多文档
]
}
Claude 读到这份索引后，会根据用户问题判断："MCP 配置？应该是 codebuddy/mcp-configuration.md 这份。"然后它会主动请求读取完整文档。
整个过程，Claude 可以解释为什么选这份文档。 如果选错了，我能看到推理过程，知道问题出在哪。
为什么我之前没想到
说实话，Agentic Search 的思路并不复杂。为什么我一开始就奔着 RAG 去了？
因为惯性思维。
RAG 是行业标准方案，大家都在用，论文里写的也是这个。当你遇到"检索不准"的问题，本能反应就是"优化检索"，而不是"换个思路"。
但 Boris 提醒了我一件事：Claude 不是需要被喂数据的 API。它是能自己读文件、自己思考的智能体。
既然如此，为什么要用向量相似度替它做判断？
第四章：分库——2400 份文档怎么办
2400 份文档的挑战
Agentic Search 有一个前提：Claude 能读完索引。
如果索引太大（比如包含 10 万份文档），Claude 的上下文窗口装不下，这条路就走不通了。
我有 2400 份文档，全放一个索引里大概需要 500KB。这个体积对 Claude 来说有点吃力——不是读不了，是效率会下降。
怎么办？
分库：让大问题变成小问题
答案是分库。
2400 份文档听起来很多，但仔细看，它们天然分成了几个领域：
knowledge-hub (~2400 docs)
↓ 按领域分库
├── codebuddy/ (~50 份) → 10KB 索引
├── cnb-docs/ (~200 份) → 40KB 索引
├── ai-coding/ (~100 份) → 20KB 索引
└── internal/ (~500 份) → 100KB 索引
每个库的索引都在 100KB 以内，Claude 轻松加载。
两步流程
分库后，查询流程变成：
第一步：确定目标库。 用户问"MCP 怎么配置"——这是 CodeBuddy 的问题，去 codebuddy 库。
第二步：在目标库里搜索。 读 codebuddy 的索引，找到 mcp-configuration.md，读取完整文档。
这不就是我之前 RAG 方案里的"意图识别"吗？
对，但有本质区别。RAG 的意图识别是为了过滤向量检索结果，是补丁。Agentic Search 的意图识别是为了选择正确的索引文件，是设计。
写进 CLAUDE.md
最后，我把分库策略写进了项目的 CLAUDE.md（Claude 的配置文件）：
## 知识库检索
本项目包含多个知识库，按领域分类：
| 库 | 路径 | 适用场景 |
|---|---|---|
| CodeBuddy | knowledge/codebuddy/ | AI 编程助手相关 |
| CNB Docs | knowledge/cnb-docs/ | 云开发平台相关 |
| AI Coding | knowledge/ai-coding/ | AI 编程实践相关 |
查询时：
1. 先根据问题判断目标库
2. 读取对应库的 index.json
3. 根据索引匹配相关文档
4. 读取完整文档后回答
Claude 每次启动都会读这份配置，自然就知道该怎么检索了。
第五章：更大的图景——从技术选型到工程哲学
不只是技术选型
回过头看，RAG vs Agentic Search 不只是一个技术选型问题。
旧范式的假设是：信息太多，需要系统帮你筛选。 所以我建向量索引、做相似度排序、设计复杂的检索管道。
新范式的假设是：AI 足够聪明，可以自己判断。 所以我只需要提供结构化的索引，让 AI 自己去读、去想、去选。
这不是 Boris 第一次表达这种思路。在他分享的 Claude Code 开发经验里，有几条原则反复出现：
"朴素配置"——不要迷信复杂系统，开箱即用往往最好。我的五步 RAG 管道，每一步都有理由，但合在一起就是过度工程。
"工具使用者心态"——Claude 不是被调用的 API，是能调用工具的执行主体。RAG 把 Claude 当成"需要被喂数据的模型"，Agentic Search 把它当成"能自己找数据的智能体"。
"验证闭环"——没有反馈循环，AI 输出永远不可靠。向量检索是黑盒，出错时你不知道为什么。Agentic Search 里，Claude 会解释它的推理过程。
知识库的真正价值
说到底，知识库的价值不在于"存了多少"，而在于"能用起来"。
传统知识库的悲剧是：存了 → 搜不到 → 遗忘 → 重新创建 → 存了 → 搜不到...
新范式的知识库：存了 → 随时对话 → 用的时候深入 → 持续积累。
这不是科幻，这是 Claude Code 每天在做的事情。它读你的代码库，理解你的项目结构，在你需要时提供精准的帮助。
我的知识库应该也能做到这一点。
尾声：信任 AI 的判断
写完这篇文章，我最大的感触是：
RAG 背后的假设是"不信任 AI 能找到正确答案"，所以用向量相似度替它做决定。
Agentic Search 背后的假设是"AI 足够聪明"，让它自己读、自己想、自己选。
这种信任不是盲目的。Claude 不是三年前的 GPT-3，它有强大的推理能力，能理解上下文，能解释自己的判断。当工具足够强大时，我的工程设计也应该跟着进化。
三个月的 RAG 优化方案，4 小时的 Agentic Search 实现。
复杂度不是价值，是成本。
下次遇到问题，在设计复杂系统之前，也许应该先问一句：能不能让 AI 自己解决？
