面試官要你把 LLM、RAG、Agent、MCP 串成一句話：卡住的往往不是知識點，是全景圖

11月4日，掘金出現一篇約一萬五千字的長文，作者以「面試官高頻題」為切入：把 LLM、RAG、Agent、MCP、向量、餘弦相似度串起來講清楚。作者的觀察很直接，多數 Java 工程師單一概念都背得出來，一旦被要求連成完整流程，當場就斷線。文章選擇用一條真實的電商客服請求當主線，從「我的訂單為什麼還沒發貨」一路走到最終的流式回覆，把每個環節的技術選擇與踩過的坑攤開來講。

這個現象值得從「為什麼會斷線」往深一層看。斷線的原因通常不是沒學過，而是每個名詞是在不同時間、不同文章裡零散撿回來的，彼此之間沒有先後與依賴關係。作者給出的解法是先建立一個統一的比喻體系：LLM 是發動機，Embedding 是語言的座標系，餘弦相似度是尺子，向量庫是圖書館的索引卡，RAG 是外掛資料室，Tool 是手腳，MCP 是 USB-C 插座，Skills 是崗位手冊，Agent 則是那個會自己拆任務、做完還會覆盤的數字員工。

把這串比喻放進流程裡就通了。使用者在電商平臺問一句「訂單為什麼還沒發貨」，系統先把問題轉成向量，用餘弦相似度在向量庫裡量出方向最接近的幾筆資料，這是 RAG 在做事，瓶頸多半在檢索而非生成。接著 Agent 拆解任務，決定要不要查訂單系統，而查系統這個動作透過 MCP 這個統一插座去接工具，最後 LLM 把結果組織成回覆流式輸出。每個名詞在流程裡有明確位置，這正是面試官想聽的「串起來」。

Java 工程師的位置：造整車，不是造發動機

文章裡有個說法值得單獨拿出來談：企業招 Java 工程師做 AI 應用，要的從來不是訓練模型的能力，而是「把不確定的模型能力，裝進確定的工程系統裡」。發動機是模型廠商的事，Java 工程師的價值在造整車、修高速、建加油站，對應到技術上就是 Spring AI 或 LangChain4j 調 API、SSE 流式輸出、把 float 向量存進 pgvector 或 Milvus、寫帶防護的 ReAct 迴圈。

這個定位與先前一篇老工程師的說法互相印證：名詞換得快，底子沒換，MCP 與 Skills 改變的主要是交付方式，工程基本功仍是同一套。文中列出的生產級細節也佐證這點，例如向量內積用 float 儲存但用 double 累加防止精度污染、零向量先短路避免 NaN、用 JDK Vector API 做 SIMD 加速餘弦相似度計算。這些全是傳統後端的看家本領，只是場景換到了語意檢索。

幾個反直覺的工程結論

文中整理了幾個與直覺相悖、但在落地時很關鍵的判斷。

RAG 的瓶頸在檢索不在生成。回覆品質差時，多數人的第一反應是換模型，實際問題常出在分塊策略與召回品質。

Skills 不要全塞進 System Prompt，要用漸進式揭露。一次給太多指令，模型反而抓不到重點。

工具集要收斂。從 28 個工具收到 5 至 8 個，模型的選擇準確度會明顯提升，選項太多對模型和對人一樣都是負擔。

MCP 的 HTTP 端點預設無鑑權。裸暴露在網路上等同裸奔，這是後端工程師最能發揮把關價值的地方。

所以呢：給正在準備面試的人

這篇文章的價值不在於它給了答案，而在於它示範了「串講」的正確結構：先給全景與依賴關係，再依請求流程走一遍，最後落到具體的工程取捨。面試官問這題，驗證的正是你腦中有沒有這張圖。

對照站內先前對 Agent 外層馬具程式碼職責的分析可以發現同一個趨勢：企業篩選 AI 方向的後端工程師時，考的越來越少是模型原理，越來越多是「你知不知道每層各自該做什麼、邊界在哪」。想轉方向的人與其再收集十篇入門文，不如挑一條自己熟悉的業務請求，親手把向量、檢索、工具呼叫、流式輸出走通一遍。斷線與不斷線的差距，往往就在有沒有走過這一遭。