从RAG到LangGraph：AI Agent开发全链路学习路线-编程实验室

这次我们看的不是某个开源模型，也不是一份可以直接拉取的 GitHub 仓库，而是一套以 AI Agent 开发为终点、串起 RAG + MCP + LangChain + LangGraph + 企业级项目实战的视频教程。宣传文案说“全B站最用心”，这种说法不太好量化，但从覆盖的技术关键词来看，它确实把当前 AI 应用开发里最热门、也最容易绕晕的几个方向全部串起来了。

这套内容最核心的几个特点很明确：一是从大模型 API 基础讲起，不是一上来就丢框架源码；二是 RAG 知识库和 MCP 工具调用被单独拉出来讲，强调真实业务里“模型 + 数据 + 工具”如何配合；三是 LangChain 和 LangGraph 都有专门章节，从 Chain 讲到位图化编排，解决了“学了 LangChain 但还是写不出多步 Agent”的断层问题；四是最后落到企业级项目实战，覆盖 Agent 落地过程中会遇到的日志、权限、批量任务、效果评估等现实问题。

本文不只介绍这套教程有什么，我会按教程的学习路径拆成一条可执行的技术路线：先搞清楚 RAG、MCP、LangChain、LangGraph 各自解决什么问题，再给出环境准备清单、几段可直接参考的代码结构和企业级项目设计思路。如果你正准备系统学习 AI Agent 开发，但不知道从哪下手，这篇文章可以当一份路线图用。

1. 核心能力速览

先把整套内容的关键信息整理成一张表，方便你快速判断值不值得花时间跟学。

能力项	说明
教程定位	从 LLM 基础到企业级 AI Agent 的全链路视频教程
核心覆盖方向	RAG 知识库、MCP、LangChain、LangGraph、AI Agent 实战
技术栈关键词	RAG、MCP Server、LangChain、LangGraph、Agent Skills、企业级项目
前置基础	Python 基础、大模型 API 调用经验、Prompt 基本概念
内容形式	视频讲解 + 项目实战演示
环境门槛	未提供固定硬件要求，通常准备一台可联网的开发机即可
是否覆盖批量任务	从企业级项目实战角度会涉及批量处理与评估
是否覆盖 API 集成	涉及 MCP 服务和 Agent 接口设计，具体以教程实际演示为准
适合人群	想系统掌握 AI Agent 开发的工程师、算法工程师、学生
学习时长成本	教程本身耗时千余小时开发，完整跟学需要投入较多时间

需要注意：这不是一份可一键安装的工具包，而是一套学习资料。它能帮你节省自己从零梳理文档的时间，但最终能不能落地，取决于你是否照着项目实战部分动手敲代码。

2. 适用读者与学习边界

这套教程适合以下三类人：

第一类：已经会调用大模型 API，但写出来的程序只是“单轮问答”，不知道怎么把业务数据接进去。这类人最需要补 RAG 和 MCP。

第二类：知道 LangChain 的 Chain 和 Tool 概念，但要写多步任务时不知道如何管理状态、条件分支和循环。LangGraph 就是为这个问题设计的。

第三类：正在做企业内部 AI 应用，比如知识库问答、数据报表 Agent、代码生成助手，需要一套从原型到生产的工程思路。

同时要说清楚边界：这套教程解决的是“开发框架和架构设计”问题，不负责某个具体业务特效。如果你要的是类似“自动写 PPT 的数字人 Agent”，那是更上层的应用封装；教程会更偏底层框架理解和企业级通用架构。

另外，AI Agent 开发涉及版权和数据安全问题。尤其是企业知识库 RAG，必须确认文档来源是否合规；调用第三方大模型服务时，注意数据脱敏和私有化部署边界。后面第 9 章会专门展开。

3. 技术栈全景：RAG、MCP、LangChain、LangGraph 分别解决什么问题

在动笔写代码之前，先把这几个术语之间的关系讲清楚。很多初学者卡住，就是因为把 LangChain、LangGraph、RAG、MCP 当成四个并列的“知识点”，实际上它们处于不同层级。

3.1 RAG：给大模型外接知识库

RAG 全称 Retrieval-Augmented Generation，检索增强生成。核心思路是：每次提问时，先从外部知识库检索出和问题最相关的片段，再把片段拼进提示词，让大模型基于这些片段回答。

RAG 解决的主要问题是：

大模型训练数据有截止时间，新知识不知道。
企业私有文档不能直接放进模型权重。
纯靠模型记忆回答容易幻觉，缺少可验证来源。

