一、传统 RAG 的局限：为什么“先查后答”不够用

在之前的 LangChain 教程中，我们建立了一个基本认知：RAG 的本质是“给 LLM 外挂知识库”。传统实现方式（LangChain 文档中称为 

）非常直观：用户提问 → 向量检索 → 把检索结果塞进提示词 → 生成回答。

这个模式在 FAQ 场景下工作得很好。但企业知识库的真实使用场景远比 FAQ 复杂：

问题一：用户问的不一定是知识库里有的东西。

 如果用户问“今天天气怎么样”，传统 RAG 仍然会去知识库里搜“天气”，返回一堆不相关的文档，然后 LLM 硬着头皮用这些无关内容编造答案。LangChain 官方文档明确指出，传统 RAG 的检索是

问题二：一个问题可能需要查多个数据源。

 用户问“我们的认证系统是怎么设计的”，这个问题可能横跨 GitHub 代码、Notion 文档和 Slack 讨论三个地方。传统 RAG 只有一个向量库，你很难让它“先查代码，发现不够，再查文档”。

 用户的原始问题往往带有口语化表达或歧义，直接拿去做向量搜索，召回率堪忧。LangChain 的 Agentic RAG 教程中特别指出了一个关键机制：

——如果第一次检索的结果不相关，Agent 应该重新表述问题再查一次，而不是硬着头皮回答。

 用户先问“LangGraph 的检查点机制是什么”，再追问“那它和 Agent 状态有什么关系？”——第二个问题脱离上下文毫无意义。传统 RAG 要么把追问直接拿去搜（必然失败），要么把整个对话历史塞进去（越来越臃肿）。

二、Agentic RAG 的核心理念：把“查”变成一种能力

不要把检索写成流程中的一个固定步骤，而是把它封装成一个工具，交给 Agent 自主决定什么时候用、怎么用、用几次

LangChain 官方文档对这两种架构做了一个清晰的对比：

换句话说，传统 RAG 是你告诉系统“先查，再答”；Agentic RAG 是你告诉系统“你有查的能力，你自己判断什么时候该查”。

这听起来简单，但背后需要一套完整的机制支撑：Agent 需要能判断“这个问题需不需要查知识库”，需要能在检索结果不好时重试，需要能从多个知识源中选择正确的那个。这些能力，LangChain 通过 

三、实战：从知识库到检索工具

构建 Agentic RAG 的第一步，仍然是准备知识库。这部分工作与传统 RAG 完全一致：加载文档、切分、向量化、存入向量库。

import requests
from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter

# 1. 加载文档（以内部文档 URL 列表为例）
def load_docs(urls: list[str]) -> list[Document]:
    docs = []
    for url in urls:
        response = requests.get(url, timeout=20)
        response.raise_for_status()
        docs.append(Document(
            page_content=response.text,
            metadata={"source": url}
        ))
    return docs

raw_docs = load_docs([
    "https://internal.company.com/docs/auth.md",
    "https://internal.company.com/docs/api.md",
])

# 2. 切分
splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=50)
splits = splitter.split_documents(raw_docs)

# 3. 向量化 + 存储
embeddings = OpenAIEmbeddings()
vectorstore = InMemoryVectorStore.from_documents(splits, embeddings)

。这个工具的定义方式，直接决定了 Agent 能否正确使用它。

from langchain.tools import tool

@tool
def search_knowledge_base(query: str) -> str:
    """在企业内部知识库中搜索相关信息。
    
    当用户询问关于公司内部流程、技术文档、API 使用方式、
    认证机制等问题时，使用此工具。查询应该是一个清晰的
    搜索语句，而不是直接复制用户的原话。
    """
    results = vectorstore.similarity_search(query, k=5)
    if not results:
        return "未找到相关信息。"
    return "\n\n---\n\n".join(
        f"来源：{doc.metadata['source']}\n{doc.page_content}"
        for doc in results
    )

工具描述中的细节至关重要。你需要明确告诉模型：

什么场景下该用这个工具，以及查询参数应该长什么样

