Java 世界的 MCP：將架構(gòu)策略應(yīng)用于 LLM 集成

作者 | Matteo Rossi

譯者 | 平川

1 簡(jiǎn)介：為什么 MCP Java SDK 很重要

大語(yǔ)言模型不再僅僅用于實(shí)驗(yàn)性的聊天機(jī)器人或個(gè)人生產(chǎn)力工具。在企業(yè)中，這些模型正在改變團(tuán)隊(duì)與系統(tǒng)互動(dòng)以及做出實(shí)際決策的方式。從本質(zhì)上講，它們已經(jīng)成為真正的架構(gòu)組件。

盡管如此，當(dāng)前的集成還比較脆弱。許多團(tuán)隊(duì)使用供應(yīng)商特有的機(jī)制將集成邏輯嵌入到提示中，或者直接向模型暴露 API。雖然這些方法在原型設(shè)計(jì)階段很有用，但它們難以擴(kuò)展，并且治理能力也非常有限。

這種情況與 SOA 的早期階段頗為相似，當(dāng)時(shí)由于缺乏統(tǒng)一的標(biāo)準(zhǔn)，導(dǎo)致系統(tǒng)結(jié)構(gòu)脆弱，難以開(kāi)發(fā)和集成。MCP 現(xiàn)在處于同樣的穩(wěn)定化階段：它在基于 LLM 的架構(gòu)中引入了一個(gè)協(xié)議層，其中包含了結(jié)構(gòu)、邊界和互操作模型。

為了應(yīng)對(duì)這些挑戰(zhàn)，模型上下文協(xié)議（MCP）引入一種標(biāo)準(zhǔn)化且與模型無(wú)關(guān)的方法，用于展示上下文工具和數(shù)據(jù)。MCP 在模型與外部系統(tǒng)之間定義了一個(gè)協(xié)議層的契約，避免了將集成語(yǔ)義硬編碼到提示或特定于 SDK 的調(diào)用中。這種共享且標(biāo)準(zhǔn)化的約定使功能變得明確、可發(fā)現(xiàn)且可管理。

在這個(gè)背景下，Java MCP SDK 的出現(xiàn)尤為重要。JVM 生態(tài)系統(tǒng)支撐著企業(yè)的大部分工作負(fù)載，這里的架構(gòu)規(guī)范并非是一種審美上的偏好。基于 Java 的系統(tǒng)必須具備可觀測(cè)性、可測(cè)試性、高可靠性以及長(zhǎng)期可維護(hù)性。如果在這些環(huán)境中引入 LLM，而沒(méi)有與之相匹配的同等水平的規(guī)范，就會(huì)導(dǎo)致不一致的情況，變得難以管理和解決。

Java 中基于 SDK 和 MCP 的集成方案，使架構(gòu)師能夠?qū)⒋笳Z(yǔ)言模型的采用與企業(yè)現(xiàn)有的架構(gòu)實(shí)踐相融合，并將服務(wù)邊界、契約和控制平面等概念應(yīng)用于與大語(yǔ)言模型的交互中。

本文將從這一角度探討 MCP 及其 Java SDK。本文的目的并非講解如何編寫 MCP 代碼，而是探討 MCP 如何重新定義大語(yǔ)言模型的集成標(biāo)準(zhǔn)，它解決了哪些問(wèn)題，以及在設(shè)計(jì)旨在突破原型階段、實(shí)現(xiàn)規(guī)模化應(yīng)用的系統(tǒng)時(shí)要做哪些權(quán)衡取舍。

2 MCP 入門：基于協(xié)議的 LLM 集成視角

為了從架構(gòu)的角度更好地理解 MCP，我們需要將關(guān)注點(diǎn)從單個(gè)集成轉(zhuǎn)向交互模型。MCP 既不是代理框架，也不是運(yùn)行時(shí)環(huán)境；它是一種協(xié)議，通過(guò)結(jié)構(gòu)化的契約來(lái)定義模型如何與外部功能進(jìn)行交互。

MCP 架構(gòu)基于一組明確區(qū)分的角色。主機(jī)為模型提供執(zhí)行環(huán)境；客戶端負(fù)責(zé)處理模型的請(qǐng)求，而服務(wù)器則將工具和資源作為明確定義的功能對(duì)外提供。這種間接模型是刻意設(shè)計(jì)的：模型絕不會(huì)直接調(diào)用 API 或基礎(chǔ)設(shè)施，它們只調(diào)用通過(guò)協(xié)議聲明的內(nèi)容。其結(jié)果是形成了一道治理邊界，該邊界可以控制訪問(wèn)，而不會(huì)干擾模型的推理過(guò)程。

圖 1： MCP 分層架構(gòu)圖（圖片來(lái)源）

