Spring AI 應用實戰：別只做聊天機器人，從 ChatClient、Advisors、RAG 到 MCP 的工程化設計

很多人第一次接觸 Spring AI，會把它理解成「Spring Boot 版的 OpenAI SDK」。這個理解不能說完全錯，但如果停在這裡，做出來的應用通常很快就會遇到瓶頸：提示詞越寫越亂、外部工具越接越難控、知識檢索和對話記憶糾纏在一起，最後只能維持一個 demo 可以跑、但很難進入正式系統的狀態。

真正有價值的 Spring AI 應用，不是把 LLM 接進來而已，而是把 LLM 放進一個可以驗證、可以治理、可以維運的 Java 系統裡。Spring AI 的價值正是在這裡：它不是只提供 model call，而是提供一個把聊天模型、檢索流程、工具調用、上下文攔截與 Spring Boot 工程能力接起來的應用框架。

這篇文章不打算重複官方文件的功能列表，而是從工程角度回答一個更重要的問題：如果你真的要用 Spring AI 做內部知識助理、客服協作、工作流代理或企業工具入口，應該怎麼設計，才不會三個月後整套系統變成不可維護的 prompt 泥沼？

先看一個比較符合真實場景的架構：

spring-ai-app/
 ├─ api layer
 │   └─ ChatController
 ├─ orchestration layer
 │   ├─ ChatClient
 │   ├─ Advisors
 │   └─ Prompt policies
 ├─ knowledge layer
 │   ├─ VectorStore
 │   ├─ QuestionAnswerAdvisor
 │   └─ RetrievalAugmentationAdvisor
 ├─ tool layer
 │   ├─ Internal business tools
 │   └─ MCP client / MCP server
 ├─ policy layer
 │   ├─ Security
 │   ├─ Auditing
 │   └─ Guardrails
 └─ ops layer
     ├─ Metrics / logs / traces
     ├─ Evaluation
     └─ Release workflow

Spring AI 到底是什麼，不是什麼

先把邊界講清楚。

Spring AI 是一個 AI application framework，它的核心目標不是重新發明 LLM，而是把 Spring 生態系長期強調的可組裝性、可替換性、模組化與 Boot 自動配置，帶進 AI 應用開發裡。官方文件也很明確：Spring AI 支援主流模型供應商、支援 Spring Boot starter、自動配置 ChatClient.Builder，也提供 RAG、Advisors、MCP 等整合能力。

但它不是：

• 一個 magically 幫你做好 prompt engineering 的框架
• 一個把 agent 自動做對的黑盒子
• 一個只要接上模型就能直接企業上線的解法

如果你把 Spring AI 當成「只會呼叫模型的 client library」，你會低估它；如果你把它當成「接上就能自動做好 agent workflow 的平台」，你又會高估它。

比較準確的說法是：Spring AI 提供了構建 AI 應用的工程骨架，但系統最後好不好用，取決於你如何設計資料邊界、工具邊界、驗證流程與運行治理。

為什麼很多 Spring AI 專案一開始順，後面卻會失控

這類專案常見的失控模式其實很一致。

1. 把所有事情都塞進單一 Prompt

早期 demo 常見做法是把角色設定、資料上下文、工具說明、回答格式、例外條件全部塞進 system prompt。剛開始看起來很快，但一旦需求增加：

• prompt 會越來越長
• 可測試性會越來越差
• 同一段邏輯會在多個 endpoint 重複出現
• 無法清楚知道錯誤是出在資料、模型、工具還是 prompt policy

這不是模型問題，而是應用分層失敗。

2. 只有 Chat，沒有工作流控制

很多團隊做出來的其實只是「聊天入口」，而不是「AI 工作流」。真正有商業價值的應用通常至少需要：

• 問題理解
• 上下文補強
• 文件檢索
• 工具呼叫
• 結果格式化
• 稽核與記錄

如果沒有 orchestration，系統最後只是會說話，但不可靠。

3. 把 RAG 當作萬用銀彈

一遇到 hallucination，很多團隊第一反應就是「加向量資料庫」。但問題往往不在有沒有 RAG，而在：

