LangChain+LangGraph+MCP+Agent：企业级AI应用开发实战

在企业级 AI 应用开发中，LangChain、LangGraph、MCP 与 Agent 是当前大模型应用落地绕不开的核心组合。很多开发者从 LangChain 入门，学完 Prompt 和 RAG 之后，却发现实际项目还要处理状态流转、循环控制、外部工具接入、多智能体协作等问题。LangGraph 补足了流程编排能力，MCP 统一了外部工具接入方式，Agent 再把模型、工具和流程组装成真正可用的产品。这篇文章围绕一条清晰主线展开：先拆解四个技术分别解决什么问题，再搭建学习环境，然后跑通一个包含工具调用和条件路由的最小闭环，最后接入一个 MCP 服务端，给出企业级落地时最该关注的配置、安全、可观测性和排查清单。内容不夸大成“一套课程包打天下”，而是按真实工程经验给出可学习、可复现、可排查的路径，适合正在做 AI 应用开发、想从简单模型调用升级到工程化方案的读者。

1. 先理清 LangChain、LangGraph、MCP、Agent 各自解决什么问题

这四个词经常被放在一起，但它们不是同层级的替代关系。LangChain 更像一套组件库，LangGraph 是一个流程编排引擎，MCP 是一种工具接入协议，Agent 是基于模型循环决策的运行时。理解清楚各自的边界，后面的代码才不会写成一锅粥。

1.1 LangChain 是工具链，不是单一框架

LangChain 解决的核心问题是“让大模型调用变得更工程化”。它把模型、Prompt、记忆、检索、工具都抽象成组件，开发者不需要为每个模型写一套重复的接入代码。

常见的 LangChain 组件包括：

• ChatPromptTemplate：管理 Prompt 模板
• ChatOpenAI/ChatOllama：统一模型调用入口
• Retriever：接收文档索引并返回相关内容
• Tool：把普通函数暴露给模型调用
• Memory：在对话中维护上下文状态

下面是一个最小模型调用示例，使用 LangChain Core 定义 Prompt，再调用一个 OpenAI 兼容接口：

from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI prompt = ChatPromptTemplate.from_messages([ ("system", "你是企业知识库助手。"), ("user", "{question}"), ]) llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) chain = prompt | llm response = chain.invoke({"question": "请用一句话说明什么是 RAG"}) print(response.content)

这里的prompt | llm使用 LangChain 表达式语言，把模板和模型串成一条可执行的链。实际项目里，链条中还可以插入 RAG、工具调用、输出解析器等节点。

需要区分的是，LangChain 本身不解决“流程复杂时如何跳转”的问题。比如一个任务需要先查数据库，再根据结果决定是否调用外部系统，用简单链写起来会非常别扭。这时需要 LangGraph 这样的编排层。

1.2 LangGraph 用有状态图来编排流程

LangGraph 的核心思想是：把一次 AI 任务看成一个状态图，每个节点是一个执行步骤，每个边是一条流转路径。节点可以访问和修改共享状态，图可以支持循环、条件分支、子图和并行节点。

LangGraph 和 LangChain 的直观区别可以从下面这个对比中理解：

维度	LangChain	LangGraph
定位	组件库、链式调用	图执行引擎、状态机
结构	Chain	StateGraph、节点、边
状态管理	依赖外部 Memory	内置 State 对象，节点间共享
循环和分支	不擅长	原生支持条件边和循环
适用场景	固定流程的 RAG、问答	需要自主决策、多步工具调用的 Agent

实际项目中，LangGraph 节点里常会复用 LangChain 组件。例如 LLM 节点内部用ChatOpenAI调用模型，检索节点内部用 LangChain 的Retriever获取知识。LangGraph 不取代 LangChain，而是解决它不擅长的编排问题。

1.3 MCP 让外部工具接入标准化

MCP（Model Context Protocol）可以理解为“给大模型应用配一个通用的 USB 接口”。没有 MCP 之前，每个外部系统接入模型应用时都要单独写一套 HTTP 接口、鉴权和参数转换逻辑。有了 MCP，服务端只需要按照协议暴露工具，客户端统一发现和调用工具。

MCP 体系里有几个基础概念：

• MCP Server：提供工具、资源或提示词的一方
• MCP Client：连接 Server 并发现工具的一方
• 工具发现：Client 从 Server 获取工具描述列表
• 工具调用：Client 把模型选择好的工具名和参数发送给 Server 执行

