LangChain集成MCP实战：从概念到多工具AI应用搭建

从大模型到AI应用：为什么需要开发框架

大语言模型（LLM）的核心能力是强大的推理与理解，我们可以通过对话让它理解意图并给出回复。但大模型本身存在一个天然局限：它的知识仅停留在训练时的数据快照上，无法感知企业内部的实时业务数据。具体而言，大语言模型的训练数据存在时间截止点（knowledge cutoff），例如GPT-4的训练数据截止到2023年4月，Claude 3的训练数据截止到2024年初。这意味着模型对截止日期之后发生的事件一无所知。更重要的是，模型永远无法获知企业内部的私有数据——如CRM系统中的客户信息、ERP中的库存数据、内部知识库文档等。这一局限性催生了RAG（检索增强生成）和工具调用两大技术路线。

RAG（Retrieval-Augmented Generation，检索增强生成）由Meta AI研究团队于2020年首次提出，其核心思想是在生成回答之前，先从外部知识库中检索相关文档片段，将检索结果作为上下文注入到提示词中，再由大模型基于这些上下文生成回答。RAG的典型技术栈包括：文档分块（Chunking）、向量嵌入（Embedding）、向量数据库存储（如Pinecone、Milvus、Chroma）、相似度检索、以及最终的上下文拼接与生成。RAG主要适用于"查询已有信息"的场景，而工具调用则适用于"执行操作"的场景（如查询实时API、操作数据库等），二者互补，共同构成了企业级AI应用的基础能力。

要让大模型结合企业内部业务进行对话，一个关键手段就是给大模型绑定工具。工具绑定（Tool Binding）的底层机制是：开发者将工具的名称、描述和参数Schema以结构化JSON格式传递给大模型。大模型在推理时，会根据用户问题判断是否需要调用工具，如果需要，它会输出一个结构化的工具调用请求（包含工具名和参数值）。需要注意的是，大模型本身并不执行工具，它只负责"决策"调用哪个工具以及传什么参数——真正的执行需要外部程序来完成。绑定工具后，大模型不仅能理解你的问题，还能调用工具获取企业内部的实时数据，再依靠推理能力整理并给出有逻辑的回答。

但如果我们从零手写大模型调用、工具管理、对话内容管理这些底层逻辑，精力就会全部消耗在基础设施上，而无法聚焦于真正创造价值的业务层。LangChain 正是为解决这个问题而生的AI应用开发框架。LangChain由Harrison Chase于2022年10月创建，已发展为AI应用开发的事实标准框架之一。其核心模块包括：LangChain Core（基础抽象层）、LangChain Community（第三方集成）、LangGraph（有状态多步骤编排）、LangSmith（可观测性平台）。LangChain通过统一的Runnable接口将模型调用、提示模板、输出解析器等组件串联，支持LCEL（LangChain Expression Language）声明式编排，大幅降低了构建复杂AI应用链的代码量。

LCEL是LangChain在2023年下半年引入的声明式编排语法，其核心是将所有组件统一为Runnable接口，通过管道操作符（|）将组件串联。例如 chain = prompt | model | parser 就声明了一个"提示词→模型调用→输出解析"的处理链。LCEL的设计灵感来源于Unix管道和函数式编程中的组合子模式，关键优势包括：自动支持流式输出（streaming）、自动支持异步调用（async）、自动支持批量处理（batch）、以及内置的重试和fallback机制。开发者只需关注数据流转逻辑，框架自动处理并发、错误恢复等运行时关注点。LangChain把大模型调用、并发控制、状态管理、对话历史管理等繁琐工作封装好，让开发者站在巨人的肩膀上专注业务。

值得强调的是：类似的框架还有 Claude SDK、OpenAI SDK 等，都可以用来构建AI应用。不建议为了"钻牛角尖"而手写一个框架——那些成熟框架本身就是从零实现的优秀方案，重复造轮子只会浪费精力。

Agent智能体：比大模型更高层的能力封装

