LangChain + MCP 实战：架构协议与 Agent 工具集成

大模型能对话、能推理，但要让它真正接入企业内部业务，光靠对话远远不够。LangChain 和 MCP 的组合，正在解决工具复用与跨框架兼容这两个核心痛点。

LangChain 是什么：构建 AI 应用的框架

LangChain 是一个开发大模型应用的框架。大模型本身具备推理能力，可以理解用户意图、整理杂乱信息，但它回复的内容基于训练时的数据，无法直接获取企业内部业务数据。要让大模型结合公司业务对话，就需要给它绑定工具——让它在理解问题之外，还能调用工具获取业务数据或文本内容，再依靠推理能力给出回答。

自己从零手写大模型调用、工具管理、对话历史管理，精力会被大量消耗在底层逻辑上。LangChain 把这些能力封装成现成 API，开发者可以把精力聚焦在业务本身。类似框架还有 Cloud SDK、OpenAI SDK 等，但没必要自己手搓一个 LangChain 的替代品——站在巨人肩膀上更划算。

理解 LangChain 的定位，可以把它拆成几个可替换的抽象层：Model（统一封装各家大模型的调用接口）、Tool（把业务函数描述成模型可理解的结构）、Retriever（对接向量库做检索增强）、Memory / 会话状态（管理多轮对话历史）以及把这些串联起来的链（Chain）与编排层。开发者替换模型供应商时，通常只需改动 Model 层的一行配置，其余业务逻辑不受影响。

LangChain 采用 MIT 开源协议，同时提供 Python 与 JavaScript/TypeScript 两套实现，社区生态包含大量现成的文档加载器、向量库适配器和工具集成。需要注意的是，LangChain 早期以「链」为核心，后来编排能力逐渐下沉到同团队开发的 LangGraph，LangChain 本身更侧重模型、工具、检索等组件抽象，这也是文中技术栈分层说法的由来。

Agent 是更高层的封装

Agent（智能体）比单纯的大模型调用做了更高层的封装。与大模型对话会产生大量历史聊天记录，Agent 可以自动管理；大模型单独调用工具时只知道要调用，却不会真正执行，Agent 会真正完成工具调用并返回结果。更进一步，Agent 还能根据工具返回的结果判断是否需要继续调用工具。

在 LangChain 框架中，create_agent 是创建 Agent 的入口，指定模型和工具即可。LangChain 自身提供了定义工具的方式，比如用 add_tool 定义 get_stock_price、search_news 这类业务工具。但这些工具与 MCP 没有关系，这也引出了 MCP 存在的理由。

MCP 解决什么问题：工具与模型的解耦

早期 Agent 调用工具时，不同大模型厂商各有一套写法。A 模型调用工具 1、2、3、4 有一套 API，B 模型调用同样四个工具又有一套写法，C 模型再有一套。结果就是一换底层模型，调用工具的代码可能全部重写。

MCP（Model Context Protocol）是一套协议，规定了工具如何被发现、如何被调用、如何处理返回结果。无论上层是 OpenAI、DeepSeek^广告、Cloud 还是其他厂商的模型，只要工具按 MCP 协议开发，就能被兼容适配。它类似电脑的 USB 接口：外部设备只要兼容 USB 协议，插上就能被识别。

MCP 由 Anthropic 提出，发布后迅速获得主流 AI 供应商支持。据分享者观察，几乎所有主流供应商的大模型都能调用按 MCP 协议开发的工具，这带来了极大的便利。

MCP 在架构上采用客户端—服务器模型：MCP Server 负责暴露能力，MCP Client 通常内置于 Agent 宿主或 AI 应用中，二者通过标准化消息通信。协议定义了三种主要能力——Tools（可被模型调用的函数）、Resources（可供读取的数据或文件上下文）、Prompts（预置的提示模板），使「工具」之外的上下文供给也被统一。

传输层上，MCP 支持基于标准输入输出的本地 stdio 方式，以及基于 HTTP 的远程方式（早期为 HTTP+SSE，后演进为 Streamable HTTP），前者适合把本地脚本或数据库封装成工具，后者适合团队共享的公共服务。这种设计让 MCP Server 可以独立开发、独立部署、独立升级，与调用它的 Agent 完全解耦，因此一个企业内部系统只需实现一次 MCP Server，就能同时服务于不同团队、不同框架乃至不同厂商的 AI 产品。

LangChain 与 MCP 整合的真实价值

在 LangChain 中直接定义的工具，只能给当前代码里构建的那个 Agent 使用。如果第二个代码构建了新的 Agent，想复用同样两个工具，就得重新定义一遍，复用性很差。

MCP 带来两个明确好处。其一，工具可以做到很好的复用：多个代码、多个 Agent 需要相同工具时，用 MCP 统一管理即可。其二，按 MCP 协议开发的工具不局限于 LangChain 构建的 Agent，任何符合 MCP 协议的 Agent 都能使用，包括 Cloud SDK、OpenAI SDK 开发的 Agent，以及各类 AI 编程工具等，实现了与具体框架的解耦。

实际讨论中，分享者也会用案例把本地工具和 MCP 工具放在同一个 Agent 里使用，直观呈现两者的差异。

MCP 与 Function Calling 是什么关系

Function Calling 是 OpenAI 推出的概念，MCP 是 Anthropic 推出的概念，两者做的是同一件事，只是不同公司的不同叫法。区别在于 Function Calling 没有 MCP 发展得好，而 OpenAI 如今也已完全兼容 MCP。在今天的语境下，把两者看作同一个东西没有问题，业界讨论中 MCP 的出现频率明显更高。

Function Calling（函数调用）是大模型提供的一种结构化输出能力：开发者以 JSON Schema 描述可用函数的名称、参数与用途，模型在需要时返回符合该 Schema 的调用请求，由宿主程序执行并把结果回传给模型。它的本质是「模型告诉你要调什么」，真正的执行仍由应用侧完成。因此 Function Calling 是模型侧能力，而 MCP 是应用侧的通信协议，二者处于不同层次：一次 MCP 工具调用在底层往往正是通过 Function Calling 让模型产生调用意图，再由 MCP 客户端完成发现、传输与结果回填。

这也解释了为什么二者常被混为一谈——从开发者视角看，最终效果都是「模型用上了外部工具」。但 MCP 额外规定了工具的注册与发现机制、传输方式（如 stdio 与 HTTP）以及生命周期管理，使得同一份工具实现能被不同模型、不同框架复用，这是单纯的 Function Calling 不具备的。

技术栈层次与常见疑问

LangChain 的技术架构从下往上依次是：LangGraph 作为更靠近底层的 API，Agent 基于 LangGraph 开发并做上层封装，再往上是 Deep Agent。越靠下的 API 越灵活，越靠上的封装使用越方便。

此外，Harness 是一种架构思想，涉及工具管理、内容隔离、文件处理、上下文自动压缩等；它的实现体现在 Deep Agent 层，而 Deep Agent 底层基于 LangChain 和 LangGraph 开发。

对于想入门大模型开发的小白，答案是可行的，但需要从零基础学起。智能体本身没有国内外之分，有国内外之分的是大模型；开发智能体建议直接用 LangChain。至于 Codex、Cursor 这类工具，主要面向编程场景，与企业内构建自有 AI 应用是不同层面的问题。