一、两位工程师，为了一个“AI 助手”吵起来了

上周和一个朋友聊天，他在一家 ToB 创业公司做技术负责人。

他们准备做一个“销售 AI 助手”：

• 能查 CRM 里的客户信息

• 能看飞书文档里的成交话术

• 能根据当天线索，生成跟进建议和话术

而在他们技术方案会上，两个工程师吵了起来：

小王：
“我们用LangChain做一个 Agent，接CRM、接文档库、接搜索，再编排个流程就完事了。”

小李：
“现在都2025了，搞什么LangChain啊，直接上MCP。
以后不管接 Claude 还是别的模型，都能复用。”

不懂技术的老板懵了：

“MCP、LangChain，不都是给大模型接工具的吗？
差别在哪？会不会选错坑一两年？”

MCP 和 LangChain，本质上在干的完全不是一件事。

二、MCP / LangChain 是什么？

1. LangChain 是什么？

通俗来说： LangChain = 给程序员用的“AI 应用开发框架”。

它帮你干的，是一整条“从无到有把 AI 应用搭出来”的活儿：

• 怎么把模型、向量库、数据库、搜索、工具拼在一起（Chains / Agents）

• 怎么把多步推理、调用顺序、分支逻辑组织清楚

• 怎么把过程里的中间结果、记忆、对话上下文管理起来

• 提供一堆现成的封装：LLM、Embeddings、VectorStore、Tools、Memory…

如果你有技术基础，你可以把他理解为：

一个针对“AI 应用”的后端开发框架，（有点像当年的 Django / Spring，只不过对象换成了大模型应用）。

2. MCP 是什么？

通俗来说：MCP = 一套“通用标准 + 通信协议”，专门定义“大模型怎么用各种工具 / 系统”。

它 不帮你 写业务逻辑，也不帮你编排流程，它只做一件小而关键的事：

• 约定：一个“工具服务器”要怎么向大模型自我介绍

  • 我有什么能力（tools）

  • 每个能力要什么参数、返回什么

  • 哪些操作是危险的，要二次确认

• 约定：大模型要怎么“请求使用工具”、怎么拿结果

你可以把它理解为：

给大模型和外部系统，定了一套“USB 口”的标准。
谁都可以实现自己的“U 盘 / 鼠标 / 键盘”（MCP server），
只要插上这口，任何支持 MCP 的大模型客户端都能用。

三、核心区别：一个做“工程 + 编排”，一个做“标准 + 接口”

很多人之所以容易把 MCP 和 LangChain 混为一谈，是因为它们都在讨论：大模型怎么用工具。

但站位完全不一样，可以用一个比喻：

• MCP 更像“插线板标准 + 插头协议”
  规定插头长啥样、电压多少，怎么插都能用。

• LangChain 更像“装修队 + 施工图 + 现场调度”
  负责：水电怎么走线、开关在哪、先装哪里、后装哪里。

我用几个具体维度，帮你拆开看。

---

四、从 5 个维度看差异

1. 面向对象：谁在用它？

• LangChain：给“写代码的人”用的工程框架

  • Python / TS 程序员

  • 写后端 / 工具链的工程师

  • 需要构建一整个 AI 应用的人

• MCP：给“工具提供方 + 模型客户端”用的协议

  • 想把自家系统开放给各种大模型用的开发者（CRM、内部系统、SaaS…）

  • 做 IDE 插件、桌面客户端、网页客户端的人

  • 本质上是 infra / 平台层的角色

一句话：
LangChain 更像“应用层开发框架”， 而MCP 更像“基础设施层标准协议”。

---

2. 解决的问题范围：大还是小？

• LangChain：管得多

  • LLM / Embedding 调用封装

  • 向量库接入（Chroma、FAISS、PGVector…）

  • RAG（检索增强生成）的标准套路

  • Chains（顺序/并行）

  • Agents（动态选择工具）

  • 还有各种 Memory、Callback、Tracing…

• MCP：管得极少，只管“模型 ↔ 工具”这一条链路

  • 定义工具（Tool）的元信息

  • 定义调用请求 / 返回结构

  • 定义“资源”（如文件、文档）怎么暴露给模型

  • 不关心：

    • 你怎么做多步推理

    • 你是 RAG 还是 Agent

    • 你用的是哪家大模型

所以有一个很关键的认知：

MCP 自己不是“Agent 框架”，
它只是给 Agent / 客户端提供了“统一的工具接口”。

