Embabel 的問題意識：不要為了 AI 重寫既有系統

今天要解決的問題

• JVM 是企業系統主場
• LLM 應該進入工程邊界
• Embabel 建構在 Spring 生態上

內容

官方文件裡有一個很傳神的比喻：把 AI 導入既有系統，不應該像是「為了裝一台新機器，把整座工廠拆掉重建」。這句話值得先記住，因為它幾乎定義了 Embabel 的問題意識。

很多 Agentic AI 展示都像是從空白專案開始：丟一個 prompt、接幾個工具、讓模型自己想下一步。這類 demo 看起來很順，因為它沒有歷史包袱——沒有既有的權限模型要遵守，沒有跑了十年的交易邏輯不能動，沒有稽核單位會問「這筆折扣是誰核准的」。

但企業 Java 團隊面對的是另一種現實：既有系統已經有 Domain Model、Spring service、資料庫、權限、交易邊界與測試流程。這些東西不是技術債，而是多年累積下來的業務正確性。Embabel 的切入點就是這個落差。它不是要你把 CRM、ERP、訂單與客服流程搬去 Python agent sandbox，而是讓 AI 能被嵌入 JVM 既有工程邊界。LLM 可以做摘要、分類、草稿、判斷，但流程選擇、資料邊界、工具暴露與審核點仍由工程系統管理。

觀念圖解

核心觀念不是「Java 也能呼叫 LLM」，而是「LLM 應該被放回既有系統的邊界內」。

可以把 LLM 想成一位很會整理文字的同事，但不是流程總指揮。它可以在某個 action 裡摘要、分類、產生草稿；至於下一步該不該執行、資料能不能用、優惠能不能發，仍由 Java 程式、資料庫、權限與審核規則決定。

所以 Embabel 的價值，是讓 Spring service、domain object、工具與模型在同一個 JVM 工程邊界內協作。企業系統不用為了 AI 整個重寫，也不用把關鍵流程交給模型自由發揮。

那為什麼不能只靠 LLM 加工具就好

這是最該被誠實面對的質疑：模型每天都在變強，MCP 又讓工具接得越來越容易，那再多疊一層框架，是不是只是增加複雜度？

官方文件正面回答了這個問題。以下幾點是對企業 Java 團隊最有感的：

• 可解釋：事情做完之後，你要能回答「為什麼當初選了這條路」。如果每一步都是模型當下決定的，這個問題就只剩下「因為模型這樣想」。
• 工具的可發現性：工具不是越多越好。當可用工具堆到幾十個，模型反而容易選錯或選不定。誰在什麼時機該看到哪些工具，本身就是需要被設計的事。
• 混用模型的能力：不是每一步都需要最貴的模型。分類與格式化可以交給小模型甚至本地模型，這同時關係到成本與隱私——但前提是流程被切得夠細，才有地方可以換。
• guardrail 的插入點：規則要能放在流程的任意一步，而不是全部塞進一段 prompt 裡祈禱模型照做。
• 對敏感既有系統的安全整合：文件講得很直白——就算是最好的 LLM，給它資料庫寫入權限都是危險的。

把這幾點合起來看，會得到一個更清楚的區分：一個系統裡同時存在「程式的自主性」與「模型的自主性」。框架要做的，是決定哪些決策屬於前者、哪些屬於後者，而不是把兩者混成一鍋。

這也是本系列的第一個立場：AI agent 不只是模型能力問題，而是軟體架構問題。當流程牽涉金額、個資、審核與對外發送，能不能說清楚每一步為什麼發生，比能不能讓模型看起來很聰明更重要。

今日實作 / 思考任務

列出你目前系統中 3 個可能導入 AI 的流程，標註哪些部分適合 LLM，哪些必須由既有 Java 程式或資料庫負責。

如果你也想進一步學習如何透過 AI 開發 Spring Framework 應用，讓 AI 協助理解框架、撰寫程式、除錯與驗>證，歡迎到 Hahow 看凱文大叔的最新課程【駕馭 AI 的全端實戰養成班：從零打造企業級智慧應用系統】。一起>學習如何駕馭 AI，提升 Spring 應用的開發效率與品質。