大语言模型不再仅仅用于实验性的聊天机器人或个人生产力工具。在企业中，这些模型正在改变团队与系统互动以及做出实际决策的方式。从本质上讲，它们已经成为真正的架构组件。
尽管如此，当前的集成还比较脆弱。许多团队使用供应商特有的机制将集成逻辑嵌入到提示中，或者直接向模型暴露 API。虽然这些方法在原型设计阶段很有用，但它们难以扩展，并且治理能力也非常有限。
这种情况与 SOA 的早期阶段颇为相似，当时由于缺乏统一的标准，导致系统结构脆弱，难以开发和集成。MCP 现在处于同样的稳定化阶段：它在基于 LLM 的架构中引入了一个协议层，其中包含了结构、边界和互操作模型。
为了应对这些挑战，模型上下文协议（MCP）引入一种标准化且与模型无关的方法，用于展示上下文工具和数据。MCP 在模型与外部系统之间定义了一个协议层的契约，避免了将集成语义硬编码到提示或特定于 SDK 的调用中。这种共享且标准化的约定使功能变得明确、可发现且可管理。
在这个背景下，Java MCP SDK 的出现尤为重要。JVM 生态系统支撑着企业的大部分工作负载，这里的架构规范并非是一种审美上的偏好。基于 Java 的系统必须具备可观测性、可测试性、高可靠性以及长期可维护性。如果在这些环境中引入 LLM，而没有与之相匹配的同等水平的规范，就会导致不一致的情况，变得难以管理和解决。
Java 中基于 SDK 和 MCP 的集成方案，使架构师能够将大语言模型的采用与企业现有的架构实践相融合，并将服务边界、契约和控制平面等概念应用于与大语言模型的交互中。
本文将从这一角度探讨 MCP 及其 Java SDK。本文的目的并非讲解如何编写 MCP 代码，而是探讨 MCP 如何重新定义大语言模型的集成标准，它解决了哪些问题，以及在设计旨在突破原型阶段、实现规模化应用的系统时要做哪些权衡取舍。
为了从架构的角度更好地理解 MCP，我们需要将关注点从单个集成转向交互模型。MCP 既不是代理框架，也不是运行时环境；它是一种协议，通过结构化的契约来定义模型如何与外部功能进行交互。
MCP 架构基于一组明确区分的角色。主机为模型提供执行环境；客户端负责处理模型的请求，而服务器则将工具和资源作为明确定义的功能对外提供。这种间接模型是刻意设计的：模型绝不会直接调用 API 或基础设施，它们只调用通过协议声明的内容。其结果是形成了一道治理边界，该边界可以控制访问，而不会干扰模型的推理过程。
图 1： MCP 分层架构图（图片来源）
MCP 的主要特点之一在于其功能发现能力。MCP 并非预先配置好模型可用的工具，而是允许客户端在运行时向服务器发起查询，从而发现功能及其关联的模式。这一能力使系统更具适应性，并减少在提示词或代理逻辑中对功能进行硬编码的需求。从架构角度来看，该机制实现了模型与系统之间的松耦合。
MCP 还区分了工具和资源。工具代表模型可以请求的操作，而资源则提供结构化的上下文数据。这种区分便于清晰地区分不同的数据访问模式。无论是从安全性还是治理角度来看，只读上下文数据与会改变状态的操作在管理方式上都大不相同。
图 2：MCP 服务器组成
作为一种规范，MCP 还重新定义了快速开发流程。其上下文不能只是在运行时临时拼凑而成的固定字符串，而必须是通过明确的接口提供的经过精心策划的结构化信息集合。
最终，MCP 代表了从以模型为中心的集成向基于协议的设计转变。LLM 交互被视为分布式系统交互，需遵循与任何其他类型的集成相同的架构规范。
Java MCP SDK 将 Anthropic 公司 MCP 协议的抽象原则转化为适用于基于 JVM 的系统的具体实现。Anthropic 的设计既保持了协议的准确性，又遵循了 Java 企业应用的最佳实践。该协议侧重于定义抽象角色、消息格式和能力协商，而 SDK 则通过以 Java 为中心的设计选择实现了这些概念。这些设计选择包括强类型模型、为客户端和服务器提供明确的接口，以及基于模式交互所采用的构建器结构。
总体上看，该 SDK 采用多层架构设计。其中，传输机制（如用于本地集成的 STDIO 或用于分布式通信的 HTTP）、协议语义以及会话管理之间有着明确的划分。这种划分使得团队能够根据不同的交互模式调整 MCP 协议，而不会影响底层逻辑。
该 SDK 支持同步和异步两种交互模式。在内部，它倾向于采用非阻塞通信和响应式流程，这种模式非常适合 MCP I/O 交互。同时，该 SDK 还提供了更高层次的抽象，可以在传统的命令式代码中使用。在企业生态系统中，这两种选择使得纯响应式技术栈能够与传统或混合编程范式共存。
该 SDK 的另一个关键方面是与框架集成。在 Java 企业环境中，首要问题就是：它是否能与 Spring 进行集成？在基于 Spring 的应用程序中，MCP 服务器可以与现有的服务一起集成，从而受益于 Spring 的独有特性，例如依赖注入、配置管理以及已有的针对其他应用程序的管理实践。这种设计使得 MCP 能够逐步采用，一步一步引入 MCP 端点，而不需要从头重写应用程序或重新组织整个架构。
只需很少的代码，就可以将 MCP 工具提供程序集成到 Spring 框架中：
@Configurationpublic class McpServerConfiguration { @Bean ToolCallbackProvider tools(MonitoringTools monitoringTools) { return MethodToolCallbackProvider.builder() .toolObjects(monitoringTools) .build(); }}复制代码
在这个例子中，MonitoringTools 是一个标准的 Spring 托管 Bean。该 Bean 暴露的方法只需向 MethodToolCallbackProvider 注册，即可成为 MCP 工具。通过这种机制，MCP 功能得以与其他服务的行为保持一致，并成为同一依赖关系图的一部分。Spring 对其生命周期、配置和注入的处理方式，与应用程序中所有其他 Bean 完全一致。
Java SDK 的最大优势在于将协议概念明确化。工具的定义需要有明确的输入和输出，而资源则必须进行恰当的描述和结构化。这种对明确性的要求迫使团队将 MCP 服务器视为有界上下文，而非通用的集成层。
从架构的角度来看，这些特性使 MCP 服务器与防腐层、API 网关等成熟的模式相契合。SDK 提供了构建模块，而这些边界所带来的架构规范则带来了长远价值。
此外，通过将功能暴露视为一项需要开发和设计的活动，该 SDK 有效防止了功能的无序扩张——这是大语言模型集成中非常常见的陷阱。因此，并非将整个 API 对外开放，而是根据功能和业务需求，提供经过精心设计的功能。
从这个意义上说，Java MCP SDK 远不止是一个协议。它迫使开发团队重新思考大语言模型的集成，将其视为系统架构中的核心组件，而非仅仅是需要接入的外部工具。
在使用 MCP 时，一个关键决策在于如何将 MCP 服务器集成到整体架构中。乍看之下，将 MCP 服务器视为一个简单的适配器，负责将模型请求转发给现有的 API，似乎既直观又易于实现。然而，这种做法会削弱该协议的许多优势。
在企业系统中，API 通常是为大语言模型设计的。在理想情况下，它们会暴露底层的基本操作，并假设特定的调用序列。在其他情况下，它们则反映了历史上的限制或组织层面的问题（参见康威定律）。即使通过 MCP，将此类 API 直接暴露给模型，也可能会导致产生 MCP 本意要解决的紧耦合问题。
一种更有效的方法是将 MCP 服务器视为功能提供者。采用这种方法，MCP 服务器将定义封装了特定领域业务功能的高级工具，而不是直接暴露原始端点。让我们以票务系统为例。MCP 服务器无需暴露完整的 API，而是可以设计为仅暴露诸如 retrieveIncidentSummary、searchRelatedIncidents 和 proposeMitigationSteps 之类的工具。这些工具暴露了模型被授权执行的操作，而非底层系统在技术上能够执行的操作。
这种设计在 MCP 服务器与防腐层之间建立了非常紧密的对应关系。服务器负责将模型发出的请求转换为与核心系统之间安全且经过验证的交互。在任何调用到达核心系统之前，系统都会对输入进行验证、执行授权检查，并确保数据被正确地建模。除非明确允许，否则模型绝不应接触到内部标识符、实现细节、过于具体的错误信息，或可能产生副作用的操作。
因此，可以使用 Java 来实现 MCP 服务器，既可以将其作为独立的服务来运行，也可以将其集成到现有的 Spring 应用程序中。这种实现方式使我们可以复用领域服务、存储库和安全组件，同时为模型提供一个有限制而且是有意暴露的接口。
如上所述，另一个需要考虑的重要区别在于只读功能与状态修改功能之间的区别。许多用例都是基于这样一个事实而开发的，即模型能够探索数据并提出操作建议，但不能直接执行这些操作。MCP 通过鼓励开发细粒度的详细工具来明确这种区别。例如，MCP 服务器可以提供一个工具，用于评估操作的影响或准备请求，而将操作的执行留给一个独立的由人工驱动的流程。
要实现所有这些功能，必须采用良好的操作规范。MCP 服务器为可观测性和审计提供了天然的切入点。该工具的每一次调用都可以进行记录、跟踪和分析，而且不依赖模型的内部推理过程。
MCP 服务器决定提供哪些功能，而 MCP 客户端则决定如何使用这些功能。在早期的大语言模型（LLM）集成中，编排逻辑直接嵌入到提示词或代理框架中，这使得维护工作变得非常复杂，运行时的关联关系也很难理解。
MCP 客户端充当模型与一个或多个 MCP 服务器之间的中介。它负责识别可用的工具、管理会话以及协调对工具的调用。它是该架构的关键组件，而不是一个被动的通信层。
在 Java 生态系统中，我们可以将 MCP 客户端集成到能够协调复杂工作流的服务中。例如一个运维助手，它利用 MCP 客户端查询多个服务器（监控、工单和文档），并将这些服务器的响应整合到适合该模型的上下文中。这种协调逻辑现在位于代码而非提示词中，使得版本控制和测试都变得更加容易。
该模型的一大关键优势在于能够明确控制交互流程，包括调用序列、超时处理、部分错误处理以及备用方案。客户端可以处理所有这些情况，并自主决定何时中断模型的运行，将控制权交由人工操作员管理。在提示词中实现这些功能非常复杂，在应用程序代码中则要简单得多。
MCP 客户端在上下文管理中发挥着核心作用。客户端不需要手动拼凑冗长的提示词，就能够精确地决定在任何给定的时刻向模型暴露哪些资源。这种选择能最大限度地精简上下文，并大幅降低敏感或无关信息泄露的风险。
从架构角度来看，MCP 客户端不过是分布式系统中的协调器。它们管理对话，并将对话视为对服务的调用流。这种方法将大语言模型集成的复杂性分解为三个关键问题：状态管理、幂等性和错误处理。对于基于 Java 的分布式系统开发者而言，他们对于这些问题都有着非常明确且立场鲜明的看法。
使用 MCP 是有代价的。与大语言模型提供商提供的原生工具调用方式相比，MCP 增加了额外的层级和抽象。对于小型或实验性项目而言，其额外带来的成本很可能超过好处。
原生调用工具更为简单直观：模型调用一个函数，接收响应，然后继续执行。这种简单性带来了一个副作用：强耦合。工具定义通常嵌入在提示词或 SDK 配置中，这使得版本控制和独立模型管理变得十分困难。
另一方面，MCP 通过协议实现标准化，将定义及与工具的交互关系外部化。虽然这种标准化增加了复杂性，但也提升了架构的清晰度。工具因此成为具有明确模式、属性和生命周期的一等实体，不用修改或重新配置模型，即可对其进行管理、控制和开发。
另一个权衡在于可观测性。调用原生工具往往会模糊模型推理与工具交互之间的界限：我该如何追踪故障和意外行为？MCP 的客户端-服务器模型明确界定了边界和职责，便于记录和追踪指标。
在性能方面，MCP 会引入网络跳数和协议开销，在延迟敏感的场景中必须对此进行评估。实际上，这是在可预测性、可观测性和可测试性与纯粹性能之间的一种权衡。具体取决于你的解决方案中哪些要求更为重要。
MCP 的真正优势在于其架构方法。它使我们能够将基于大语言模型的系统与其他分布式系统进行整合，并采用一致且经过验证的运维、开发和测试实践来统一管理。如果在我们所处的环境中，长期维护、安全性以及职责的合理划分（包括组织层面的职责）比快速实验更为重要，那么 MCP 就是应该采用的模式。
一旦实验阶段结束，安全性和治理问题便会立即成为首要的关注点。MCP 并不能消除这些问题，而是提供了架构层面的切入点，而这通常无法应用于基于提示词或原生模型的集成方案中。
通过在协议层限制访问权限，MCP 本质上贯彻了最小权限原则。这与那些让模型直接与整个 API 集合或数据库交互的方法截然不同——后者通常使用通用凭证且权限定义模糊。
该模型可轻松地集成到现有的安全框架中：可以在 MCP 服务器的边界上实施身份验证和授权控制，采用 OAuth、mTLS 等机制或企业身份验证提供商。安全职责不会下放给模型。大语言模型不会判断某项操作是否被允许，而只能请求 MCP 服务器明确暴露的功能。
治理原则同样适用于工具的生命周期。随着时间的推移，新的用例会推动新工具的诞生，因此必须应用与 API 管理中类似的治理策略：版本控制、弃用策略、文档编写以及属性暴露。
最后，上下文管理对安全性和合规性也具有重要的影响。上下文被视为受管理的资源，而非无结构的提示，这使得 MCP 能够应用数据最小化策略。随着时间的推移，根据具体用例，敏感信息可以被屏蔽、审查或有选择地限制。在受监管的环境中，这种控制有助于降低意外泄露数据的风险，并简化数据保护法规的合规流程。
让我们以企业运维助手的设计为例，试着更深入地理解这些概念的运作原理。该系统的目标是根据相关信号提出解决方案，从而帮助服务经理和应用程序维护团队处理事件，同时又不赋予大语言模型对生产系统的直接控制权。
图 3：企业运营助手
在绝大多数企业中，用于支持生产的运维知识分散在监控平台、工单系统、运维手册和内部文档中。一旦发生故障，运维团队必须手动整合各项指标、日志和历史数据。时间就是关键。大语言模型是综合和聚合信息并提供洞察的理想工具，但以这种方式将其集成到运维工作流中可能存在很高的风险。
直接方法是指将监控 API 和工单系统直接暴露给模型，并利用它对原生工具的调用。这种方案会导致系统耦合度高、结构脆弱且存在潜在风险：模型能够访问所有数据，数据验证机制非常有限，最重要的是，几乎没有任何监督机制。在这种情况下，很难在事后控制操作，也难以应用一致的安全约束。
在基于 MCP 的设计中，我们引入了明确的架构边界；我们针对每个运营领域提供专用的 MCP 服务器：
MCP 监控服务器提供了一个只读工具，例如 getSystemMetrics。
MCP 知识服务器将运行手册和历史事件报告作为结构化资源提供，并配有 getRecentIncidents 工具。
MCP 工单服务器允许创建事件报告草稿，但在未经人工批准的情况下，不允许发送和打开工单。
每个 MCP 服务器都有其自身的运行逻辑，并负责验证对领域内特定功能的访问权限。这些工具的设计基于运行环境，而非原始 API 功能。
集成到运维助手中的 MCP 客户端负责协调这些服务器之间的交互，管理上下文构建，并根据正在分析的事件决定应公开哪些资源。该模型接收选好的运维环境视图，从而使大语言模型能够有效地进行推理，而且不需要过多的权限或信息。
当运维人员向 MCP 客户端询问诸如“为什么服务 X 最近几天一直出现问题？”之类的问题时，在后台，客户端会：
向 MCP 监控服务器查询系统的最新指标。
从 MCP 知识服务器检索相关的运行手册和历史事件。
创建一个针对性的上下文，并将其提供给模型。
允许模型提出假设及相应的解决方案建议。
如有需要，生成一份事件报告草稿以供审核和评估。
该模型从不直接与生产系统交互，而且只提供解决问题的思路和建议，而具体的事件解决工作由运维人员负责。
让我们来分析一下代码层面实现了哪些内容。为了实现 MCP 客户端，我们使用了 spring-ai-starter-mcp-client，并结合 OpenAI 以及 spring-ai-starter-model-openai 来实现 ChatClient 部分。
客户端提供了一个调用 analyze() 方法的 API。该方法随后会调用 getSystemMetrics 工具来获取系统指标，调用 getRecentIncidents 工具来获取近期事件，然后构建上下文并传递给 ChatGPT 用于检索相关信息。
public String analyze() { try { McpSchema.CallToolRequest systemMetricsRequest = new McpSchema.CallToolRequest("getSystemMetrics", Map.of()); McpSchema.CallToolResult systemMetricsToolResult = mcpClient.callTool(systemMetricsRequest); SystemMetrics systemMetricsTool = parseSystemMetrics(systemMetricsToolResult); McpSchema.CallToolRequest recentIncidentsRequest = new McpSchema.CallToolRequest("getRecentIncidents", Map.of()); McpSchema.CallToolResult recentIncidentsToolResult = mcpClient.callTool(recentIncidentsRequest); List<Incident> recentIncidents = parseRecentIncidents(recentIncidentsToolResult); StringBuilder incidentsSection = buildIncidentsSection(recentIncidents); // 通过 Spring AI ChatClient 使用 OpenAI 进行分析 return chatClient .prompt() .user(buildUserPrompt(systemMetricsTool, incidentsSection)) .call() .content(); } catch (Exception e) { return "Error during the analysis: " + e.getMessage(); }}复制代码
提示词构造如下：
private static String buildUserPrompt(SystemMetrics systemMetricsTool, StringBuilder incidentsSection) { return String.format( """ Analyse the following system metrics and recent incidents and provide operational recommendations: - Average latency: %d ms - Error rate: %.2f%% - Timestamp: %s Recent Incidents: %s Constraints: 1) Highlight possible causes (DB, network, CPU/memory saturation, external dependencies). 2) Suggest actions in order of priority (quick wins -> structural interventions). 3) Indicate any additional metrics to be collected. """, systemMetricsTool.avgLatencyMs(), systemMetricsTool.errorRate() * 100, systemMetricsTool.timestamp(), incidentsSection );}复制代码
在 MCP 服务器端，我们仅通过 spring-ai-starter-mcp-server 和 spring-ai-starter-mcp-server-webmvc 暴露了上述两个工具。简单起见，工具响应是模拟的；在实际应用场景中，MCP 服务器将集成监控工具、知识工具以及最终的工单工具 API 。
@Tool(description = "Retrieve current system metrics including response time, error rate and timestamp")public SystemMetrics getSystemMetrics() { return new SystemMetrics(120,0.02, Instant.now());}@Tool(description = "Retrieve list of recent incidents with their ID, description, timestamp and status")public List<Incident> getRecentIncidents() { return List.of( new Incident("INC-42","Database latency spike", Instant.now().minusSeconds(3600), "Resolved"), new Incident("INC-43","Cache eviction anomaly", Instant.now().minusSeconds(7200), "Investigating") );}复制代码
通过调用客户端 API，我们得到了以下结果（为便于阅读，只截取了部分结果）：
Possible Causes: 1. Database Latency Spike: This could be due to a sudden increase in database read/write operations, or a poorly optimized query…….Actions in Order of Priority: 1. Investigate the Cache Eviction Anomaly: Since the status of this incident is still under investigation, this should be the top priority…Additional Metrics to be Collected: 1. Database operation times: This would help identify any problematic queries or operations…..复制代码
你可以利用这些内容提交工单，其中包含对当前情况的初步分析、可能的原因以及解决方案。
本案例研究重点介绍了 MCP 架构的一些基本特征。首先，它展示了 MCP 服务器如何作为反腐层发挥作用，保护核心系统，并在所有情况下提供预先定义好且受控的交互。其次，它展示了 MCP 客户端如何实现显式编排和上下文管理，将复杂性从提示构建转移到源代码层面。最后，它阐明了治理和可观测性是架构中天然存在的集成需求。
照此构建的系统既能充分发挥大语言模型的优势（例如推理、综合和解释能力），又能满足业务环境（如运营）所需的安全性和可靠性要求。
与任何架构设计选择一样，其价值主要取决于具体情境。MCP 并非适用于所有 LLM 集成的通用解决方案。在某些情况下，当更简单、更直接的方法已经足够时，就不应该使用 MCP 替代，尤其是在原型开发阶段。为了做出明智的决策，重要的是要了解 MCP Java SDK 何时能带来价值，何时只是引入了不必要的管理、维护复杂性。
其中最重要的一个经验是，在必须兼顾大语言模型交互以及业务约束的环境中，MCP 能发挥最大的价值。临时拼凑的工具很难像 MCP 那样，建立起具有明确边界和可维护性的强治理机制。显式契约、功能发现、职责分离以及最小化暴露面等概念，有助于 MCP 与企业环境中的设计实践保持一致。
另一个关键点在于，MCP 在用于揭示意图而非基础设施时效果最佳。如果仅仅将 MCP 服务器视为现有 API 的简单封装，就无法实现这些优势。必须投入精力设计具有实际意义且与业务目标相契合的功能，从而实现更清晰的边界、更安全的交互，以及更加可预测和可观测的行为。这是从多年 API 设计经验中总结出的教训：高质量的抽象比协议的选择更重要。
MCP 还倡导并推行一种更健康、更合理的职责分配模式，即将所有任务分配给源代码而非提示词。授权、验证和协调工作由专门为此设计的系统负责，从而使大语言模型能够专注于推理和综合：这不仅减轻了认知负荷，还提升了系统的韧性。
然而，这一切都是有成本的。MCP 会引入额外的组件、通信开销、操作复杂性以及更多的故障点。对于小型团队或短期实验而言，这些成本很可能超过其带来的收益。在这种情况下，只要了解其局限性，原生工具或直接集成可能就是完全合适的解决方案。
其中一项限制在于组织是否已经准备好使用这一新范式。MCP 要求具备一定的架构成熟度，团队必须已经意识到定义契约、管理版本的必要性，并且要在共享基础设施上进行操作。如果忽视了这些职责，MCP 便会沦为又一层集成，而非一种规范。
归根结底，MCP 必须被视为一项长期架构投资。随着系统的发展以及团队和解决方案的可扩展性提升，其回报也会随之增长。当这些条件都具备时，MCP 便能提供一个能够支撑可持续增长的基础，而非仅仅是短期内的权宜之计。
将大语言模型集成到企业系统中，标志着软件架构的构思与设计方式正在发生根本性的变革。大语言模型将概率推理引入了传统上由确定性逻辑主导的环境。要管理这一变革，需要一套结构严谨的架构规范；仅靠个别供应商提供的智能提示或原生扩展是远远不够的。
MCP 正是朝着这一方向迈出的重要一步。MCP 定义了一种标准化方式来提供工具和上下文，将大语言模型（LLM）的集成重新定义为协议层面的挑战，而非实现细节。这一转变使得架构师们能够将他们熟悉的原则（例如职责分离、最小权限原则、可观测性，以及明确且有文档记录的契约）应用于一类全新的系统。
MCP Java SDK 的发布对整个 Java 生态系统和企业界而言都具有根本性的重要意义。它使企业在进行大语言模型集成时，不会牺牲支撑其关键系统架构的严谨性。MCP 不再将大语言模型视为游离于规则和既定边界之外的外部特殊组件，而是将其纳入企业架构，使其成为一个常规且重要的组成部分。
然而，MCP 的核心并非在于提供新功能，而在于赋予现有功能一种更本质、更负责任的形式。它提供了一个控制平面，用于随着时间的推移观察、管理和开发模型与系统之间的交互。随着基于大语言模型（LLM）的功能日益融入核心业务流程，这种治理机制变得至关重要。
需要明确的是，MCP 既无法消除大语言模型固有的不确定性，也无法保证更高的准确性。它所提供的，是在明确界定且预先设定的架构边界内管理不确定性的一种方法。对于那些希望超越实验阶段、迈向可持续 AI 应用的组织而言，这一区别至关重要。
随着大语言模型的持续发展，MCP 等协议将在未来的架构转型中发挥与 HTTP 和 REST 范式在以往转型中同样重要的作用。其目标并非规定具体的实现细节，而是确立共同的预期，从而在系统之间实现可持续的互操作。
这项工作仅仅是个开始：大语言模型正在持续重塑系统设计，而 MCP 是一个让基于 Java 的企业架构可以将其自身生态系统与 AI 相融合的协议。文中代码可通过以下链接获取（ mcp-client 和 mcp-server ）。
原文链接：
https://www.infoq.com/articles/mcp-java-architectural-strategy-llm-integrations/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。