先分清楚基礎設施、工具型 agent 與 planner 型 agent

今天要解決的問題

• Spring AI 是低層 LLM 基礎設施
• Agent Utils 偏探索式工具迴圈
• Embabel 偏可解釋流程規劃

內容

剛接觸 JVM 上的 agentic AI，最先撞上的困惑通常不是技術，而是命名：Spring AI、spring-ai-agent-utils、Embabel，名字長得像，都掛在 Spring 生態下，官網也都說自己能做 AI agent。到底該用哪一個？

先講結論：這三者不是競爭關係，而是同一個生態系的不同層次與路線。agent-utils 與 Embabel 都站在 Spring AI 之上。要分辨它們，最有效的一把尺是問：誰決定下一步？

Spring AI 解決的是低層問題：讓 Spring 應用能用 ChatClient、模型 provider、tool calling、VectorStore 與 MCP。它很適合單次 LLM 呼叫，或由開發者明確寫死順序的 pipeline。這裡決定下一步的是開發者本人——你寫什麼順序，它就跑什麼順序。

spring-ai-agent-utils 走的是工具型 agent 路線，讓 LLM 在迴圈中選工具、讀檔案、跑 shell、搜尋資料。這種模式適合探索式任務，例如 coding assistant 或資料分析，因為目標可能開放，路徑也可能需要模型臨場判斷。這裡決定下一步的是 LLM 自己。

Embabel 不同，它關心的是『流程本身』。開發者宣告 action 的輸入輸出、條件與 goal，planner 根據目前 world state 推導路徑。這讓企業流程可以被測試、被稽核、被解釋，而不是每一次都由 LLM 即興決定下一步。Rod Johnson 形容它「更像 server 而不只是 framework」——因為它管的不只是怎麼呼叫模型，還包括流程規劃與 process 管理。

觀念圖解

三種角色最容易混在一起，所以先用「誰決定下一步」來分。

Spring AI 像水電管線，負責把模型、工具與向量資料庫接進 Spring。spring-ai-agent-utils 像探索型助理，讓 LLM 自己在迴圈裡選工具。Embabel 則像流程規劃器，開發者先宣告 action、條件與 goal，再由 planner 推導下一步。

如果你的任務是探索式的，讓模型多試幾步很合理；但如果流程牽涉金額、個資、審核與對外通知，就需要 Embabel 這種比較可解釋、可測試的方式。

三者對照表

把上面的分法攤開成表，選型時可以直接對著看：

判斷準則其實很單純：探索式任務讓 LLM 自主選工具很合理；流程一旦涉及生產系統、權限與審核，planner 路線才能讓每一步可解釋、可測試。

兩個常被問到的問題

Embabel 會取代 Spring AI 嗎？ 不會，而且方向剛好相反。Embabel 建構在 Spring AI 之上——模型連線、tool calling、MCP 協定都沿用 Spring AI，Embabel 加上去的是規劃與 agent process 管理。你不會因為用了 Embabel 就用不到 Spring AI 的東西，反而是整套繼承下來。

只想呼叫一次 LLM 也要用 Embabel 嗎？ 不用。單次呼叫用 Spring AI 就夠了，多包一層只是增加複雜度。Embabel 的價值要等到流程出現多步驟、條件分支、需要測試與審核時才顯現——如果你的需求只是「把這段文字摘要一下」，那它是殺雞用牛刀。

今日實作 / 思考任務

用表格比較一個你熟悉的流程：如果用 Spring AI、agent-utils、Embabel 各會怎麼做，誰決定下一步？

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