一个典型的场景是：企业内部有一个订单查询服务，MCP Server 把它封装成query_order工具，LangGraph Agent 通过 MCP Client 发现这个工具，模型判断用户问题需要查询订单时，自动填入参数并调用。

1.4 Agent 是决策循环的运行时

Agent 不是一个具体的大模型，而是一套“看到信息、选择工具、执行工具、获得反馈、再决策”的循环。模型在这个循环里发挥理解、判断和生成能力，工具则负责落地执行。

以 ReAct 思路为例：

1. 模型接收用户问题和系统提示。
2. 模型输出想法和下一步要调用的工具名及参数。
3. Agent 执行工具，把结果返回到消息列表。
4. 模型根据工具结果继续判断，是再次调用工具还是生成最终答案。

LangGraph 很适合实现这种循环，因为它允许图中存在环。每次模型返回tool_calls时就转到工具节点，工具执行完成后再回到模型节点，直到模型认为可以结束。

1.5 四者组合起来的企业级链路

在企业级项目中，四个技术的分工可以概括成一句话：LangChain 提供模型能力抽象，LangGraph 控制流程状态，MCP 统一工具接入，Agent 是产品入口。

一个典型链路如下：

1. 用户问题进入 Agent 入口。
2. LangGraph 状态中记录本轮消息。
3. LangChain 组件调用模型，得到文本或工具调用意图。
4. 如果模型需要查询知识库，走 RAG 检索节点。
5. 如果模型需要外部系统数据，通过 MCP Client 调用对应的 MCP Server 工具。
6. 工具结果回到模型中，模型生成最终回答。
7. LangGraph 根据结果从条件边分流转发，或结束流程。

这种组合适合智能客服、企业内部数据助手、知识库问答、自动化报表生成等场景。一个明显的收益是：新增外部系统不需要从业务代码写一套配套逻辑，只要按 MCP 协议提供 Server 即可；流程变化时也不用重写代码，改图结构和节点就能完成。

2. 环境准备与依赖安装

在实际动手写 Agent 之前，先把环境对齐。版本不一致是 LangChain 和 LangGraph 项目最常见的初期问题，建议用独立的 Python 虚拟环境，并固定生产依赖。

2.1 学习环境基本要求

推荐的学习环境如下：

项目	推荐要求	说明
Python	3.10 到 3.12	LangChain 和 LangGraph 对新版本支持较快，但生产环境不宜使用过于新的 Python
包管理工具	uv 或 venv + pip	建议用 uv，速度更快，锁文件也方便
模型服务	OpenAI 兼容接口或本地 Ollama	学习阶段可以用本地模型减少成本
操作系统	Windows / macOS / Linux 均可	命令有差异，但核心代码一致
外部服务	模型 API、可选的内存或磁盘存储	本地 MCP 示例不需要额外服务

如果使用云端模型，需要准备模型 API Key，并把 Key 写入环境变量，不要硬编码到代码里。如果使用本地模型，可以安装 Ollama，并提前下载一个小模型。

2.2 创建虚拟环境并安装核心依赖

先创建项目目录和虚拟环境：

mkdir langgraph-agent-demo cd langgraph-agent-demo python -m venv .venv source .venv/bin/activate

Windows PowerShell 下激活命令是：

.venv\Scripts\Activate.ps1

激活后安装核心依赖：

pip install --upgrade pip pip install "langchain" pip install "langchain-openai" pip install "langgraph" pip install "mcp" pip install "python-dotenv"

有些版本会把 LangChain Core 单独拆出来，但安装langchain时通常会自动带上。生产项目建议使用锁文件，例如uv lock生成固定版本，避免一段时间后重新安装时拿到不兼容的新版本。

安装完成后检查版本：

python -c "import langchain_core, langgraph, mcp; print(langchain_core.__version__, langgraph.__version__, mcp.__version__)"

如果某个模块找不到，说明当前安装的包名或版本组合有问题，要先解决依赖再继续。

2.3 模型服务选型

学习阶段最简单的做法是使用 OpenAI 兼容接口。很多模型服务商提供兼容端点，只需要修改base_url和模型名即可，代码不需要大幅改动。

在项目根目录创建.env文件：

OPENAI_API_KEY=your-api-key OPENAI_BASE_URL=https://api.example.com/v1 OPENAI_MODEL=gpt-4o-mini

然后在代码中加载环境变量：

import os from dotenv import load_dotenv load_dotenv() os.environ["OPENAI_API_KEY"]

