AI Agent 记忆新范式：从向量 RAG 转向 Agentic RAG

检索增强生成（RAG）已成为将语言模型与外部信息连接的标准方式之一。传统方法为人熟知：将文档分割成块，生成嵌入向量，将这些向量存储在数据库中，并在请求模型回答之前检索最相关的段落。

这种架构解决了一个重要的早期问题。但 AI 智能体正在改变“检索”的含义。智能体不仅仅回答问题，它们还会选择工具、比较来源、检查中间结果、执行多步工作流，并决定何时拥有足够的信息采取行动。下一代 RAG 正从固定的“先检索后生成”流水线转向智能体 RAG（Agentic RAG）：由智能体在更广泛的决策过程中控制检索。微软将这一转变描述为：将检索视为智能体可以调用、评估并在必要时重复使用的工具。

这并不意味着向量数据库、嵌入或分块会一夜之间消失。这意味着它们不再是唯一值得考虑的架构，对于许多文档-智能体工作流而言，它们也不应是开发人员首先构建的内容。

什么是面向 AI 智能体的 RAG？

面向 AI 智能体的 RAG 是一种系统，它在智能体进行推理和行动时，赋予其访问外部信息的能力。传统的 RAG 通常遵循一个固定的序列。而智能体 RAG 改变了这一序列，由智能体决定何时进行检索。

传统 RAG

用户提问
→ 对问题进行嵌入处理
→ 在向量数据库中搜索
→ 检索文本块
→ 将文本块发送给模型
→ 生成答案

智能体 RAG

用户任务
→ 智能体分析任务
→ 智能体决定所需的信息
→ 智能体调用检索或文档工具
→ 智能体评估结果
→ 如有必要，智能体调用其他工具
→ 智能体采取行动或作出回应

关键区别在于，检索不再是一个隐形的预处理步骤，而是成为智能体可用的一种能力。LangChain 的文档直接阐述了这一原则：智能体可以使用一个或多个工具来获取外部知识，包括文档加载器、API 和数据库查询，而不是仅仅依赖预先构建的检索链。

传统 RAG 与智能体 RAG 对比

因此，Agentic RAG 并非简单地在 RAG 中添加一个 Agent。它是重新设计 Agent、文档和外部工具之间关系的一种全新方式。

固定向量 RAG 的局限性

基于向量的 RAG 依然有用，尤其适用于大型且持久的文本集合。但当它成为所有 Agent 的默认解决方案时，标准流程存在若干弱点。

分块可能破坏文档结构

分块将文档划分为较小的段落，以便进行索引和检索。但文档本质上并非任意文本片段的集合。含义可能取决于章节标题、表头、脚注、前一段落、页码引用、行之间的关系、条款及其修订内容，或表单中数值的位置。

没有列标题的表格行并不等同于完整的表格。缺少定义部分的合同条款可能会产生误导。从政策中提取的一句话可能依赖于几段之后所述的例外情况。

Embeddings 衡量的是相似度，而非业务相关性

Embeddings 表示语义关系。它们可以识别与查询相似的文本，但相似度并不等同于对业务任务的相关性。当被问及发票是否与采购订单匹配时，Agent 需要供应商、产品、数量、单价、税额、总额和货币等信息。向量搜索可能会检索到涉及这两份文档的文本，但它不会自动执行比较。

单次检索调用可能不够

固定的 RAG 链假设单次检索操作即可提供所需上下文。而智能体（Agent）通常需要多个步骤：查找合同、查找最新修正案、检查续约条款、比对日期、确定是否需要发出通知，最后创建提醒。智能体根据已发现的信息决定下一步要检查什么。固定的“先检索后回答”流水线并非为这种流程而设计。

向量数据库增加了基础设施负担

• 文档摄取、解析、分块（Chunking）和嵌入（Embedding）生成。
• 向量存储、元数据过滤、索引更新和文档删除。
• 版本管理、访问控制和检索评估。
• 引用处理以及解析逻辑变更时的重新处理。

