後端轉AI應用開發的12個名詞：掘金長文以分層架構梳理RAG、Tool Calling與MCP的邊界

掘金作者T_Wizard於2026年11月5日刊出長文，標題為「後端轉 AI 應用開發，我先把這 12 個名詞理清了」。文章以會Spring Boot、想進入AI應用開發的後端工程師為讀者設定，主張這類新手的障礙不在技術本身，而在概念分層未釐清：同一件事從部署位置、接觸途徑與程式寫法三個角度各有命名，混著記容易打結。

文章主張：先架構，再能力塊，最後落地程式碼

作者提出任何AI應用的骨架可分為五層，並歸納四個記憶要點。第一，Advisor的角色等同AOP：前置Advisor在請求進入模型前處理敏感詞過濾、拼接Prompt、注入檢索結果，後置Advisor在模型回應後處理記憶落庫、日誌與去識別化，多個Advisor以@Order控制順序。作者稱此為Spring AI相較其他框架最有價值的抽象，橫切邏輯都能掛在Advisor上，業務程式碼不必修改。

第二，四個中間能力塊的觸發方式並不相同。文中對照如下：Tools由模型自行決定是否呼叫，屬被動觸發，程式端以.tools()設定；MCP同樣由模型決定，但對象是遠端程序，需設定MCP Client；RAG由框架主動塞入Prompt，掛QuestionAnswerAdvisor；Memory由框架自動注入歷史，掛MessageChatMemoryAdvisor。作者指出，搞混四者會出現「明明設了知識庫，模型卻不查」的情況，原因在於把被動觸發誤認為自動執行。

一次提問的九步鏈路與工具呼叫來回

文章以時序圖描述一次提問的完整流程：使用者提問後，服務端先經前置Advisor、取記憶、執行RAG檢索，再帶著tools定義請求大模型；模型若返回tool_calls，Spring AI會以反射方式呼叫對應的@Tool方法，將結果回灌後再請求模型一次，最終以SSE串流輸出答案。

作者特別說明，這就是日誌中出現兩輪Request/Response的原因：工具呼叫並非單次請求，而是「模型到工具再回到模型」的往返，屬正常行為而非錯誤。

RAG的兩套說法實為同一件事

針對RAG教學常見的混亂，作者指出業務文章常畫流程圖，Spring AI官方文件畫ETL圖，看似兩套體系，實為同一件事的兩種命名。文中對照：Reader離線讀取資料源產出Document；Transformer離線執行切分與清洗成chunks；Writer離線向量化後寫入向量庫；VectorStore為線上線下共用的向量庫（文中以PGvector為例）；Retriever在線上以問題檢索chunks，即業務說法的相似度搜尋加TopK。

也就是說，ETL三階段屬離線流程，每次請求執行的是檢索階段。此一「離線與線上」的劃分，正是文首自測題中「RAG的ETL與檢索哪個離線跑」的答案。

外部依賴與安全紅線

文末列出外部依賴清單，包含向量庫PGvector、模型API或本地Ollama、用於記憶持久化與生成PDF的檔案系統，以及終端機。作者將終端權限單獨標注為安全紅線，理由是把終端交給模型等於賦予其執行命令的能力，並預告在MCP章節會反覆回到此議題。

本臺查核邊界

依據掘金頁面資訊，該文刊於2026年11月5日，閱讀數為34次，全文約12分鐘閱讀長度。文中有關Spring AI的類別與方法名稱（QuestionAnswerAdvisor、MessageChatMemoryAdvisor、@Tool、@Order等）屬作者的技術整理，本臺未實測程式碼，技術細節以Spring AI官方文件為準。文章其餘章節（含Tool Calling與MCP的差異論述及五個實戰踩坑）在本次抓取的來源內容中未完整呈現，相關細節暫無法核實。

與本站先前整理的Skill、MCP、Workflow等功能邊界釐清一文對照，兩篇皆以實際開發任務劃分AI編程概念的使用時機；而MCP治理與安全議題，亦可參考開發者開源MCP治理網關r2r-jev的分歧處理方案。