RAG 在 2026 年依然是企业落地 AI 应用最稳妥的方案，原因很简单：它不改模型，只改“输入 + 检索”，架构改动小，出了问题好排查。

3.2 MCP：把工具接入标准化

MCP 全称 Model Context Protocol，模型上下文协议。我在社区里看到“MCP 是 AI 应用里的 USB-C 接口”这个类比，虽然通俗，但方向是对的。

MCP 解决的核心问题是：不同 Agent 要接各种外部工具，如果每个工具都写一套自定义集成，项目会变得非常难维护。MCP 把工具封装成标准化的 Server，Agent 通过统一协议发现并调用工具。

典型角色：

MCP Server：提供工具能力，比如访问文件系统、调数据库、调用业务 API。
MCP Client：运行在 Agent 侧，负责发现工具、调用工具。
Agent：根据任务选择要调用的工具，处理返回结果。

实际项目中，你可能会把内部报表系统、工单系统、代码仓库封装成 MCP Server，让 Agent 以统一方式调用。这也是企业级 AI Agent 和玩具 Demo 最明显的分水岭。

3.3 LangChain：一站式 LLM 应用框架

LangChain 是最早被广泛使用的 LLM 应用开发框架之一，核心能力包括：文档加载、文本分割、向量存储、Prompt 模板、输出解析、工具调用、记忆管理。

这么说吧：没有 LangChain，你也可以直接拼 Prompt + API 实现 RAG，但代码会很碎。LangChain 的价值在于把通用流程抽象成可复用的组件，让 80% 的场景有现成代码可抄。

但 LangChain 也有问题：Chain 的抽象对复杂多步任务不够直观。你很难用一条纯链式的结构表达“根据用户意图决定走哪条子流程，失败后还要重试”这种逻辑。

3.4 LangGraph：面向复杂 Agent 的编排引擎

LangGraph 是 LangChain 生态里的图编排框架，把 Agent 的执行过程建模成一张有向图。核心概念包括：

StateGraph：定义全局状态。
Node：每个处理步骤是一个节点，比如检索节点、生成节点、工具调用节点。
Edge：节点之间的连接。
Conditional Edge：根据当前状态动态决定下一步走到哪个节点，这是 Agent 能做条件路由的基础。
Subgraph：把一段复杂的子流程封装成子图。
Loop：实现多轮工具调用的循环检测，避免 Agent 陷入死循环。

我见到很多从 LangChain 迁移到 LangGraph 的开发者，主要原因就是“图结构比链式结构更适合表达真实业务”。真实业务里，一个任务可能要先判断用户意图，再走不同分支，中途还要调用多个工具，最后汇总结果——这就是一张有向无环图，甚至带循环。

LangGraph 和其他框架的关系，可以用一句话概括：LangChain 提供工具组件，LangGraph 负责编排多步流程，RAG 负责供给知识，MCP 负责把外部能力标准化后接入。

4. 环境准备与前置条件

虽然是视频教程，但跟学过程需要自己搭建环境。下面给出一套通用环境准备清单，具体以教程源码要求为准。

4.1 开发语言与版本

建议使用 Python 3.10 或更高版本。当前较新的 LangChain、LangGraph 版本对 Python 3.10+ 支持更稳定。如果本机同时有多个 Python 版本，推荐用虚拟环境隔离，不要直接往全局环境装。

# 创建并激活虚拟环境，Windows 环境请按需调整命令 python -m venv venv source venv/bin/activate # macOS / Linux # 或 venv\Scripts\activate # Windows

4.2 依赖安装

根据教程使用的版本选择安装方式。如果教程给你依赖清单，直接安装：

pip install -r requirements.txt

如果是手动安装常用依赖，可以按模块安装：

pip install langchain langchain-openai langgraph pip install chromadb pip install python-dotenv

这里特别提醒：LangChain 生态更新很快，有时官方会调整包名和 API 路径。遇到ImportError时，先把包升级到当前版本，再看对应版本的官方文档。不要拿 2024 年的教程代码直接跑 2026 年的包，大概率会有兼容问题。

4.3 大模型 API Key

教程中会大量调用大模型接口，你需要准备一个可用的大模型 API Key。常见选择包括 OpenAI 系、国产大模型、本地通过 Ollama 部署的开源模型。不要在上传到 GitHub 的代码里硬编码 Key，统一放到.env文件：

OPENAI_API_KEY=你的Key

然后通过dotenv加载：

