LangChain接入MCP与Skill：Agent工具调用实战解析

在AI Agent开发日益普及的今天，MCP（Model Context Protocol，模型上下文协议）和Skill成为绕不开的关键概念。然而，许多开发者对这两者的理解仍然模糊——甚至有人只是听说过名词，从未真正用过。本文将系统梳理LangChain Agent接入MCP与Skill的核心逻辑，帮助你理清概念、明确使用场景。

LangChain是当前最流行的大语言模型应用开发框架之一，由Harrison Chase于2022年创建。它提供了一套标准化的抽象层，使开发者能够将LLM与外部数据源、工具和API进行组合。LangChain中的Agent概念尤为关键——Agent是一种能够根据用户输入动态决定调用哪些工具、以什么顺序执行的智能体。与简单的Chain（固定流程链）不同，Agent具备推理和决策能力，能够在运行时根据中间结果调整策略。理解了这一背景，我们才能更好地把握MCP和Skill在其中扮演的角色。

为什么Agent开发需要MCP？

如果直接给出定义——"MCP是大语言模型调用外部工具、业务系统或传统接口的协议"——大多数人恐怕会一头雾水。它在语文层面是个"协议"，但到底解决什么问题，并不直观。

要真正理解MCP的价值，需要回顾软件开发的历史。在大模型出现之前，我们已经积累了几十年的软件系统：有的用Java开发，有的用Go，有的用PHP。市场上沉淀了海量的业务系统和接口。

一个关键问题随之而来：大模型火了之后，这些历史系统就都要废弃吗？答案显然是否定的。如果真是如此，市场上90%的程序员可能都要失业，整个社会的软件基础设施都会瘫痪。

以电商系统为例，我们有商品查询接口、库存查询接口等大量业务接口。大模型出现后，这些接口并不会消失，而是需要被大模型"理解"和"调用"——MCP正是为解决这个衔接问题而生。

从技术定位来看，MCP（Model Context Protocol）本质上是一种标准化的接口描述和调用协议，它定义了大模型如何发现、理解和调用外部工具的完整流程。与传统的API Gateway或RPC协议不同，MCP的核心创新在于引入了语义层——每个工具不仅有技术规格（参数类型、返回值），还必须包含自然语言描述，使大模型能够基于语义匹配来决定何时调用。这一设计理念源自Anthropic在2024年底开源的Model Context Protocol规范，旨在解决工具调用碎片化的问题。

传统接口的本质：为程序而非大模型设计

要理解MCP的必要性，我们得先看清传统接口的本质。

传统接口的调用链路

在一个典型的电商系统中，调用流程大致如下：前端负责页面展示，真正的业务逻辑由后端接口实现。当用户搜索商品时，前端调用后端的商品搜索服务，服务层执行业务逻辑，到数据库查询数据，最后返回商品列表。

典型的企业级应用采用分层架构：表现层（前端UI）、应用层（业务逻辑）、服务层（领域服务）和数据层（数据库）。在微服务架构流行后，各服务之间通常通过RESTful API、gRPC或消息队列通信。这些接口遵循严格的类型约定——调用方必须精确知道端点地址、HTTP方法、请求体格式和响应结构。这种设计对机器间通信高效可靠，但缺乏大模型所需的语义上下文。

这里的核心洞察是：传统接口本质上是给程序用的。比如一个ProductService里的search方法，程序员一看就懂——在哪一层、调哪个方法、参数是什么、返回值是什么类型（大概率是一个集合），这些对科班程序员来说清晰明了。

大模型为什么看不懂传统接口

但对于大模型来说，情况完全不同。你不能直接对大模型说"帮我调一下那个search方法"。

无论是ChatGPT、豆包还是DeepSeek，如果你直接让它"调用刚才写的方法"，它根本无从下手——它不知道这个接口做什么、参数怎么传、什么情况下该用、返回的数据是什么。

这正是问题的关键：传统接口是为程序设计的，而大模型需要的是自然语言层面的语义描述。它需要一个"工具"——一个带有清晰描述（这个工具是做什么的、什么时候用、参数含义是什么）的封装。当大模型面对一个明确描述的"商品查询工具"时，它才能正确地在合适的场景下发起调用。

