Agent开发学习路线：LangChain与LangGraph实战全解析

很多开发者面对Agent开发时，常被LangChain、LangGraph、MCP等名词绕晕，误以为每个新概念都要从头学一套。B站UP主“复返AI”在实战课程中给出了清晰的关系梳理：LangChain负责提供构建Agent的常用能力，LangGraph负责编排任务的执行流程，MCP则是连接外部系统的协议。三者配合，才能高效开发出能实际干活的Agent。本文基于该课程内容，整理出一条从模型工具接入到多智能体协作的完整学习路径。

三个核心概念的关系：别再重复造轮子

据B站UP主“复返AI”的讲解，LangChain是一套开发大模型应用的框架，它把接入模型、配置工具、根据工具返回结果决定下一步等常用能力组织起来，让开发者不必每次从头编写。比如做一个资料助手，模型负责理解查询意图，检索工具负责找资料，LangChain帮助把它们串成一个能执行任务的Agent。

LangGraph同样是开发框架，但更侧重任务的执行流程。一个任务有好几步，哪些按顺序做、哪些可以同时做、什么情况返回上一步、什么地方必须停下来等人确认，这些都可以用LangGraph来组织。同样是资料助手，查完资料要写报告，报告审核通过才能发送，没通过则返回修改，这就是LangGraph管理的流程。

两者的关系是配合使用：LangChain提供常用的Agent构建能力，其Agent底层也用到了LangGraph；当需要自己细致安排执行步骤时，可以直接用LangGraph来编排。而MCP是一套连接协议，解决的是“怎么对接外部能力”的问题——如果某个资料系统提供MCP服务，就可以通过支持MCP的客户端按统一规范接入它开放的工具和数据。至于具体做什么、按什么顺序做，仍然要由Agent和工作流来决定。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出并开源的连接协议，旨在为 AI 应用与外部数据源、工具之间提供一套标准化的通信规范。在 MCP 出现之前，每接入一个外部系统（如数据库、CRM、文件系统），开发者往往需要为其单独编写适配代码，形成大量重复且难以复用的“胶水层”。MCP 将这些对接方式抽象为统一的客户端-服务器模型：外部系统以 MCP Server 的形式暴露其工具和数据资源，Agent 端则通过支持 MCP 的客户端按统一接口进行调用。可以把它类比为 AI 应用领域的“USB 接口标准”——只要双方都遵循协议，连接就不再需要定制开发。需要注意的是，MCP 只负责“能不能连上、怎么连”，并不决定 Agent 的业务逻辑和执行顺序，后者仍由 LangChain/LangGraph 承担。

环境搭建与核心API：Create Agent是必须吃透的代码

课程演示了LangChain的基本安装部署。现在普遍使用LangChain的V1版本，要求Python 3.10以上，推荐用UV创建独立的Python虚拟环境，比Conda更轻量、灵活、易维护。安装时需要一并装上LangChain、LangGraph以及对应的模型接入包，比如LangChain DeepSeek^广告专门用于接入DeepSeek模型，此外还有OpenAI等第三方集成包，按需安装即可。

配置API Key后，课程重点讲解了create_agent这个核心API。对于LangChain 1.0大版本来说，它把Agent开发的核心环节封装在一个API里：你可以设置模型，在Tools列表中加载所有想给Agent使用的工具，再传入System Prompt。从最底层的角度看，一个Agent最核心的就是模型、工具和系统提示词，而create_agent把这些元素合理、稳定地融合在一起。未来与Agent对话时，底层就是调用模型、视情况启用工具、遵循System Prompt来完成回答。

UP主强调，这段代码是必须掌握的，其他技术细节可以交给AI编程辅助，但必须理解Agent最核心的底层API是如何实现的。

Agent Loop：所有复杂Agent的底层原理

安装和调用环节结束后，课程深入剖析了Agent Loop，也就是Agent运行时的基本概念。一个简单Agent的核心功能，就是一次又一次地循环调用工具，直到解决用户问题为止：用户问题输入后，模型判断是否需要调用工具，调用后把结果返回给模型，模型再看结果能否解决问题，能则回复用户，不能则继续调用工具。