• 檢索切片策略是否合理
• metadata 是否足夠過濾
• 問題是否真的適合用文件檢索回答
• 工具調用與知識檢索的責任是否混在一起

RAG 解的是「模型不知道你的專有內容」，不是「任何不準都可以靠向量查詢補救」。

Spring AI 真正好用的幾個核心能力

Core Concepts

1. ChatClient：把模型呼叫變成可組裝流程

ChatClient 是 Spring AI 很重要的入口。它的價值不只是 fluent API 好看，而是它把 prompt、options、advisors、tool callbacks、同步與串流模式整合在同一套呼叫模型裡。

最基本的用法大致如下：

@Bean
ChatClient chatClient(ChatClient.Builder builder) {
    return builder.build();
}

@Service
public class AiSupportService {

    private final ChatClient chatClient;

    public AiSupportService(ChatClient chatClient) {
        this.chatClient = chatClient;
    }

    public String summarizeTicket(String ticketText) {
        return chatClient.prompt()
                .system("""
                    你是企業客服協作助理。
                    請先抽取問題摘要、影響範圍、可能根因與下一步建議。
                    """)
                .user(ticketText)
                .call()
                .content();
    }
}

這裡要注意的不是「可以呼叫模型」，而是你應該把 ChatClient 視為 orchestration entrypoint。真正成熟的系統不會讓 controller 直接拼 prompt，而是把 prompt policy、advisors、tool callbacks 和 response shaping 包進 service layer。

2. Advisors：把攔截、補強、改寫做成可組合中介層

如果只看名字，很多人會把 Advisors 理解成「附加功能」。其實它更像 AI workflow 裡的攔截鏈。

官方文件指出 Advisors API 可以在請求與回應流程中攔截、修改、增強 AI 互動，而且會依照順序形成 advisor chain。這個能力很關鍵，因為它決定你能不能把 AI 邏輯拆乾淨。

一個比較成熟的 advisor chain 通常會包含：

• request normalization
• retrieval injection
• memory enrichment
• policy enforcement
• response post-processing
• auditing context

也就是說，prompt 不必單獨承擔所有責任。

3. RAG：不是加資料庫，而是設計知識邊界

Spring AI 的 RAG 支援不是單點功能，而是一種 modular architecture。官方文件提到你可以透過 QuestionAnswerAdvisor 或更模組化的 RetrievalAugmentationAdvisor 來組裝檢索流程。

一個常見做法如下：

@Bean
ChatClient knowledgeChatClient(ChatClient.Builder builder,
                               QuestionAnswerAdvisor qaAdvisor) {
    return builder
            .defaultAdvisors(qaAdvisor)
            .build();
}

這個模式很實用，但真正難的是怎麼判斷哪些問題應該走 RAG，哪些不應該。

例如：

• 「公司請款流程怎麼走？」適合文件檢索
• 「這筆交易為什麼失敗？」通常更適合工具查詢或事件追蹤
• 「幫我綜合這個月異常案件模式」可能需要檢索 + 工具 + 多步驟分析

換句話說，RAG 是 knowledge access pattern，不是整個 AI application architecture。

4. MCP：把工具整合升級成標準協議

如果你的應用要連很多工具，Model Context Protocol 會比你自己硬寫一堆 function calling adapter 更有長期價值。Spring AI 在 MCP 生態裡投入很深，官方文件也說明了它同時支援 MCP server 與 MCP client，還提供 Boot starters、annotations 與 Spring integration。

這意味著你可以把工具系統設計得更標準化。

一個簡化版 MCP server 工具定義長這樣：

@Service
public class AccountTools {

    @McpTool(description = "查詢客戶訂閱方案")
    public SubscriptionView getSubscription(
            @McpToolParam(description = "客戶編號", required = true) String customerId) {
        return new SubscriptionView(customerId, "PRO", "ACTIVE");
    }
}

而 client 端則可以透過 ToolCallbackProvider 或 MCP client starter 來把工具接進 ChatClient。

這裡的重點不是「可以 call tool」，而是：

