在 AI Agent 的技术栈中，MCP (Model Context Protocol) 正在成为连接大语言模型（LLM）与外部工具（Tools）的通用标准。通过 MCP，开发者可以无缝地为模型提供实时数据查询、本地文件操作或第三方 API 调用能力。
本文将基于两种不同的实现逻辑，深入分析如何构建一套高效、稳定的 MCP 接入系统。
一、 方案一：客户端直连模式（轻量化调度）
方案一的核心逻辑是将 Chat 组件（前端/客户端） 作为整个协同流程的枢纽。客户端直接负责与 MCP Server 的通信以及与 LLM 的多轮对话管理。
1. 协同流程图
sequenceDiagram
autonumber
actor U as 用户
participant C as Chat组件
participant M as MCP Server
participant L as LLM后台
Note over U,M: 前置：用户已配置 MCP Server（地址/鉴权/启用开关等）
U->>C: 发起对话/打开聊天
C->>M: 握手（连接/初始化）
M-->>C: 握手成功（server info）
C->>M: 拉取 tools 列表
M-->>C: tools 元数据（name/description/schema）
U->>C: 输入问题/需求
C->>L: 输入 + 上下文 + tools 列表
alt LLM 判断需要调用 tool
L-->>C: 返回 tool 调用计划（toolName + args）
C->>M: 调用 tool（toolName + args）
M-->>C: tool 执行结果（数据/错误）
C->>L: tool 结果 + 对话上下文
L-->>C: 最终回复（基于 tool 结果分析）
C-->>U: 展示最终回复
else LLM 判断不需要调用 tool
L-->>C: 直接回复
C-->>U: 展示回复
end
Note over C,L: 如需要多次工具调用，可重复"返回调用计划 -> Chat调用MCP -> 结果回灌LLM"直至收敛
2. 实现要点
- 工具感知 ：客户端在初始化时即获取工具的 JSON Schema，并将其注入到 LLM 的系统提示词或特定的
tools参数中。 - 客户端中转：所有的工具执行结果必须先返回给客户端，再由客户端回传给 LLM 进行后续分析。
二、 方案二：后端代理模式（工程化解耦）
方案二引入了 Backend MCPClient（后端代理） 。该架构将 UI 展示与工具执行逻辑完全剥离，由后端统一管理与多个 MCP Server 的交互。
1. 协同流程图
sequenceDiagram
autonumber
participant UI as Frontend Chat组件
participant API as Backend(HTTP/WebSocket)
participant LLM as Backend LLM(Agent)
participant MC as Backend MCPClient
participant MS as MCP Server
rect rgb(245,245,255)
note over UI,MS: 1) Chat组件初始化 -> MCP握手 -> 获取Tools描述
UI->>API: 初始化/启动(请求MCP握手)
API->>MC: 创建/获取MCPClient并发起握手
MC->>MS: handshake()
MS-->>MC: handshake ok + capabilities
MC->>MS: listTools() (获取可用工具列表)
MS-->>MC: tools描述列表 (Tool Definitions)
MC-->>API: 握手成功回调(含可用tools描述)
API->>LLM: 同步/更新当前会话可用tools描述
API-->>UI: 通知握手成功(显示可用状态)
end
rect rgb(245,255,245)
note over UI,MS: 2) 正式对话 -> LLM已持有tools描述 -> 触发tool_call
UI->>API: 用户发送消息(user prompt)
API->>LLM: 后端开始对话(用户prompt)
note over LLM: 构建系统提示词：注入初始化时已持有的tools描述
LLM->>LLM: 推理决定是否触发tool_call
alt 需要调用工具
LLM->>MC: tool_call(选择tool + params)
MC->>MS: callTools(tool, params)
MS-->>MC: tool result
MC-->>LLM: tool result
else 无需调用工具
note over LLM: 直接生成回答
end
end
rect rgb(255,245,245)
note over UI,LLM: 3) LLM基于tool result分析生成答案 -> 返回前端展示
note over LLM: 将tool result写入上下文并生成最终回复
LLM-->>API: assistant response(可流式)
API-->>UI: 推送assistant response(可流式)
UI-->>UI: 渲染消息给用户
end
2. 实现要点
- 后端闭环：工具的触发（tool_call）与执行（callTools）完全在后端完成，前端仅负责呈现最终结果。
- 状态常驻：后端可以维护长连接，支持更复杂的 Agent 策略和流式输出（Streaming）。
三、 方案优缺点对比
| 维度 | 方案一：客户端直连 | 方案二：后端代理 |
|---|---|---|
| 开发难度 | 低。逻辑简单，适合快速原型。 | 中。需要处理后端服务间的协同。 |
| 安全性 | 弱。敏感工具的执行环境暴露在客户端。 | 强。后端统一审计，隐藏工具端点。 |
| 性能体验 | 本地工具响应极快，无网络中转。 | 存在二跳延迟，但适合处理长耗时任务。 |
| 扩展性 | 受限于单机环境，难以支持复杂 Agent。 | 极高。可横向扩展多个 MCP Server 节点。 |
四、 总结与建议
- 如果您开发的是本地化工具 （如 IDE 插件、个人桌面助手），推荐使用方案一。它能提供最低的延迟，且部署成本极低。
- 如果您构建的是企业级平台 或 SaaS 应用 ，推荐使用方案二。它在安全性、可维护性和多用户并发支持上具有压倒性优势。