UP主指出，很多复杂的Agent，比如Cloud Code动辄调用几十次工具、持续运行很长时间，底层仍然是这个Agent运行时架构，只不过在复杂情况下大循环里会嵌套小循环，甚至三层循环。理解Agent Loop对后续开发大有用处。

课程用一个智能客服场景的数据集做了演示，定义了订单查询、物流轨迹、运费计算、库存查询等函数作为外部工具集，然后用create_agent关联这些工具。演示中，当用户询问订单状态时，Agent会调用查询工具并返回结果；当用户提出“查物流状态并计算1.5公斤商品从北京到上海的运费”这类复合问题时，Agent会并行调用两个工具，分别查询并最终汇总结果。

理解 Agent Loop 时，一个关键概念是工具调用（Tool Calling / Function Calling）。它指大模型在生成回复时，不是直接输出自然语言答案，而是输出一个结构化的调用请求，指明要调用哪个函数、传什么参数。Agent 运行时收到该请求后，执行对应的真实函数（如查询订单数据库），再把返回值作为一条新消息送回模型，模型据此继续推理。正是这种“模型输出调用意图—外部执行—结果回传”的机制，让模型突破了仅凭训练知识作答的限制，能够获取实时数据和执行实际操作。工具调用的参数通常以 JSON Schema 描述，模型依据 Schema 决定如何填参，这也是为何工具的函数名、参数说明和描述写得越清晰，Agent 调用越准确。

工具调用的细节与后续学习路径

据课程演示，LangChain的封装程度很高，并行调用、多步调用都能自动处理，即使关联大量工具（约200个以内）也能顺利识别和调用，当前主流大模型也普遍具备这种能力。一些细节API只需了解：invoke用于批量运行，stream用于流式打印，前面加A的ainvoke和astream则代表异步运行。

完成工具接入后，Agent的雏形就出来了。课程后续的学习路径包括：加入记忆让Agent保留对话和偏好，处理状态管理记录任务进度，加入中间件记录调用和处理异常，设置人工介入让需要确认的动作先停下来。技术打好基础后，进入Agentic RAG和Deep Agents实战——前者让Agent根据任务决定何时检索、还需补哪些资料，后者提供规划、文件处理和子Agent等能力。最后是多智能体协作，看如何分工、交接，以及出错后如何沿执行过程定位问题。

UP主总结的开发思路是：从一个任务出发，判断需要哪些能力，再把它们组合起来；简单任务先用单个Agent完成，需要更复杂流程和协作时再逐步增加。这条课程要带大家建立的，正是这种组合能力的开发思维，而非死记硬背每个框架的细节。

对于想系统学习的同学，UP主表示完整实战课程已准备好，可在评论区留言获取。

Agentic RAG 是传统 RAG（检索增强生成）的演进形态。传统 RAG 的流程是固定的：用户提问后先检索固定数量的文档片段，再拼入提示词交给模型生成答案，检索与否、检索几次都在流程设计时写死。Agentic RAG 则把检索封装成 Agent 可调用的工具，由模型自主判断是否需要检索、检索什么关键词、结果是否足够、是否需要补充检索。这使得它更适合处理多跳问题（如先查产品规格再比对价格）和资料分散的场景，但也带来了检索次数不可控、延迟和成本上升的问题，通常需要配合最大轮次限制和兜底策略。

Deep Agents 指的是在基础 Agent Loop 之上叠加规划、任务分解、文件系统操作和子 Agent 派生等能力的增强型 Agent 架构。它与多智能体协作的区别在于：Deep Agents 通常仍由一个主 Agent 掌控全局，子 Agent 更像是被主 Agent 调用的一次性子任务执行单元，完成任务后结果回传给主 Agent；而多智能体协作则是多个具备独立角色和目标的 Agent 之间进行分工、交接与协商。前者适合长流程、需要中间产物落盘（如写代码、写报告）的任务，后者适合需要多视角或多专业领域配合的复杂业务。