LangChain与MCP整合实战：从框架到Agent开发

为什么需要 LangChain：别在底层调用的泥潭里重复造轮子

大模型的推理能力很强，能理解问题并给出回复，但它回复的内容本质上是训练数据里的知识。想让大模型结合公司内部业务数据来对话，常见做法是给它绑定工具——模型不仅能理解问题，还能调用工具获取业务数据或文本内容，再依靠推理能力整理成答案。

问题在于，如果自己手写大模型调用、工具管理、对话历史管理这一整套逻辑，精力会被底层细节大量消耗，难以聚焦业务。LangChain 正是为此而生的开发框架：它把大模型调用、工具定义、对话状态管理等能力封装成可直接使用的 API，让开发者站在巨人肩膀上做应用。

那么解释完了Longchain

课程中讲师还澄清了一个常见误区：不建议手搓一个 LangChain 式的框架。既然已有成熟框架，把时间花在重复实现底层调用和状态管理上并不划算，聚焦业务才是更合理的选择。

Agent 是比大模型更高层的封装

智能体（Agent）可以理解为对大模型更高层的封装。单独和大模型对话时，聊天历史需要自己管理；调用工具时，大模型只知道"要调用"，并不会真正执行。Agent 补上了这些环节：自动管理历史记录、真正执行工具调用并返回结果，还能根据工具返回的结果判断是否需要继续调用工具。

据讲师介绍，LangChain 底层用 LangGraph 实现 Agent 能力，LangGraph 更贴近底层、更灵活，而 Agent 层做了上层封装、使用更方便。框架提供的 API 从下往上越靠上封装越好、对用户越友好。

LangGraph 是 LangChain 团队推出的底层编排框架，其核心抽象是“图”：节点代表计算步骤（如调用模型、执行工具），边代表步骤间的流转条件，状态则在节点间传递与累积。相比早期 LangChain 的链式结构，图结构支持循环、分支与中断恢复，因此天然适合实现 Agent 的“推理—调用工具—根据结果再决定下一步”的多轮闭环。LangChain 的 Agent 层正是在 LangGraph 之上做了默认图模板与便捷参数封装，让开发者不必手写状态机即可获得完整的工具调用循环，代价是灵活性略低于直接使用 LangGraph。

MCP 解决的是工具调用的"接口标准"问题

早期不同厂商的大模型在调用工具时各有各的写法：A 模型调用四个工具有一套 API 写法，B 模型调用同样的四个工具又要另写一套。一旦 Agent 底层更换模型，调用工具的代码就可能全部重写。

MCP（Model Context Protocol）就是为消除这种碎片化而出现的协议。它规定了工具如何被发现、如何被调用、如何返回结果；只要工具按这套协议开发，无论上层是哪个厂商的模型都能兼容适配。讲师用 USB 接口做类比：只要外设兼容 USB 协议，插上电脑就能被识别。

就是说我的大模型

MCP 由 Anthropic（Claude Code 背后的公司）提出，据课程内容，该协议发布后主流 AI 供应商几乎都已支持 MCP，生态兼容性带来了极大的便利。

function calling 和 MCP 是一回事吗

课程中专门回应了这个高频疑问：function calling 是 OpenAI 推出的概念，MCP 是 Anthropic 推出的概念，两者做的是同一件事，只是不同公司的不同叫法。据讲师说明，OpenAI 如今也已完全兼容 MCP，因此把两者看作同一个东西没有问题——早期大家提 function calling，现在更多直接说 MCP。

工具发现与注册 是 MCP 协议中容易被忽略但很关键的一环。按 MCP 规范，工具由 MCP Server 以结构化描述（名称、用途说明、入参 JSON Schema）对外暴露，Client 在连接时先拉取这份工具清单，再交给大模型判断何时调用、如何填参。这意味着新增或修改工具只需在 Server 侧完成，所有接入的 Agent 自动获得更新，无需改动调用方代码。协议同时定义了传输方式（如本地 stdio、远程 HTTP/SSE）和结果返回格式，使工具可以独立部署、跨进程甚至跨网络复用。

LangChain 与 MCP 的整合：重点在 Agent

LangChain 提供调用大模型和开发 Agent 的 API，MCP 提供按协议开发的工具集，两者的整合就是让 LangChain 构建的 Agent 能调用 MCP 工具。由于单独使用大模型缺乏上下文管理和中间件处理，实际开发中更多讨论的是 Agent 与 MCP 的整合，即 LangGraph 层面的整合。

这个就是lunchain的agent嘛

为什么有了内置工具还要用 MCP

LangChain 自身提供了定义工具的方式，例如用 create_agent 创建 Agent 时，model 参数指定大模型，tools 参数指定工具列表；工具本身可以用 add_tool 这类方式定义。课程示例中的两个工具——按公司名查询股价的 get_stock_price 和搜索公司新闻的 search_news——与 MCP 没有任何关系，纯粹是 LangChain 内部开发的工具。

既然如此，为什么还要开发 MCP 工具？核心有两个原因：

工具复用：内建工具只能服务于当前代码里构建的那个 Agent。第二个代码里新建一个 Agent 想用同样的工具，就得重新定义一遍。把工具用 MCP 管理起来，多个 Agent、多处代码可以共享同一套工具。
跨框架解耦：LangChain 内建工具只能被 LangChain 开发的 Agent 识别。而现实中还有 Cloud SDK、OpenAI SDK 等框架，以及各类 AI 工具，它们同样是 Agent、同样要调用工具。按 MCP 协议开发的工具可以提供给任何 Agent 使用，与具体框架解耦。

我刚才已经解释过这个这个问题了

工具拦截器（tool interceptor） 是 MCP 集成中的常用机制：在 Agent 真正执行工具调用前后插入一层可编程逻辑，用于参数校验、权限检查、调用日志、结果脱敏或失败重试。由于 MCP 工具来自外部 Server，调用方往往无法直接修改其内部实现，拦截器就成了在客户端侧统一施加管控策略的位置。它与 MCP 的“解耦”理念互补——工具按标准协议提供能力，管控策略则按需在调用方叠加，二者不必耦合在同一份代码里。

课程中的其他要点与学习建议

版本信息：课程基于 LangChain 1.3 版本讲解。
LangChain 4J：讲师建议直接学 LangChain，LangChain 4J 目前用得不多，Python 版 LangChain 的生态更完整。
学习路径：小白可以从零基础开始学大模型开发；如果连大模型是什么都不清楚，课程会稍有难度——大模型即大语言模型，可理解为能对话、能做推理回复的系统。
工具选择：做企业自研 AI 应用适合用 LangChain 这类框架；如果只是想要编程助手，可以用 Claude Code、Cursor 这类现成工具。
架构关系：Harness 是一种架构思想（如何管理工具、做内容隔离、上下文自动压缩等），DeepAgent 是这种思想的一种实现，而 DeepAgent 底层基于 LangChain 和 LangGraph 开发。

课程后续内容

按原始课程大纲，本教程覆盖 MCP Server 开发、客户端集成、工具拦截器，以及电商 Agent 项目落地，属于从 0 到 1 的实战路径。本文梳理的是概念铺垫部分，理解框架分层与协议价值，是后续动手开发 MCP Server 和 Agent 项目的前提。