除了直接与大模型对话调用工具外，如今更火的概念是 Agent（智能体）。Agent 是在大模型之上做了更高层的封装，它的能力体现在几个方面：

• 自动管理对话历史：大模型对话会产生大量历史聊天记录，Agent 可以自动帮你管理这些上下文。
• 真正执行工具调用：大模型单独调用工具时，它只"知道"要调用哪个工具，但不会真正去执行。而 Agent 能够真正操作工具、执行调用，并把结果返回。
• 多轮自主决策：Agent 还能根据工具返回的结果，继续判断是否需要调用下一个工具，形成自主的推理循环。

Agent的多轮自主决策能力源于ReAct（Reasoning + Acting）范式，由普林斯顿大学的Shunyu Yao等人在论文《ReAct: Synergizing Reasoning and Acting in Language Models》（2022年10月发表于ICLR 2023）中提出。其核心思想是：模型先进行推理（Thought），然后决定行动（Action），观察行动结果（Observation），再进入下一轮推理。在ReAct之前，存在两种独立的范式：Chain-of-Thought（CoT）仅做推理不执行操作，而传统Agent仅执行操作缺乏显式推理。ReAct将二者统一，通过在提示词中交替生成Thought和Action来实现。实验表明，ReAct在知识密集型任务（如多跳问答）和决策任务（如网页导航）上均优于纯推理或纯行动的方法。这种"思考-行动-观察"的循环赋予了Agent超越单次问答的复杂任务处理能力。

正因为如此，本文讨论的 LangChain 集成 MCP，本质上更多是指 Agent 与 MCP 的整合。在 LangChain 的技术栈中，Agent 的底层实现依托的是 LangGraph——一个更靠近底层、更灵活的 API 层。LangGraph将Agent的执行流程建模为有状态的有向图（Stateful Graph），开发者可以定义节点（Node）和边（Edge），节点代表具体操作（如调用模型、执行工具），边代表流转条件（如模型决定调用工具则流转到工具执行节点）。相比传统的链式调用，图结构支持循环、条件分支和并行执行，能表达更复杂的Agent行为模式。

LangGraph的有状态有向图模型借鉴了状态机和数据流编程的思想。在传统的链式调用中，执行流是线性的——A→B→C，无法表达"如果B的结果满足条件则回到A"这样的循环。而图结构天然支持循环边（Cycle），这对Agent至关重要，因为Agent的ReAct循环本质上就是一个"模型节点→条件判断→工具节点→模型节点"的环。LangGraph的状态（State）是一个TypedDict，在图的每次节点执行后被更新。检查点（Checkpoint）机制将完整的状态快照持久化到存储后端（如SQLite、PostgreSQL），支持断点恢复、时间旅行调试（回退到历史状态）和人机协作（human-in-the-loop，在关键决策点暂停等待人类确认）。从下往上看：LangGraph 最灵活，LangChain 的 Agent API 居中，DeepAgent 则封装度最高、对用户最友好。

MCP协议详解：AI世界的USB接口

MCP（Model Context Protocol，模型上下文协议）是理解本文的核心概念。它要解决的痛点非常具体。

痛点：不同大模型调用工具的写法各不相同

假设你的 Agent 底层用的是某个厂商的大模型（如 DeepSeek、OpenAI、Claude），每个厂商调用工具都有自己的一套 API 写法。这就意味着：

一旦你的 Agent 底层更换大模型厂商，原来那套调用工具的代码往往就崩掉了，需要针对新模型重写一遍。这对多模型、多工具的复杂系统来说是巨大的维护负担。

解决方案：一套标准协议兼容所有模型