from dotenv import load_dotenv load_dotenv()

4.4 向量库选型

RAG 项目需要向量数据库。入门阶段用 Chroma 或 FAISS 就够，安装简单、数据量小时性能足够。到了企业级场景，才考虑 Qdrant、Milvus 或 Elasticsearch 这类服务化方案。

4.5 网络与端口

联网场景下需要能正常访问大模型 API。本地服务类项目要注意端口冲突，比如你之前已经启动了一个 8000 端口的服务，再启动新服务时就要换端口。启动前用下面命令检查端口占用：

lsof -i :8000 # macOS / Linux netstat -ano | findstr :8000 # Windows

5. 学习路线：从 RAG 到企业级 Agent

这套教程的核心价值在于给出了一条完整学习路线。下面是我推荐的跟学顺序，也是从我的经验看最不容易劝退的路径。

5.1 第一阶段：LLM API 与 Prompt 基础

不要一上来直接学框架。先掌握以下能力：

已知发起一次大模型调用需要哪些参数：模型名、消息体、温度、最大 token 数。
清楚 system prompt、user prompt、assistant message 之间的角色差异。
尝试用一次 API 调用完成结构化输出，比如让模型返回 JSON 而不是解释性文字。

学完这一阶段，你应该能写出一个“输入问题，返回答案”的最小程序。如果这一步还不熟，直接学 RAG 和 Agent 会非常吃力。

5.2 第二阶段：RAG 最小闭环

用不超过 200 行代码跑通一个最小 RAG：

加载文档。
文本分割成 chunk。
为 chunk 生成向量并存入向量库。
输入问题，检索 top-k 相关片段。
拼接上下文，调用大模型生成答案。

可以参考下面的通用代码结构，具体 API 以教程实际版本为准：

from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import Chroma loader = TextLoader("docs/company_manual.txt") documents = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings()) retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

写完后要做的第一件事不是调精度，而是检查三件事：

文档能否被正确切分。
检索出来的片段是否和问题相关。
大模型是否真的用了这些片段，而不是自己瞎编。

5.3 第三阶段：LangChain 组件梳理

有了 RAG 最小闭环后，再系统学 LangChain 组件。重点看这些：

Document Loader：不同格式文件如何加载。
Text Splitter：不同分割策略对检索效果的影响。
Embedding：向量化的效果差异。
Tool：如何把自定义函数包装成模型可调用的工具。
Memory：如何在多轮对话中保留历史信息。

学习 LangChain 的核心目的是“知道有哪些现成零件”。不要试图背下所有 API，能查文档、能正确组装更重要。

5.4 第四阶段：MCP 工具接入

先理解 MCP 的协议关系，再动手跑一个 Server。如果你是第一次接触，建议先跑一个官方示例，比如文件系统 MCP Server，感受一下“Agent 请求 -> MCP Server 执行 -> 返回结果”的完整链路。

下面是 MCP Server 配置的一个常见示意，不同客户端和版本配置路径会有差异：

{ "mcpServers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"] } } }

跑通官方示例后，再尝试写一个自己的 Server，比如查数据库、调用公司内部 API。这个阶段的核心指标是：工具能被 Agent 发现，并且 Agent 知道在什么场景下调用它。

5.5 第五阶段：LangGraph 编排与条件路由

LangGraph 是整套路线里最难但也最有价值的一环。先理解一个观点：Agent 不是一个模型，Agent 是“模型 + 状态机 + 工具”的组合。LangGraph 就是这个状态机。

一个最简单的 LangGraph 流程包括：定义状态结构、添加节点、添加边、编译图。下面是伪代码级示例，主要用来理解结构，不能直接复制运行：

from typing import TypedDict from langgraph.graph import StateGraph, END class AgentState(TypedDict): query: str context: list answer: str def retrieve(state: AgentState): state["context"] = retrieve_docs(state["query"]) return state def generate(state: AgentState): state["answer"] = generate_answer(state["query"], state["context"]) return state graph = StateGraph(AgentState) graph.add_node("retrieve", retrieve) graph.add_node("generate", generate) graph.add_edge("retrieve", "generate") graph.add_edge("generate", END) app = graph.compile()

跑通基础图之后，再学条件路由。比如：如果检索结果置信度太低，直接让用户澄清问题，而不是硬答。这里要用到conditional_edge，根据状态里的某个字段决定下一个节点。

5.6 第六阶段：Agent 模式与复杂任务