MCP 的主要特點(diǎn)之一在于其功能發(fā)現(xiàn)能力。MCP 并非預(yù)先配置好模型可用的工具，而是允許客戶端在運(yùn)行時(shí)向服務(wù)器發(fā)起查詢，從而發(fā)現(xiàn)功能及其關(guān)聯(lián)的模式。這一能力使系統(tǒng)更具適應(yīng)性，并減少在提示詞或代理邏輯中對(duì)功能進(jìn)行硬編碼的需求。從架構(gòu)角度來(lái)看，該機(jī)制實(shí)現(xiàn)了模型與系統(tǒng)之間的松耦合。

MCP 還區(qū)分了工具和資源。工具代表模型可以請(qǐng)求的操作，而資源則提供結(jié)構(gòu)化的上下文數(shù)據(jù)。這種區(qū)分便于清晰地區(qū)分不同的數(shù)據(jù)訪問(wèn)模式。無(wú)論是從安全性還是治理角度來(lái)看，只讀上下文數(shù)據(jù)與會(huì)改變狀態(tài)的操作在管理方式上都大不相同。

圖 2：MCP 服務(wù)器組成

作為一種規(guī)范，MCP 還重新定義了快速開(kāi)發(fā)流程。其上下文不能只是在運(yùn)行時(shí)臨時(shí)拼湊而成的固定字符串，而必須是通過(guò)明確的接口提供的經(jīng)過(guò)精心策劃的結(jié)構(gòu)化信息集合。

最終，MCP 代表了從以模型為中心的集成向基于協(xié)議的設(shè)計(jì)轉(zhuǎn)變。LLM 交互被視為分布式系統(tǒng)交互，需遵循與任何其他類型的集成相同的架構(gòu)規(guī)范。

3 MCP Java SDK 內(nèi)部的設(shè)計(jì)與架構(gòu)選擇

Java MCP SDK 將 Anthropic 公司 MCP 協(xié)議的抽象原則轉(zhuǎn)化為適用于基于 JVM 的系統(tǒng)的具體實(shí)現(xiàn)。Anthropic 的設(shè)計(jì)既保持了協(xié)議的準(zhǔn)確性，又遵循了 Java 企業(yè)應(yīng)用的最佳實(shí)踐。該協(xié)議側(cè)重于定義抽象角色、消息格式和能力協(xié)商，而 SDK 則通過(guò)以 Java 為中心的設(shè)計(jì)選擇實(shí)現(xiàn)了這些概念。這些設(shè)計(jì)選擇包括強(qiáng)類型模型、為客戶端和服務(wù)器提供明確的接口，以及基于模式交互所采用的構(gòu)建器結(jié)構(gòu)。

總體上看，該 SDK 采用多層架構(gòu)設(shè)計(jì)。其中，傳輸機(jī)制（如用于本地集成的 STDIO 或用于分布式通信的 HTTP）、協(xié)議語(yǔ)義以及會(huì)話管理之間有著明確的劃分。這種劃分使得團(tuán)隊(duì)能夠根據(jù)不同的交互模式調(diào)整 MCP 協(xié)議，而不會(huì)影響底層邏輯。

該 SDK 支持同步和異步兩種交互模式。在內(nèi)部，它傾向于采用非阻塞通信和響應(yīng)式流程，這種模式非常適合 MCP I/O 交互。同時(shí)，該 SDK 還提供了更高層次的抽象，可以在傳統(tǒng)的命令式代碼中使用。在企業(yè)生態(tài)系統(tǒng)中，這兩種選擇使得純響應(yīng)式技術(shù)棧能夠與傳統(tǒng)或混合編程范式共存。

該 SDK 的另一個(gè)關(guān)鍵方面是與框架集成。在 Java 企業(yè)環(huán)境中，首要問(wèn)題就是：它是否能與 Spring 進(jìn)行集成？在基于 Spring 的應(yīng)用程序中，MCP 服務(wù)器可以與現(xiàn)有的服務(wù)一起集成，從而受益于 Spring 的獨(dú)有特性，例如依賴注入、配置管理以及已有的針對(duì)其他應(yīng)用程序的管理實(shí)踐。這種設(shè)計(jì)使得 MCP 能夠逐步采用，一步一步引入 MCP 端點(diǎn)，而不需要從頭重寫應(yīng)用程序或重新組織整個(gè)架構(gòu)。

只需很少的代碼，就可以將 MCP 工具提供程序集成到 Spring 框架中：

}

在這個(gè)例子中，MonitoringTools 是一個(gè)標(biāo)準(zhǔn)的 Spring 托管 Bean。該 Bean 暴露的方法只需向 MethodToolCallbackProvider 注冊(cè)，即可成為 MCP 工具。通過(guò)這種機(jī)制，MCP 功能得以與其他服務(wù)的行為保持一致，并成為同一依賴關(guān)系圖的一部分。Spring 對(duì)其生命周期、配置和注入的處理方式，與應(yīng)用程序中所有其他 Bean 完全一致。

