在上一篇中我们把 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 场景下的可观测性与故障排查。
在上一篇中我们把 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 场景下的可观测性与故障排查。
