重塑 AI 交互边界：基于 LangChain 与 MCP 协议的全栈实践

栀秋666
3 阅读9分钟

引言：从封闭模型到开放生态的范式转移

在大语言模型（LLM）爆发的初期，我们往往将其视为一个全知全能的“黑盒”。然而，随着应用场景的深入，开发者们逐渐意识到，缺乏外部上下文和实时数据交互能力的模型，其价值是有限的。模型需要“手”和“眼”，需要能够访问数据库、读取文档、调用 API。正是在这种背景下，Model Context Protocol (MCP) 应运而生。

MCP 不仅仅是一个通信协议，它是一套标准化的“上下文接口规范”。它定义了 AI 模型（Client/Host）如何安全、高效地与外部数据源和服务（Server）进行交互。本文将结合具体的代码实现，深入剖析如何在 LangChain 框架中构建 MCP Host，并连接自定义的 MCP Server，从而打造一个具备实时数据查询能力的智能 Agent。我们将通过一个完整的“用户信息查询”案例，揭示从底层协议通信到上层应用逻辑的全链路实现细节。

一、架构解构：理解 MCP 的核心三角

在深入代码之前，我们必须厘清 MCP 架构中的三个核心角色，这对应了经典的 C/S（Client/Server）架构在 AI 领域的演进。

  1. MCP Server（服务端） ：数据的提供者与能力的封装者。 在我们的案例中，my-mcp-server.mjs 扮演了这一角色。它不直接面对最终用户，而是封装了具体的业务逻辑（如查询数据库中的用户信息）和资源（如使用指南）。它通过标准输入输出流（Stdio）或网络套接字暴露能力，遵循“最小权限原则”，只暴露必要的 Tool 和 Resource。
  2. MCP Client（客户端） ：协议的发起者与适配者。 在传统的 IDE 插件（如 Cursor）中，内置的 MCP Client 负责连接服务器。而在我们的 LangChain 实践中，MultiServerMCPClient 充当了这一角色。它的核心职责是启动 Server 进程，建立通信通道，并将 Server 暴露的 Tools 转换为 LangChain 能够识别的标准工具对象。
  3. MCP Host（宿主/主机） ：智能的决策中枢。例如Cursor 这是本文的重点。Host 通常是 LLM 本身或其运行环境（如 LangChain Agent）。Host 接收用户指令，分析意图，决定调用哪个 Tool，解析 Server 返回的结果，并最终生成自然语言回复。在代码中，ChatOpenAI 配合 funAgentWithTools 循环逻辑，共同构成了强大的 Host 端。

这种架构的精妙之处在于解耦。Server 可以用任何语言编写，只要遵循 MCP 协议；Host 可以切换不同的模型提供商；而 Client 则作为中间的桥梁，屏蔽了底层通信的复杂性。

二、构建 MCP Server：标准化能力的封装

让我们首先审视服务端的实现。代码片段展示了一个基于 Node.js 的轻量级 MCP Server。

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { z } from 'zod';

这里引入了关键依赖。McpServer 是核心类，StdioServerTransport 表明我们将采用本地进程间通信（Local Process Communication）。这种方式非常适合本地开发环境和桌面应用，通过标准输入输出流（stdin/stdout）传输 JSON-RPC 消息，无需配置复杂的网络端口，安全性高且延迟极低。

1. 定义 Tool：结构化数据的入口

MCP 的核心能力之一是 Tool（工具）。在代码中，我们注册了一个名为 query-user 的工具：

server.registerTool('query-user', {
    description: '查询数据库中的用户信息。输入用户ID, 返回该用户的详细信息（姓名、邮箱、角色）。',
    inputSchema: {
        userId: z.string().describe("用户 ID, 例如：001, 002, 003")
    }
}, async ({ userId }) => {
    // ... 业务逻辑 ...
})

这里有几个关键点值得注意：

  • 语义化描述：description 字段至关重要。LLM 完全依赖这段自然语言描述来判断何时调用该工具。描述越清晰，模型的调用准确率越高。
  • 强类型约束：利用 zod 库定义 inputSchema。这不仅提供了运行时验证，更重要的是为 LLM 提供了明确的结构化指引。模型知道它必须提供一个字符串类型的 userId，这大大减少了幻觉导致的参数错误。
  • 异步执行：工具的处理函数是 async 的，这意味着我们可以轻松集成数据库查询、HTTP 请求等异步操作，展现了 MCP 处理真实世界任务的能力。

2. 注册 Resource：上下文的动态注入

除了 Tool，MCP 还引入了 Resource 的概念。代码中注册了一个 URI 为 docs://guide 的资源：

server.registerResource('使用指南', 'docs://guide', {
   description:'MCP Server 使用文档',
   mimeType:'text/plain', 
}, async()=>{
    return { contents: [...] }
})

为什么需要 Resource？因为 Context（上下文）不仅仅是 Tool 的集合。Resource 允许 Server 向 LLM 提供静态或动态的文档、配置信息或知识库。在这个例子中，它提供了一份“使用指南”。当模型对如何使用 Server 感到困惑时，它可以主动读取这个 Resource 来获取元数据。这体现了 MCP 协议中Context = Tool + Resource + PromptTemplate 的完整设计理念，使得 AI 的上下文不再局限于对话历史，而是扩展到了整个系统生态。

三、打造 LangChain Host：智能代理的编排

服务端就绪后，我们需要在 LangChain 中构建 Host 来驱动这一切。这是将“死”的工具变成“活”的智能体的关键步骤。

1. 初始化 MultiServerMCPClient