Java SDK 的最大優(yōu)勢(shì)在于將協(xié)議概念明確化。工具的定義需要有明確的輸入和輸出，而資源則必須進(jìn)行恰當(dāng)?shù)拿枋龊徒Y(jié)構(gòu)化。這種對(duì)明確性的要求迫使團(tuán)隊(duì)將 MCP 服務(wù)器視為有界上下文，而非通用的集成層。

從架構(gòu)的角度來(lái)看，這些特性使 MCP 服務(wù)器與防腐層、API 網(wǎng)關(guān)等成熟的模式相契合。SDK 提供了構(gòu)建模塊，而這些邊界所帶來(lái)的架構(gòu)規(guī)范則帶來(lái)了長(zhǎng)遠(yuǎn)價(jià)值。

此外，通過(guò)將功能暴露視為一項(xiàng)需要開(kāi)發(fā)和設(shè)計(jì)的活動(dòng)，該 SDK 有效防止了功能的無(wú)序擴(kuò)張——這是大語(yǔ)言模型集成中非常常見(jiàn)的陷阱。因此，并非將整個(gè) API 對(duì)外開(kāi)放，而是根據(jù)功能和業(yè)務(wù)需求，提供經(jīng)過(guò)精心設(shè)計(jì)的功能。

從這個(gè)意義上說(shuō)，Java MCP SDK 遠(yuǎn)不止是一個(gè)協(xié)議。它迫使開(kāi)發(fā)團(tuán)隊(duì)重新思考大語(yǔ)言模型的集成，將其視為系統(tǒng)架構(gòu)中的核心組件，而非僅僅是需要接入的外部工具。

4 使用 Java 設(shè)計(jì) MCP 服務(wù)器：暴露功能，而非 API

在使用 MCP 時(shí)，一個(gè)關(guān)鍵決策在于如何將 MCP 服務(wù)器集成到整體架構(gòu)中。乍看之下，將 MCP 服務(wù)器視為一個(gè)簡(jiǎn)單的適配器，負(fù)責(zé)將模型請(qǐng)求轉(zhuǎn)發(fā)給現(xiàn)有的 API，似乎既直觀又易于實(shí)現(xiàn)。然而，這種做法會(huì)削弱該協(xié)議的許多優(yōu)勢(shì)。

在企業(yè)系統(tǒng)中，API 通常是為大語(yǔ)言模型設(shè)計(jì)的。在理想情況下，它們會(huì)暴露底層的基本操作，并假設(shè)特定的調(diào)用序列。在其他情況下，它們則反映了歷史上的限制或組織層面的問(wèn)題（參見(jiàn)康威定律）。即使通過(guò) MCP，將此類 API 直接暴露給模型，也可能會(huì)導(dǎo)致產(chǎn)生 MCP 本意要解決的緊耦合問(wèn)題。

一種更有效的方法是將 MCP 服務(wù)器視為功能提供者。采用這種方法，MCP 服務(wù)器將定義封裝了特定領(lǐng)域業(yè)務(wù)功能的高級(jí)工具，而不是直接暴露原始端點(diǎn)。讓我們以票務(wù)系統(tǒng)為例。MCP 服務(wù)器無(wú)需暴露完整的 API，而是可以設(shè)計(jì)為僅暴露諸如 retrieveIncidentSummary、searchRelatedIncidents 和 proposeMitigationSteps 之類的工具。這些工具暴露了模型被授權(quán)執(zhí)行的操作，而非底層系統(tǒng)在技術(shù)上能夠執(zhí)行的操作。

這種設(shè)計(jì)在 MCP 服務(wù)器與防腐層之間建立了非常緊密的對(duì)應(yīng)關(guān)系。服務(wù)器負(fù)責(zé)將模型發(fā)出的請(qǐng)求轉(zhuǎn)換為與核心系統(tǒng)之間安全且經(jīng)過(guò)驗(yàn)證的交互。在任何調(diào)用到達(dá)核心系統(tǒng)之前，系統(tǒng)都會(huì)對(duì)輸入進(jìn)行驗(yàn)證、執(zhí)行授權(quán)檢查，并確保數(shù)據(jù)被正確地建模。除非明確允許，否則模型絕不應(yīng)接觸到內(nèi)部標(biāo)識(shí)符、實(shí)現(xiàn)細(xì)節(jié)、過(guò)于具體的錯(cuò)誤信息，或可能產(chǎn)生副作用的操作。

因此，可以使用 Java 來(lái)實(shí)現(xiàn) MCP 服務(wù)器，既可以將其作為獨(dú)立的服務(wù)來(lái)運(yùn)行，也可以將其集成到現(xiàn)有的 Spring 應(yīng)用程序中。這種實(shí)現(xiàn)方式使我們可以復(fù)用領(lǐng)域服務(wù)、存儲(chǔ)庫(kù)和安全組件，同時(shí)為模型提供一個(gè)有限制而且是有意暴露的接口。