• 工具輸入 schema 比較清楚
• 工具整合方式比較標準
• 不同工具供應端可以逐步解耦
• agent orchestration 比較容易治理

不要只做聊天機器人，應該做 AI Workflow Gateway

如果你要做真正有價值的 Spring AI 應用，我比較建議用「AI workflow gateway」來思考，而不是「chatbot」。

例如一個內部營運助手，可能需要整合：

• FAQ / SOP 文件檢索
• 客戶狀態查詢
• 訂單與付款資訊查詢
• 審批流程觸發
• 回答內容稽核

這時比較合理的流程會像這樣：

flowchart TD
    A[User Question] --> B[ChatController]
    B --> C[ChatClient]
    C --> D[Advisor Chain]
    D --> E{Need Knowledge?}
    E -- Yes --> F[VectorStore / RAG]
    E -- No --> G{Need Tool?}
    F --> G
    G -- Yes --> H[MCP Client or Tool Callback]
    G -- No --> I[LLM Response Generation]
    H --> I
    I --> J[Response Policy / Audit]
    J --> K[Final Response]

這個架構有幾個好處：

• ChatClient 是統一入口
• RAG 和 tool calling 可以分責任
• advisor chain 可以做治理
• 稽核、記錄、評估可以後掛

這比「controller 收到字串，直接拼 prompt 回答」穩定太多。

一個更像真實世界的應用案例

假設你要做一個「B2B 客服協作助手」，目標不是直接讓模型回答所有事，而是幫人工客服縮短處理時間。

它要做的事情

• 看懂客戶問題
• 從內部文件找 SOP
• 查詢客戶當前合約或產品狀態
• 根據結果產生建議回覆草稿
• 避免回覆超出權限或憑空捏造政策

這時候怎麼分層比較合理

1. ChatClient 負責統一請求入口
2. Advisor 注入語氣規範、上下文與稽核 metadata
3. QuestionAnswerAdvisor 處理 FAQ / SOP 類檢索
4. MCP client 或 tool callbacks 處理「查詢客戶狀態」這類具體工具
5. response post-processor 做輸出格式清洗
6. audit log 記錄「用了哪些文件、調了哪些工具」

這種設計的好處是，你可以清楚區分：

• 文件回答錯，是檢索問題
• 客戶資料錯，是工具資料問題
• 語氣不對，是 prompt / advisor policy 問題
• 回答結構不對，是 response shaping 問題

沒有這種分層，系統出了問題時，你幾乎無法 debug。

What Usually Goes Wrong

1. 把 Tool Calling 和 RAG 混成一鍋

很多人會把所有上下文都想成「資料來源」，但文件檢索和交易查詢根本不是同一種責任。

• 文件檢索是提供語意背景
• 工具調用是查詢即時狀態或執行動作

這兩者如果混在一起，模型很容易做出不穩定決策。

2. 沒有做回答治理

只要進到正式環境，回答治理一定是需求，不是加分項。至少要考慮：

• 哪些問題不能直接回答
• 哪些欄位不能在回覆中暴露
• 哪些回答必須加上來源或依據
• 哪些操作需要人工確認

如果沒有這層治理，Spring AI 應用很容易變成公司內部的高風險輸出端點。

3. 沒有把評估當產品能力

很多團隊只有 demo 驗證，沒有持續評估。這是錯的。

真正的 AI 應用要評估：

• 命中正確知識的比例
• 工具選擇是否合理
• hallucination 發生條件
• 回答是否符合格式與政策
• 不同模型版本替換後的回歸風險

Spring AI 幫你把流程接起來，但你還是要自己把 evaluation 變成正式能力。

Advantages of Spring AI 應用架構化設計

• 比直接 SDK 更容易維護： ChatClient、Advisors、RAG、MCP 都有明確責任邊界。
• 更符合 Spring Boot 團隊習慣： starter、自動配置、bean 組裝對 Java 團隊很友善。
• 更適合逐步演進： 一開始先做 Chat + RAG，之後再接 tools 或 MCP，不需要整套重寫。
• 比較容易治理： 可以把安全、稽核、政策、測試放回工程流程裡。

Use Cases