。如果描述太模糊（比如只写“搜索知识库”），模型可能在不需要的时候也去搜，或者在需要的时候不知道该怎么组织查询。

四、创建 Agent：让模型自主决定“查不查”

有了工具之后，创建 Agent 只需要几行代码：

from langchain.agents import create_agent

agent = create_agent(
    model="openai:gpt-4o",
    tools=[search_knowledge_base],
    system_prompt=(
        "你是一个企业知识助手。当用户的问题涉及公司内部信息时，"
        "使用 search_knowledge_base 工具检索相关内容后再回答。"
        "如果用户的问题与公司知识库无关（如闲聊、常识问题），"
        "直接回答即可，不需要检索。"
        "当你使用检索结果回答时，请注明信息来源。"
    ),
)

这个 Agent 的行为逻辑是：收到问题后，先判断“我需要查知识库吗”。如果是公司内部问题，调用工具；如果只是闲聊，直接回答。这种

是 Agentic RAG 最直接的收益——它避免了传统 RAG 中“无差别检索”带来的噪音和幻觉风险。

但仅仅“能查”还不够。真正让企业知识助手可用的，是它在

五、进阶：当第一次没查准时，Agent 应该怎么办

LangChain 官方 Agentic RAG 教程中展示了一个关键模式：

流程是这样的：Agent 调用检索工具拿到文档后，不是直接拿去生成回答，而是先让一个“评分器”判断：

 如果不相关，就进入重写环节——把用户的问题改写成更精确的查询，然后再检索一次。

from pydantic import BaseModel, Field
from langchain.chat_models import init_chat_model

class GradeDocuments(BaseModel):
    binary_score: str = Field(
        description="相关性评分：'yes' 表示相关，'no' 表示不相关"
    )

grader = init_chat_model("openai:gpt-4o-mini", temperature=0)

def grade_and_rewrite(state):
    """评估检索结果，不相关则重写查询"""
    question = state["messages"][0].content
    context = state["messages"][-1].content
    
    # 评分
    grade = grader.with_structured_output(GradeDocuments).invoke(
        f"用户问题：{question}\n\n检索到的文档：\n{context}\n\n"
        f"这些文档与用户问题相关吗？只回答 yes 或 no。"
    )
    
    if grade.binary_score == "yes":
        return {"next": "generate_answer"}
    else:
        # 重写查询
        new_query = grader.invoke(
            f"用户问题：{question}\n\n"
            f"检索结果不相关。请将用户问题改写为更精确的搜索查询，"
            f"只输出改写后的查询语句。"
        )
        return {"next": "retrieve_again", "query": new_query.content}

这个循环的价值在于：它让知识助手具备了

的能力。用户用模糊的口语提问jspzwx.com，第一次检索可能失败，但系统不会就此放弃或胡编，而是主动优化查询再试。

六、多源知识库：当企业数据分散在各个系统

真实的企业知识很少集中在单一的向量库里。代码在 GitHub，文档在 Notion，讨论在 Slack，工单在 Jira。Agentic RAG 的另一个核心优势是

：Agent 可以根据问题类型，选择最相关的知识源。

LangChain 文档中展示了一个多智能体路由的架构：一个“分类器”先分析用户问题，决定应该查哪些源，然后并行调用对应的子 Agent。

from langchain.agents import create_agent
from langchain.tools import tool
from langgraph.graph import StateGraph, START, END
import operator

# 为每个知识源定义专属工具
@tool
def search_github(query: str) -> str:
    """搜索 GitHub 代码库和 Pull Request。适用于 API 用法、实现细节类问题。"""
    return f"GitHub 搜索结果：{query} 相关代码片段..."

@tool
def search_notion(query: str) -> str:
    """搜索 Notion 文档。适用于内部流程、政策、规范类问题。"""
    return f"Notion 搜索结果：{query} 相关文档..."

@tool
def search_slack(query: str) -> str:
    """搜索 Slack 讨论。适用于团队决策、非正式知识分享类问题。"""
    return f"Slack 搜索结果：{query} 相关讨论..."