如上所述，另一個(gè)需要考慮的重要區(qū)別在于只讀功能與狀態(tài)修改功能之間的區(qū)別。許多用例都是基于這樣一個(gè)事實(shí)而開(kāi)發(fā)的，即模型能夠探索數(shù)據(jù)并提出操作建議，但不能直接執(zhí)行這些操作。MCP 通過(guò)鼓勵(lì)開(kāi)發(fā)細(xì)粒度的詳細(xì)工具來(lái)明確這種區(qū)別。例如，MCP 服務(wù)器可以提供一個(gè)工具，用于評(píng)估操作的影響或準(zhǔn)備請(qǐng)求，而將操作的執(zhí)行留給一個(gè)獨(dú)立的由人工驅(qū)動(dòng)的流程。

要實(shí)現(xiàn)所有這些功能，必須采用良好的操作規(guī)范。MCP 服務(wù)器為可觀測(cè)性和審計(jì)提供了天然的切入點(diǎn)。該工具的每一次調(diào)用都可以進(jìn)行記錄、跟蹤和分析，而且不依賴模型的內(nèi)部推理過(guò)程。

5 MCP 客戶端與編排：當(dāng)模型遇到架構(gòu)

MCP 服務(wù)器決定提供哪些功能，而 MCP 客戶端則決定如何使用這些功能。在早期的大語(yǔ)言模型（LLM）集成中，編排邏輯直接嵌入到提示詞或代理框架中，這使得維護(hù)工作變得非常復(fù)雜，運(yùn)行時(shí)的關(guān)聯(lián)關(guān)系也很難理解。

MCP 客戶端充當(dāng)模型與一個(gè)或多個(gè) MCP 服務(wù)器之間的中介。它負(fù)責(zé)識(shí)別可用的工具、管理會(huì)話以及協(xié)調(diào)對(duì)工具的調(diào)用。它是該架構(gòu)的關(guān)鍵組件，而不是一個(gè)被動(dòng)的通信層。

在 Java 生態(tài)系統(tǒng)中，我們可以將 MCP 客戶端集成到能夠協(xié)調(diào)復(fù)雜工作流的服務(wù)中。例如一個(gè)運(yùn)維助手，它利用 MCP 客戶端查詢多個(gè)服務(wù)器（監(jiān)控、工單和文檔），并將這些服務(wù)器的響應(yīng)整合到適合該模型的上下文中。這種協(xié)調(diào)邏輯現(xiàn)在位于代碼而非提示詞中，使得版本控制和測(cè)試都變得更加容易。

該模型的一大關(guān)鍵優(yōu)勢(shì)在于能夠明確控制交互流程，包括調(diào)用序列、超時(shí)處理、部分錯(cuò)誤處理以及備用方案。客戶端可以處理所有這些情況，并自主決定何時(shí)中斷模型的運(yùn)行，將控制權(quán)交由人工操作員管理。在提示詞中實(shí)現(xiàn)這些功能非常復(fù)雜，在應(yīng)用程序代碼中則要簡(jiǎn)單得多。

MCP 客戶端在上下文管理中發(fā)揮著核心作用。客戶端不需要手動(dòng)拼湊冗長(zhǎng)的提示詞，就能夠精確地決定在任何給定的時(shí)刻向模型暴露哪些資源。這種選擇能最大限度地精簡(jiǎn)上下文，并大幅降低敏感或無(wú)關(guān)信息泄露的風(fēng)險(xiǎn)。

從架構(gòu)角度來(lái)看，MCP 客戶端不過(guò)是分布式系統(tǒng)中的協(xié)調(diào)器。它們管理對(duì)話，并將對(duì)話視為對(duì)服務(wù)的調(diào)用流。這種方法將大語(yǔ)言模型集成的復(fù)雜性分解為三個(gè)關(guān)鍵問(wèn)題：狀態(tài)管理、冪等性和錯(cuò)誤處理。對(duì)于基于 Java 的分布式系統(tǒng)開(kāi)發(fā)者而言，他們對(duì)于這些問(wèn)題都有著非常明確且立場(chǎng)鮮明的看法。

6 MCP 與原生工具調(diào)用：權(quán)衡與設(shè)計(jì)考量

使用 MCP 是有代價(jià)的。與大語(yǔ)言模型提供商提供的原生工具調(diào)用方式相比，MCP 增加了額外的層級(jí)和抽象。對(duì)于小型或?qū)嶒?yàn)性項(xiàng)目而言，其額外帶來(lái)的成本很可能超過(guò)好處。

原生調(diào)用工具更為簡(jiǎn)單直觀：模型調(diào)用一個(gè)函數(shù)，接收響應(yīng)，然后繼續(xù)執(zhí)行。這種簡(jiǎn)單性帶來(lái)了一個(gè)副作用：強(qiáng)耦合。工具定義通常嵌入在提示詞或 SDK 配置中，這使得版本控制和獨(dú)立模型管理變得十分困難。

