AI Agent 的资料现在很多但多数要么只讲一个组件要么直接从某个框架的 Hello World 开始。真正把 RAG、MCP、LangChain、LangGraph 串成一条完整技术链路再落回企业级项目场景的内容反而很少见。这次我们要梳理的这套方法核心价值就是解决这个问题它不以单个 API 演示为目标而是按“知识库检索 - 工具接入 - 应用组装 - 智能体编排 - 项目落地”的完整路径来组织。如果你正在学 AI Agent或者准备在公司里做一个真正能用的智能体项目建议先把这条技术栈的边界和顺序搞清楚。RAG 负责让模型“知道该查什么”MCP 负责让 Agent“能操作什么”LangChain 负责把组件拼起来LangGraph 负责把流程控住。它们不是互相替代的关系而是同一套系统里的不同层次。这篇文章会把这四个模块分别讲清楚再用一个企业级项目案例说明如何整合最后给出环境准备、最小验证、常见问题和工程化建议。本文适合三类读者第一类是已经会调用大模型 API但不知道如何组织复杂业务逻辑的开发者第二类是做过简单 RAG 问答想从 Demo 走向生产环境的工程师第三类是准备面试或者写技术方案需要系统性理解 Agent 技术栈的人。1. 全套知识地图RAG、MCP、LangChain、LangGraph 到底在解决什么问题很多人学 AI Agent 学不下去不是因为模型多难而是因为组件之间的关系没有建立起来。每个框架都在快速迭代今天学的 API 明天可能就变了。但只要你能分清每个模块在整个系统中的位置就不会被版本带着跑。先给一张总览表技术栈主要作用典型问题关键概念RAG检索增强生成给模型补充外部知识模型不知道私有知识、回答容易幻觉文档切分、向量化、召回、重排、指标评估MCP模型上下文协议规范 Agent 与外部工具/数据源的连接每个工具一套接入方式难以复用MCP Server、MCP Client、Tool 定义、资源权限LangChainLLM 应用开发框架提供基础组件和编排能力手动拼接 Prompt、调用、解析太繁琐Prompt、Model、OutputParser、Retriever、Tool、ChainLangGraph有状态的 Agent 编排引擎控制智能体执行流程Agent 流程不可控、循环容易卡死、状态难管理StateGraph、Node、Edge、Conditional Edge、子图、持久化Agent智能体本体负责理解目标、规划步骤、调用工具、评估结果动态任务无法用固定流程写死规划、工具调用、记忆、反思、终止条件理解这张表的正确方式不是问“RAG 好还是 Agent 好”也不是“LangChain 是不是要被 LangGraph 替代”。更准确的关系是RAG 是知识供给链路MCP 是工具连接标准LangChain 是组件抽象层LangGraph 是流程执行层。Agent 是最终形态它需要前面所有模块配合。LangChain 和 LangGraph 的区别常常让人困惑。从设计定位看LangChain 聚焦“将模型调用封装成链式组件”适合线性、确定的流程LangGraph 聚焦“图状态机编排”适合带分支、循环、回退的复杂流程。实际项目中完全可以在 LangGraph 的节点内部使用 LangChain 的 Retriever、Prompt 和 Model 组件两者不是竞争关系。另一个需要区分的概念是 RAG 和 Agentic RAG。传统 RAG 是固定的“检索一次、生成一次”Agentic RAG 则让 Agent 自主决定是否需要检索、分几步检索、如何根据检索结果调整下一步。从知识库问答到企业级 Agent最常见的技术升级路径就是先做标准 RAG再把检索节点嵌入 LangGraph让流程变得更智能。2. RAG 模块知识库问答的核心链路RAGRetrieval-Augmented Generation是整套体系里最独立也最容易验证的模块。它解决的核心问题是模型没有训练过的私有知识如何通过检索补充进去。2.1 RAG 的标准流程一个可落地的 RAG 链路通常包含以下环节文档加载从 PDF、Word、Markdown、HTML、数据库等来源读取内容。文档切分把长文本切成适合检索的 Chunk切分策略直接影响召回效果。向量化用 Embedding 模型把每个 Chunk 转成向量。存储把向量写入向量数据库同时保存原文和元数据。检索根据用户问题生成查询向量做相似度检索。重排可选对召回结果做二次排序把最相关内容排到前面。生成把检索到的上下文和用户问题一起交给大模型要求它基于上下文回答。很多人做 RAG 效果不好问题不一定出在模型而更多是切分策略和检索质量的问题。比如一段产品文档被硬切成 512 字符的小块完整的产品参数被拆到两个 Chunk回答自然残缺。更合理的做法是优先按标题层级切分再结合段落语义做二次合并。2.2 RAG 知识库指标怎么看热搜里提到“RAG 知识库指标有哪些、如何理解”这块在项目验收时很关键。常见的评估维度包括指标类别代表指标说明检索效果召回率、命中率、MRR、NDCG判断正确答案是否在召回结果中以及排序是否靠前生成效果忠实度、相关性、完整性判断回答是否忠于检索内容是否答非所问系统效果响应延迟、首 Token 时间、端到端成功率判断线上是否可用成本Token 消耗、向量库存储量判断长期运行成本判断 RAG 系统是否可用不要只看“回答得像不像”要拆开看检索环节能召回正确答案吗生成环节有没有忠实使用召回内容如果检索没召回生成模型再强也答不出来如果召回了但生成时没用那就是 Prompt 或上下文组织的问题。2.3 RAG 最小实现示例下面给一个常见实现结构基于 LangChain 系列组件核心目的是把流程跑通。不同版本组件路径可能有差异实际运行时以你安装的版本为准。# 示例基于 LangChain 的 RAG 最小链路 from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 加载文本 with open(knowledge.txt, r, encodingutf-8) as f: text f.read() # 2. 切分 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_text(text) # 3. 向量化并存储 # 这里使用向量数据库客户端具体 API 以实际库为准 # vectorstore.add_documents(documents) # 4. 检索 # docs vectorstore.as_retriever().invoke(产品支持哪些协议) # 5. 构造 Prompt 并调用模型 # prompt ChatPromptTemplate.from_template(基于以下资料回答问题\n{context}\n问题{question})上面代码省略了向量库和模型调用细节目的是先建立流程感。实际落地时需要根据选用的向量数据库、Embedding 模型和大模型 API 替换对应部分。RAG 项目里最容易出问题的是 Embedding 模型。中文场景下Embedding 模型的选择会直接影响相似度检索效果。建议在生产环境里准备一组真实问答对分别用不同 Embedding 模型跑一遍召回率用数据而不是感觉来做选择。3. MCP 模块让 Agent 安全地操作外部工具MCPModel Context Protocol是当前 AI Agent 生态里非常重要的协议层。它解决的问题非常实际Agent 需要调用数据库、日志系统、浏览器、设计稿、代码仓库等外部工具如果每个工具都单独实现一套调用协议Agent 的接入成本就会失控。3.1 MCP 的角色MCP 采用 Client-Server 结构MCP Client运行在 Agent 侧负责发现可用的 MCP Server、调用工具、接收结果。MCP Server封装具体能力比如文件系统、Elasticsearch、Playwright 浏览器控制、蓝湖设计稿查询、Figma、IDA Pro 等。ToolMCP Server 对外暴露的原子能力有名称、描述、输入参数和返回结果。对 Agent 来说MCP 的价值在于标准化。Agent 不需要关心某个工具是 Java 写的还是 Python 写的也不需要关心它的鉴权方式。只要目标是“帮我查一下 ES 里最近一小时的错误日志分布”Agent 就能根据 MCP Server 暴露的 Tool 描述自动生成参数并调用。常见可接入的 MCP Server 包括MCP Server能力场景文件系统读取、写入、搜索本地文件Elasticsearch查询日志、聚合分析、获取索引信息Playwright控制浏览器执行页面操作蓝湖 / Figma读取设计稿、标注信息、切图资源数据库执行受控的只读 SQL 查询IDA Pro逆向分析场景的脚本化操作3.2 MCP 工具定义与接入下面的示例展示如何在一个 MCP Server 里声明一个日志查询工具。不同 MCP SDK 写法会有差异这里只表达结构。# 示例MCP Server 中声明一个 Tool 的常见结构 # 具体导入路径和装饰器写法以你使用的 MCP SDK 为准 from mcp.server.fastmcp import FastMCP mcp FastMCP(log-analysis) mcp.tool() def query_es_logs(index: str, query: dict, time_range: str) - str: 查询 Elasticsearch 日志索引。 Args: index: 日志索引名称。 query: 查询条件。 time_range: 时间范围例如 1h。 # 实际实现替换为你的 ES 客户端调用 return 查询结果 if __name__ __main__: mcp.run()企业里接入 MCP 时建议先把 MCP Server 封装在独立服务内只暴露受控能力。不要把数据库的完整写权限直接暴露给 Agent更不要让 Agent 直接操作生产环境。MCP 解决的是“能不能调用”的问题但“该不该调用”需要 Agent 应用层做权限校验。4. LangChain 模块LLM 应用的组件化组装LangChain 在整套体系里的角色是提供一套通用的 LLM 应用组装抽象。它把 Prompt 管理、模型调用、输出解析、记忆、检索器、工具调用等操作封装成可组合的组件。即使你最终用 LangGraph 做流程编排也依然可以在节点内部使用 LangChain 的组件。4.1 核心组件LangChain 的核心概念包括ChatPromptTemplate结构化 Prompt 模板支持系统消息、用户消息、上下文变量注入。ChatModel / LLM统一封装不同厂商的模型调用比如 OpenAI、Anthropic、本地模型。OutputParser把模型输出解析成结构化内容比如 JSON、列表。Retriever封装向量检索给 RAG 提供统一接口。Tool封装外部函数供 Agent 调用。Memory管理多轮对话的历史记录。Chain / Runnable把多个组件串成执行链。4.2 LangChain 适合做什么LangChain 适合确定性强的链路。比如“问题 - 检索 - 组装 Prompt - 调用模型 - 输出解析”这种流程用 LangChain 很顺手。它的组件抽象可以让你在不同模型、不同向量库之间切换减少业务代码改动。但 LangChain 不适合需要复杂分支、循环和状态管理的流程。比如一个 Agent 需要先判断问题是否需要检索再决定调用哪个工具工具结果异常时还要重试或换方案这种流程如果硬用 Chain 拼代码会非常难维护。这也正是 LangGraph 存在的理由。LangGraph 把流程从“链”升级为“图”每个节点是一个执行单元节点之间有明确的流转关系可以支持条件路由、循环、并分支和子图。5. LangGraph 模块有状态 Agent 编排的核心LangGraph 是当前做企业级 Agent 编排时非常值得投入的技术方向。它和 LangChain 的区别可以概括为LangChain 强调“组件怎么组织”LangGraph 强调“流程怎么控制”。5.1 LangGraph 的核心概念用 LangGraph 构建一个 Agent通常要理解以下概念概念作用StateGraph对 Agent 执行流程建模核心是维护一个全局 StateState跨节点传递的数据结构比如问题、检索结果、中间判断、最终回答Node执行单元每个 Node 接收 State 并返回 State 的增量Edge节点之间的连接表示正常流转Conditional Edge条件分支根据 State 数据决定下一步走向哪个节点子图把一个复杂流程封装成独立图主图可以调用它持久化保存 Agent 执行状态支持断点续跑、人工审核、恢复执行并行分支多个节点同时执行适合多个独立工具调用5.2 LangGraph 条件路由示例下面是一个简化示例体现“先判断是否走 RAG再生成回答”的流程。不同版本 API 可能有变动请以官方文档为准。from typing import TypedDict, Literal from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): question: str need_rag: bool context: str answer: str def plan_node(state: AgentState) - AgentState: # 实际项目中这里可以调用意图识别模型或规则判断 need_rag 内部知识 in state[question] or 文档 in state[question] return {need_rag: need_rag} def rag_node(state: AgentState) - AgentState: # 调用向量检索产出上下文 context 这里是检索到的资料摘要 return {context: context} def direct_node(state: AgentState) - AgentState: # 不检索直接回答 return {context: } def answer_node(state: AgentState) - AgentState: # 把问题和上下文一起交给大模型生成回答 answer f生成结果上下文长度为 {len(state[context])} return {answer: answer} def route(state: AgentState) - Literal[rag_node, direct_node]: return rag_node if state[need_rag] else direct_node graph StateGraph(AgentState) graph.add_node(plan_node, plan_node) graph.add_node(rag_node, rag_node) graph.add_node(direct_node, direct_node) graph.add_node(answer_node, answer_node) graph.add_edge(START, plan_node) graph.add_conditional_edges(plan_node, route) graph.add_edge(rag_node, answer_node) graph.add_edge(direct_node, answer_node) graph.add_edge(answer_node, END) app graph.compile() # 实际运行 result app.invoke({question: 帮我查一下内部文档中的权限说明}) print(result[answer])这段代码体现的就是条件路由根据need_rag的布尔值把流程导向不同分支。企业级 Agent 里route函数通常不是一个简单的关键词判断而是由模型决策或者规则引擎触发的。5.3 LangGraph 为什么适合企业级企业级 Agent 和 Demo 最大的区别在于可控性和可恢复性。Demo 只需要跑通一次成功路径企业级必须考虑失败情况。LangGraph 提供的有状态执行模型让每一步都有明确的输入输出和状态记录。Agent 执行到一半失败时可以基于持久化状态恢复而不是从头再来。对于需要人工审核的流程比如财务报销、内容审批可以在 Agent 执行到某个节点后暂停等待人工确认再继续。另外LangGraph 的并行分支能力很适合多工具并行场景。例如在一个“客户服务 Agent”里需要同时查订单状态、查物流信息、查售后政策这三个检索相互独立可以并行执行再汇总显著降低整体延迟。6. 企业级实战设计用一个智能日志分析 Agent 打通全链路前面几个模块单独都容易理解但真正有价值的是把它们组合起来。这里设计一个案例企业智能日志分析 Agent用来演示 RAG、MCP、LangChain、LangGraph 如何在同一个项目里协同。6.1 场景与目标运维团队每天需要从 Elasticsearch 中查询大量应用日志定位报错、分析趋势、排查根因。传统做法是人工写 DSL 查询门槛高、效率低。我们希望做一个 Agent让用户直接用自然语言提问Agent 自动完成理解用户意图判断是否需要查询 ES。通过 MCP Server 调用 ES API执行日志检索。对检索结果做聚合分析。结合团队内部的排障文档RAG 知识库给出结论与建议。如果原始日志不足以判断Agent 可以继续追问条件或扩大时间范围。6.2 流程设计用 LangGraph 来编排这个 Agent 的流程可以设计为节点输入输出说明意图识别用户问题、历史状态是否查日志、目标索引、时间范围用大模型或规则解析RAG 知识检索用户问题相关排障文档片段查内部文档库MCP 日志查询查询参数ES 返回的原始日志走 MCP Server 调用结果分析原始日志、知识文档根因建议、置信度大模型综合判断结果复核分析结果可执行答复必要时进入人工审核节点在这个流程里RAG 负责提供“团队内部的排障经验和已知问题库”MCP 负责把“ES 查询能力”安全地开放给 AgentLangChain 负责组装 Prompt 和解析模型输出LangGraph 负责把整个流程串成有状态、可恢复、可审核的图。6.3 工程化要点从 Demo 到这个项目至少要多考虑下面几点权限控制不是所有用户都能查询所有索引。MCP Server 层要按用户角色校验索引范围。数据脱敏日志中可能包含手机号、身份证、Token 等敏感信息查询结果返回给模型前要脱敏。查询审计记录每一次 Agent 触发的 ES 查询方便事后追溯。失败重试ES 超时、索引不存在、查询语法错误都需要明确的重试和降级策略。人工介入对于“根因分析”这种高风险结论默认走人工审核节点。这样的设计也体现了 MCP 和 Agent Skill 的区别。MCP 更多是工具连接协议解决“怎么连”Agent Skill 更偏重封装“某个任务的完整做法”。实际项目里通常两者配合使用MCP 提供原子能力Skill 提供可复用的任务模板。7. 环境准备与最小验证学习这套技术栈不建议一开始就上很重的生产架构。先用最小环境把链路跑通再逐步加复杂度。7.1 环境准备清单建议按以下清单检查环境检查项建议Python3.10 及以上创建独立虚拟环境大模型 API准备可用的 API Key或本地部署推理服务Embedding 模型准备中英文效果较好的模型或调用远端 Embedding API向量数据库可选先跑通内存版或轻量级库再上正式环境Node.js仅在使用部分 MCP 生态工具时需要Docker企业级部署建议准备但不是本地学习必需7.2 安装命令示例下面是一个通用安装示例。LangChain、LangGraph 版本更新较快建议先确定主版本再按官方文档安装对应依赖。python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install langchain langchain-openai langchain-text-splitters pip install langgraph pip install mcp如果使用本地模型或者向量库需要额外安装对应依赖比如sentence-transformers、chromadb等。不要在全局环境里直接装免得和其他项目冲突。7.3 最小验证顺序第一次跑通这套体系建议按以下顺序验证验证 LangChain用 Prompt 模板 大模型 API 跑通一个最简单的问答。验证 RAG准备一段文本切分后手动检索确认能召回正确内容。验证 MCP启动一个打印 Hello World 的 MCP Server确认 Agent 能发现并调用它的 Tool。验证 LangGraph运行前面的条件路由示例确认流程能按预期走到不同分支。组合验证把 RAG 检索节点和 MCP 工具节点放入同一个 LangGraph 图里跑通端到端。每步验证通过后再进入下一步不要一次把所有组件全部接上。版本报错时优先看官方文档的迁移说明很多改动只是 API 路径变了核心概念没变。8. 常见问题与排查方法学习这套技术栈时会遇到很多问题下面整理高频问题问题现象可能原因排查方式解决方案安装依赖失败Python 版本不兼容、依赖冲突查看报错栈确认 Python 版本创建新虚拟环境按官方文档指定版本安装模型调用报 401/403API Key 无效或过期检查环境变量和 Key 配置重新配置 Key确认网络可以访问模型服务RAG 检索效果差Chunk 切分不当、Embedding 模型不匹配抽样检查召回结果调整切分策略替换 Embedding 模型增加重排向量库连接失败服务没有启动、端口被占用检查端口和日志重启服务更换端口LangGraph 报错版本 API 变动、State 结构不匹配查看官方文档迁移说明按新版本 API 调整节点和边写法Agent 进入死循环终止条件设计不当查看状态流转日志增加最大步数限制设计明确的终止节点工具调用参数错误大模型生成的参数不符合 Tool Schema记录模型输出检查 Tool 描述优化 Tool 描述增加参数校验回答不忠实于知识库Prompt 没有约束模型只使用上下文检查生成所用 Prompt强制要求“仅基于资料回答资料不足请说明”上下文过长检索结果太多或历史记录过长统计 Token 消耗限制召回数量压缩历史记录生产环境数据泄露风险未做脱敏和权限控制审计日志和接口权限在 MCP 层做索引白名单响应内容脱敏排查问题的时候先确认“当前是在验证哪个环节”不要在一个混合链路里盲猜。建议每个节点都输出结构化日志记录输入、输出、耗时和 Token 消耗。9. 最佳实践与落地建议把这套技术真正用到项目里有几个工程习惯很关键。9.1 先小参数验证再放大规模第一次跑 Agent 流程时检索条数、模型温度、历史轮数都用保守参数。确认链路稳定后再逐步放大。尤其是批量任务场景先跑 3 到 5 条数据看结果再决定是否全部放开。9.2 用指标管理 RAG 和 Agent 效果RAG 不要只靠“觉得回答不错”来验收。把真实问答对建成评测集分别计算检索命中率和生成忠实度。Agent 也要记录“单次任务是否成功”“平均调用工具次数”“是否出现死循环”。有了这些数据后续优化才有依据。9.3 数据安全与合规优先涉及企业日志、用户数据、知识库内容时务必注意先在测试环境使用脱敏数据确认流程无误再考虑真实数据。MCP Server 只暴露最小必要权限不提供通用写接口。外部工具调用要记录审计日志。使用版权内容、内部文档、人脸和声音等素材前确保有授权。对外发布或商用前对模型输出做人工复核。9.4 保持可观测性Agent 比普通接口更依赖可观测性。为每个节点记录状态变更、耗时和异常条件路由的关键判断要输出原因工具调用要记录请求参数和返回摘要。对于一个复杂的 LangGraph Agent能回放执行轨迹比能“重新调用一次”重要得多。9.5 不要把所有逻辑塞进 PromptAgent 能力强但把业务规则全写在 Prompt 里会导致难以维护。稳定规则用代码实现动态策略用 Prompt 控制只有真正需要模型判断的内容才交给模型。这样既提高稳定性也降低 Token 成本。10. 总结与下一步这套技术栈最值得投入的地方不是某个 API 的写法而是建立完整的工程视角。RAG 解决知识供给MCP 解决工具接入LangChain 解决组件组装LangGraph 解决流程控制。把它们串起来AI Agent 才能从“能聊天”走向“能干活”。建议从三个动作开始一是用 RAG 跑通一个私有知识库问答二是用 MCP 接入一个真实工具三是用 LangGraph 把这两个模块画进一张状态图。最容易踩的坑是版本兼容和边界混淆碰到问题先定位技术栈层次再查对应文档。后续可以继续扩展的方向包括多 Agent 协作与任务分配、Agent 执行结果自动评估、面向具体业务场景的 Agent Skill 封装、以及把 LangGraph 流程接入人工审核机制。建议把这些留到下一阶段逐步深入。