今天接着聊AI智能知识库的话题。传统RAG模式是否还是最佳选择？相信不少朋友在实际使用中都有过类似的困惑：同一套大模型，为什么基于RAG搭建的知识库和通过AI辅助编程工具写出来的文章，在质量上有明显差异？之前我们聊过通过Cursor+Claude进行AI辅助写作的话题，也一直在思考这个关键问题——底层模型明明相同，为何输出质量差别这么大？

其实核心原因并不复杂：AI辅助写作走的不是RAG增强检索和向量匹配这条路。但它具体的实现逻辑到底是什么？带着这个疑问，我们干脆让大模型自己来回答这个问题。

为了说清楚这件事，先还原一下具体的测试场景。我们有2000篇左右的个人博客文章，已经全部转换为Markdown格式的源代码文件。现在要基于这些历史文章来回答问题，比如“如何搭建自己的知识体系？”。这里有两种实现方案：

方案一：将历史文章构建一个RAG知识库，基于特定提示语进行知识库问答，底层采用Claude Sonnet 4.0。
方案二：将文章构建为一个源代码项目，启动Claude Code CLI进入目录，同样用提示语让AI回答问题。

测试结果很明确：方案二的输出质量明显优于方案一。那么问题来了——方案二的实现思路和RAG一样吗？如果不一样，它的内在逻辑是什么？为什么能更准确地回答问题？

核心差异：它们不是同一种技术路线

方案二并不是传统RAG思路。虽然表面上都是“基于已有文档回答问题”，但底层实现逻辑完全不同。

方案一：RAG的实现逻辑

RAG（检索增强生成）的工作流程如下：

• 文档预处理：将2000篇文章切分成chunks（通常几百字一段）
• 向量化索引：每个chunk转换为embedding向量，存入向量数据库
• 查询检索：你的问题也转成向量，通过相似度计算找出最相关的top-k个chunks
• 上下文注入：把检索到的chunks拼接成prompt，连同问题一起发给大模型
• 生成答案：模型基于有限的检索片段生成回答

但RAG方式的局限性也很明显：

• 依赖语义相似度检索，可能漏掉关键信息
• Chunks切分会破坏文章的完整逻辑
• 受限于context window，只能传入部分检索结果
• 无法全局理解你的写作风格和知识体系

方案二：Claude Code的实现逻辑

Claude Code采用的是Agentic coding模式，这是完全不同的范式。

1. 完整文件系统访问

Claude Code可以遍历整个项目目录结构，读取任意markdown文件的完整内容，理解文件间的组织关系，根据需要动态决定读取哪些文件。这就像一个人可以随时翻阅你的“博客书架”，而不是只能看预先挑出来的几页纸。

2. 主动的多轮信息收集

工作流程是：先浏览目录结构，了解文章分类和主题分布；根据问题识别相关关键词；打开可能相关的文章，快速扫描确认相关性；深度阅读确认相关的文章全文；交叉对比多篇文章，提取共同观点；最后整合信息，形成结构化回答。这是一个迭代推理过程，不是一次性检索。

3. 超大上下文窗口的优势

Claude Sonnet 4.5的context window是200K tokens（约15万字），这意味着可以一次性加载几十篇完整文章，保留文章的完整语境和逻辑链，进行全文级的语义理解，捕捉跨文章的论述模式。

4. 工具使用能力

Claude Code不只是“读文件+生成”，它可以使用grep搜索关键词在哪些文件中间出现，用find命令按文件名模式筛选，编写临时脚本做统计分析，动态调整搜索策略。

为什么方案二效果更好？

信息完整性方面：RAG可能只检索到5-10个相关片段，而方案二可以读取所有相关文章全文，不遗漏任何关键观点。

上下文连贯性方面：RAG检索到的chunks来自不同文章，逻辑可能跳跃；方案二可以完整阅读每篇文章，理解前后文关系。

风格一致性方面：RAG只看到碎片化文本，难以捕捉写作风格；方案二可以对比多篇完整文章，学习表达习惯、用词偏好和论述结构。

智能决策方面：RAG的检索策略是固定的（embedding相似度）；方案二可以根据初步发现调整搜索策略，比如发现有个“方法论”系列文章后，主动去读这个系列。

逻辑推理能力方面：RAG主要是“匹配+生成”；方案二可以进行复杂推理，比如发现“作者在A文章提到X，在B文章提到Y，X和Y虽然表述不同但本质是同一个观点”。

类比理解

