本文是 T 系列的第 06 篇，主要比较在构建 Chatbot 中，MCP 与 LangChain 之间的区别。

T 系列为技术文章翻译系列，加以本人的一些拙见，如有雷同，实属正常，如有不同，欢迎交流。

人工智能 Agent 的发展历程一直致力于超越简单的问答功能，迈向多步骤、工具支持的自动化。为应对这一挑战，已形成两种不同的理念：LangChain 所代表的 Agent 编排框架，以及基于协议的 Model Context Protocol（MCP）方法。尽管两者都支持 Agent 使用外部工具，但它们在技术栈的不同层级运行，导致了不同的架构设计、开发体验，以及对特定应用场景的适用性差异。

架构设计和运行时控制

ReAct 是 LangChain 常常采用的推理模式，而 LangChain 本质上是编排框架，它的核心功能是提供控制 Agent 行为的逻辑。LangChain Agent 在一个“思考—行动—观察”循环中运行。Agent 的“大脑”通常是一个大语言模型（LLM），它接收用户的查询以及可用工具列表，然后生成一个“思考”，决定执行“行动”（即选择使用哪个工具），执行该工具，并获得一个“观察”。这一循环持续重复，直到模型确定最终答案为止。从推理到工具执行的整个过程，均由框架管理，该框架充当中央协调者和状态管理者。

ReAct = Reasoning + Acting，是 2022 年提出的一种 Agent 推理范式。核心思想是：让 LLM 在「思考」和「行动」之间交替循环，而不是一次性吐出答案。

MCP 同样遵循 ReAct 的推理模式：请求解析 → 工具选择 → 工具调用生成 → 执行 → 上下文更新 → 响应生成。

相比之下，模型上下文协议（MCP）并非一个编排框架，而是一种用于人工智能应用与外部服务之间通信的开放标准。MCP 定义了一种客户端-服务器架构，其中 LLM 应用充当 MCP 主机，包含一个客户端，用于与一个或多个 MCP Server 进行通信，MCP Server 是对工具或数据源的标准封装。该协议为应用发现和调用工具以及服务器返回结构化结果规定了统一的消息格式，通常采用 JSON-RPC。这种方法将 Agent 的推理逻辑与工具的实现分离开来。Agent 的“大脑”仍然决定调用某个工具，但不再由框架直接执行函数调用，而是向 MCP Server 发送结构化的请求，MCP Server 则负责处理 API 调用，并以可预测的格式返回结果。

开发者体验

开发人员在不同方法上的体验一定程度上反映了方法本身的设计哲学。

LangChain 的设计以快速原型开发和灵活性为核心，提供了一个庞大的预构建组件库（如链、代理、加载器、工具包），开发者可快速组合这些组件来构建概念验证。对于开发定制 Chatbot 的开发者而言，LangChain 能大幅减少样板代码，使其专注于业务逻辑。然而，这种灵活性在大规模扩展时可能成为瓶颈。当需要集成新的非标准工具时，通常必须在主应用代码中编写自定义的“工具”封装和逻辑，从而导致系统复杂度上升，并形成难以维护的单体架构。

MCP 的设计虽然可能需要初始设置客户端-服务器架构，但其设计注重模块化和可扩展性。一旦为某个工具创建了 MCP Server，任何兼容 MCP 的 Agent 都可以直接使用，无需编写自定义代码，从而推动“即插即用”的生态系统发展。对于大型企业而言，这意味着 IT 部门可以为内部 CRM 系统搭建一个统一的 MCP Server，不同部门的多个 AI 代理均可安全访问。代理代码保持简洁，专注于推理功能，而工具相关的复杂性则被隔离在 MCP Server 内部。这种职责分离简化了维护工作，并支持代理和工具的独立开发与部署。这标志着从“构建并集成”模式向“集成并组合”模式的根本转变。

幕后：如何工作

为了说明技术上的差异，以分析一个简单的“搜索与总结”任务的流程为例子：

LangChain 流程