MCP 由 Anthropic（Claude 的母公司） 于 2024 年 11 月提出。Anthropic由前OpenAI研究副总裁Dario Amodei于2021年创立，以AI安全研究著称，其代表产品Claude系列模型在推理能力和安全性方面表现突出。MCP的设计动机源于行业痛点：当时每个AI厂商都有自己的工具调用格式，开发者需要为不同模型维护不同的工具适配代码。MCP采用JSON-RPC 2.0作为底层通信协议，定义了工具发现（list tools）、工具调用（call tool）、资源访问（read resource）等标准化操作，并在GitHub上以开源方式维护规范文档和SDK。

JSON-RPC 2.0是一个轻量级的远程过程调用协议，使用JSON作为数据格式，定义了标准的请求结构（包含method、params、id字段）和响应结构（包含result或error、id字段）。相比RESTful API，JSON-RPC更适合"调用某个方法并获取结果"的语义，与MCP中"调用工具"的场景天然契合。MCP选择JSON-RPC而非gRPC或REST，主要考虑是：JSON-RPC足够简单、易于跨语言实现、无需复杂的路由设计，且支持批量调用和通知（无需响应的单向消息），这对工具发现和异步工具执行非常有用。

MCP规定了一套统一标准：无论你是 OpenAI、DeepSeek、Claude 还是微软、亚马逊的模型，只要工具按照 MCP 协议开发，任何符合协议的模型都能发现、调用并处理这些工具的返回结果。

用一个绝妙的类比来解释：MCP 就像电脑的 USB 接口。外部的 U 盘、硬盘、其他设备（对应各种工具），只要兼容 USB 协议，插上就能被电脑识别；而电脑这一端（对应大模型），无论换成什么型号，都能识别这些标准接口的设备。

目前几乎所有主流 AI 供应商都已支持 MCP。此前流行的 Function Calling（OpenAI 提出的概念）与 MCP 做的其实是同一件事。Function Calling由OpenAI于2023年6月随GPT-3.5/GPT-4 API发布时首次引入，它定义了模型如何输出结构化的函数调用请求——开发者在API请求中附带functions参数（JSON Schema描述），模型在响应中可能返回function_call字段（包含函数名和参数），开发者代码负责解析该字段、执行实际函数、将结果作为新消息回传给模型。但Function Calling仅规范了模型侧的输出格式，并未规范工具服务端如何注册、发现和暴露工具。MCP则更进一步，它不仅覆盖了调用协议，还标准化了工具的注册、发现、描述、权限控制等完整生命周期。可以说Function Calling解决了"模型如何表达调用意图"，而MCP解决了"工具如何被统一管理和跨系统共享"。如今 OpenAI 也已完全兼容 MCP，MCP 已成为事实标准。

LangChain原生工具的局限性分析

LangChain 框架本身也提供了定义工具的方式，比如通过装饰器直接声明工具：

from langchain.agents import create_agent

# 定义 LangChain 原生工具
def get_stock_price(company: str):
    """根据公司名获取股票价格"""
    ...

def search_news(company: str):
    """搜索指定公司的相关新闻"""
    ...

agent = create_agent(
    model="...",           # 指定大模型
    tools=[get_stock_price, search_news]  # 指定工具
)

既然 LangChain 已能定义工具，为什么还要用 MCP？关键在于复用与解耦这两大问题。

局限一：工具无法跨代码复用

LangChain 原生定义的工具，只能给当前代码里构建的这个 Agent 使用。如果你在另一份代码中构建了新的 Agent，想复用相同的工具，就必须把工具重新定义一遍，做不到很好的复用。

局限二：工具无法跨框架使用

LangChain 原生工具只能被 LangChain 的 Agent 识别。但现实中 Agent 框架多种多样——Claude SDK、OpenAI SDK，乃至各类编程助手如 Cursor、Codex 等都是能调用工具的智能体。用 LangChain 原生方式写的工具，无法提供给这些异构框架使用。

MCP 恰好补齐了这两点：