RAG模式像是：你雇了一个助理，他预先做了读书笔记，当你问问题时，他快速翻笔记找相关条目，然后根据笔记回答你。

Claude Code模式像是：你雇了一个真正读过你所有文章的研究员，他可以随时重新查阅原文，交叉验证，甚至发现你自己都没意识到的观点关联。

技术建议

如果要继续优化，可以考虑结合两种方式的优点：第一轮用RAG快速定位，找出最相关的20-30篇文章；第二轮用Claude Code深度分析，只让它精读这20-30篇，既保证覆盖面，又不浪费token。或者直接用Claude Code，但加入结构化搜索指令。

因此可以确认，基于AI辅助编程工具进行知识问答的做法不是RAG模式，而是Agentic Reasoning + Full File Access，这才是效果更好的根本原因。

那么接下来自然要追问：这种Agentic Full-text Retrieval模式和Agentic RAG又有什么区别？

Agentic RAG的处理模式

传统RAG：问题 → 向量检索 → 生成答案
Agentic RAG：问题 → Agent决策 → 多轮检索策略 → 重排序 → 生成答案

核心特征是：仍然基于向量检索，但用agent让检索过程更智能。

而方案二实际上：有agent能力（多轮决策、工具使用），但没有向量检索（不需要embedding、向量数据库），直接访问原始文件系统，基于全文搜索、文件遍历、内容理解。这更像是“Code-based Knowledge Retrieval”或“File-native QA”。

根据技术特征，可以称为：Agentic File System QA（强调自主决策能力和直接操作文件系统）、Code-native Knowledge Retrieval（强调通过代码工具直接访问源文件）、或者Full-context Document Processing（强调访问完整文档上下文）。如果非要带“RAG”，可以叫“File-native Agentic RAG”。

为什么区分很重要？在技术交流中，如果说“Agentic RAG”，别人默认有向量数据库、在用embedding模型、优化方向是检索策略和重排序。但实际架构是：Markdown Files → Claude Code Agent → 文件系统API → 全文读取 → 生成答案，这和传统RAG的技术栈完全不同。

传统RAG像图书馆的卡片索引系统，先查索引找相关卡片。
Agentic RAG像有个聪明馆员帮你查索引，能优化检索策略。
方案二像直接进入图书馆书架，随便翻阅任何书的任何页。

以“如何搭建知识体系”的问题为例。假设2000篇博客中，关于“知识体系”的内容分散在不同文章里：

传统RAG的结果：检索到5个chunks，内容零散，缺少系统性，没有提到完整方法论，漏掉了深入思考。

Agentic RAG的处理模式：进行多轮检索，从发现相关文章到读取完整大纲，再到检索关键词和工具名，最后找到实践案例。生成答案时系统性强、逻辑完整，找到了最核心的方法论文章，结合理论和实践，风格符合写作习惯。

GraphRAG能否达到同样效果？

再看GraphRAG。它的核心机制是：文档 → 实体抽取 → 关系抽取 → 构建知识图谱 → 图推理 → 生成答案。关键创新在于把文本转换为结构化的实体-关系图。

以“如何搭建知识体系”为例：从2000篇文章中抽取实体和关系，形成一个巨大的网络，节点是实体，边是关系。图查询时找到“知识体系”节点，沿着“包含”“需要”“使用”等边扩展，发现更多相关节点。GraphRAG还会把图谱分成不同社区，进行多层次总结。

GraphRAG的独特优势在于：发现隐含关联（传统RAG可能检索不到的关联），多跳推理（给出完整的因果链），全局视角（通过社区总结功能体现整体探索）。这种全局视角是传统RAG做不到的。

最后简单总结

传统RAG：像一个只会查字典的学生，查到什么用什么。
Agentic RAG：像一个会研究的学者，知道如何全面调研、交叉验证、系统整理。
方案二（Claude Code）：像一个能直接翻阅所有书籍的研究助理，不受检索技术限制，可以真正理解你的知识体系。

对于基于个人博客回答问题并保持风格一致的需求，方案二 > Agentic RAG > 传统RAG。因为方案二无需向量化，直接访问完整文档；Agentic RAG虽然有Agent能力，但仍受限于chunks；传统RAG最受限，只能被动检索片段。

当然，传统RAG模式并非完全没有用处。如果文档难以像个人知识库一样进行Markdown方式的结构化，文件大小特别大，同时对检索速度要求高，那么传统RAG仍然是获取知识答案的可行方式。另外值得注意的是，Agentic Full-text Retrieval模式每次回答的耗时都相当长，Token消耗巨大，成本开销也明显更高。