要深入理解这一机制，需要了解Function Calling的技术原理。大模型的工具调用能力（Function Calling）是MCP得以实现的技术基础。OpenAI在2023年率先推出Function Calling功能，随后各主流模型厂商相继跟进。其原理是：在系统提示中以结构化格式（通常是JSON Schema）描述可用工具的名称、用途和参数，大模型在生成回复时可以选择输出一个工具调用指令而非直接文本回答。框架层负责解析这个指令、实际执行工具、将结果返回给模型进行下一步推理。MCP在此基础上进一步标准化了工具的注册、发现和调用流程，使得不同来源的工具能够以统一的方式被Agent使用。

MCP的核心价值：架起大模型与外部系统的桥梁

综合来看，MCP的价值在于架起了大模型与既有系统之间的桥梁。它把传统的、面向程序的接口，转化为大模型能够理解的、带有语义描述的"工具"。

这样一来：

• 企业几十年沉淀的业务系统无需推倒重来
• 大模型可以通过统一的协议调用这些能力
• Agent开发者不必为每个接口手写复杂的适配逻辑

在LangChain Agent开发的整个链路中，MCP是极其重要的一环。它让"大模型 + 业务系统"的组合成为可能，而不是让二者割裂存在。

MCP、Skill与RAG的区别和使用场景

很多开发者不仅对MCP模糊，对Skill乃至RAG也常常混淆——不知道什么场景该用哪个。这里做一个方向性的辨析：

• MCP（模型上下文协议）：解决大模型"调用外部工具/系统接口"的问题，强调协议化的能力对接
• Skill（技能单元）：更偏向于封装某种特定能力或技能单元，在某些场景下比MCP粒度更细、更灵活
• RAG（检索增强生成）：解决的是知识检索增强，让大模型基于外部知识库回答，与工具调用是不同维度的问题

关于Skill，需要进一步说明其在不同框架中的实现形式。在微软Semantic Kernel中，Skill被定义为一组相关函数的集合，每个函数代表一个原子能力。在更广泛的Agent开发语境中，Skill通常指封装了特定领域能力的模块，它可能包含多个工具调用、提示模板和后处理逻辑的组合。与MCP强调"协议层面的标准化对接"不同，Skill更关注"能力层面的模块化封装"——一个Skill内部可能通过MCP调用多个外部接口来完成一个复杂的业务动作。例如，一个"订单处理Skill"可能内部组合了库存查询、价格计算和物流调度三个MCP工具调用。

关于RAG，其技术原理值得深入了解。RAG（Retrieval-Augmented Generation，检索增强生成）由Meta AI在2020年提出，核心思路是将外部知识库的检索过程嵌入到生成流程中。典型RAG流程包括：将文档分块并通过Embedding模型转为向量、存入向量数据库（如Pinecone、Milvus、FAISS）、用户提问时先检索相关文档片段、将检索结果作为上下文注入Prompt、最终由LLM基于上下文生成回答。RAG解决的是"知识不足"问题（模型训练数据的时效性和专业性限制），而MCP解决的是"能力不足"问题（模型无法执行外部操作）。前者是"让模型知道更多"，后者是"让模型做到更多"。

三者并非互斥，而是在Agent架构中承担不同职责。理解它们各自解决的问题，才能在实际项目中做出正确选型。在一个完整的Agent系统中，这三者往往协同工作：RAG提供知识支撑，MCP打通外部系统，Skill组织和编排复杂业务逻辑。

总结：从理解核心矛盾出发掌握MCP

对于已经学过LangChain的开发者来说，接入MCP和Skill相当于在原有基础上"加装新能力"。理解MCP的第一步，不是死记协议定义，而是想清楚：传统接口为程序而生，大模型需要语义化的工具描述。抓住这一核心矛盾，MCP存在的意义也就豁然开朗了。

在后续的实战中，把MCP、Skill与RAG的边界厘清，才能真正搭建出既能复用既有系统、又能灵活扩展的AI Agent应用。