1. 工具复用：通过 MCP 集中管理工具，多份代码、多个 Agent 都能连接同一套 MCP 工具。这类似于微服务架构中将公共能力抽取为独立服务的思想——工具作为独立的MCP Server运行，任何需要该能力的Agent只需连接即可使用，无需重复实现。
2. 框架解耦：只要符合 MCP 协议开发的工具，可以提供给任意 Agent 使用，无论对方是 LangChain、Claude SDK 还是 OpenAI SDK。这实现了工具提供者和工具消费者之间的完全解耦，开发者可以独立演进工具实现而不影响上游Agent。

MCP的架构理念与微服务架构高度一致。在微服务架构中，单体应用被拆分为多个独立部署的服务，服务间通过标准化协议通信。类似地，MCP将工具从Agent代码中抽取为独立的Server，每个Server可以专注于一个领域（如一个Server提供数据库查询工具，另一个提供邮件发送工具）。这带来了微服务的经典优势：独立部署（工具更新不需要重启Agent）、技术异构（工具Server可以用任何语言实现，只要遵循MCP协议）、独立扩展（高频工具可以水平扩容）、故障隔离（某个工具Server崩溃不影响其他工具和Agent本身）。

MCP Server与Client：两大角色及通信机制

构建 MCP 应用时，需要理解其中的两类核心角色：

• MCP Server（服务端）：构建并暴露一系列工具的一端。你把工具封装好后通过 Server 对外发布。
• MCP Client（客户端）：使用工具的一端，也就是 Agent 所在的一端。Agent 要连接 MCP Server 来调用工具，它就扮演 Client 角色。

对应上面的 USB 类比：Client 端相当于大模型/电脑主机，Server 端相当于挂载着各种工具的外设。

Stdio与Streamable HTTP两种通信方式

Client 与 Server 之间的通信有两种典型场景：

1. Stdio（标准输入输出）

当 Client 与 Server 运行在同一节点（甚至同一进程）时，可采用 Stdio 方式。它以标准输入输出流进行通信，适合本地开发与调试场景。更严谨地说，Stdio 模式的技术实现是：Client进程通过subprocess机制启动Server进程，然后通过操作系统的管道（pipe）进行进程间通信。Client向Server的stdin写入JSON-RPC请求，从Server的stdout读取JSON-RPC响应。这种方式的优势是零网络开销、无需端口配置、天然安全（不暴露网络接口）；劣势是Client和Server必须在同一台机器上，且Server的生命周期与Client绑定——当Client进程退出时，Server进程也会随之终止。

2. Streamable HTTP

当 Server 部署在远端、Client 位于另一个进程或节点时，就采用 Streamable HTTP（常简称 HTTP）的通信方式。Streamable HTTP是MCP协议在2025年3月引入的远程通信方式（替代了早期的SSE方案）。它基于标准HTTP协议，Client通过POST请求向Server的/mcp端点发送JSON-RPC消息。Server可以选择直接返回JSON响应，也可以升级为SSE（Server-Sent Events）流式响应，适合长时间运行的工具调用。SSE是HTML5标准中的服务器推送技术，允许服务端通过持久的HTTP连接向客户端发送多条消息，非常适合工具执行过程中的进度反馈或流式结果输出。这种设计兼顾了简单场景的低延迟和复杂场景的流式能力，同时天然支持负载均衡、TLS加密等生产级基础设施，适合分布式、服务化的生产部署场景。

总结：从概念到实践的完整路径

本文梳理了从大模型、Agent 到 MCP 的完整技术脉络：

• LangChain 是构建 AI 应用的高效框架，让开发者专注业务而非底层实现。
• Agent 在大模型之上封装了对话管理、工具执行与多轮决策能力。
• MCP 作为统一协议，像 USB 接口一样实现了工具与模型的解耦，带来跨代码复用和跨框架兼容两大核心价值。

理解了这些概念后，就可以着手实践：搭建 MCP Server 发布工具、用 LangChain/LangGraph 构建 Agent 作为 Client 连接工具，并在同一个 Agent 中同时使用本地工具与 MCP 工具，切身感受二者的区别。这也是构建可调用多工具 AI 应用的关键第一步。

核心要点

核心要点