import {MultiServerMCPClient} from '@langchain/mcp-adapters'

const mcpClient = new MultiServerMCPClient({
  mcpServers: {
    "my-mcp-server": {
      command: "node",
      args: ["/path/to/my-mcp-server.mjs"],
    },
  },
});

@langchain/mcp-adapters 是连接 LangChain 生态与 MCP 协议的桥梁。MultiServerMCPClient 的设计非常灵活，它允许在一个 Host 中同时连接多个 MCP Server。配置对象中，我们指定了启动 Server 的命令（node）和脚本路径。 关键机制：当 mcpClient 实例化时，它会在后台 spawn 一个子进程运行 my-mcp-server.mjs，并通过 Stdio 管道与其建立连接。随后调用 await mcpClient.getTools()，适配器会自动拉取 Server 注册的所有 Tools 和 Resources，并将它们转换为 LangChain 标准的 Tool 对象列表。这一步实现了异构系统间的无缝对接。

2. 模型绑定与工具增强

const tools = await mcpClient.getTools();
const modelWithTools = model.bindTools(tools);

model.bindTools(tools) 是 LangChain 的核心魔法之一。它将获取到的工具列表注入到模型的 System Prompt 或特定的 API 参数中（取决于模型提供商的实现）。此时，模型不仅拥有了语言能力，还拥有了“行动能力”。它知道存在一个 query-user 工具，并了解其参数要求。

3. 实现 ReAct 循环：Host 的核心逻辑

真正的智能体现在 funAgentWithTools 函数中，这是一个典型的 ReAct (Reasoning + Acting) 模式实现：

async function funAgentWithTools(query, maxIterations = 30) {
    const messages = [new HumanMessage(query)];
    for (let i = 0; i < maxIterations; i++) {
        // 1. 模型思考
        const response = await modelWithTools.invoke(messages);
        messages.push(response);

        // 2. 判断是否完成
        if (!response.tool_calls || response.tool_calls.length === 0) {
            return response.content; // 输出最终结果
        }

        // 3. 执行工具调用
        for (const toolCall of response.tool_calls) {
            const foundTool = tools.find(t => t.name === toolCall.name);
            const toolResult = await foundTool.invoke(toolCall.args);
            
            // 4. 反馈结果给模型
            messages.push(new ToolMessage({
                content: JSON.stringify(toolResult),
                tool_call_id: toolCall.id
            }));
        }
    }
}

这个循环清晰地展示了 Host 的工作流：

  1. 感知与推理：模型接收当前消息历史，分析用户意图。如果它认为需要外部数据，它会生成一个包含 tool_calls 的响应，而不是直接回答。
  2. 拦截与执行：Host 检测到 tool_calls，暂停生成，查找对应的本地工具对象，并传入参数执行。注意，这里的执行实际上是通过 MCP Client 转发给 MCP Server 处理的。
  3. 观察与修正：Server 返回结果（如用户张三的信息），Host 将其封装为 ToolMessage 并追加到消息列表中。
  4. 再推理：模型再次被调用，这次它看到了工具的返回结果，结合原始问题，生成最终的自然语言回答。

这种循环机制使得 Agent 能够处理多步任务。例如，如果用户问“查一下用户002的信息，然后告诉我他的角色是什么”，模型可以先调用工具，拿到结果后，再进行二次推理回答角色问题。

四、深度洞察：MCP 带来的工程价值

通过上述代码实践，我们可以总结出 MCP 结合 LangChain 的几大工程优势：

  1. 标准化的互操作性： 在此之前，每个 AI 应用都需要自定义工具接口。现在，只要遵循 MCP 协议，任何语言编写的 Server 都可以被 LangChain、Cursor 或其他支持 MCP 的 Host 直接使用。这极大地降低了集成成本。
  2. 安全的沙箱执行： 通过 Stdio 本地通信，Server 运行在独立的进程中。即使 Server 代码存在漏洞或被恶意利用，其影响范围也被限制在该进程内，不会直接污染 Host 的主线程或内存空间。
  3. 动态上下文管理： Resource 机制的引入，解决了长上下文窗口浪费的问题。模型不需要一次性加载所有文档，而是可以根据需要，通过 URI 动态“挂载”所需的资源。这在处理大型知识库时尤为重要。
  4. 开发体验的提升： 对于全栈工程师而言，编写 MCP Server 就像编写普通的 API 接口一样简单，只需关注业务逻辑和 Zod schema 定义。复杂的协议握手、消息序列化、错误重试等底层细节全部由 SDK 和 Adapter 屏蔽。

五、结语：迈向通用的 AI 操作系统

本文通过一个具体的用户查询案例，展示了如何利用 LangChain 作为 Host，连接自定义的 MCP Server，构建出一个具备实时数据交互能力的智能 Agent。从 my-mcp-server.mjs 中对 Tool 和 Resource 的精确定义，到 LangChain 中 MultiServerMCPClient 的灵活适配，再到 funAgentWithTools 中严谨的 ReAct 循环，我们见证了一套现代化 AI 应用架构的诞生。

MCP 协议的出现，标志着 AI 开发从“模型为中心”转向“生态为中心”。未来的 AI 应用将不再是孤立的聊天机器人，而是能够像操作系统一样，自由调度各种工具、数据和服务的智能中枢。作为开发者，掌握 MCP 与 LangChain 的结合使用，不仅是掌握了一项新技术，更是拿到了通往下一代智能应用开发的钥匙。在这个新的范式中，想象力是唯一的限制，而 MCP 则是将想象力转化为现实的最坚实桥梁。

avatar
文章
阅读
粉丝