一、引言：为什么我们需要 MCP？

在 LangChain、LlamaIndex 等框架的推动下，AI Agent 已经从概念走向落地。但一个核心问题始终存在：如何让大模型安全、高效、标准化地调用外部工具？

传统的做法是为每个工具编写自定义的 Function Calling 逻辑，导致代码耦合度高、复用性差、维护成本巨大。而 MCP（Model Context Protocol） 的出现，正是为了解决这一痛点。

MCP 是一个开放协议，旨在统一大模型与外部工具之间的通信标准。它允许开发者以声明式的方式注册工具，大模型则通过标准接口发现并调用这些工具，无需关心底层实现细节。

今天，我们就通过一个真实项目——mcp_in_action，来深入理解 MCP 如何在实际场景中发挥作用。

二、项目结构解析：模块化设计的艺术

首先，让我们看看项目的目录结构：

mcp_in_action/
└── mcp-test/
    ├── node_modules/
    ├── .env
    ├── beijing_south_station_hotels.md
    ├── main.mjs          ← 核心入口文件
    ├── package.json
    └── pnpm-lock.yaml

这是一个典型的 Node.js 项目，使用 pnpm 作为包管理器。核心逻辑集中在 main.mjs 文件中，采用 ES Module 语法（.mjs 后缀），体现了现代 JavaScript 开发的最佳实践。

2.1 环境配置：.env 文件的作用

.env文件中包含以下关键变量：

MODEL_NAME=gpt-4o
OPENAI_API_KEY=sk-xxx
OPENAI_BASE_URL=
AMAP_MAPS_API_KEY=your_amap_key

这种将敏感信息与环境变量分离的做法，是云原生开发的基本准则，既保证了安全性，又提升了部署灵活性。

三、核心代码拆解：构建多服务器 MCP 客户端

3.1 初始化大模型

const model = new ChatOpenAI({
    modelName: process.env.MODEL_NAME,
    apiKey: process.env.OPENAI_API_KEY,
    configuration: {
        baseURL: process.env.OPENAI_BASE_URL
    }
});

这里使用了 LangChain 的 ChatOpenAI 类，支持自定义模型名称、API Key 和基础 URL。这种设计使得我们可以轻松切换不同的 LLM 提供商（如 Azure OpenAI、本地部署的 vLLM 等）。

3.2 创建 MultiServerMCPClient

这是整个项目的灵魂所在：

const mcpClient = new MultiServerMCPClient({
    mcpServers: {
        "amap-maps-streamableHTTP": {
            url: `${process.env.AMAP_MAPS_API_KEY}`
        },
        "filesystem": {
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-filesystem",
                "D:/Workspace/lesson_zp/ai/agent/mcp_in_action/mcp-test"
            ]
        },
        "chrome-devtools": {
            "command": "npx",
            "args": [
                "-y",
                "chrome-devtools-mcp@latest"
            ]
        }
    }
})

三种不同类型的 MCP 服务器：

1. 远程 HTTP 服务（高德地图）
   通过 URL 直接连接官方提供的 MCP 服务，适用于标准化、高可用的公共 API。
2. 本地命令行服务（文件系统）
   使用 npx 动态安装并运行 @modelcontextprotocol/server-filesystem，指定工作目录为当前项目路径。这种方式非常适合需要访问本地资源的场景。
3. 浏览器自动化服务（Chrome DevTools）
   同样通过 npx 启动 chrome-devtools-mcp，实现对浏览器的程序化控制。这是实现“视觉型 Agent”的关键。

3.3 获取工具并绑定到模型

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

这两行代码完成了从“纯语言模型”到“增强型 Agent”的转变。getTools() 会向所有注册的 MCP 服务器发起 discovery 请求，收集可用工具列表；bindTools() 则将这些工具注入到模型的推理过程中，使其具备调用能力。

四、Agent 执行引擎：循环推理与工具调用

4.1 主循环逻辑

async function runAgentWithTools(query, maxIterations = 30) {
    const messages = [new HumanMessage(query)];
    for (let i = 0; i < maxIterations; i++) {
        console.log(chalk.bgGreen('⏳正在等待AI思考...'));
        const response = await modelWithTools.invoke(messages);
        messages.push(response);

        if (!response.tool_calls || response.tool_calls.length === 0) {
            console.log(`n AI 最终回复：n ${response.content}n`);
            return response.content;
        }

        // 处理工具调用...
    }
}

这个函数实现了经典的 ReAct（Reason + Act） 模式：

1. Reason：模型根据当前对话历史生成下一步动作（可能是直接回答，也可能是调用工具）。
2. Act：如果检测到 tool_calls，则逐个执行对应工具，并将结果以 ToolMessage 形式反馈给模型。
3. Loop：重复上述过程，直到模型不再调用工具或达到最大迭代次数。

4.2 工具调用处理细节

for (const toolCall of response.tool_calls) {
    const foundTool = tools.find(t => t.name === toolCall.name);
    if (foundTool) {
        const toolResult = await foundTool.invoke(toolCall.args);
        let contentStr;
        if (typeof toolResult === 'string') {
            contentStr = toolResult;
        } else if (toolResult && toolResult.text) {
            contentStr = toolResult.text;
        }
        messages.push(new ToolMessage({
            content: contentStr,
            tool_call_id: toolCall.id
        }));
    }
}

这里有几个值得注意的设计：

• 容错机制：通过 find 查找工具，避免不存在的工具调用导致崩溃。
• 结果标准化：无论工具返回的是字符串还是对象（含 text 字段），都统一转换为字符串内容，确保消息格式一致。
• Traceability：保留 tool_call_id，便于后续调试和审计。

五、实战案例：从需求到执行的完整链路

最后，我们来看一个具体的任务：

await runAgentWithTools(`
北京南站附近的3个酒店，拿到酒店图片，展开浏览器，展示每个酒店的图片，
每个tab一个url展示，并且把那个页面标题改为酒店名
`)

这个看似简单的自然语言指令，背后涉及多个复杂步骤：

1. 地理搜索：调用高德地图 MCP 服务，查询“北京南站附近酒店”。
2. 数据提取：从返回结果中提取酒店名称、地址、图片 URL 等信息。
3. 浏览器控制：启动 Chrome DevTools MCP，打开新标签页加载图片。
4. DOM 操作：修改每个标签页的