對於許多剛接觸 AI Agent 開發的工程師來說，最直覺的作法通常是寫一連串的 Prompt（提示詞），然後定義一些 Tool（工具函數），讓 LLM 決定何時呼叫。但隨著業務邏輯變得複雜，這種「線性」或「手動定義路徑」的方式會導致程式碼變得難以維護，且面對意外錯誤時缺乏彈性。
最近正式發布 1.0 版本的 Embabel 框架，嘗試為 Java 與 Kotlin 開發者提供一種不同的思維模型。它不再要求開發者去「畫流程圖」，而是讓開發者定義「目標」與「能力」，由框架在執行時動態決定如何達成目標。
從底層基礎到高層抽象的定位
要理解 Embabel，首先要釐清它與 Spring AI 的關係。很多初學者會混淆這兩者，但其實它們處在不同的層級。
Spring AI 扮演的是底層基礎設施的角色，負責處理與 LLM 的連線、管理 Embedding（將文字轉為向量的過程）以及基本的工具調用。如果用 Web 開發來類比，Spring AI 就像是 Servlet API，它提供了最基本的通訊能力，但如果你直接用它開發，你會發現自己得重複處理大量瑣碎的參數解析與流程控制。
而 Embabel 則定位於 Spring AI 之上，類似於 Spring MVC 之於 Servlet。它提供了一套高階的宣告式模型，讓開發者可以用強型別的物件來定義 Agent 的目標與動作，而不需要手動編寫複雜的 Prompt 序列。
引入遊戲 AI 的 GOAP 規劃機制
Embabel 最核心的技術特點在於引入了 GOAP（Goal-Oriented Action Planning，目標導向動作規劃）。這原本是電子遊戲 AI 用來讓 NPC 表現得更聰明的技術。
在傳統的 Agent 框架（例如 LangGraph）中，開發者通常需要定義一個有向圖（Directed Graph），明確規定從節點 A 執行完後，在什麼條件下跳到節點 B。這種方式雖然可控，但缺乏靈活性。如果執行過程中發生預料之外的錯誤，或者環境狀態改變，Agent 往往會卡死或崩潰，除非開發者預先寫好了所有可能的例外路徑。
GOAP 的運作邏輯完全不同。開發者只需要定義： 目標（Goal）：最終想要達成的狀態。 動作（Action）：每個動作包含前置條件（Preconditions）與執行後的影響（Effects）。
當 Agent 啟動時，規劃器會自動搜尋目前狀態與目標狀態之間的路徑，動態組合出一連串的動作序列。如果執行中途某個工具呼叫失敗或獲取了新資訊，規劃器會立即重新評估，尋找另一條可行的路徑來達成目標，而不需要開發者預先定義所有的分支路徑。
靈活的模型路由與資源管理
在實務開發中，我們不會對所有任務都使用最強（也最貴）的模型。Embabel 繼承了 Spring AI 的多模型支持，並在此之上實現了靈活的路由機制。
開發者可以為特定的動作指定特定的模型，或者定義角色別名。例如，將需要強邏輯推理的步驟分配給 GPT-4 或 Claude 3.5（定義為 best 模型），而將簡單的格式轉換或摘要任務分配給本地運行的 Llama 3 或 DeepSeek（定義為 cheapest 模型）。這種設計讓團隊能在成本、隱私與效能之間取得平衡。
與其他 Agent 框架的對比
目前 Java 生態系中主要有三種不同的 Agent 構建思路：
第一種是 Embabel 的型別驅動模型，強調透過宣告目標與動作，利用規劃器在執行時決定路徑。
第二種是以 LangGraph 為代表的圖導向模型，強調對執行流程的精確控制，適合路徑相對固定且對穩定性要求極高的業務場景。
第三種是以 Akka 為代表的基礎設施驅動模型。Akka 利用 Actor Model（參與者模型）來解決分佈式系統的問題，將 Agent 的狀態與對話紀錄封裝在 Actor 中，使其具備強大的容錯能力與跨機器擴展能力。如果說 Embabel 解決的是怎麼編寫邏輯，Akka 解決的就是如何讓邏輯在分佈式環境下穩定運行。
總結與實務建議
對於已經在使用 Spring Boot 的 Java 團隊來說，Embabel 1.0 提供了一個從指令編排轉向目標驅動的機會。如果你發現目前的 AI 流程圖變得過於龐大且難以維護，或者 Agent 經常因為微小的環境變化而失效，那麼嘗試使用 GOAP 這種動態規劃機制將會是一個有效的解決方案。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。