另一方面，MCP 通過(guò)協(xié)議實(shí)現(xiàn)標(biāo)準(zhǔn)化，將定義及與工具的交互關(guān)系外部化。雖然這種標(biāo)準(zhǔn)化增加了復(fù)雜性，但也提升了架構(gòu)的清晰度。工具因此成為具有明確模式、屬性和生命周期的一等實(shí)體，不用修改或重新配置模型，即可對(duì)其進(jìn)行管理、控制和開(kāi)發(fā)。

另一個(gè)權(quán)衡在于可觀測(cè)性。調(diào)用原生工具往往會(huì)模糊模型推理與工具交互之間的界限：我該如何追蹤故障和意外行為？MCP 的客戶端 - 服務(wù)器模型明確界定了邊界和職責(zé)，便于記錄和追蹤指標(biāo)。

在性能方面，MCP 會(huì)引入網(wǎng)絡(luò)跳數(shù)和協(xié)議開(kāi)銷，在延遲敏感的場(chǎng)景中必須對(duì)此進(jìn)行評(píng)估。實(shí)際上，這是在可預(yù)測(cè)性、可觀測(cè)性和可測(cè)試性與純粹性能之間的一種權(quán)衡。具體取決于你的解決方案中哪些要求更為重要。

MCP 的真正優(yōu)勢(shì)在于其架構(gòu)方法。它使我們能夠?qū)⒒诖笳Z(yǔ)言模型的系統(tǒng)與其他分布式系統(tǒng)進(jìn)行整合，并采用一致且經(jīng)過(guò)驗(yàn)證的運(yùn)維、開(kāi)發(fā)和測(cè)試實(shí)踐來(lái)統(tǒng)一管理。如果在我們所處的環(huán)境中，長(zhǎng)期維護(hù)、安全性以及職責(zé)的合理劃分（包括組織層面的職責(zé)）比快速實(shí)驗(yàn)更為重要，那么 MCP 就是應(yīng)該采用的模式。

7 安全性、治理與可觀測(cè)性：實(shí)現(xiàn) MCP 的大規(guī)模可運(yùn)維性

一旦實(shí)驗(yàn)階段結(jié)束，安全性和治理問(wèn)題便會(huì)立即成為首要的關(guān)注點(diǎn)。MCP 并不能消除這些問(wèn)題，而是提供了架構(gòu)層面的切入點(diǎn)，而這通常無(wú)法應(yīng)用于基于提示詞或原生模型的集成方案中。

通過(guò)在協(xié)議層限制訪問(wèn)權(quán)限，MCP 本質(zhì)上貫徹了最小權(quán)限原則。這與那些讓模型直接與整個(gè) API 集合或數(shù)據(jù)庫(kù)交互的方法截然不同——后者通常使用通用憑證且權(quán)限定義模糊。

該模型可輕松地集成到現(xiàn)有的安全框架中：可以在 MCP 服務(wù)器的邊界上實(shí)施身份驗(yàn)證和授權(quán)控制，采用 OAuth、mTLS 等機(jī)制或企業(yè)身份驗(yàn)證提供商。安全職責(zé)不會(huì)下放給模型。大語(yǔ)言模型不會(huì)判斷某項(xiàng)操作是否被允許，而只能請(qǐng)求 MCP 服務(wù)器明確暴露的功能。

治理原則同樣適用于工具的生命周期。隨著時(shí)間的推移，新的用例會(huì)推動(dòng)新工具的誕生，因此必須應(yīng)用與 API 管理中類似的治理策略：版本控制、棄用策略、文檔編寫以及屬性暴露。

最后，上下文管理對(duì)安全性和合規(guī)性也具有重要的影響。上下文被視為受管理的資源，而非無(wú)結(jié)構(gòu)的提示，這使得 MCP 能夠應(yīng)用數(shù)據(jù)最小化策略。隨著時(shí)間的推移，根據(jù)具體用例，敏感信息可以被屏蔽、審查或有選擇地限制。在受監(jiān)管的環(huán)境中，這種控制有助于降低意外泄露數(shù)據(jù)的風(fēng)險(xiǎn)，并簡(jiǎn)化數(shù)據(jù)保護(hù)法規(guī)的合規(guī)流程。

8 案例研究：基于 MCP 構(gòu)建的企業(yè)運(yùn)營(yíng)助手

讓我們以企業(yè)運(yùn)維助手的設(shè)計(jì)為例，試著更深入地理解這些概念的運(yùn)作原理。該系統(tǒng)的目標(biāo)是根據(jù)相關(guān)信號(hào)提出解決方案，從而幫助服務(wù)經(jīng)理和應(yīng)用程序維護(hù)團(tuán)隊(duì)處理事件，同時(shí)又不賦予大語(yǔ)言模型對(duì)生產(chǎn)系統(tǒng)的直接控制權(quán)。

圖 3：企業(yè)運(yùn)營(yíng)助手

