如果你写过一段时间大模型应用大概率会遇到这样一个场景Prompt 写得挺顺RAG 流程也跑通了模型也能给出看起来不错的回答。但一旦让它去查数据库、调内部系统、操作某个网页工具整个 Agent 就变得很僵硬。要么是每个工具都要单独写一套调用代码要么是换了模型之后工具调用全部失效要么是项目里的工具多了以后代码乱到根本不敢加新功能。这个痛点的根源不在模型能力而在工具接入方式。2026 年再谈大模型应用开发LangChain 与 MCP 的组合已经绕不开了。LangChain 解决的是 Agent 的编排、记忆、规划和多模型适配MCP 解决的是 Agent 与外部工具之间的标准化连接。两者配合之后工具可以像 USB 设备一样即插即用Agent 才能从“聊天机器人”变成真正能干活的应用。这篇文章不打算重复官方的 API 文档而是从实际开发的角度把 LangChain 与 MCP 的核心概念、组合方式、完整代码实战、常见坑位和生产环境建议一次讲透。无论你是刚开始学 LangChain 的新手还是已经写过 Agent 但还没接 MCP 的开发者这篇文章都值得收藏。1. LangChain 与 MCP两个经常被误解的技术先说一个判断LangChain 没有过时它只是从“包罗万象的框架”变成了“Agent 编排底座”。很多人看到 LangChain 早期版本 API 频繁变动就认为这个项目不行了。但实际情况是LangChain 已经拆分成了 langchain-core、langchain、langchain-community、langchain-openai 等一系列子包结构更清晰了也更适合作为 Agent 应用的骨架层。MCP 则是一个协议全称是 Model Context Protocol中文可以理解为“模型上下文协议”。它由 Anthropic 在 2024 年底提出目标是统一 AI 应用与外部数据源、工具之间的交互方式。到了 2026 年MCP 已经不只是某个模型的专属协议OpenAI、Google、各大 IDE、各类低代码平台都在支持或兼容它。这两个技术经常被放在一起讨论原因是它们在 AI 应用架构中处于不同层次LangChain 管的是“大脑如何思考”对话流程、工具选择、记忆管理、任务规划。MCP 管的是“手脚如何接入”工具怎么被描述、怎么被调用、怎么返回结果。如果用传统软件开发类比LangChain 类似 Spring 里的控制层和服务层MCP 类似 JDBC、ODBC 这类数据库访问标准。JDBC 不关心你的业务逻辑怎么写但它定义了 Java 程序连数据库的统一方式。MCP 也不关心你的 Agent 怎么规划任务但它定义了 AI 应用调用工具的统一方式。这篇文章要解决的核心问题有三个第一MCP 到底是什么它和 Function Calling、插件、Agent Skill 的区别在哪里。 第二如何用 LangChain 接入一个真实可用的 MCP Server跑通一个完整案例。 第三生产环境中使用 LangChain MCP 有哪些容易踩的坑以及正确的工程姿势是什么。2. 核心概念LangChain 的模块划分与 MCP 的协议设计2.1 LangChain 到底提供了什么LangChain 不是一个单一的大模型框架而是一套组件化工具集。它的核心模块大致可以分成六个方向模型接口Model I/O统一封装 OpenAI、Claude、国产大模型等各种模型的调用方式包括 Prompt 模板、输出解析器。检索增强Retrieval各种向量库、文档加载器、切分器、Embedding 模型的对接。Agent 与工具Agents Tools让模型根据用户需求自动决定调用哪些工具以及如何处理工具返回结果。记忆Memory保存历史对话、短期记忆、长期记忆。编排Chains 与 LangGraph把多个步骤串联或组织成图结构。回调与集成Callbacks/Integrations日志、监控、第三方框架对接。在 LangChain 的早期版本里Chain 是核心抽象我们现在则更推荐基于 LangGraph 做 Agent 流程编排。LangGraph 适合处理分支、循环、人工确认这些复杂流程而传统的 Chain 更适合简单固定链路。这也是热词里很多人问“LangGraph 和 LangChain 的区别”的原因。简单说LangChain 是工具箱LangGraph 是基于这个工具箱构建的可控状态机。2.2 MCP 的三个核心角色MCP 协议定义了三个角色MCP Host发起连接和调用的 AI 应用比如 Claude Desktop、Cursor、Dify也包括你自己写的 LangChain 程序。MCP ClientHost 内部与 Server 建立连接的组件负责协议通信。MCP Server暴露工具、资源、提示词的进程可以是一个本地 Python 脚本也可以是一个远程 HTTP 服务。一条完整的 MCP 调用链路是这样的用户输入 - LangChain AgentHost - MCP Client 发起初始化握手 - MCP Server 暴露工具列表 - Agent 决定调用哪个工具 - Server 执行并返回结构化结果对于开发者来说MCP 最重要的贡献是规范了工具的描述格式与调用协议。工具不再是一个藏在代码里的函数而是一个能被模型发现、理解并调用的独立服务。2.3 MCP 与 Function Calling、Skill、插件的区别很多初学者把 MCP 和 Function Calling 混为一谈这里需要做一个明确区分。Function Calling 是一种模型能力意思是模型在生成回复时可以输出一个结构化的“我要调用某个函数”的意图。它解决的是“模型如何表达调用意图”的问题。每一个模型厂商的函数调用格式都不太一样OpenAI 有 tool callingClaude 有 tool use国产模型也各有各的格式。MCP 则是一套工具接入标准解决的是“工具如何被描述、如何被发现、如何被调用”的问题。它位于 Function Calling 之下。你可以这样理解Function Calling 是模型的能力MCP 是工具接入层的通用协议。就算模型不支持 Function CallingMCP Server 也可以作为普通接口被调用只是体验和效率会差一些。Agent Skill 和 MCP 的边界也常被问。Skill 通常是一段 Prompt、一套工作流或一个子 Agent 的组合解决的是“某个任务怎么做”的问题更像一个技能包。MCP 则更底层解决的是“某个具体功能怎么被调用”的问题。实际项目里Skill 可以调用多个 MCP 工具来完成一个复合任务二者不是竞争关系而是互补关系。3. 为什么说 2026 年学习 LangChain MCP 是正确选择做一个比较现实的判断如果你在 2026 年还要从零开始对接十几个工具的调用却不用 MCP你的工作量会非常大而且每换一个 Agent 框架就要重写一遍。MCP 之所以在 2026 年变得如此重要背后有一个很清晰的技术趋势AI 应用正在从“对话框”走向“工具台”。过去的 Agent 只会聊天现在的 Agent 要写代码、查数据库、操作浏览器、控制设计软件甚至调用支付接口。工具数量和类型越来越多如果每个工具都单独对接整个系统的维护成本会指数级上升。MCP 通过统一协议解决了两个问题第一工具发现的标准化。MCP Server 启动后Host 可以自动获取到所有工具的名称、描述、参数结构。Agent 不需要预先硬编码每个工具的调用格式而是通过协议动态发现。第二工具接入的解耦。只要工具方提供一个 MCP Server任何支持 MCP 的 Host 都能用。这意味着同一个工具可以被 LangChain Agent、Dify 工作流、Claude Desktop、Cursor 等不同平台复用不需要为每个平台单独写适配层。这也是为什么很多工具厂商都在发布自己的 MCP Server。从 Figma、Playwright、SSH到数据库工具、设计工具、甚至是 MATLAB、IDA Pro 这类专业软件都在向 MCP 靠拢。对开发者来说掌握 MCP 意味着你以后写 Agent 时不需要再从零封装工具了而是去市场上找一个现成的 MCP Server或者写一个薄薄的适配层即可。4. 环境准备搭建 LangChain MCP 开发环境在开始写代码之前先准备开发环境。以下环境以 Python 为例这是目前 LangChain 生态支持最好、示例最多的语言。4.1 安装 Python 与虚拟环境建议使用 Python 3.10 以上版本具体小版本以你本机环境为准。在项目的根目录下创建并激活虚拟环境python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate4.2 安装依赖包需要安装的核心包如下pip install langchain langchain-openai pip install langchain-mcp-adapters pip install mcp[cli] pip install langgraph版本说明LangChain 生态包更新速度较快安装时建议以官方 PyPI 最新版本为准不要锁定一个过旧的版本。如果你使用的是国内直连 PyPI 较慢可以配置清华镜像加速。在写代码之前还需要准备一个大模型 API 的访问密钥。示例中我们使用 OpenAI 兼容接口你可以换成任意支持工具调用的模型比如通过 API 网关暴露的国产模型、本地部署的 Qwen 模型等只要它是 OpenAI 兼容格式即可。创建项目目录结构langchain-mcp-demo/ ├── .venv/ ├── .env ├── system_info_server.py └── langchain_client.py.env文件用来保存模型 API 配置不要提交到 Git 仓库。OPENAI_API_KEY你的Key OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODEL_NAMEgpt-4o-mini如果你使用的是其他兼容 OpenAI 接口的服务只需要修改OPENAI_BASE_URL和OPENAI_MODEL_NAME即可。5. 完整实战手写第一个 MCP Server这一节我们做一个最小但完整的案例一个返回系统信息的 MCP Server。它会暴露两个工具一个返回当前系统时间和日期一个返回 CPU、内存、磁盘使用概况。为什么选这个案例因为它不依赖外部系统不需要数据库不需要前置服务最不容易出现环境问题适合用来理解 MCP 的核心机制。5.1 用 FastMCP 编写 Server官方 Python SDK 提供了 FastMCP 类可以像写普通函数一样定义工具。文件路径system_info_server.py# 文件路径system_info_server.py import platform import shutil import psutil from datetime import datetime from zoneinfo import ZoneInfo from mcp.server.fastmcp import FastMCP mcp FastMCP(SystemInfoServer) mcp.tool() def get_system_time(timezone: str Asia/Shanghai) - str: 获取指定时区的当前时间。timezone 参数使用 IANA 时区名称例如 Asia/Shanghai。 try: tz ZoneInfo(timezone) current datetime.now(tz) return f当前时间{current.strftime(%Y-%m-%d %H:%M:%S)}时区{timezone} except Exception as e: return f无法解析时区 {timezone}{e} mcp.tool() def get_system_status() - str: 获取当前服务器的系统与资源概况包括操作系统、CPU、内存和磁盘使用率。 cpu_percent psutil.cpu_percent(interval1) memory psutil.virtual_memory() disk shutil.disk_usage(/) info { 操作系统: platform.system() platform.release(), CPU使用率: f{cpu_percent}%, 内存使用率: f{memory.percent}%, 内存可用: f{memory.available / (1024 ** 3):.2f} GB, 磁盘总容量: f{disk.total / (1024 ** 3):.2f} GB, 磁盘可用: f{disk.free / (1024 ** 3):.2f} GB, } lines \n.join(f{k}: {v} for k, v in info.items()) return 系统状态如下\n lines if __name__ __main__: mcp.run(transportstdio)这个 Server 有几个点值得说明第一mcp.tool()装饰器把普通函数变成了 MCP 可发现的工具。函数名、参数名、docstring 都会成为模型理解工具的依据所以描述要尽量写清楚。第二mcp.run(transportstdio)表示以标准输入输出方式运行。这种模式适合本地进程间通信也是 LangChain 客户端默认支持的模式。第三docstring 不是可有可无的注释。在 MCP 协议中docstring 会被传给模型模型靠它决定“什么时候调用这个工具”。如果你写的 docstring 含糊不清模型就会在错误场景下调用工具。5.2 手动测试 MCP Server写完后先不急着接 LangChain先用 MCP 官方的 Inspector 模式手动测试一下。python system_info_server.py正常情况下程序会进入等待状态屏幕上不会输出任何内容因为所有通信都是通过标准输入输出完成的。如果你想看到工具的注册信息可以给 FastMCP 加上 debug 日志或者先运行一个简单的启动检查python -c import system_info_server; print(mcp server import ok)如果导入没有报错说明语法和依赖安装没有问题。更完整的测试方式是使用 MCP Inspectormcp dev system_info_server.py启动后浏览器打开 Inspector 提供的地址可以查看工具列表、手动发起工具调用。这一步非常建议做因为它能帮你确认 MCP Server 本身没有逻辑问题后续问题排查时就不会把锅甩给 LangChain 了。6. 核心实战LangChain 接入 MCP 工具MCP Server 写好了现在让 LangChain Agent 调它。6.1 安装额外依赖前面已经安装了langchain-mcp-adapters这是 LangChain 官方提供的 MCP 适配层。它负责把 MCP Server 暴露的工具转换成 LangChain 的 Tool 对象从而被 Agent 调用。6.2 编写 LangChain 客户端文件路径langchain_client.py# 文件路径langchain_client.py import asyncio import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_mcp_adapters.tools import load_mcp_tools from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client load_dotenv() async def main(): # 1. 启动 MCP Server 进程 server_params StdioServerParameters( commandpython, args[system_info_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # 2. 初始化协议握手 await session.initialize() # 3. 将 MCP 工具加载为 LangChain 工具 tools await load_mcp_tools(session) print(已加载 MCP 工具) for tool in tools: print(-, tool.name) # 4. 创建支持工具调用的模型 llm ChatOpenAI( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), temperature0, ) # 5. 创建 Prompt prompt ChatPromptTemplate.from_messages([ (system, 你是一个能调用系统工具的助手。请根据用户问题调用合适的工具并基于工具结果回复。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 6. 创建 Agent agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) # 7. 测试调用 result await executor.ainvoke({input: 现在上海是什么时间顺便看下服务器 CPU 使用率。}) print(\n最终回答, result[output]) if __name__ __main__: asyncio.run(main())这段代码里最关键的是第 3 步。load_mcp_tools会通过 MCP 协议向 Server 请求工具列表并把工具转换成 LangChain 的 Tool 对象。转换完成后Agent 就能像使用普通工具一样使用 MCP 工具调用细节被完全屏蔽了。整个流程可以分为四个阶段建立连接stdio_client启动 MCP Server 子进程。初始化会话ClientSession负责协议握手和消息传递。加载工具load_mcp_tools拉取工具列表并转换。执行任务Agent 根据用户输入决定调用哪个 MCP 工具。这种做法的优势在于如果你新增了一个工具只需要在system_info_server.py里加一个函数客户端代码完全不用改。这就是 MCP 解耦能力最直观的体现。6.3 运行与验证执行客户端代码python langchain_client.py预期输出大致如下已加载 MCP 工具 - get_system_time - get_system_status Entering new AgentExecutor chain... Invoking: get_system_time with {timezone: Asia/Shanghai} ... Invoking: get_system_status with {} ... 最终回答 上海当前时间是 2026-01-05 14:30:00服务器 CPU 使用率为 12.5%。如果你看到 Agent 正确调用了两个工具并给出了基于结果的回答说明 LangChain MCP 全链路已经跑通。7. 进阶实战用 LangGraph 编排多工具 Agent上面的例子用传统的AgentExecutor实现了基本调用但在生产项目中我们更推荐使用 LangGraph 来做编排。原因是 LangGraph 可以精确控制 Agent 的状态流转、错误处理和人工确认节点。下面是一个简化版的 LangGraph 示例功能是让 Agent 根据用户问题决定调用工具并把结果通过状态对象传递。7.1 安装与导入# 文件路径langgraph_agent.py import asyncio import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_mcp_adapters.tools import load_mcp_tools from langgraph.prebuilt import create_react_agent from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client load_dotenv() async def main(): server_params StdioServerParameters( commandpython, args[system_info_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await load_mcp_tools(session) llm ChatOpenAI( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), temperature0, ) agent create_react_agent(llm, tools) result await agent.ainvoke( {messages: [{role: user, content: 服务器内存还够用吗}]} ) for message in result[messages]: print(f[{message.type}] {message.content}) if __name__ __main__: asyncio.run(main())create_react_agent是 LangGraph 内置的预构建 Agent它在内部建立了“思考 - 调用工具 - 观察结果 - 继续思考”的循环。和上一节的AgentExecutor相比LangGraph 版的状态传递更透明也更容易在中间插入人工审批节点。7.2 为什么生产环境更推荐 LangGraph如果你只需要一个简单的问答工具调用AgentExecutor完全够用。但在真实项目中通常会有这些需求某个工具调用失败了需要重试或走降级分支。某个操作执行前需要人工确认。不同的工具组合需要不同的 Prompt。需要对 Agent 的每一步做详细日志和追踪。这些需求在 LangGraph 中都可以通过状态图来实现。你可以把“调用系统信息工具”画成一个节点把“判断是否需要人工确认”画成另一个节点通过条件边连接它们。相比传统的 ChainLangGraph 的表达能力更强也更能反映真实业务逻辑。由于篇幅原因这里只给出一个最简单的 LangGraph 版本。实际项目中建议先画出状态转移图再写代码这样可维护性会高很多。8. 常见问题与排查思路LangChain MCP 的组合在实际开发中问题不算少。这里整理了几个高频问题按排查优先级排序。问题现象可能原因排查方式解决方案客户端启动后没有任何工具被加载MCP Server 启动失败或路径错误先单独运行python system_info_server.py看是否报错确认command、args路径正确必要时用绝对路径工具已加载但 Agent 一直不调用模型不支持工具调用或 Prompt 未配置agent_scratchpad查看模型是否启用了 tool calling 能力更换支持工具调用的模型检查 Prompt 模板是否完整调用工具时报超时或连接断开MCP Server 进程提前退出或 stdio 管道被占用查看 Server 进程是否存活观察客户端是否有 traceback给 Server 增加日志输出或使用mcp dev模式单独调试明明代码没改换个环境后工具全部失效依赖版本不匹配检查pip freeze对比环境差异用 requirements.txt 锁定版本或使用 uv/poetry 管理依赖在 Windows 上运行时报command找不到 PythonWindows 下python可能指向 Microsoft Store 别名执行where python查看真实路径将command改为python的绝对路径或改用py命令Agent 把工具参数传错总是拿到错误结果函数参数命名与模型理解不一致在 MCP Server 端打印收到的参数优化函数名和参数名docstring 中写清楚参数格式和示例使用了远程 MCP Server但一直连不上网络策略或鉴权配置问题检查端口连通性和鉴权 header 配置确认 MCP Server 支持 SSE/Streamable HTTP并在客户端配置正确凭据这里特别想强调一个问题当 MCP 工具加载成功但 Agent 表现不好时不要立刻怀疑 MCP更可能是模型对工具描述的理解不到位。MCP 协议解决了工具如何被发现和调用但“什么时候用这个工具”依然依赖于函数名、参数名和 docstring 写得是否清晰。9. 从 Demo 到生产LangChain MCP 的最佳实践写一个 Demo 很容易但把 LangChain MCP 的组合用到生产环境需要额外关注几个层面。9.1 明确工具边界不是所有功能都应该暴露成 MCP 工具。如果一个操作需要大量上下文、涉及复杂人机交互或者参数很难用 JSON Schema 描述那它可能更适合做成一个独立的子 Agent而不是 MCP 工具。MCP 工具适合那些边界清晰、输入输出简单、可以独立验证的功能。9.2 安全与权限控制MCP Server 一旦暴露给 AgentAgent 就有了执行某个操作的能力。生产环境中必须在 MCP Server 层做权限校验而不是在 Prompt 里告诉模型“不要乱调”。因为模型可能被注入攻击绕过所以工具本身要假设所有调用都是不可信的。对于高危操作比如删除数据、支付、发送消息应该加入人工确认节点。在 LangGraph 中你可以在调用工具之后、执行下一步之前插入一个interrupt节点等人工批准后再继续。9.3 日志与可观测性MCP 把工具调用过程封装成了黑盒这对排查问题带来了一定挑战。生产环境至少要记录以下信息请求 ID、用户 ID、Agent 每次调用的工具名称、传入参数、返回结果、耗时、错误信息。建议在 LangChain 的 callbacks 中挂载自定义日志处理器同时在 MCP Server 侧输出结构化日志。9.4 工具描述的质量决定了 Agent 上限这可能是整个生产经验里最容易被低估的一条。很多人写完 MCP Server工具名和描述写得非常随意然后抱怨 Agent 太笨。实际上模型对工具的理解完全来自工具名、参数名和 docstring。给工具写描述时建议包含工具适用场景、参数格式、返回值结构、典型示例。尽可能用英文还是中文取决于模型但描述本身一定要完整。例如下面的写法就比只写一句话要好很多mcp.tool() def get_user_order(order_id: str, include_items: bool True) - str: 根据订单号查询用户订单信息。 适用场景用户询问“我的订单”“订单状态”“物流信息”时调用。 参数: order_id: 订单号格式为字母数字例如 OD20260101001。 include_items: 是否返回订单明细默认返回。 返回: 订单状态、下单时间、商品数量。如果查询不到返回错误描述。 9.5 明确 MCP 与 Skill 的使用选择如果你需要的是一个可以复用的“完成某类任务”的流程比如“自动生成周报”“批量处理报销单”这种复合型能力更适合做成 Skill。如果只是一个原子能力比如“查天气”“查订单”“发消息”则更适合做成 MCP 工具。实际项目中经常是 Skill 内部编排多个 MCP 工具调用两者结合使用。10. 总结与下一步学习建议这篇文章从概念到实战完整走了一遍 LangChain MCP 的主流用法。现在回头总结真正值得记住的判断是LangChain 做编排MCP 做连接两者解决的是不同层面的问题。如果你正在构建 Agent 应用MCP 不是可选项而是让工具层不被绑定死的必要底座。下一步建议按这个顺序实践第一把文章里的system_info_server.py和langchain_client.py完整跑通确认你理解了 MCP 工具加载和调用机制。 第二尝试给 MCP Server 增加一个自己的工具比如查询本地某个 JSON 文件、调用一个 HTTP API然后让 Agent 去调用它。 第三学习 LangGraph 的状态图把现在简单的 ReAct Agent 改造成带分支和人工确认的流程。 第四关注你日常使用的工具是否有 MCP Server 支持。很多平台已经提供了现成的 MCP 服务直接在 LangChain 或 Dify 里接入即可不需要重复造轮子。如果面试中被问到 LangChain 和 MCP你要能说清楚三件事MCP 解决的是工具接入标准化问题LangChain 解决的是 Agent 编排问题两者组合的核心收益是工具解耦和复用成本下降。能用自己的项目讲明白这三层比背任何面试题都有说服力。这篇文章建议收藏备用遇到 MCP Server 连接问题、工具加载失败、Agent 不调用工具这些场景时翻回来看排查表格大概率能省下不少调试时间。 LangChain与MCP集成实战：从Agent编排到工具标准化连接
如果你写过一段时间大模型应用大概率会遇到这样一个场景Prompt 写得挺顺RAG 流程也跑通了模型也能给出看起来不错的回答。但一旦让它去查数据库、调内部系统、操作某个网页工具整个 Agent 就变得很僵硬。要么是每个工具都要单独写一套调用代码要么是换了模型之后工具调用全部失效要么是项目里的工具多了以后代码乱到根本不敢加新功能。这个痛点的根源不在模型能力而在工具接入方式。2026 年再谈大模型应用开发LangChain 与 MCP 的组合已经绕不开了。LangChain 解决的是 Agent 的编排、记忆、规划和多模型适配MCP 解决的是 Agent 与外部工具之间的标准化连接。两者配合之后工具可以像 USB 设备一样即插即用Agent 才能从“聊天机器人”变成真正能干活的应用。这篇文章不打算重复官方的 API 文档而是从实际开发的角度把 LangChain 与 MCP 的核心概念、组合方式、完整代码实战、常见坑位和生产环境建议一次讲透。无论你是刚开始学 LangChain 的新手还是已经写过 Agent 但还没接 MCP 的开发者这篇文章都值得收藏。1. LangChain 与 MCP两个经常被误解的技术先说一个判断LangChain 没有过时它只是从“包罗万象的框架”变成了“Agent 编排底座”。很多人看到 LangChain 早期版本 API 频繁变动就认为这个项目不行了。但实际情况是LangChain 已经拆分成了 langchain-core、langchain、langchain-community、langchain-openai 等一系列子包结构更清晰了也更适合作为 Agent 应用的骨架层。MCP 则是一个协议全称是 Model Context Protocol中文可以理解为“模型上下文协议”。它由 Anthropic 在 2024 年底提出目标是统一 AI 应用与外部数据源、工具之间的交互方式。到了 2026 年MCP 已经不只是某个模型的专属协议OpenAI、Google、各大 IDE、各类低代码平台都在支持或兼容它。这两个技术经常被放在一起讨论原因是它们在 AI 应用架构中处于不同层次LangChain 管的是“大脑如何思考”对话流程、工具选择、记忆管理、任务规划。MCP 管的是“手脚如何接入”工具怎么被描述、怎么被调用、怎么返回结果。如果用传统软件开发类比LangChain 类似 Spring 里的控制层和服务层MCP 类似 JDBC、ODBC 这类数据库访问标准。JDBC 不关心你的业务逻辑怎么写但它定义了 Java 程序连数据库的统一方式。MCP 也不关心你的 Agent 怎么规划任务但它定义了 AI 应用调用工具的统一方式。这篇文章要解决的核心问题有三个第一MCP 到底是什么它和 Function Calling、插件、Agent Skill 的区别在哪里。 第二如何用 LangChain 接入一个真实可用的 MCP Server跑通一个完整案例。 第三生产环境中使用 LangChain MCP 有哪些容易踩的坑以及正确的工程姿势是什么。2. 核心概念LangChain 的模块划分与 MCP 的协议设计2.1 LangChain 到底提供了什么LangChain 不是一个单一的大模型框架而是一套组件化工具集。它的核心模块大致可以分成六个方向模型接口Model I/O统一封装 OpenAI、Claude、国产大模型等各种模型的调用方式包括 Prompt 模板、输出解析器。检索增强Retrieval各种向量库、文档加载器、切分器、Embedding 模型的对接。Agent 与工具Agents Tools让模型根据用户需求自动决定调用哪些工具以及如何处理工具返回结果。记忆Memory保存历史对话、短期记忆、长期记忆。编排Chains 与 LangGraph把多个步骤串联或组织成图结构。回调与集成Callbacks/Integrations日志、监控、第三方框架对接。在 LangChain 的早期版本里Chain 是核心抽象我们现在则更推荐基于 LangGraph 做 Agent 流程编排。LangGraph 适合处理分支、循环、人工确认这些复杂流程而传统的 Chain 更适合简单固定链路。这也是热词里很多人问“LangGraph 和 LangChain 的区别”的原因。简单说LangChain 是工具箱LangGraph 是基于这个工具箱构建的可控状态机。2.2 MCP 的三个核心角色MCP 协议定义了三个角色MCP Host发起连接和调用的 AI 应用比如 Claude Desktop、Cursor、Dify也包括你自己写的 LangChain 程序。MCP ClientHost 内部与 Server 建立连接的组件负责协议通信。MCP Server暴露工具、资源、提示词的进程可以是一个本地 Python 脚本也可以是一个远程 HTTP 服务。一条完整的 MCP 调用链路是这样的用户输入 - LangChain AgentHost - MCP Client 发起初始化握手 - MCP Server 暴露工具列表 - Agent 决定调用哪个工具 - Server 执行并返回结构化结果对于开发者来说MCP 最重要的贡献是规范了工具的描述格式与调用协议。工具不再是一个藏在代码里的函数而是一个能被模型发现、理解并调用的独立服务。2.3 MCP 与 Function Calling、Skill、插件的区别很多初学者把 MCP 和 Function Calling 混为一谈这里需要做一个明确区分。Function Calling 是一种模型能力意思是模型在生成回复时可以输出一个结构化的“我要调用某个函数”的意图。它解决的是“模型如何表达调用意图”的问题。每一个模型厂商的函数调用格式都不太一样OpenAI 有 tool callingClaude 有 tool use国产模型也各有各的格式。MCP 则是一套工具接入标准解决的是“工具如何被描述、如何被发现、如何被调用”的问题。它位于 Function Calling 之下。你可以这样理解Function Calling 是模型的能力MCP 是工具接入层的通用协议。就算模型不支持 Function CallingMCP Server 也可以作为普通接口被调用只是体验和效率会差一些。Agent Skill 和 MCP 的边界也常被问。Skill 通常是一段 Prompt、一套工作流或一个子 Agent 的组合解决的是“某个任务怎么做”的问题更像一个技能包。MCP 则更底层解决的是“某个具体功能怎么被调用”的问题。实际项目里Skill 可以调用多个 MCP 工具来完成一个复合任务二者不是竞争关系而是互补关系。3. 为什么说 2026 年学习 LangChain MCP 是正确选择做一个比较现实的判断如果你在 2026 年还要从零开始对接十几个工具的调用却不用 MCP你的工作量会非常大而且每换一个 Agent 框架就要重写一遍。MCP 之所以在 2026 年变得如此重要背后有一个很清晰的技术趋势AI 应用正在从“对话框”走向“工具台”。过去的 Agent 只会聊天现在的 Agent 要写代码、查数据库、操作浏览器、控制设计软件甚至调用支付接口。工具数量和类型越来越多如果每个工具都单独对接整个系统的维护成本会指数级上升。MCP 通过统一协议解决了两个问题第一工具发现的标准化。MCP Server 启动后Host 可以自动获取到所有工具的名称、描述、参数结构。Agent 不需要预先硬编码每个工具的调用格式而是通过协议动态发现。第二工具接入的解耦。只要工具方提供一个 MCP Server任何支持 MCP 的 Host 都能用。这意味着同一个工具可以被 LangChain Agent、Dify 工作流、Claude Desktop、Cursor 等不同平台复用不需要为每个平台单独写适配层。这也是为什么很多工具厂商都在发布自己的 MCP Server。从 Figma、Playwright、SSH到数据库工具、设计工具、甚至是 MATLAB、IDA Pro 这类专业软件都在向 MCP 靠拢。对开发者来说掌握 MCP 意味着你以后写 Agent 时不需要再从零封装工具了而是去市场上找一个现成的 MCP Server或者写一个薄薄的适配层即可。4. 环境准备搭建 LangChain MCP 开发环境在开始写代码之前先准备开发环境。以下环境以 Python 为例这是目前 LangChain 生态支持最好、示例最多的语言。4.1 安装 Python 与虚拟环境建议使用 Python 3.10 以上版本具体小版本以你本机环境为准。在项目的根目录下创建并激活虚拟环境python -m venv .venv source .venv/bin/activate # Windows 下执行 .venv\Scripts\activate4.2 安装依赖包需要安装的核心包如下pip install langchain langchain-openai pip install langchain-mcp-adapters pip install mcp[cli] pip install langgraph版本说明LangChain 生态包更新速度较快安装时建议以官方 PyPI 最新版本为准不要锁定一个过旧的版本。如果你使用的是国内直连 PyPI 较慢可以配置清华镜像加速。在写代码之前还需要准备一个大模型 API 的访问密钥。示例中我们使用 OpenAI 兼容接口你可以换成任意支持工具调用的模型比如通过 API 网关暴露的国产模型、本地部署的 Qwen 模型等只要它是 OpenAI 兼容格式即可。创建项目目录结构langchain-mcp-demo/ ├── .venv/ ├── .env ├── system_info_server.py └── langchain_client.py.env文件用来保存模型 API 配置不要提交到 Git 仓库。OPENAI_API_KEY你的Key OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODEL_NAMEgpt-4o-mini如果你使用的是其他兼容 OpenAI 接口的服务只需要修改OPENAI_BASE_URL和OPENAI_MODEL_NAME即可。5. 完整实战手写第一个 MCP Server这一节我们做一个最小但完整的案例一个返回系统信息的 MCP Server。它会暴露两个工具一个返回当前系统时间和日期一个返回 CPU、内存、磁盘使用概况。为什么选这个案例因为它不依赖外部系统不需要数据库不需要前置服务最不容易出现环境问题适合用来理解 MCP 的核心机制。5.1 用 FastMCP 编写 Server官方 Python SDK 提供了 FastMCP 类可以像写普通函数一样定义工具。文件路径system_info_server.py# 文件路径system_info_server.py import platform import shutil import psutil from datetime import datetime from zoneinfo import ZoneInfo from mcp.server.fastmcp import FastMCP mcp FastMCP(SystemInfoServer) mcp.tool() def get_system_time(timezone: str Asia/Shanghai) - str: 获取指定时区的当前时间。timezone 参数使用 IANA 时区名称例如 Asia/Shanghai。 try: tz ZoneInfo(timezone) current datetime.now(tz) return f当前时间{current.strftime(%Y-%m-%d %H:%M:%S)}时区{timezone} except Exception as e: return f无法解析时区 {timezone}{e} mcp.tool() def get_system_status() - str: 获取当前服务器的系统与资源概况包括操作系统、CPU、内存和磁盘使用率。 cpu_percent psutil.cpu_percent(interval1) memory psutil.virtual_memory() disk shutil.disk_usage(/) info { 操作系统: platform.system() platform.release(), CPU使用率: f{cpu_percent}%, 内存使用率: f{memory.percent}%, 内存可用: f{memory.available / (1024 ** 3):.2f} GB, 磁盘总容量: f{disk.total / (1024 ** 3):.2f} GB, 磁盘可用: f{disk.free / (1024 ** 3):.2f} GB, } lines \n.join(f{k}: {v} for k, v in info.items()) return 系统状态如下\n lines if __name__ __main__: mcp.run(transportstdio)这个 Server 有几个点值得说明第一mcp.tool()装饰器把普通函数变成了 MCP 可发现的工具。函数名、参数名、docstring 都会成为模型理解工具的依据所以描述要尽量写清楚。第二mcp.run(transportstdio)表示以标准输入输出方式运行。这种模式适合本地进程间通信也是 LangChain 客户端默认支持的模式。第三docstring 不是可有可无的注释。在 MCP 协议中docstring 会被传给模型模型靠它决定“什么时候调用这个工具”。如果你写的 docstring 含糊不清模型就会在错误场景下调用工具。5.2 手动测试 MCP Server写完后先不急着接 LangChain先用 MCP 官方的 Inspector 模式手动测试一下。python system_info_server.py正常情况下程序会进入等待状态屏幕上不会输出任何内容因为所有通信都是通过标准输入输出完成的。如果你想看到工具的注册信息可以给 FastMCP 加上 debug 日志或者先运行一个简单的启动检查python -c import system_info_server; print(mcp server import ok)如果导入没有报错说明语法和依赖安装没有问题。更完整的测试方式是使用 MCP Inspectormcp dev system_info_server.py启动后浏览器打开 Inspector 提供的地址可以查看工具列表、手动发起工具调用。这一步非常建议做因为它能帮你确认 MCP Server 本身没有逻辑问题后续问题排查时就不会把锅甩给 LangChain 了。6. 核心实战LangChain 接入 MCP 工具MCP Server 写好了现在让 LangChain Agent 调它。6.1 安装额外依赖前面已经安装了langchain-mcp-adapters这是 LangChain 官方提供的 MCP 适配层。它负责把 MCP Server 暴露的工具转换成 LangChain 的 Tool 对象从而被 Agent 调用。6.2 编写 LangChain 客户端文件路径langchain_client.py# 文件路径langchain_client.py import asyncio import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_mcp_adapters.tools import load_mcp_tools from langchain.agents import AgentExecutor, create_tool_calling_agent from langchain_core.prompts import ChatPromptTemplate from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client load_dotenv() async def main(): # 1. 启动 MCP Server 进程 server_params StdioServerParameters( commandpython, args[system_info_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: # 2. 初始化协议握手 await session.initialize() # 3. 将 MCP 工具加载为 LangChain 工具 tools await load_mcp_tools(session) print(已加载 MCP 工具) for tool in tools: print(-, tool.name) # 4. 创建支持工具调用的模型 llm ChatOpenAI( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), temperature0, ) # 5. 创建 Prompt prompt ChatPromptTemplate.from_messages([ (system, 你是一个能调用系统工具的助手。请根据用户问题调用合适的工具并基于工具结果回复。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 6. 创建 Agent agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) # 7. 测试调用 result await executor.ainvoke({input: 现在上海是什么时间顺便看下服务器 CPU 使用率。}) print(\n最终回答, result[output]) if __name__ __main__: asyncio.run(main())这段代码里最关键的是第 3 步。load_mcp_tools会通过 MCP 协议向 Server 请求工具列表并把工具转换成 LangChain 的 Tool 对象。转换完成后Agent 就能像使用普通工具一样使用 MCP 工具调用细节被完全屏蔽了。整个流程可以分为四个阶段建立连接stdio_client启动 MCP Server 子进程。初始化会话ClientSession负责协议握手和消息传递。加载工具load_mcp_tools拉取工具列表并转换。执行任务Agent 根据用户输入决定调用哪个 MCP 工具。这种做法的优势在于如果你新增了一个工具只需要在system_info_server.py里加一个函数客户端代码完全不用改。这就是 MCP 解耦能力最直观的体现。6.3 运行与验证执行客户端代码python langchain_client.py预期输出大致如下已加载 MCP 工具 - get_system_time - get_system_status Entering new AgentExecutor chain... Invoking: get_system_time with {timezone: Asia/Shanghai} ... Invoking: get_system_status with {} ... 最终回答 上海当前时间是 2026-01-05 14:30:00服务器 CPU 使用率为 12.5%。如果你看到 Agent 正确调用了两个工具并给出了基于结果的回答说明 LangChain MCP 全链路已经跑通。7. 进阶实战用 LangGraph 编排多工具 Agent上面的例子用传统的AgentExecutor实现了基本调用但在生产项目中我们更推荐使用 LangGraph 来做编排。原因是 LangGraph 可以精确控制 Agent 的状态流转、错误处理和人工确认节点。下面是一个简化版的 LangGraph 示例功能是让 Agent 根据用户问题决定调用工具并把结果通过状态对象传递。7.1 安装与导入# 文件路径langgraph_agent.py import asyncio import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_mcp_adapters.tools import load_mcp_tools from langgraph.prebuilt import create_react_agent from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client load_dotenv() async def main(): server_params StdioServerParameters( commandpython, args[system_info_server.py], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() tools await load_mcp_tools(session) llm ChatOpenAI( modelos.getenv(OPENAI_MODEL_NAME, gpt-4o-mini), temperature0, ) agent create_react_agent(llm, tools) result await agent.ainvoke( {messages: [{role: user, content: 服务器内存还够用吗}]} ) for message in result[messages]: print(f[{message.type}] {message.content}) if __name__ __main__: asyncio.run(main())create_react_agent是 LangGraph 内置的预构建 Agent它在内部建立了“思考 - 调用工具 - 观察结果 - 继续思考”的循环。和上一节的AgentExecutor相比LangGraph 版的状态传递更透明也更容易在中间插入人工审批节点。7.2 为什么生产环境更推荐 LangGraph如果你只需要一个简单的问答工具调用AgentExecutor完全够用。但在真实项目中通常会有这些需求某个工具调用失败了需要重试或走降级分支。某个操作执行前需要人工确认。不同的工具组合需要不同的 Prompt。需要对 Agent 的每一步做详细日志和追踪。这些需求在 LangGraph 中都可以通过状态图来实现。你可以把“调用系统信息工具”画成一个节点把“判断是否需要人工确认”画成另一个节点通过条件边连接它们。相比传统的 ChainLangGraph 的表达能力更强也更能反映真实业务逻辑。由于篇幅原因这里只给出一个最简单的 LangGraph 版本。实际项目中建议先画出状态转移图再写代码这样可维护性会高很多。8. 常见问题与排查思路LangChain MCP 的组合在实际开发中问题不算少。这里整理了几个高频问题按排查优先级排序。问题现象可能原因排查方式解决方案客户端启动后没有任何工具被加载MCP Server 启动失败或路径错误先单独运行python system_info_server.py看是否报错确认command、args路径正确必要时用绝对路径工具已加载但 Agent 一直不调用模型不支持工具调用或 Prompt 未配置agent_scratchpad查看模型是否启用了 tool calling 能力更换支持工具调用的模型检查 Prompt 模板是否完整调用工具时报超时或连接断开MCP Server 进程提前退出或 stdio 管道被占用查看 Server 进程是否存活观察客户端是否有 traceback给 Server 增加日志输出或使用mcp dev模式单独调试明明代码没改换个环境后工具全部失效依赖版本不匹配检查pip freeze对比环境差异用 requirements.txt 锁定版本或使用 uv/poetry 管理依赖在 Windows 上运行时报command找不到 PythonWindows 下python可能指向 Microsoft Store 别名执行where python查看真实路径将command改为python的绝对路径或改用py命令Agent 把工具参数传错总是拿到错误结果函数参数命名与模型理解不一致在 MCP Server 端打印收到的参数优化函数名和参数名docstring 中写清楚参数格式和示例使用了远程 MCP Server但一直连不上网络策略或鉴权配置问题检查端口连通性和鉴权 header 配置确认 MCP Server 支持 SSE/Streamable HTTP并在客户端配置正确凭据这里特别想强调一个问题当 MCP 工具加载成功但 Agent 表现不好时不要立刻怀疑 MCP更可能是模型对工具描述的理解不到位。MCP 协议解决了工具如何被发现和调用但“什么时候用这个工具”依然依赖于函数名、参数名和 docstring 写得是否清晰。9. 从 Demo 到生产LangChain MCP 的最佳实践写一个 Demo 很容易但把 LangChain MCP 的组合用到生产环境需要额外关注几个层面。9.1 明确工具边界不是所有功能都应该暴露成 MCP 工具。如果一个操作需要大量上下文、涉及复杂人机交互或者参数很难用 JSON Schema 描述那它可能更适合做成一个独立的子 Agent而不是 MCP 工具。MCP 工具适合那些边界清晰、输入输出简单、可以独立验证的功能。9.2 安全与权限控制MCP Server 一旦暴露给 AgentAgent 就有了执行某个操作的能力。生产环境中必须在 MCP Server 层做权限校验而不是在 Prompt 里告诉模型“不要乱调”。因为模型可能被注入攻击绕过所以工具本身要假设所有调用都是不可信的。对于高危操作比如删除数据、支付、发送消息应该加入人工确认节点。在 LangGraph 中你可以在调用工具之后、执行下一步之前插入一个interrupt节点等人工批准后再继续。9.3 日志与可观测性MCP 把工具调用过程封装成了黑盒这对排查问题带来了一定挑战。生产环境至少要记录以下信息请求 ID、用户 ID、Agent 每次调用的工具名称、传入参数、返回结果、耗时、错误信息。建议在 LangChain 的 callbacks 中挂载自定义日志处理器同时在 MCP Server 侧输出结构化日志。9.4 工具描述的质量决定了 Agent 上限这可能是整个生产经验里最容易被低估的一条。很多人写完 MCP Server工具名和描述写得非常随意然后抱怨 Agent 太笨。实际上模型对工具的理解完全来自工具名、参数名和 docstring。给工具写描述时建议包含工具适用场景、参数格式、返回值结构、典型示例。尽可能用英文还是中文取决于模型但描述本身一定要完整。例如下面的写法就比只写一句话要好很多mcp.tool() def get_user_order(order_id: str, include_items: bool True) - str: 根据订单号查询用户订单信息。 适用场景用户询问“我的订单”“订单状态”“物流信息”时调用。 参数: order_id: 订单号格式为字母数字例如 OD20260101001。 include_items: 是否返回订单明细默认返回。 返回: 订单状态、下单时间、商品数量。如果查询不到返回错误描述。 9.5 明确 MCP 与 Skill 的使用选择如果你需要的是一个可以复用的“完成某类任务”的流程比如“自动生成周报”“批量处理报销单”这种复合型能力更适合做成 Skill。如果只是一个原子能力比如“查天气”“查订单”“发消息”则更适合做成 MCP 工具。实际项目中经常是 Skill 内部编排多个 MCP 工具调用两者结合使用。10. 总结与下一步学习建议这篇文章从概念到实战完整走了一遍 LangChain MCP 的主流用法。现在回头总结真正值得记住的判断是LangChain 做编排MCP 做连接两者解决的是不同层面的问题。如果你正在构建 Agent 应用MCP 不是可选项而是让工具层不被绑定死的必要底座。下一步建议按这个顺序实践第一把文章里的system_info_server.py和langchain_client.py完整跑通确认你理解了 MCP 工具加载和调用机制。 第二尝试给 MCP Server 增加一个自己的工具比如查询本地某个 JSON 文件、调用一个 HTTP API然后让 Agent 去调用它。 第三学习 LangGraph 的状态图把现在简单的 ReAct Agent 改造成带分支和人工确认的流程。 第四关注你日常使用的工具是否有 MCP Server 支持。很多平台已经提供了现成的 MCP 服务直接在 LangChain 或 Dify 里接入即可不需要重复造轮子。如果面试中被问到 LangChain 和 MCP你要能说清楚三件事MCP 解决的是工具接入标准化问题LangChain 解决的是 Agent 编排问题两者组合的核心收益是工具解耦和复用成本下降。能用自己的项目讲明白这三层比背任何面试题都有说服力。这篇文章建议收藏备用遇到 MCP Server 连接问题、工具加载失败、Agent 不调用工具这些场景时翻回来看排查表格大概率能省下不少调试时间。