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

今天要解決的問題

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

內容

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

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

所以這個系列會一直圍繞一個核心觀念：讓 AI 有能力，但要把能力放在可控邊界內。後端要能說清楚每一步為什麼發生，前端要能限制 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 應用的開發效率與品質。