# 每个源可以有自己的子 Agent，也可以简单封装为工具
# 路由器 Agent 的 system_prompt 负责指导决策
router_agent = create_agent(
    model="openai:gpt-4o",
    tools=[search_github, search_notion, search_slack],
    system_prompt=(
        "你是一个企业知识路由助手。根据用户问题的性质，"
        "选择最合适的知识源进行检索：\n"
        "- 技术实现问题 → GitHub\n"
        "- 流程政策问题 → Notion\n"
        "- 团队讨论问题 → Slack\n"
        "如果问题涉及多个方面，可以并行调用多个工具。"
    ),
)

分类逻辑不是硬编码的规则，而是模型根据语义自主判断的

。当用户问“我们的 API 认证是怎么设计的”，模型可能同时调用 GitHub 和 Notion，因为这个问题既涉及代码实现也涉及设计文档。

七、企业级考量：延迟、成本与可控性

Agentic RAG 给了 Agent 更多自主权，但这也意味着

。一次简单的 FAQ 查询可能触发多轮“检索-评分-重写”，耗时从几百毫秒变成几秒。

企业级部署需要在灵活性和效率之间找到平衡。几个实用策略：

策略一：根据问题类型动态选择架构。

 并非所有问题都需要 Agentic 的复杂性。对于明确的 FAQ 类问题，可以直接走传统 RAG 路径；只有复杂查询才启用 Agent 循环。LangChain 文档中提到的 

策略二：给检索加上“刹车”。

 限制 Agent 的最大检索次数（比如最多 3 次），避免它陷入无限重写的循环。这可以通过中间件的 

 相同或相似的查询可以直接命中缓存，避免重复的 Agent 循环。LangGraph 的持久化机制天然支持这一点。

策略四：人工审批高风险操作。

 如果知识助手需要执行写操作（如修改工单、发送邮件），可以在工具调用前插入 

八、从“能查”到“好用”的关键认知

回顾整个构建过程，Agentic RAG 的真正价值不在于技术复杂度，而在于它

把“检索”从机械步骤变成了有判断力的行为

传统 RAG 的思维方式是：“用户提问了，我该查什么？”Agentic RAG 的思维方式是：“用户提问了，这个问题需要查吗？如果需要，查哪里最有效？如果没查到，我该怎么办？”

这个转变对企业知识助手至关重要。内部知识库的使用场景天然是模糊的、多源的、需要追问的。用户不会像写搜索引擎查询词那样规范地提问，他们会说“那个认证的东西怎么搞的”，会追问“那这个和那个有什么关系”，会在一个问题里混入多个不相关的话题。

Agentic RAG 通过赋予 Agent 判断力，让系统能够应对这种真实世界的混乱。而 LangChain 的 

 + 工具封装 + 中间件的组合，提供了一个足够灵活又不失可控性的实现路径。

下一步值得深入的方向包括：用 LangSmith 追踪 Agent 的检索决策路径，理解它“为什么选择了这个知识源”；以及用评估机制持续衡量检索质量，确保 Agent 的自主判断不会逐渐偏离正轨。

在之前的 LangChain 教程中，我们建立了一个基本认知：RAG 的本质是“给 LLM 外挂知识库”。传统实现方式（LangChain 文档中称为 2-Step RAG）非常直观：用户提问 → 向量检索 → 把检索结果塞进提示词 → 生成回答。

构建企业知识助手：用 LangChain Agentic RAG 让检索“有脑子”

人工智能

开发工具

架构设计

Agentic RAG通过"边想边查"替代传统"先查后答"，让AI助手能自主判断检索时机、重写模糊查询、路由多源知识库，并支持追问与自我纠错。相比传统RAG的固定流程，这种模式显著提升复杂知识场景下的回答准确性与适应性，是企业知识助手的进阶方案。

路由器

智能体

中间件

LangGraph

LangChain

路由

GitHub

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

构建企业知识助手：用 LangChain Agentic RAG 让检索“有脑子”

构建企业知识助手：用 LangChain Agentic RAG 让检索“有脑子”

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