LlamaIndex 和 LangChain 等框架简化了该过程的部分环节，但并未消除底层的架构决策需求。LlamaIndex 在数据连接器、索引构建和查询引擎方面依然特别有用，而其他框架则侧重于编排（Orchestration）和工具使用。问题不在于这些工具是否有价值，而在于是否每个智能体都必须从一开始就配备完整的向量检索技术栈。

分块、嵌入和向量数据库并非未来的全部

断言向量数据库、嵌入和分块已过时是过于简化的。它们在大型文档库、持久化企业知识库、语义搜索、相似性发现、推荐系统、长期集合以及高并发重复查询场景中仍然具有重要价值。

真正的转变在于架构层面。向量检索正成为智能体式信息系统中的一个工具，而非所有 AI 智能体的通用基础。智能体将为每项任务选择最合适的工具：发票使用结构化提取，财务记录使用 SQL，实时业务数据使用 API，短文件使用全文档处理，案件工作流使用文档比较，关系网络使用知识图谱，词汇查询使用搜索索引，语义发现使用向量检索，歧义处理则引入人工审核。

什么是 Agentic RAG？

Agentic RAG 是一种检索架构，其中 AI 智能体控制何时以及如何访问外部信息。智能体可以自行决定是否需要检索、选择数据源、制定更精确的子问题、从多个来源进行检索、评估结果、提出后续问题、比较输出、检测证据不足，并在采取无依据行动之前停止执行。

Microsoft 的 Agentic RAG（智能体增强检索生成）指南将这种模式描述为动态查询规划、多步推理和自主信息收集，而非单一的固定检索调用。

检索成为工具

• search_documents() 和 query_document()
• process_multiple_documents() 和 compare_documents()
• extract_fields() 和 query_database()
• search_web()、get_contract_amendment() 和 request_human_review()

当被问及发票是否与采购订单匹配时，智能体可以同时处理这两个文件，比较供应商和总额，如果存在差异则返回异常，并在结果不明确时请求人工审核。它不需要依赖通用的语义搜索来“碰运气”，指望检索到的文本块恰好包含所需的对比信息。

RAG 在智能体中的演进

阶段一：检索与生成
Query → Vector search → Chunks → LLM answer

阶段二：检索与重排序
Query → Vector search → Reranking → Better chunks → LLM answer

阶段三：混合检索
Query → Vector + keyword + metadata → Combined context → LLM answer

阶段四：Agentic Retrieval（智能体检索）
Task → Agent plans → Selects tools → Retrieves or processes
→ Evaluates → Iterates → Acts

系统不再以单一数据库为中心，而是以智能体使用信息工具的能力为核心。

基于向量 RAG 的替代方案

“RAG 替代方案”这一说法往往具有误导性，因为许多替代方案仍然为模型提供外部上下文，只是采用了不同的检索或处理机制。

结构化提取

结构化提取将文档转换为智能体可以直接使用的字段：供应商、总额、税额和到期日，随后进行验证并生成会计记录。当工作流依赖于已知字段时，这种方法通常优于分块检索。

直接文档查询

应用程序无需预先对文档建立索引，而是直接发送文档并提出相关问题。这种方法非常适合一次性文件、用户上传内容、临时案例、短文档以及动态工作流。

多文档处理

可以在单次操作中同时处理和比较多个文档：例如，将发票、采购订单和送货单放在一起，返回匹配或不匹配的结果。这不是传统的 RAG，而是一种旨在理解跨文件关系的文档处理操作。

基于工具的检索、完整文档、图谱与 SQL

该智能体可以调用查询 SQL 数据库、CRM 系统、API、内部系统、文档存储库、网络搜索和知识图谱的工具。LangChain 的检索文档对此做了清晰区分：现有的数据库或内部系统可以直接作为智能体工具接入，而无需将其重建为向量知识库。

