[控场AI]
· 6 分钟阅读· 3,240 字

LangChain MCP Agent关系详解:一文理清AI应用技术栈

LangChain MCP Agent关系详解:一文理清AI应用技术栈

构建AI应用时,很多开发者会被LangChain、MCP、LangGraph、Agent这些概念绕晕。它们究竟是什么关系?为什么要用框架而不是手写?MCP和早期的Function Calling又有何区别?本文基于一线实战经验,帮你彻底理清这套技术栈的底层逻辑。

LangChain:构建AI应用的开发框架

要理解LangChain,先要理解大模型能做什么。大模型的核心价值在于强大的推理能力——它能理解你的意思并给出有逻辑的回复,也能把杂乱无序的文件整理成结构化内容。但这里有一个天然缺陷:大模型回复的内容,本质上是它训练时那个时间点的数据。

那么问题来了:**如何让大模型结合企业内部的业务数据来对话?**答案是给大模型绑定工具。当大模型理解你的问题后,它可以调用工具去获取企业内部的业务数据或文本内容,再依靠推理能力整理成答案。

如果从零去实现大模型调用、工具管理、对话历史管理,精力就全都耗在底层,根本无法聚焦于业务。LangChain正是为解决这个问题而生——它是一套开发大模型应用的框架,把底层能力封装好,让开发者专注于业务逻辑。

把精力放在这里面

不要重复造轮子

一个很重要的观点:不要自己手写框架。有些开发者觉得既然有大模型API,就干脆自己手戳一个类似LangChain的框架,这完全没有必要。

类似的框架还有很多,比如Claude SDK、OpenAI SDK等,都能用来构建AI应用。这些框架已经把底层的大模型调用、并发处理、状态管理、对话内容管理都封装好了。站在巨人的肩膀上,把精力留给业务,才是正确的做法。

Agent:大模型之上的高层封装

除了单纯与大模型对话调用工具,我们更常听到的词是Agent(智能体)。Agent相当于在大模型之上做了更高层的封装,主要体现在两个方面:

第一,自动管理对话历史。你与大模型对话时会产生大量历史聊天记录,Agent能自动管理这些上下文。

第二,真正执行工具调用。大模型单独调用工具时,它只知道"该调用工具",但不会真正执行。而Agent可以真正操作调用工具、把结果返回,甚至根据工具返回的结果继续判断是否再次调用工具,形成一个自动化的循环。

在LangChain体系里,Agent的底层实现是由LangGraph完成的。LangGraph是更靠近底层的API,Agent则是基于LangGraph的上层封装。从架构上看,越靠底层越灵活,越靠上层封装越好、使用越方便。

MCP:统一工具调用的协议标准

早期开发Agent的痛点

理解MCP,要先理解早期开发Agent的痛点。不同厂商的大模型(DeepSeek广告、OpenAI、Claude等)在调用工具时,都有自己的一套API写法。假设你要调用4个工具,A模型有A的写法,B模型有B的写法,C模型又有C的写法。

这就带来一个严重问题:一旦更换底层大模型,调用工具的整套代码都要重写。

那LangChain和MCP啥关系呢

MCP协议的诞生与定义

MCP(Model Context Protocol,模型上下文协议)正是为此而生。它是由Anthropic(Claude背后的公司)提出的一套协议标准。

这套协议规定了:无论你是哪个厂商的大模型,只要按照MCP协议来开发工具,那么当你构建Agent、替换底层模型时,调用工具的代码都是同一套,无需重写。协议内容涵盖了如何发现工具、如何调用工具、如何处理工具返回的结果。

一个很形象的比喻:MCP就像电脑的USB接口。外部的工具就像U盘、硬盘等设备,只要兼容USB协议插上来,电脑都能识别。同理,无论上层用什么大模型,只要工具符合MCP协议,都能被调用。

目前几乎所有主流AI供应商——DeepSeek、通义千问广告、微软、百炼等——都已支持MCP协议,这为开发者带来了极大的便利。

MCP与Function Calling的区别和联系

很多人纠结"MCP用得多还是Function Calling用得多"。答案是:它们本质上是同一件事,只是两家公司的不同叫法。

Function Calling是OpenAI推出的概念,MCP是Anthropic推出的概念,做的是同一件事——让大模型能够调用外部工具。只不过MCP发展得更好,形成了更完整的协议标准,如今OpenAI也已完全兼容MCP。所以早期大家还在提Function Calling,现在几乎都统一说MCP了,不必在这个概念上纠结。

为什么用MCP工具而非LangChain自带工具

这是核心问题。LangChain本身就提供了定义工具的方式,比如用create_agent创建Agent时,通过tools参数指定工具,工具可以用装饰器方式直接定义(如get_stock_price获取股票价格、search_news搜索新闻)。既然如此,为什么还要用MCP开发工具?

各位你想想

答案在于复用与跨框架通用,具体有两大好处:

好处一:工具复用能力

LangChain自带方式定义的工具,仅能给当前代码里构建的那个Agent使用。如果在另一份代码里构建了新的Agent,想用相同的工具就得重新定义一遍,做不到很好的复用。而用MCP协议开发的工具,可以被多个Agent统一管理和复用。

好处二:跨框架通用性

LangChain自带方式写的工具,本质上只能给LangChain框架开发的Agent识别使用。但Agent不只有LangChain能做——Claude SDK、OpenAI SDK,乃至Cursor、Trae、Windsurf等编程工具,本质上也都是能调用工具的智能体。

LangChain自带工具无法给这些框架使用,而符合MCP协议开发的工具,可以给任何Agent使用,无论它是用哪个SDK构建的。这种跨框架的通用性,正是MCP最大的价值所在。

技术栈层级关系总览

最后梳理一下这套技术栈的层级(基于LangChain 1.3版本):

  • LangGraph:最底层的API,灵活度最高,适合需要精细控制流程的场景。
  • LangChain:在LangGraph之上,提供开发Agent的API,使用更便捷。
  • DeepAgents:更上层的封装,是Context Engineering(上下文工程)架构思想的体现,涵盖工具管理、内容隔离、文件处理、上下文自动压缩等能力。

大家慢慢讲的时候

从下往上:越靠底层越灵活,越靠上层封装越好、使用越方便。所谓的LangChain与MCP整合,更准确地说是Agent(或LangGraph)与MCP的整合——即用LangChain构建的Agent去调用MCP协议开发的工具。

总结

理清这套技术栈的关系,能帮你避开大部分弯路:

  • LangChain是构建AI应用的开发框架
  • Agent是大模型之上的高层封装,具备对话管理和工具执行能力
  • LangGraph是Agent的底层实现,提供更灵活的控制
  • MCP是统一工具调用的协议标准,解决跨模型、跨框架的兼容问题

核心原则:不要重复造轮子,把精力聚焦在业务本身,用MCP实现工具的复用与跨框架通用,才是构建企业级AI应用的正确路径。

#LangChain MCP整合#MCP协议#Agent智能体#LangGraph#Function Calling#AI应用开发框架#MCP工具调用#LangChain Agent开发
分享:

相关推荐