最后把 RAG、MCP、LangGraph 组合起来，实现一个真正的 Agent。典型流程：

接收用户任务。
判断任务是否需要检索知识库。
必要时查询 MCP Server，获取业务数据。
调用大模型生成答案。
检查输出是否满足要求，不满足则进入下一轮修正循环。

这一阶段要特别关注循环检测。Agent 工具调用很容易出现“反复调用同一个工具”“绕了几圈还在原地”的情况。LangGraph 提供循环控制机制，但你要在实际项目中主动设计退出条件。

6. 企业级项目实战设计思路

教程名称里有“企业级项目实战”，这是最容易被低估的部分。企业级不等于代码量大，而是要考虑以下工程问题。

6.1 知识库问答系统

如果你要做企业内部知识库问答：

文档权限怎么控制？一个普通员工不能检索到财务薪资文档。
多部门知识库是否分开？语义相似但权限不同的文档可能互相干扰。
文档更新后，向量库里过期片段怎么清理？

建议先按部门或业务域做 Collection 隔离，再在检索层增加权限过滤。这个方案比“全部放一个向量库，靠提示词限制”要安全得多。

6.2 日志和可观测性

生产环境 Agent 必须可追溯。每个请求至少要记录：

用户输入和最终输出。
模型名和参数。
检索到的文档 ID 和得分。
调用过哪些 MCP 工具。
每一步耗时。

少了这些日志，用户反馈“回答不对”时，你根本不知道是检索错了、工具错了还是模型生成错了。

6.3 权限、限流与并发

Agent 接口一旦被太多人使用，会出现两个问题：大模型 API 费用暴涨；单个请求因步骤多，占用线程时间长。

建议：

同一用户设置请求频率限制。
批量任务拆成队列，控制并发数。
高耗时的长任务异步化，不让用户一直等 HTTP 响应。

6.4 缓存与降级

完全相同的用户问题重复调用大模型，既慢又贵。可以在检索前加一层缓存：相同问题优先复用上次答案。如果第三方模型服务超时，能否降级到备用模型，或提示用户稍后重试？这些都属于企业级项目里会真实遇到的细节。

7. Agent 效果验证与 RAG 知识库指标

“跑通了”和“效果好”完全是两回事。企业落地 RAG 和 Agent，必须定义效果指标。这是近期社区问得最多的问题之一：RAG 知识库指标有哪些，如何理解各指标。

7.1 检索侧指标

检索质量直接影响最终回答质量。常用指标：

指标	中文含义	说明
Hit Rate	命中率	正确答案是否出现在检索结果的前 k 条中
MRR	倒数排名	正确答案排在第几位，用于衡量排序质量
Recall@k	召回率	前 k 条结果覆盖了多少相关文档
Precision@k	精确率	前 k 条结果里有多少是真正相关的

实际项目中，Hit Rate 和 MRR 可以优先看。命中率上不去，后面模型再强也回答不准。

7.2 生成侧指标

生成侧更关注答案质量：

指标	说明
忠实度	答案是否严格基于检索到的上下文，有没有幻觉
相关性	答案是否真的回答用户问题
完整性	信息有没有漏
可读性	语言是否通顺，格式是否清晰

生成侧指标很难用纯自动评估覆盖，建议建立一个小而可靠的评测集：50 到 100 条代表性问题，每次改完代码跑一遍，对比答案质量。把评测集提交到 CI 里，做回归测试。

7.3 从指标反推问题

Hit Rate 低：问题在于文本分割策略、Embedding 模型或检索条数。先换分割策略，再尝试换 Embedding。
Hit Rate 高但答案错：问题在生成侧，上下文拼接、Prompt 模板或模型能力需要调整。
工具调用频繁失败：MCP Server 返回结构不稳定，或 Agent 不理解工具用途。需要优化工具描述。

记住：不要用同一套参数盲调模型。先判断问题出在检索侧还是生成侧，再做针对性优化。

8. 常见问题与排查方法

从社区讨论和常见项目情况看，AI Agent 学习过程中最常遇到以下问题。我整理成排查表：