如果使用本地 Ollama，模型调用部分改成：

from langchain_ollama import ChatOllama llm = ChatOllama( model="qwen2.5:7b", temperature=0, )

本地模型适合调试流程，但推理速度、上下文长度和工具调用稳定性通常不如云端模型。做 Agent 功能开发时，建议至少有一个支持工具调用的模型。

2.4 环境验证清单

在进入下一步之前，建议逐项确认环境，避免后面报错时无法快速定位：

检查项	检查命令或方式	预期结果
虚拟环境激活	which python或where python	路径指向项目下的.venv
依赖安装完成	pip list | grep langchain	能看到 langchain、langgraph、mcp
环境变量加载	在 Python 中打印OPENAI_MODEL	能输出配置值
模型接口连通	写一个最简单的invoke测试	能返回文本
MCP SDK 可用	python -c "import mcp; print(mcp.__version__)"	不报错

这一环节最容易犯的错误是：在全局 Python 环境里安装了依赖，然后激活虚拟环境后仍然提示模块不存在；或者在多个 Python 版本之间切换，导致pip安装到了另一个版本。先解决环境问题，再写代码，能省下大量排查时间。

3. 从 Prompt、RAG 到 Agent：先跑通最小闭环

很多教程把 LangGraph 讲得很复杂，但从工程角度看，先用一个最小 Agent 跑通模型、工具和状态图，再逐步增加节点，是最稳妥的路线。

3.1 构造一个基础 Agent 骨架

这里用一个简化版的 ReAct Agent 演示。它包含三个部分：模型节点、工具节点、条件路由。

首先定义共享状态：

from typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.prebuilt import ToolNode from langchain_core.messages import BaseMessage import json class AgentState(TypedDict): messages: Annotated[list[BaseMessage], "聊天消息列表"]

然后用一个函数作为工具。这个工具不做真实请求，只用于演示工具调用流程：

def get_today_weather(city: str) -> str: """查询城市天气的示例工具，返回模拟数据。""" weather_map = { "北京": "晴，18℃", "上海": "多云，22℃", } return weather_map.get(city, "暂无该城市数据")

为了让模型能调用这个函数，使用@tool装饰器：

from langchain_core.tools import tool @tool def get_today_weather(city: str) -> str: """查询指定城市今日天气。""" weather_map = { "北京": "晴，18℃", "上海": "多云，22℃", } return weather_map.get(city, "暂无该城市数据")

3.2 给 Agent 接入检索与工具调用

有了工具之后，把模型和工具绑定在一起。模型必须支持工具调用，才能知道什么时候应该把请求转给工具执行。

from langchain_openai import ChatOpenAI llm = ChatOpenAI(model=os.getenv("OPENAI_MODEL"), temperature=0) llm_with_tools = llm.bind_tools([get_today_weather])

再定义两个节点。模型节点负责调用模型，工具节点负责执行模型选择的工具：

def agent_node(state: AgentState): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def should_continue(state: AgentState): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return "end"

这里的关键判断是tool_calls。如果模型输出中带有工具调用参数，说明模型希望执行某个工具，需要跳转到工具节点；否则直接结束流程。

3.3 用 LangGraph 控制条件路由与循环

接下来把节点和边组装成图：

tool_node = ToolNode([get_today_weather]) graph = StateGraph(AgentState) graph.add_node("agent", agent_node) graph.add_node("tools", tool_node) graph.add_edge(START, "agent") graph.add_conditional_edges( "agent", should_continue, { "tools": "tools", "end": END, }, ) graph.add_edge("tools", "agent") app = graph.compile()

这里的流程是：

1. 用户消息进入agent节点。
2. 模型生成回答，如果包含工具调用，进入tools节点。
3. 工具执行后，把结果放回消息列表，再回到agent节点。
4. 模型根据最新消息继续决策，直到没有工具调用时结束。

调用一次：

from langchain_core.messages import HumanMessage result = app.invoke({"messages": [HumanMessage(content="北京今天天气怎么样？")]}) print(result["messages"][-1].content)

这个最小闭环已经具备 Agent 的核心能力。它可以执行工具，还能基于工具结果继续生成回答。真实项目中需要加一层循环次数限制，例如当模型连续多次调用工具时强制结束，避免失控。

LangGraph 中可以使用recursion_limit参数限制最大执行步数：

result = app.invoke( {"messages": [HumanMessage(content="北京今天天气怎么样？")]}, config={"recursion_limit": 10}, )