問(wèn)題空間

在絕大多數(shù)企業(yè)中，用于支持生產(chǎn)的運(yùn)維知識(shí)分散在監(jiān)控平臺(tái)、工單系統(tǒng)、運(yùn)維手冊(cè)和內(nèi)部文檔中。一旦發(fā)生故障，運(yùn)維團(tuán)隊(duì)必須手動(dòng)整合各項(xiàng)指標(biāo)、日志和歷史數(shù)據(jù)。時(shí)間就是關(guān)鍵。大語(yǔ)言模型是綜合和聚合信息并提供洞察的理想工具，但以這種方式將其集成到運(yùn)維工作流中可能存在很高的風(fēng)險(xiǎn)。

直接方法是指將監(jiān)控 API 和工單系統(tǒng)直接暴露給模型，并利用它對(duì)原生工具的調(diào)用。這種方案會(huì)導(dǎo)致系統(tǒng)耦合度高、結(jié)構(gòu)脆弱且存在潛在風(fēng)險(xiǎn)：模型能夠訪問(wèn)所有數(shù)據(jù)，數(shù)據(jù)驗(yàn)證機(jī)制非常有限，最重要的是，幾乎沒(méi)有任何監(jiān)督機(jī)制。在這種情況下，很難在事后控制操作，也難以應(yīng)用一致的安全約束。

基于 MCP 的架構(gòu)

在基于 MCP 的設(shè)計(jì)中，我們引入了明確的架構(gòu)邊界；我們針對(duì)每個(gè)運(yùn)營(yíng)領(lǐng)域提供專用的 MCP 服務(wù)器：

• MCP 監(jiān)控服務(wù)器提供了一個(gè)只讀工具，例如 getSystemMetrics。

• MCP 知識(shí)服務(wù)器將運(yùn)行手冊(cè)和歷史事件報(bào)告作為結(jié)構(gòu)化資源提供，并配有 getRecentIncidents 工具。

• MCP 工單服務(wù)器允許創(chuàng)建事件報(bào)告草稿，但在未經(jīng)人工批準(zhǔn)的情況下，不允許發(fā)送和打開(kāi)工單。

每個(gè) MCP 服務(wù)器都有其自身的運(yùn)行邏輯，并負(fù)責(zé)驗(yàn)證對(duì)領(lǐng)域內(nèi)特定功能的訪問(wèn)權(quán)限。這些工具的設(shè)計(jì)基于運(yùn)行環(huán)境，而非原始 API 功能。

集成到運(yùn)維助手中的 MCP 客戶端負(fù)責(zé)協(xié)調(diào)這些服務(wù)器之間的交互，管理上下文構(gòu)建，并根據(jù)正在分析的事件決定應(yīng)公開(kāi)哪些資源。該模型接收選好的運(yùn)維環(huán)境視圖，從而使大語(yǔ)言模型能夠有效地進(jìn)行推理，而且不需要過(guò)多的權(quán)限或信息。

交互流程

當(dāng)運(yùn)維人員向 MCP 客戶端詢問(wèn)諸如“為什么服務(wù) X 最近幾天一直出現(xiàn)問(wèn)題？”之類的問(wèn)題時(shí)，在后臺(tái)，客戶端會(huì)：

• 向 MCP 監(jiān)控服務(wù)器查詢系統(tǒng)的最新指標(biāo)。

• 從 MCP 知識(shí)服務(wù)器檢索相關(guān)的運(yùn)行手冊(cè)和歷史事件。

• 創(chuàng)建一個(gè)針對(duì)性的上下文，并將其提供給模型。

• 允許模型提出假設(shè)及相應(yīng)的解決方案建議。

• 如有需要，生成一份事件報(bào)告草稿以供審核和評(píng)估。

該模型從不直接與生產(chǎn)系統(tǒng)交互，而且只提供解決問(wèn)題的思路和建議，而具體的事件解決工作由運(yùn)維人員負(fù)責(zé)。

實(shí)際代碼

讓我們來(lái)分析一下代碼層面實(shí)現(xiàn)了哪些內(nèi)容。為了實(shí)現(xiàn) MCP 客戶端，我們使用了 spring-ai-starter-mcp-client，并結(jié)合 OpenAI 以及 spring-ai-starter-model-openai 來(lái)實(shí)現(xiàn) ChatClient 部分。

客戶端提供了一個(gè)調(diào)用 analyze() 方法的 API。該方法隨后會(huì)調(diào)用 getSystemMetrics 工具來(lái)獲取系統(tǒng)指標(biāo)，調(diào)用 getRecentIncidents 工具來(lái)獲取近期事件，然后構(gòu)建上下文并傳遞給 ChatGPT 用于檢索相關(guān)信息。

}

提示詞構(gòu)造如下：

}