问题现象	可能原因	排查方式	解决方案
`ImportError: cannot import name`	LangChain 或 LangGraph 版本过旧/过新	查看依赖版本和 API 变更日志	升级到教程指定版本或查阅最新官方文档
调用大模型一直超时	网络代理异常，或 API Key 无效	检查网络连通性、Key 是否有效	配置正确的网络环境，更换可用 Key
向量库搜索总返回空结果	Embedding 维度不匹配，或文档切分后为空	打印向量库数量和 chunk 内容	检查加载文件和分词逻辑
RAG 检索到不相关内容	chunk 太大或太小，Embedding 模型效果差	观察召回文档与问题的相关性	调整 chunk_size 和 chunk_overlap，换 Embedding
Agent 反复调用同一个 MCP 工具	缺少循环检测，退出条件设计不合理	查看执行日志中工具调用次数	在 LangGraph 中增加最大轮次限制，或增加条件判断
多个服务端口冲突	占用了相同端口	`lsof -i`或`netstat`检查端口	修改端口配置或终止占用进程
批量任务跑着跑着卡住	某条数据触发异常，但没捕获	查看批量任务日志，定位卡住的数据	增加单条异常捕获和失败重试
回答不稳定，同一问题两次结果不同	温度参数过高，或检索上下文顺序有变化	对比两次日志中的上下文	降低温度，稳定 top-k 结果排序
上下文过长导致接口报错	单次请求 token 超过上限	查看报错信息	减少检索片段数，或使用支持更长上下文的模型

这套排查逻辑不仅适用于教程跟学，也适用于你后续自己的项目。核心原则是：先定位问题属于哪一层，再针对性修复。

9. 最佳实践与合规边界

以下实践建议是我认为值得长期遵守的，尤其在走向生产环境时。

9.1 工程实践建议

第一，第一次跑通流程时，用最小规模验证。只要 1 个文档、1 个问题，先确认链路是通的，再逐渐增加数据量。一上来就灌几千个 PDF，出问题时根本分不清是加载器问题、切分问题还是向量库问题。

第二，模型文件、输入素材、输出结果分目录管理。文档加载、临时缓存、最终答案不要堆在一起。建议目录结构：

project/ ├── data/ # 原始文档 ├── cache/ # 向量库或中间缓存 ├── outputs/ # 生成结果 ├── logs/ # 运行日志 └── configs/ # 配置文件

第三，批量任务要加日志和失败重试。具体做法是：每条任务记录状态，失败后自动重试有限次数，重试仍失败则写入失败队列，人工复查。

第四，API 服务要控制访问范围。企业内部的 Agent 接口不要直接暴露到公网，建议走内网或网关鉴权。

第五，涉及生成式 AI 的内容，发布或商用前一定要做效果复核。特别是面向客户的内容，至少要有人工抽检环节。

9.2 合规与安全边界

RAG 知识库、MCP 工具、Agent 自动化执行这几项能力叠在一起，权限边界就变得非常重要。我在这里单独强调几条底线：

使用企业内部文档前，确认文档的密级和可访问范围。不能让 Agent 通过检索把高权限文档透出。
第三方工具或 MCP Server 需要账号权限时，确认是否遵守平台的自动化使用规则，避免违反平台服务条款。
调用大模型 API 时，敏感数据要脱敏。企业数据建议优先考虑私有化部署或采用支持数据合规的云服务。
自动化 Agent 执行有外部影响的操作，比如发邮件、提交订单、删文件，必须加审批环节，不能完全自动执行。
不要用 RAG 或 Agent 处理未经授权的受版权保护材料。

合规不是一句空话，而是 Agent 从 Demo 走向生产的最大门槛之一。

10. 总结

这套 AI Agent 教程真正值得跟的地方，不是某一段代码，而是它构建了一条“LLM 基础 -> RAG 知识库 -> MCP 工具 -> LangChain 组件 -> LangGraph 状态编排 -> 企业级项目”的学习路径。如果一个初学者直接去看官方文档，很容易被 LangChain 和 LangGraph 的版本差异劝退；按这条路径走，每一步都有明确的前置条件和输出目标。

建议你最先验证的是 RAG 最小闭环。文档加载、切分、检索、生成，这四个环节都跑通后，再往后学习 LangGraph 会有一种“原来多步任务就是状态图上的节点流转”的感觉。

最容易踩的坑有两个：一个是盲目追求最新版本依赖，导致教程代码跑不通；另一个是忽略效果评估，只追求“能出结果”。先固定版本，再建立 50 条问题的评测集，后面迭代会顺畅很多。

后续可以继续扩展的方向包括：把 MCP Server 接到更多企业内外部工具、用 LangGraph 实现多 Agent 协作、把 RAG 检索指标接入自动化回归测试，以及探索 Agentic RAG 这种“检索 + 多步推理”的混合模式。这四条路，每一条都足够你深入研究一段时间。