很多人第一次接觸 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

Continue Reading