对于中小型文档，发送结构化的全文表示可能比将其拆分为块（chunks）更可靠，尤其是在章节关系至关重要、表格需要保持完整，或者智能体必须比较多个文件时。知识图谱能够表征相似度检索无法自然捕捉的实体与关系。许多企业级问题——如逾期发票、供应商额度限制、入职流程未完成等——通过 SQL 查询往往能提供更精确的答案。

成熟的智能体可能会结合文档处理、结构化提取、SQL、API、搜索、知识图谱以及人工审核等多种能力，并根据具体任务选择最匹配的功能模块。

面向智能体的文档 RAG

文档 RAG 常被等同于将 PDF 存入向量数据库。但这只是一种实现方式。在处理文档时，智能体可能需要读取文件、提取字段、提出后续问题、对比文档、追踪源证据、理解表格、检测缺失文件、维护上下文、创建任务以及在不确定性较高时进行升级处理。

• extract_document() 和 query_document()
• process_multiple_documents() 和 compare_documents()
• get_source_evidence() 和 detect_missing_information()
• retain_context() 和 request_review()

这种模型更接近智能体在真实工作流中的运作方式。智能体被赋予一组文档处理能力，并自行决定如何组合使用这些能力。

Claix 与下一代文档 RAG

Claix 可以被定位为面向智能体的文档层，旨在帮助那些不希望手动构建每个 RAG 组件的用户。Claix 不再强制所有工作流都经过解析、分块、嵌入、存储和检索这一传统路径，而是直接暴露文档处理能力：将文件转换为用于智能体上下文的结构化 Markdown，将文件转换为用于工具调用的结构化 JSON，对多个文件进行跨文档比较，以及将文档转化为持久化上下文以支持后续提问。

其核心理念并非断言所有向量数据库都已过时，而是指出智能体通常可以从更直接的文档操作开始。有关本文所描述的两个层级，请参阅“文档转 Markdown”和“多文档处理”。

Markdown 作为智能体上下文

Claix 可以将 PDF、Excel 和 CSV、Word 文档、图像、音频以及 TXT、HTML 或 XML 转换为结构化的 Markdown。Markdown 能够保留标题、章节、列表、表格、转录内容、文档顺序以及人类可读的结构。该应用程序可以将生成的 Markdown 传递给 Agent，将其存储在知识空间中，随后建立索引，将其转换为 JSON，与另一份文档进行比较，或在 Workflow 中使用。

JSON 用于执行操作，Markdown 用于提供上下文

一种实用的架构通常会同时使用这两种格式。当 Agent 需要理解文档内容时，Markdown 非常有用；而当 Agent 需要调用函数或更新系统时，JSON 则更为适用。这种设计避免了在流程初期就迫使每个文档工作流在非结构化文本和严格模式之间做出二选一的选择。

多文档处理

某些 Agent 任务根本不需要知识库。它们只需要在一组少量相关文件中回答问题：例如合同与其修正案之间发生了什么变化，发票和采购订单的总额是否匹配，申请信息与身份证件是否一致，或者哪些费用违反了政策。对于临时性的案例而言，直接进行多文档操作可能比构建向量索引更简单、也更合适。

LlamaIndex 在 Agentic RAG 中的替代方案

LlamaIndex 是一个有用的框架，用于将模型连接到数据、构建索引以及创建检索工作流。但它并非唯一的选择，也不一定适合所有 Agent 场景所需的抽象层级。合适的替代方案取决于你具体要构建什么。

• 直接模型工具调用（Direct model tool calling）：当你希望完全控制工具定义、状态管理、权限设置、重试机制和可观测性时。
• LangChain 和 LangGraph：适用于 Agent 图、分支工作流、持久化状态以及人工审批节点。
• Mastra：适合在 JavaScript 生态系统中构建 Agent、工作流和检索功能的 TypeScript 团队。
• Haystack：适用于模块化的 Python 文档处理、检索和 Agent 流水线。
• DSPy：当主要挑战在于系统地优化提示词（prompts）、推理模块或检索策略时。
• 自定义 Agent 运行时 + 托管文档 API：当你希望在提取、Markdown 转换、JSON 生成及跨文档处理方面减少抽象层级时。