在 MCP 服務(wù)器端，我們僅通過(guò) spring-ai-starter-mcp-server 和 spring-ai-starter-mcp-server-webmvc 暴露了上述兩個(gè)工具。簡(jiǎn)單起見(jiàn)，工具響應(yīng)是模擬的；在實(shí)際應(yīng)用場(chǎng)景中，MCP 服務(wù)器將集成監(jiān)控工具、知識(shí)工具以及最終的工單工具 API 。

}

通過(guò)調(diào)用客戶端 API，我們得到了以下結(jié)果（為便于閱讀，只截取了部分結(jié)果）：

Additional Metrics to be Collected: 1. Database operation times: This would help identify any problematic queries or operations…..

你可以利用這些內(nèi)容提交工單，其中包含對(duì)當(dāng)前情況的初步分析、可能的原因以及解決方案。

架構(gòu)案例小結(jié)

本案例研究重點(diǎn)介紹了 MCP 架構(gòu)的一些基本特征。首先，它展示了 MCP 服務(wù)器如何作為反腐層發(fā)揮作用，保護(hù)核心系統(tǒng)，并在所有情況下提供預(yù)先定義好且受控的交互。其次，它展示了 MCP 客戶端如何實(shí)現(xiàn)顯式編排和上下文管理，將復(fù)雜性從提示構(gòu)建轉(zhuǎn)移到源代碼層面。最后，它闡明了治理和可觀測(cè)性是架構(gòu)中天然存在的集成需求。

照此構(gòu)建的系統(tǒng)既能充分發(fā)揮大語(yǔ)言模型的優(yōu)勢(shì)（例如推理、綜合和解釋能力），又能滿足業(yè)務(wù)環(huán)境（如運(yùn)營(yíng)）所需的安全性和可靠性要求。

9 經(jīng)驗(yàn)教訓(xùn)：何時(shí)適合使用 MCP Java SDK，何時(shí)不適合

與任何架構(gòu)設(shè)計(jì)選擇一樣，其價(jià)值主要取決于具體情境。MCP 并非適用于所有 LLM 集成的通用解決方案。在某些情況下，當(dāng)更簡(jiǎn)單、更直接的方法已經(jīng)足夠時(shí)，就不應(yīng)該使用 MCP 替代，尤其是在原型開(kāi)發(fā)階段。為了做出明智的決策，重要的是要了解 MCP Java SDK 何時(shí)能帶來(lái)價(jià)值，何時(shí)只是引入了不必要的管理、維護(hù)復(fù)雜性。

其中最重要的一個(gè)經(jīng)驗(yàn)是，在必須兼顧大語(yǔ)言模型交互以及業(yè)務(wù)約束的環(huán)境中，MCP 能發(fā)揮最大的價(jià)值。臨時(shí)拼湊的工具很難像 MCP 那樣，建立起具有明確邊界和可維護(hù)性的強(qiáng)治理機(jī)制。顯式契約、功能發(fā)現(xiàn)、職責(zé)分離以及最小化暴露面等概念，有助于 MCP 與企業(yè)環(huán)境中的設(shè)計(jì)實(shí)踐保持一致。

另一個(gè)關(guān)鍵點(diǎn)在于，MCP 在用于揭示意圖而非基礎(chǔ)設(shè)施時(shí)效果最佳。如果僅僅將 MCP 服務(wù)器視為現(xiàn)有 API 的簡(jiǎn)單封裝，就無(wú)法實(shí)現(xiàn)這些優(yōu)勢(shì)。必須投入精力設(shè)計(jì)具有實(shí)際意義且與業(yè)務(wù)目標(biāo)相契合的功能，從而實(shí)現(xiàn)更清晰的邊界、更安全的交互，以及更加可預(yù)測(cè)和可觀測(cè)的行為。這是從多年 API 設(shè)計(jì)經(jīng)驗(yàn)中總結(jié)出的教訓(xùn)：高質(zhì)量的抽象比協(xié)議的選擇更重要。

MCP 還倡導(dǎo)并推行一種更健康、更合理的職責(zé)分配模式，即將所有任務(wù)分配給源代碼而非提示詞。授權(quán)、驗(yàn)證和協(xié)調(diào)工作由專門為此設(shè)計(jì)的系統(tǒng)負(fù)責(zé)，從而使大語(yǔ)言模型能夠?qū)Ｗ⒂谕评砗途C合：這不僅減輕了認(rèn)知負(fù)荷，還提升了系統(tǒng)的韌性。

然而，這一切都是有成本的。MCP 會(huì)引入額外的組件、通信開(kāi)銷、操作復(fù)雜性以及更多的故障點(diǎn)。對(duì)于小型團(tuán)隊(duì)或短期實(shí)驗(yàn)而言，這些成本很可能超過(guò)其帶來(lái)的收益。在這種情況下，只要了解其局限性，原生工具或直接集成可能就是完全合適的解決方案。