1. Agent 初始化：LangChain 的 AgentExecutor 会使用一个大语言模型（LLM）、提示语以及一组可调用的工具函数进行初始化。这些工具函数包含具体的 API 调用逻辑。
2. 用户查询：用户提出请求：“请总结谷歌最新季度财报中的关键发现。”
3. LLM 推理：Agent 将用户查询和工具说明发送给 LLM。在提示词的引导下，LLM 回应一个结构化的输出，例如：{"action": "web_search", "action_input": "Google latest quarterly earnings report key findings"}。
4. 工具执行：LangChain 框架解析该输出，并直接调用 web_search_tool 函数，传入参数“Google latest quarterly earnings report key findings”。该函数执行一次 API 调用（例如向搜索引擎发起请求），并返回搜索结果。
5. 观察与循环：框架接收搜索结果，并将其作为新的提示上下文的一部分返回给 LLM（即“观察”）。随后，LLM 根据新信息进行推理，决定下一步操作（例如“总结”），并持续循环，直到生成最终答案。

MCP 流程

1. 系统设置：Agent 上运行一个客户端。一个外部进程或服务运行 MCP Server，该服务提供搜索工具和摘要工具。客户端可通过标准化机制发现这些工具。
2. 用户查询：用户提出相同的问题。
3. LLM 推理：MCP 主机将用户查询及可用工具的描述发送给 LLM。LLM 的输出并非直接的函数调用，而是表示要使用特定工具的意图，例如：{"request": {"tool": "search", "params": {"query": "Google最新季度财报关键发现"}}}。
4. 工具调用：MCP 客户端接收到此结构化请求，并通过定义的协议将其转发至相应的 MCP Server。
5. 服务响应：MCP Server 接收请求，执行内部逻辑进行搜索，并将结果以标准化的 JSON-RPC 响应形式返回给客户端。
6. 观察与循环：MCP 客户端接收结构化响应，并将数据作为上下文的一部分反馈给 LLM。LLM 继续推理循环，决定使用摘要工具，并向 MCP Server 发送新的请求。

两者的流程逻辑是类似的，只是 LangChain 的工具是直接调用的，而 MCP 的工具是通过 MCP Server 调用的。

关键区别在于，LangChain 的流程是紧密耦合的、在进程内执行，而 MCP 的流程则是松散耦合的、跨进程或跨服务通信。这使得 MCP 在企业环境中具有更高的安全性与可扩展性，尤其适用于工具可能位于不同机器或网络的情况。

有感而发

MCP 与 LangChain 等框架的比较，并非关于哪个“更好”，而是看哪一个更适合解决特定问题。LangChain 的优势在于其全面性，它提供了一套完整的工具链，可从核心推理逻辑到数据连接器，构建一个完整的智能体。因此，对于注重快速实验和构建垂直整合产品的独立开发者或初创企业来说，它是理想的选择。

然而，这种优势在大规模生产环境中却成为一种限制。由于缺乏统一的标准协议，每个自定义工具都变成了一个需要在应用程序内部进行管理、维护和安全保护的新集成点。这导致了许多企业开始面临“框架疲劳”和“Agent 面条”等问题。

框架疲劳：随着应用程序的增长，框架的复杂性也随之增加，导致开发人员难以跟上。

多 Agent / 多工具系统 上：当一个 Agent 系统里，多个 Agent、工具、编排步骤被临时、随意地串起来，彼此调用关系缠成一团，就成「代理面条」。

另一方面，MCP 是一种面向未来的架构模式。它仅专注于标准化通信层，为真正的人工智能工具生态系统铺平了道路。其潜力在于，能够实现一个未来：任何人工智能 Agent，无论其底层框架或大语言模型如何，都可以与任何拥有 MCP Server 的工具进行交互。这类似于互联网的工作方式—— HTTP 等标准协议使网页浏览器无需为每个服务器编写自定义逻辑，即可与无数不同的服务器进行交互。目前 MCP. 的局限性源于其尚在萌芽阶段的推广；预构建服务器和客户端集成的生态系统仍在不断扩展，建立客户端-服务器架构也存在初始的学习曲线。然而，对于希望构建可扩展、安全且具备未来前瞻性的 AI 基础设施的企业而言，MCP 代表了从定制化集成向通用互操作性转变的关键一步。