Claix 更应被理解为一个文档处理层，它可以配合自定义运行时使用，也可以集成到 LangChain 和 LangGraph 等框架中。它并不能取代完整 Agent 框架的所有功能。

何时向量数据库仍然有意义

当文档片段数量达到数百万、拥有庞大的永久知识库、查询量高、需要重复进行语义搜索、大量用户查询相同数据、存在复杂的过滤和访问策略、有长期索引需求，或者搜索体验本身就是核心产品时，向量数据库可能仍然是合适的选择。

更好的问题不是“该用向量还是智能体”，而是“任务需要哪种信息操作”。对于语义发现使用向量检索，对于字段提取使用结构化抽取，对于对比分析使用多文档处理，对于结构化记录使用 SQL，对于实时数据使用 API，对于关系挖掘使用知识图谱。而智能体可以编排所有这些操作。

更适合文档智能体的架构

第一层：格式感知提取
PDF, Excel, Word, image, audio, HTML
        ↓
可读的 Markdown 或结构化 JSON

第二层：文档操作
查询、比较、提取、验证、查找缺失信息、获取证据

第三层：智能体推理
规划、选择工具、评估结果、追问后续问题、决定是否继续

第四层：业务动作
创建记录、批准、拒绝、通知、开启工单、更新 CRM、请求审查

这种架构比将向量数据库视为每个文档应用的核心更加灵活。

金融、法律和入职流程

固定的向量管道可以解析发票、分块、嵌入并向模型询问总额。但它不会自动验证发票。基于智能体的文档处理方法会将发票与采购订单和送货单一起处理，比较供应商、数量和总额，并让智能体决定是批准还是升级处理。

仅检索最相似的续约条款的法律智能体，仍然会遗漏合同、修正案和时间表之间的关系。有用的操作是提取日期和义务，比较原始条款和当前条款，识别变更的条款并创建审查任务。

客户入职也是同样的模式：申请表、身份证件和公司记录。核心操作是跨文档验证，而不是搜索相似段落。

为什么 Agentic RAG 很可能成为默认模式

• Agent 需要在多个来源和步骤之间动态获取上下文。
• 检索只是众多工具中的一种，其他工具还包括数据库、CRM、计算器、网络搜索和人工审核。
• Agent 必须评估证据是否充分、文档之间是否存在冲突，以及采取行动是否安全。
• 诸如“批准供应商”之类的任务，不能简单地通过一次向量搜索加一次响应来完成。
• 最佳信息源可能是文档、电子表格、数据库、API、知识图谱、用户或审核人员。

对开发者的影响

开发者的工作重心从构建单一的大型 RAG 流水线，转向设计一系列可靠的 Agent 能力。不要只问如何索引所有文档，而要问 Agent 应该能对文档做什么：阅读文档、提取字段、对比文档、查询文档、发现缺失信息、获取证据以及创建审核任务。

实用的决策框架

• 直接文档处理：适用于文件仅用于单次任务、文件集较小、无需持久存储，或需要立即获得跨文档答案的场景。
• 结构化提取：适用于已知目标字段、需要数据验证，或输出结果将更新其他系统的场景。
• 知识空间（Knowledge Space）：适用于文档需要持久化存储，且用户会反复查询的场景。
• 向量搜索：适用于语义发现是核心需求、数据集合庞大，且相似度匹配确实是正确操作方式的场景。
• Agent 编排：适用于任务需要调用多种工具、进行规划、对比、执行动作及审批的场景。

这些选项是互补的，而非互斥的。

构建 Agentic RAG 时的常见错误

• 当工作流实际需要总和、日期或标识符时，却将所有文档问题都当作语义搜索来处理。
• 在未理解产品的文档行为模式之前，就着手构建向量数据库。
• 直接将原始文件发送给模型，而不是使用统一的数据表示形式。
• 忽视文档之间的关联：发票、订单和送货单通常属于同一个案例。
• 将缺失信息视为否定答案。“未知”不等于“假”。
• 允许在财务、法律或客户系统上执行未经支持的操作。
• 隐藏结果背后的证据。

