在上一篇中，我们把 Agent Identity 与 Delegated Authority 作为工具调用的治理底座，回答了“谁授权、代表谁、为什么做”。当 Agent 需要接入的外部能力从一两个工具膨胀到多个数据源、多个工具服务时，单 MCP 的接入方式会迅速遇到瓶颈。本篇作为系列第 18 篇，围绕 MCP Host、MCP Client、MCP Server 三段角色，讨论从单 MCP 到多 MCP 的架构选型与落地关注点。

三段角色的职责边界

MCP 采用 C/S 架构。MCP Server 对外提供能力，资料中提到其功能类型包括 command 和 SSE 两种；MCP Client 负责与 Server 建立连接、发起调用；MCP Host 则是承载 LLM 应用的一侧，负责配置支持 function calling 的 LLM，并把 Client 接入到应用运行时中。

这个划分对生产架构的意义在于：Host 是策略与编排层，Client 是协议适配层，Server 是能力提供层。三者不应混在一个进程里随意耦合。单 MCP 场景下，很多实现会把 Host 和 Client 写在一起，甚至把 Server 也放在同一台机器上，调试方便但边界模糊。多 MCP 场景下，如果继续沿用这种写法，配置、鉴权、超时、错误处理会迅速失控。

从单 MCP 到多 MCP 的结构差异

单 MCP 的典型结构是：一个 Host 进程内嵌一个 Client，连接一个 Server。资料中提到的 ChatMCP 配置方式、Spring AI MCP 的单 MCP 体验，都属于这一类。它的优点是链路短、调试直观；缺点是 Host 与具体 Server 强绑定，新增一个能力就要改 Host 代码或配置。

多 MCP 的结构则要求 Host 管理多个 Client 实例，每个 Client 对应一个 Server。资料中 Spring AI MCP 明确提到了“单 MCP 和多 MCP 体验”，说明多 MCP 是框架层面需要显式支持的场景。此时 Host 需要解决几个新问题：

第一，Client 生命周期管理。多个 Client 的连接建立、健康检查、断线重连不能散落在业务代码里。

第二，能力发现与路由。Host 需要知道哪个 Server 提供哪些工具，并在 LLM 发起 tool call 时把请求路由到正确的 Client。

第三，配置隔离。每个 Server 的连接方式、鉴权信息、超时参数不同，配置必须按 Server 维度隔离，而不是全局一份。

第四，故障隔离。一个 Server 不可用不应拖垮整个 Host，需要独立的超时与降级策略。

MCP 与 Tool Calling 的关系对选型的影响

资料中有一个关键判断：Function Calling 已被 Tool Calling 取代。MCP 与 Tool Calling 不是替代关系，而是互补关系。Tool Calling 解决的是 LLM 如何表达“我要调用某个工具”；MCP 解决的是工具如何以统一协议接入、被发现和调用。

这个关系直接影响架构选型。如果 Host 只对接一个 LLM 且工具数量很少，直接在 Host 内实现 Tool Calling 可能更简单。但当工具来自多个外部服务、需要跨应用复用时，MCP 的统一协议价值就体现出来。资料中提到 MCP 的优势包括“一次接入，处处可用”和实时低延迟，这正是多 MCP 架构的选型依据。

需要注意的是，MCP 并不自动解决 Tool Calling 的语义问题。LLM 仍然需要根据工具描述决定调用哪个工具。资料中特别强调 MCP Server 实现时 description 字段的重要性，因为 description 是 LLM 理解工具能力的唯一入口。多 MCP 场景下，多个 Server 的工具描述会同时进入 LLM 上下文，描述不清或语义重叠会直接导致路由错误。

落地关注点

结合资料中提到的 Java SDK、Python SDK、Spring AI 集成、Playwright 自动化、MCP 服务调试等内容，多 MCP 落地需要关注以下方面：

调试环境。资料提到调试需本地有高版本 node 环境，这说明 MCP Server 的运行依赖可能超出 Java 或 Python 技术栈本身。生产环境需要把这类依赖纳入部署基线。

SDK 选择。MCP 官方支持 Python、TypeScript、Java、Kotlin 四种语言的 SDK。资料中基于 Java SDK 0.7.0 版本分析了 McpClient 接口与 McpAsyncClient 核心依赖。选型时要确认 SDK 版本与 Host 框架的兼容性，以及异步模型是否匹配现有运行时。

Server 开发方式。资料提到 MCP Server 开发有两种接口方式，具体差异需要以官方文档为准。生产落地时应统一团队内的实现范式，避免同一系统内混用多种风格。

服务发现与配置。资料提到 mcp.so 可提供超 4000 项服务，简单配置即可访问。这意味着多 MCP 的配置管理不能靠手工维护，需要把 Server 清单、能力描述、鉴权信息纳入配置中心或注册表，与系列此前讨论的 Registry 方向衔接。

安全与治理。多 MCP 扩大了攻击面。每个 Server 的接入都应经过身份与授权校验，这与上一篇 Agent Identity 与 Delegated Authority 的主题直接相关。Host 在路由 tool call 时，需要把授权上下文一并传递给 Client，而不是只传工具名和参数。

架构对比研究框架

综合以上，可以把单 MCP 与多 MCP 的对比归纳为几个维度：接入结构上，单 MCP 是 Host-Client-Server 一对一，多 MCP 是 Host 对多 Client 对多 Server；配置管理上，单 MCP 可内联，多 MCP 需要集中式配置；故障隔离上，单 MCP 故障即整体故障，多 MCP 需要按 Server 隔离；能力发现上，单 MCP 可硬编码，多 MCP 需要动态发现与路由；治理上，单 MCP 可简化，多 MCP 必须引入身份、授权与审计。

这个框架不提供唯一答案，而是帮助团队根据工具数量、复用范围、安全要求和运维能力做取舍。具体版本行为、SDK 参数和部署细节，仍需以官方资料核验为准。下一篇将继续沿着生产化方向，讨论多 MCP 场景下的可观测性与故障排查。