Embabel 的起點，為什麼要把 AI 關在可控邊界內

今天要解決的問題

• 這 30 天到底要做什麼
• 為什麼企業系統不能把流程全交給 AI 自由發揮
• 後端 Embabel 與前端 json-render 會怎麼接在一起

內容

這個系列會用 30 天，把兩件事串成一個完整專案：後端用 Embabel 管理 Agent 流程，前端用 json-render / embabel-generative-ui 把 AI 產生的畫面規格安全渲染出來。最後目標是一個自然語言生成 Dashboard 的前後端應用。

第一天先不急著寫程式。因為真正的重點不是「能不能呼叫模型」，而是「模型應該被放在哪裡」。企業系統通常已經有資料庫、權限、交易邊界、審核流程與既有服務。AI 可以幫忙摘要、判斷、產生草稿，但不應該自由決定整條業務流程，也不應該直接產生任意前端程式碼。

所以這個系列會一直圍繞一個核心觀念：讓 AI 有能力，但要把能力放在可控邊界內。後端要能說清楚每一步為什麼發生，前端要能限制 AI 只能使用允許的元件，整個系統要能測試、追蹤與驗收。

Embabel 是什麼

先用一句話說完：Embabel（唸作 Em-BAY-bel）是一個跑在 JVM 上的 AI Agent 框架，讓你用熟悉的 Java / Spring 寫法，把 AI 能力接進既有系統。

那它是誰做的？主導者是 Rod Johnson，就是當年寫出 Spring Framework 的那位。對 Java 生態來說這個名字本身就是一種訊號：Spring 當初能成為企業 Java 的預設選擇，靠的正是「框架應該遷就既有程式碼，而不是要求你為框架重寫一切」這個立場，而這也正是 Embabel 面對 AI 時採取的態度。他公開形容 Embabel 是自己創立 Spring 之後最重要的專案。

它也不是一個人的業餘作品。官方文件的署名團隊除了 Rod Johnson，還有 Alex Hein-Heifetz、Dr. Igor Dayen、Arjen Poutsma 與 Jasper Blues，背後的法人是 Embabel Pty Ltd，程式碼以 Apache-2.0 授權開源在 GitHub 的 embabel/embabel-agent。換句話說，這是一個有公司持續投入、但你可以自由使用與檢視的開源專案。

框架本身以 Kotlin 寫成——但這件事對 Java 開發者幾乎無感。Rod Johnson 在 DevNexus 2026 的實作演講中特別強調：官方文件的每一個範例都同時提供 Java 與 Kotlin 兩種版本，而從 Java 這一側寫下去，「你不會看到任何一個 KT import」。至於底層，Embabel 建構在 Spring AI 之上，不重造模型呼叫與工具串接的輪子，而是在那之上多加一層規劃與流程治理。

它跟「接一個 LLM 做聊天機器人」最大的差別，在於誰決定下一步。常見的做法是把工具清單丟給模型，讓模型自己在迴圈裡邊想邊決定下一步做什麼。Embabel 走另一條路：開發者先宣告有哪些 action（步驟）、每個 action 需要什麼輸入、會產出什麼結果，以及什麼狀態才算達成目標；接著交給一個不是 LLM 的規劃演算法去推導該走的路徑。這套方法叫 GOAP（Goal-Oriented Action Planning，目標導向行動規劃），原本來自遊戲 AI。

這個設計換來三件對企業系統很重要的事。可解釋：流程為什麼走這條路，是條件推導出來的結果，不是模型當下的臨場判斷。可測試：純運算的 action 就是一般 Java 方法，可以直接寫單元測試。強型別：action 之間靠 Java record 與方法簽章傳遞資料，而不是一個什麼都能塞的 Map<String, Object>。

那 LLM 去哪了？它還在，只是位置變了。LLM 在單一 action 內部做它擅長的事：摘要、分類、判斷、產生草稿。至於這個 action 該不該執行、下一步走哪裡、金額怎麼算、優惠能不能發，仍然由程式與規則決定。這就是前面那句「讓 AI 有能力，但把能力放在可控邊界內」在後端的具體長相。

基本案例

我們會用一個旅遊公司的客服場景貫穿前半段內容。客服人員打開客戶帳戶時，希望系統能整理近一年旅遊活動，標出高消費客戶或常旅客，再產生一份個人化服務方案。

這張圖代表我們要達成的基本目標：讓客服更快理解客戶，而不是讓 AI 取代整個客服系統。AI 可以幫忙整理摘要與產生建議，但金額、次數、會員資格與優惠規則仍要回到既有系統計算。

這張流程圖可以先用最簡單的方式理解：資料先由系統讀取，必要數字由既有工具計算，AI 負責整理與草擬，最後仍要經過規則或人工審核，再回寫 CRM。這就是「AI 在邊界內工作」的意思。

後面 30 天大綱

Day 02-04 會先建立心智模型：為什麼 JVM / Spring 團隊需要 Embabel、Spring AI / agent-utils / Embabel 差在哪裡，以及為什麼不能只靠 LLM 自主迴圈處理企業流程。

Day 05-10 會進入 Embabel 的核心觀念：把工作拆成 action、用 goal 表示成功狀態、用 world state 與條件描述流程，接著理解成本排序、Blackboard、AgentProcess 與 replanning。

Day 11-18 會把觀念拉回實作與維運：版本相容、模型設定、action 條件、工具分工、Agentic RAG、ActionAudit、測試與 guardrails。這一段會一直強調：該由 Java 算的不要交給 LLM 猜，該被記錄的流程不要只看最後答案。

Day 19-20 會補上進階流程：等待人工、狀態設計、多條路徑、不同 planner 與多 agent 協作。這些不是第一個專案一開始就需要，但知道它們存在，後面擴充時比較不會走偏。

Day 21-25 會切到前端 json-render / embabel-generative-ui：讓 AI 不只回文字，而是輸出受限制的 UI 規格；前端透過元件白名單、catalog、SSE 與漸進渲染，把畫面安全地長出來。

Day 26-30 會把後端與前端接成完整專案：從使用者自然語言需求開始，後端規劃資料與 dashboard spec，前端一路顯示進度、處理半截 JSON，最後完成一個可驗收的自然語言生成 Dashboard。

今日實作 / 思考任務

先選一個你熟悉的業務流程，寫下三件事：

• 哪些部分可以讓 AI 幫忙整理、判斷或草擬
• 哪些部分一定要由既有系統或程式規則負責
• 哪些輸出在送出前必須被審核或記錄

這張清單會在後面幾天反覆用到。

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