其中一項(xiàng)限制在于組織是否已經(jīng)準(zhǔn)備好使用這一新范式。MCP 要求具備一定的架構(gòu)成熟度，團(tuán)隊(duì)必須已經(jīng)意識(shí)到定義契約、管理版本的必要性，并且要在共享基礎(chǔ)設(shè)施上進(jìn)行操作。如果忽視了這些職責(zé)，MCP 便會(huì)淪為又一層集成，而非一種規(guī)范。

歸根結(jié)底，MCP 必須被視為一項(xiàng)長(zhǎng)期架構(gòu)投資。隨著系統(tǒng)的發(fā)展以及團(tuán)隊(duì)和解決方案的可擴(kuò)展性提升，其回報(bào)也會(huì)隨之增長(zhǎng)。當(dāng)這些條件都具備時(shí)，MCP 便能提供一個(gè)能夠支撐可持續(xù)增長(zhǎng)的基礎(chǔ)，而非僅僅是短期內(nèi)的權(quán)宜之計(jì)。

10 結(jié)論：MCP 作為大語(yǔ)言模型感知系統(tǒng)的控制平面

將大語(yǔ)言模型集成到企業(yè)系統(tǒng)中，標(biāo)志著軟件架構(gòu)的構(gòu)思與設(shè)計(jì)方式正在發(fā)生根本性的變革。大語(yǔ)言模型將概率推理引入了傳統(tǒng)上由確定性邏輯主導(dǎo)的環(huán)境。要管理這一變革，需要一套結(jié)構(gòu)嚴(yán)謹(jǐn)?shù)募軜?gòu)規(guī)范；僅靠個(gè)別供應(yīng)商提供的智能提示或原生擴(kuò)展是遠(yuǎn)遠(yuǎn)不夠的。

MCP 正是朝著這一方向邁出的重要一步。MCP 定義了一種標(biāo)準(zhǔn)化方式來(lái)提供工具和上下文，將大語(yǔ)言模型（LLM）的集成重新定義為協(xié)議層面的挑戰(zhàn)，而非實(shí)現(xiàn)細(xì)節(jié)。這一轉(zhuǎn)變使得架構(gòu)師們能夠?qū)⑺麄兪煜さ脑瓌t（例如職責(zé)分離、最小權(quán)限原則、可觀測(cè)性，以及明確且有文檔記錄的契約）應(yīng)用于一類全新的系統(tǒng)。

MCP Java SDK 的發(fā)布對(duì)整個(gè) Java 生態(tài)系統(tǒng)和企業(yè)界而言都具有根本性的重要意義。它使企業(yè)在進(jìn)行大語(yǔ)言模型集成時(shí)，不會(huì)犧牲支撐其關(guān)鍵系統(tǒng)架構(gòu)的嚴(yán)謹(jǐn)性。MCP 不再將大語(yǔ)言模型視為游離于規(guī)則和既定邊界之外的外部特殊組件，而是將其納入企業(yè)架構(gòu)，使其成為一個(gè)常規(guī)且重要的組成部分。

然而，MCP 的核心并非在于提供新功能，而在于賦予現(xiàn)有功能一種更本質(zhì)、更負(fù)責(zé)任的形式。它提供了一個(gè)控制平面，用于隨著時(shí)間的推移觀察、管理和開(kāi)發(fā)模型與系統(tǒng)之間的交互。隨著基于大語(yǔ)言模型（LLM）的功能日益融入核心業(yè)務(wù)流程，這種治理機(jī)制變得至關(guān)重要。

需要明確的是，MCP 既無(wú)法消除大語(yǔ)言模型固有的不確定性，也無(wú)法保證更高的準(zhǔn)確性。它所提供的，是在明確界定且預(yù)先設(shè)定的架構(gòu)邊界內(nèi)管理不確定性的一種方法。對(duì)于那些希望超越實(shí)驗(yàn)階段、邁向可持續(xù) AI 應(yīng)用的組織而言，這一區(qū)別至關(guān)重要。

隨著大語(yǔ)言模型的持續(xù)發(fā)展，MCP 等協(xié)議將在未來(lái)的架構(gòu)轉(zhuǎn)型中發(fā)揮與 HTTP 和 REST 范式在以往轉(zhuǎn)型中同樣重要的作用。其目標(biāo)并非規(guī)定具體的實(shí)現(xiàn)細(xì)節(jié)，而是確立共同的預(yù)期，從而在系統(tǒng)之間實(shí)現(xiàn)可持續(xù)的互操作。

這項(xiàng)工作僅僅是個(gè)開(kāi)始：大語(yǔ)言模型正在持續(xù)重塑系統(tǒng)設(shè)計(jì)，而 MCP 是一個(gè)讓基于 Java 的企業(yè)架構(gòu)可以將其自身生態(tài)系統(tǒng)與 AI 相融合的協(xié)議。文中代碼可通過(guò)以下鏈接獲取（ mcp-client 和 mcp-server ）。

https://www.infoq.com/articles/mcp-java-architectural-strategy-llm-integrations/

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。