Agent 时代 RAG 的未来

未来不太可能由单一的通用检索架构主导。正在浮现的模式是一个工具驱动的信息层：涵盖文档提取、多文档处理、结构化 JSON、Markdown 上下文、搜索、SQL、API、知识图谱以及人工审核。向量数据库和嵌入技术仍是这一生态系统的一部分，但它们是针对特定检索任务而被选用的，并非每个智能体（Agent）都必须依赖的基础设施。

传统 RAG 检索的是相似文本。而 Agentic RAG 则赋予智能体获取、比较并使用适合当前任务的正确信息的工具。对于构建具备文档感知能力的智能体的开发者而言，战略核心问题已不再是“使用哪个向量数据库”，而是“智能体应当能够调用哪些文档与信息处理能力”。

常见问题

什么是面向 AI 智能体的 RAG？面向 AI 智能体的 RAG 使智能体在推理和行动过程中，能够通过检索或文档工具访问外部信息。智能体可以自行决定何时进行检索、使用哪个数据源以及是否需要更多信息。

什么是 Agentic RAG（智能体式 RAG）？Agentic RAG 是一种动态检索架构，其中由智能体控制获取外部上下文的时机和方式。它可以调用工具、优化查询、比较结果，并持续执行直到收集到足够的信息以完成任务。

Agentic RAG 是否正在取代传统 RAG？Agentic RAG 正逐渐成为复杂智能体工作流的首选模式，但传统的向量 RAG 对于大型、持久的语义搜索集合仍然很有用。这两种方法通常会被结合使用。

向量数据库或嵌入（Embeddings）是否已过时？没有。它们在大规模语义检索和相似度发现方面仍然有用。它们并非每个文档-智能体工作流的必需品。根据具体任务，结构化提取、直接文档处理、SQL 和 API 可能是更合适的选择。

分块（Chunking）是否已成为过去式？固定分块不再具有普适性。结构感知提取、全文档处理、结构化输出以及基于工具的文档操作可能是更好的选项，具体取决于任务需求。

向量数据库 RAG 有哪些替代方案？结构化提取、直接文档查询、多文档处理、SQL、关键词搜索、知识图谱、API、全文档上下文以及智能体工具。

LlamaIndex 有哪些替代方案？直接的模型工具调用、LangChain、LangGraph、Mastra、Haystack、DSPy、自定义智能体运行时以及托管的文档处理 API。正确的选择取决于主要需求是索引、检索、编排还是文档处理。

我可以在不使用向量数据库的情况下构建智能体吗？可以。你可以使用直接文档 API、结构化提取、多文档处理、SQL 或其他工具。只有当用例确实需要大规模语义检索时，才必须使用向量数据库。

Claix 是否是 LlamaIndex 的替代品？Claix 是一个文档处理层，可以与自定义智能体运行时配合使用，也可以与 LangChain 和 LangGraph 等框架集成。它并不能替代完整智能体框架的所有功能。

Claix 如何融入 Agentic RAG？Claix 可以提供用于提取、Markdown 转换、JSON 输出、上下文保留和跨文档处理的文档工具。智能体决定何时使用这些功能，以及对结果采取何种行动。

• [产品 · 智能体

AI 智能体的知识空间：查询多个文档并关联其数据](https://www.claix.dev/blog/knowledge-spaces-ai-agents)

• [RAG · Agents

为什么当我要求 AI 智能体比较两个文档之间的数据时，它会产生幻觉？](https://www.claix.dev/blog/why-ai-agents-hallucinate-when-comparing-documents)

• [Automation · n8n

如何在不使用向量数据库的情况下将 n8n 智能体连接到 PDF 文档](https://www.claix.dev/blog/connect-n8n-agent-to-pdf-documents-without-vector-databases)

• [RAG · Context Engineering

RAG 智能体：为什么你的 AI 智能体需要像 Claix 这样的上下文工程层](https://www.claix.dev/blog/rag-agents-estructured-data)