一旦超过限制，LangGraph 会抛出GraphRecursionError。这个限制是所有 Agent 项目都应该有的安全阀门。

4. MCP 接入：把外部工具变成 Agent 的扩展能力

工具函数写在 Agent 代码里，适合小项目和内部工具数量少的情况。当企业系统增多后，直接在代码里维护所有工具函数会变得困难：每个系统一个鉴权方式、一个接口风格、一种参数格式。MCP 的价值就在这里。

4.1 MCP 的工作机制

MCP 基于 JSON-RPC 2.0 通信。服务端和客户端之间可以通过标准输入输出（stdio）或 HTTP 传输，核心流程是：

1. MCP Server 启动，声明自己提供哪些工具。
2. MCP Client 连接 Server，发送tools/list获取工具清单。
3. Agent 把工具清单交给模型，模型在生成时选择要调用的工具。
4. MCP Client 收到模型选择的工具和参数后，发送tools/call给 Server。
5. Server 执行并返回结果。

MCP 和普通 Function Calling 的区别是：Function Calling 是模型推理层的能力，负责生成结构化调用参数；MCP 是应用集成层的能力，负责把外部工具统一暴露给 Agent。两者不是替代关系，而是配合关系。

4.2 实现一个简单的 MCP Server

下面是一个使用 Python MCP SDK 实现的极简 Server。它提供一个查询天气的模拟工具：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-weather-server") @mcp.tool() def get_weather(city: str) -> str: """查询城市天气。""" weather_map = { "北京": "晴，18℃", "上海": "多云，22℃", } return weather_map.get(city, "暂无该城市数据") if __name__ == "__main__": mcp.run()

假设文件名为weather_server.py，运行方式：

python weather_server.py

这个 Server 本身不依赖具体模型，它只是把get_weather函数变成符合 MCP 协议的工具。真实项目中，函数内部会调用真实业务系统接口，例如查询数据库或调用内部 API。

4.3 在 Agent 中注册和使用 MCP 工具

要让 LangGraph Agent 使用 MCP 工具，需要启动一个 MCP Client，并连接到刚才的 Server。不同版本的 MCP SDK 和 LangChain 集成方式有差异，这里给出一个流程示意：

import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def load_mcp_tools(): server_params = StdioServerParameters( command="python", args=["weather_server.py"], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools = await session.list_tools() # 将 MCP 工具转换成 LangChain 的 StructuredTool langchain_tools = [] for tool in tools.tools: langchain_tools.append(convert_mcp_tool_to_langchain(tool, session)) return langchain_tools

上面的convert_mcp_tool_to_langchain需要自己实现，核心逻辑是包装一个函数，函数内部调用session.call_tool。具体 API 会随版本变化，落地前要先查看当前版本官方的 MCP Client 示例。

转换成 LangChain 工具后，再交给ToolNode，后面的图结构不需要大改：

tool_node = ToolNode(langchain_tools)

这里要强调的是：不要把 MCP 工具和普通@tool函数混在一起写死。MCP Server 可能启动失败、超时或返回异常格式，Agent 需要定义好容错策略，否则一个外部系统挂掉，整个流程都会卡住。

4.4 MCP 联调验证方法

接入 MCP 后，先不要直接跑 Agent，可以先用一段单独脚本验证工具列表和工具调用是否正常：

import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params = StdioServerParameters( command="python", args=["weather_server.py"], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools = await session.list_tools() print("工具列表：") for tool in tools.tools: print(f"- {tool.name}: {tool.description}") result = await session.call_tool("get_weather", {"city": "北京"}) print(result) asyncio.run(main())

预期输出应该能看到get_weather工具，并且调用后返回模拟天气数据。如果这里不通过，问题通常出在 Server 启动命令、MCP SDK 版本或参数格式上。

问题现象	检查方向
工具列表为空	Server 是否用@mcp.tool()注册；MCP 版本是否匹配
连接超时	Server 进程是否正常启动；stdio 命令是否存在
调用返回错误	参数名是否和函数签名一致；Server 是否抛异常
中文乱码	终端编码是否设置为 UTF-8

5. 企业级落地要点：配置、安全、可观测性

把单个 Agent 跑通只完成了 20%。进入企业环境后，要考虑模型配置如何管理、工具权限如何控制、每次执行如何追踪。

5.1 配置外置与多环境管理

不要在代码里硬编码模型名、API Key、MCP Server 地址。使用.env、环境变量或配置中心管理配置，并区分开发、测试、生产三套环境。

推荐做法：

• 开发环境使用本地模型或测试 API。
• 测试环境使用固定版本模型，便于回归。
• 生产环境使用网关，支持模型切换和降级。
• 所有密钥走密钥管理服务，不进入代码仓库。

一个示例.env：

APP_ENV=dev LLM_BASE_URL=https://api.example.com/v1 LLM_MODEL=gpt-4o-mini MCP_SERVER_COMMAND=python MCP_SERVER_SCRIPT=weather_server.py AGENT_MAX_ITERATIONS=10

代码里统一读取，不要散落在各个模块。

5.2 权限控制与工具白名单

Agent 调用工具越方便，风险越大。企业落地时，必须考虑三层权限：

层级	控制内容
用户层面	不同角色能使用哪些 Agent 流程
工具层面	每个 Agent 暴露哪些 MCP 工具
参数层面	工具参数是否允许用户直接输入，是否需要校验白名单

例如，联网搜索工具对普通员工开放，但写数据库工具只对管理员开放。MCP Server 内部也要做鉴权，不能因为 Agent 调用了接口就认为请求可信。

另一个容易被忽略的点是：工具返回的内容可能包含敏感数据。Agent 不应该无条件把内部系统返回值原样输出给用户，需要做脱敏或权限裁剪。

5.3 日志、追踪与评估

生产 Agent 必须能回答三个问题：它做了什么、为什么这样做、花了多少成本。

建议在每个关键节点记录结构化日志：

{ "event": "tool_call", "agent_id": "customer-service-01", "user_id": "u_10001", "tool_name": "get_weather", "tool_args": {"city": "北京"}, "tool_result": "晴，18℃", "duration_ms": 120, "token_count": 320 }

同时记录模型每步的输入和输出，尤其是tool_calls内容。这样一旦出现错误回答，可以回溯是哪一步判断错了。

评估 Agent 不能只看最终答案，还要看过程指标：

• 任务完成率
• 工具调用成功率
• 平均对话轮数
• 单次任务 token 消耗
• 关键节点超时次数
• 用户对回答的反馈评分

这些指标可以放入日志系统或评估平台，用于后续 Prompt 和工具调优。

5.4 从 Demo 到生产的技术差距

维度	Demo	生产
模型	单一模型	多模型路由、降级、灰度
请求量	低频	限流、排队、缓存
稳定性	失败直接报错	重试、熔断、降级
安全	无鉴权	身份和工具权限校验
可观测性	print 日志	结构化日志、链路追踪、指标
数据合规	不敏感数据	脱敏、审计、删除策略
发布	手动重启	镜像、滚动发布、回滚

如果要从 Demo 走向生产，建议先把“稳定性和可观测性”放在功能开发之前。Agent 是概率系统，不可能保证每次输出一样，因此生产环境必须有日志和评估机制兜底。

6. 常见问题排查

下面列出 Enterprise 开发中最常见的四类问题。排查时先看输入、再看配置、再看依赖、最后看日志。

6.1 工具调用失败或返回空结果

现象：模型表示要调用某个工具，但最终回答里显示找不到工具返回内容，或者直接报错。

可能原因：

• 工具注册时函数名和模型生成名不一致。
• 工具参数描述不清晰，模型传了不存在的参数。
• MCP Server 返回结构不是 Agent 预期的格式。
• 工具内部抛异常，但没有被捕获。

检查方式：

• 打印模型输出的tool_calls。
• 打印ToolNode执行前后的消息列表。
• 单独调用工具函数，确认返回值能正常被 LangChain 解析。

处理建议：工具函数本身要轻量、有明确异常返回；不要让工具抛裸异常，否则会把流程中断。

6.2 Agent 陷入循环或超时

现象：Agent 不停调用工具，重复做类似操作，直到recursion_limit报错或任务超时。

可能原因：

• 工具执行结果没有改变模型决策条件。
• Prompt 没有告诉模型什么时候停止。
• 工具返回内容太长，模型在长上下文里判断混乱。
• 模型能力不足，总是给出错误工具调用。

检查方式：

• 查看日志中每轮的tool_calls是否重复。
• 检查工具结果是否有效进入下一轮消息。
• 统计超过 5 轮的工具调用比例。

处理建议：

• 设置recursion_limit。
• 在 Prompt 中明确要求“直到得到充分信息后回答”。
• 对相似工具做合并，减少模型选择难度。
• 对工具调用次数设置业务阈值，例如最多 3 次失败后强制结束。

6.3 依赖版本冲突

现象：import langgraph报错，或者方法不存在。

原因：LangChain、LangGraph、MCP 都是迭代较快的库，不同版本之间 API 有差异。网上很多示例代码写的是旧版本 API，直接复制到新环境就会报错。

检查方式：

pip freeze | grep -E "langchain|langgraph|mcp|openai"

处理建议：

• 固定版本，不要使用pip install langgraph的默认最新版。
• 以官方文档中的版本为准，学习代码时先确认示例对应的版本。
• 如果旧项目升级，先看版本迁移说明，不要盲目升级。

6.4 模型上下文超限

现象：错误信息中出现 context length、token limit 等关键词。

可能原因：

• 历史消息累积太多。
• 单次工具返回结果太大。
• Prompt 模板内容过长。

处理建议：

• 对历史消息做摘要或裁剪。
• 工具返回大文档时，先做分块或只返回关键字段。
• RAG 检索结果做重排序和限量。
• 将不重要的历史消息移出模型输入，存入外部 Memory。

6.5 排查顺序备忘

遇到 Agent 问题，按以下顺序检查：

1. 输入消息是否正确。
2. 环境变量是否加载。
3. 模型是否支持工具调用。
4. 工具注册是否正确。
5. 图结构和条件边是否配置正确。
6. 是否超过了递归限制。
7. MCP Server 日志是否输出异常。
8. 模型输出和工具结果是否被正确传递。

7. 最佳实践与学习路线

7.1 新手最容易踩的坑

写了不少项目后，发现新手在 LangChain、LangGraph、MCP 这条路上最容易踩的坑有四个：

第一，把 LangGraph 当作 LangChain 的替代品去学。结果是学了图状态，却不知道图节点里大量复用 LangChain 组件。正确思路是先掌握 LangChain 的模型、工具、RAG 组件，再用 LangGraph 把它们组织到流程里。

第二，一开始就模仿官方大而全的 Agent 模板。模板代码包含很多抽象层，新手改不了几行就跑不起来。建议从最小StateGraph开始，用print看到每一步的消息流动，再逐步增加节点。

第三，不处理循环边界。Agent 的核心就是循环，但循环没有上限，生产环境会耗尽 token 和资源。一定要设置最大迭代次数，并对工具调用时间做超时。

第四，把 MCP Server 权限开得过大。MCP 本身只是协议，不解决安全。给 Agent 接入 SQL、文件、支付等工具时，必须做角色权限和参数白名单校验，否则一个提示词注入就可能造成风险。

7.2 推荐的项目演进路径

如果你想系统学习并能写到简历或公司项目里，建议按五个阶段推进：

阶段	练习目标	参考实现
阶段一	Prompt 工程和单轮模型调用	写不同行业客服 Prompt，对比输出差异
阶段二	加入 RAG	用本地文档做向量检索问答
阶段三	单 Agent 多工具	实现天气、订单、待办查询工具
阶段四	LangGraph 条件路由	让 Agent 根据问题类型走不同子流程
阶段五	MCP 标准化接入	写一个独立 MCP Server，接入 Agent

每个阶段都要保留一个可运行项目，不要只刷视频。代码能跑通、能改、能解释，才是真正掌握。

7.3 企业内部推广建议

如果团队要一起从零建设这类能力，不要直接铺开，先选一个低频、低风险、价值清晰的业务场景试点，例如知识库问答或日常报表生成。试点时把日志、评估、权限边界一次性搭好，再考虑扩大到更多工具和流程。

同时要管理好预期：Agent 不是万能的，它适合“有规则可查、有工具可用、需要多步判断”的任务，不适合完全开放式、无边界、结果必须 100% 准确的场景。任何 Agent 上线前，都要准备一条降级路径，例如模型失败时转人工客服或返回预设兜底话术。

总结与下一步建议

这四类技术串起来以后，LangChain 降低模型接入成本，LangGraph 解决流程编排复杂度，MCP 统一工具接入规范，Agent 把模型、工具、外部系统组装成产品。最难的不是把一条最快路径跑通，而是让这套系统在真实业务中稳定、可控、可观测。

你可以从最小天气 Agent 开始，把 LangGraph 的节点和边读懂；再写一个自己的 MCP Server，把工具从代码里拆出去；最后加入日志、权限和评估机制，把它改造成一个可以给业务团队试用的小工具。每一步都动手跑一次，比看十遍课程更有效。