Agent 可以是：

• LangChain 里的 Agent

• 你自己手写的一个 Python 逻辑

• 某个 IDE / 桌面应用内置的“AI 助手”

---

3. 谁负责“流程编排”？

拿“查订单 + 查用户 + 给运营建议”这个场景举例。

用 LangChain 的时候：

你一般会：

• 写一个 Chain / Agent 或 LangGraph 的 Flow：

  • 第一步：根据问题调用搜索 / RAG

  • 第二步：选择要不要调用订单系统工具

  • 第三步：再要不要调用用户画像工具

  • 最后：综合结果，生成一段自然语言结论

流程的“脑子”（要不要调用哪个工具、顺序如何）
是你在 LangChain 里“写出来的”。

用 MCP 的时候：

• 你先有一些 MCP server：

  • orders-server：负责查订单

  • user-profile-server：负责查用户画像

• 模型客户端（比如某个支持 MCP 的 IDE / Web 应用）：

  • 把这些 server 暴露给模型作为 tools

  • 然后让模型自己在对话中选择“何时调用哪个工具”

这里的区别在于：

• LangChain：你在代码层面“强编码”了一个流程。
  模型更多是“执行者 + 局部决策者”。

• MCP：协议只负责“让模型能看到这些工具”。
  至于：

  • 什么时候用哪个

  • 用几次

  • 结果怎么综合
    完全交给模型和客户端自己的“Agent 逻辑”。

MCP 不解决“怎么 orchestrate（编排）”，
LangChain 专门就是干 orchestration 的。

---

4. 技术形态：框架 vs 协议

• LangChain：一个具体的代码库

  • Python / TypeScript 包

  • 版本、依赖、Breaking Change 都要考虑

  • 你项目里真真实实 pip install langchain 那种

• MCP：一份“协议文档 + 若干参考实现”

  • 核心是：JSON-RPC 格式、工具描述规范等

  • 理论上你用任何语言都能实现一个 MCP server

  • 语言无关、模型无关、业务无关

这就导致一个很现实的区别：

• 换 LangChain，要改你项目代码结构。

• 接 MCP，更多是“在你现有系统外面包一层协议 server”。

---

5. 生态位置：各自站在哪一层？

• LangChain 生态：偏“应用层 / 组件层”

  • 大量现成集成：

    • OpenAI / Anthropic / 本地模型

    • 各种向量库、数据库、第三方 API

  • 面向的是“我要快速拼出一个 App”。

• MCP 生态：偏“工具层 / 平台层”

  • 越来越多系统开始提供 MCP server：

    • 文件系统 / Git / 日志 / 日历 / 文档 / 内部系统…

  • 面向的是“我要让我的系统，更方便被各种模型统一调用”。

你可以想象未来这样的格局：

• MCP：像“USB + 网线接口”

• LangChain：像“操作系统上的开发框架 + SDK”

它俩不是在抢饭碗，而是层级不同、可以叠着用。

---

五、那实际项目里，怎么选？几个典型场景帮你判断

回到朋友公司的“销售 AI 助手”，我当时给他们的建议是分三步想：

---

场景 1：你只是想“让现有系统更容易被各种大模型用上”

比如：

• 你是某 CRM / ERP / 工具平台的开发

• 或者你是大公司的内部工具负责人

• 想要做到：

  • 不管是 Claude、还是别家的模型，只要支持 MCP，就能直接“看懂你的系统”

这时优先考虑：👉 MCP

你的目标是：

• 暴露出一套清晰、稳定的 API 能力给“AI 助手”

• 这些能力的定义要尽可能模型无关、语言无关

做法大致是：

• 给系统写一个 MCP server：

  • 列出 tools：search_customer、get_order_detail、update_ticket_status…

  • 定义参数、返回值、权限控制

• 然后交给各类支持 MCP 的客户端去用

  • IDE 插件

  • Web App

  • 甚至未来某个 SaaS 里的 AI 助手

这时候你大概率不需要 LangChain。
因为你不是在做一个完整的 AI 应用，你是在做“基础设施”。

---

场景 2：你要“从零搭一整套 AI 应用 / 流程”

比如：

• 搭一个“智能客服系统”，包含：

  • FAQ 检索

  • 工单创建/更新

  • 升级给人工

• 搭一个“内部知识问答 + 工具调用”的一体化系统

• 需要：

  • 多步推理

  • 多工具组合调用

  • 和产品的业务流程深度绑定