Suitable Scenarios

• 內部知識助理與 SOP 查詢
• 客服協作與工單摘要
• 需要文件檢索加工具查詢的企業入口
• 想把 Java 既有系統逐步接入 AI 能力的 Spring Boot 團隊

Unsuitable Scenarios

1. 只想做一次性 PoC： 如果只是快速驗證一句 prompt，Spring AI 可能顯得太重。
2. 把 AI 當成純前端小工具： 若核心邏輯不在 Java backend，Spring AI 不一定是最佳切入點。
3. 沒有治理需求卻硬上複雜架構： 小問題不需要一開始就把 RAG、MCP、Advisors 全部堆滿。

Implementing a Production-Minded Spring AI Application

1. 先決定你的「AI 責任邊界」

先回答三個問題：

• 模型負責生成什麼？
• 檢索系統負責提供什麼？
• 工具系統負責查什麼或做什麼？

這一步比選模型還重要。

2. 用 ChatClient 當 orchestration 入口

不要把 prompt 拼裝散落在 controller、service、scheduler 各處。把 ChatClient 聚焦成單一協調入口，這樣之後才有辦法插入 advisors、tools、memory 與 policy。

3. 用 Advisors 管理中介層能力

把這些需求優先考慮做成 advisor：

• retrieval injection
• memory injection
• response policy
• audit context
• output normalization

這比把所有邏輯塞進 prompt 更可維護。

4. 把 MCP 視為工具整合升級路線

如果你只有一兩個內部方法，直接 tool callback 就夠。但只要工具整合開始擴張，MCP 會比自製協議更有未來性，因為它讓工具宣告、schema、client/server 邊界更一致。

5. 把驗證和觀測能力當成第一天需求

至少要補上：

• prompt / response logging
• tool invocation logging
• retrieval evidence logging
• failure replay capability
• regression evaluation set

否則你無法有把握地升級模型、調整 prompt 或更換檢索策略。

Validation and Governance

• 回答正確性驗證： 針對常見問題建立黃金測資，驗證回答是否命中正確資料來源。
• 工具選擇驗證： 驗證模型在什麼情況應該查文件，什麼情況應該查工具。
• 政策驗證： 驗證敏感資訊、越權資訊、未確認動作不會直接輸出。
• 回歸驗證： 每次升級模型、換 embedding、換 vector store 或改 advisor chain，都要做回歸測試。

Build and Run

依官方文件，Spring AI 支援 Spring Boot 3.4.x 和 3.5.x，且 1.0.0 之後的版本可直接使用 Maven Central。

一個最小化起步流程大致如下：

curl https://start.spring.io/starter.zip \
  -d dependencies=web \
  -d bootVersion=3.5.0 \
  -o spring-ai-demo.zip

接著加入對應的 Spring AI starter，例如 chat model、vector store、或 MCP client/server starter。

Verify the Result

./mvnw test

你真正要驗證的不是「有沒有回字」，而是：

• 是否能穩定命中正確知識來源
• 是否能正確選擇要不要調用工具
• 回答是否符合格式與權限政策
• 模型切換後行為是否仍可接受

References

• https://spring.io/projects/spring-ai
• https://docs.spring.io/spring-ai/reference/getting-started.html
• https://docs.spring.io/spring-ai/reference/api/chatclient.html
• https://docs.spring.io/spring-ai/reference/api/advisors.html
• https://docs.spring.io/spring-ai/reference/api/retrieval-augmented-generation.html
• https://docs.spring.io/spring-ai/reference/guides/getting-started-mcp.html
• https://docs.spring.io/spring-ai/reference/api/mcp/mcp-helpers.html

Takeaway

Spring AI 真正值得用的地方，不是它幫你少寫幾行 API call，而是它讓 Java 團隊可以用比較熟悉的 Spring 方式，把 AI 能力納入正式應用架構中。當你把 ChatClient 當 orchestration 入口、把 Advisors 當 workflow middleware、把 RAG 與 MCP 清楚分責任、再把評估與治理補齊，Spring AI 才會從「會聊天的 demo」升級成「可進入企業流程的 AI application」。