这时优先考虑：👉 LangChain（或类似框架，比如 LangGraph）

你需要的能力是：

• 把：

  • 模型调用

  • 检索（RAG）

  • 工具调用

  • 记忆 / 会话管理

  • 日志 / 监控 / 限流
    这些统统组织起来，变成一个可维护的“系统”。

用 MCP 也许能把“工具调用”这一块标准化，但：

• 整体流程怎么走

• 哪个步骤失败了要不要重试 / 回滚

• 怎么和你现有权限系统打通

这些 MCP 都不管，需要工程框架来兜底，LangChain 就是其中一个选择。

---

场景 3：你团队稍大，系统很多，希望“既规范接口，又好写应用”

这个时候，最舒服的姿势，往往是：LangChain + MCP 一起用。

一个常见的组合思路：

1. 底层 / 各个业务系统：

   • 用 MCP 把能力统一暴露出来

   • CRM 是一个 MCP server

   • 工单系统是一个 MCP server

   • 内部知识库是一个 MCP server

2. 上层应用 / 具体 AI 助手：

   • 用 LangChain / LangGraph 来搭应用

   • 在 LangChain 的 Agent 里，把 MCP 暴露出来的 tools 再封一层：

     • crm_search_customer

     • ticket_create

     • kb_rag_search

3. 这样一来：

   • 系统层：统一 MCP 标准，未来可以给任意模型客户端用

   • 应用层：用成熟框架快速搭业务逻辑

   • 中间如果哪天你不用 LangChain 了，也不会动到底层 MCP server

一句话：

MCP 做“接线 + 标准化”，
LangChain 做“编排 + 业务逻辑”。

---

六、几个常见误解，顺便澄清一下

误解 1：MCP 会不会“干掉”LangChain？

现阶段我判断不会，原因很简单：

• MCP 不做应用层编排

• LangChain 不想做协议标准化

它们更像：

• 一边是“USB 协议”

• 一边是“Windows 上的开发框架”

你不会说 USB 干掉了 .NET，一样的道理。

误解 2：用 MCP 就必须绑定 Claude 吗？

不是。

• MCP 协议本身是开源、模型无关的

• 现在是 Anthropic 推得比较积极，但：

  • 任何大模型厂商

  • 任何第三方客户端
    理论上都可以支持 MCP

就像最早推 USB 的也是几家厂商联手，并不妨碍后来所有硬件商都用了。

误解 3：已经在用 LangChain 了，还有必要上 MCP 吗？

看你是哪个角色：

• 如果你只是做一个单体应用，工具也就那两三个：
  → LangChain 里直接写 Tools，够用了，不一定要 MCP。

• 如果你开始发现：

  • 有多个应用都要用同一套工具

  • 公司内部有多种模型 / 多套 Agent

  • 你不想每次都重写一遍“怎么连 CRM / 怎么连工单系统”

  → 这时 MCP 很可能能帮你“抽象出一层统一工具层”。

---

七、他们怎么选的？

朋友的团队是这样做的：

• 短期（1个月内）：先用 LangChain 搭 MVP

  • 直接在 LangChain 里封装：

    • CRM API

    • 文档 RAG

    • LLM 调用

  • 赶紧先有个能见人的版本，验证效果

• 中期（半年左右）：把 CRM / 工单 / 文档系统，逐步 MCP 化

  • 把几个稳定下来的能力抽成 MCP server

  • 以后不管是 IDE 助手、飞书机器人、还是他们自家 Web 应用，都能统一复用

• 长期（看后续需求）：LangChain 可以换，MCP 不轻易动

  • 如果以后觉得 LangChain 不爽，可以换成别的 orchestrator

  • 但底下那层 MCP server，因为是协议标准，尽量保证长期稳定

“LangChain 更像是我们这两年选的一个框架；
MCP 更像是我们这几年要坚持的一个接口规范。”

---

最后

如果你哪天又被人问到：“MCP 和 LangChain 有啥区别？”
可以直接用这两句：

• MCP = 通用插线板标准：
  定义“大模型怎么跟工具说话”，偏“协议 / 接口”层。

• LangChain = 装修队 + 施工图：
  帮你把模型、工具、数据、流程统统编排起来，偏“应用框架”层。

真正落地时这样想：

• 只想让系统更“AI 友好”：先搞 MCP

• 要造一个完整 AI 应用：用 LangChain / LangGraph 这类框架

• 系统多、团队大、希望长期演进：MCP + LangChain 一起用