2026 年業界主流的 agent 開發模式叫 Loop Engineering（迴圈工程）。開發者設計一個「感知 → 推理 → 行動 → 觀察」的迴圈，讓 LLM 在其中自主選工具並迭代，直到完成目標或觸發斷路器。Claude Code、LangGraph、CrewAI 都以此為核心架構——如果你最近讀到的 agent 教學九成都長這樣，那是因為它確實是當前的主流。
這套做法的思想源頭是 ReAct（Reason + Act），也就是讓模型在「思考下一步該做什麼」與「實際呼叫工具去做」之間交替前進，而它又建立在 Chain of Thought 推理之上。今天多數模型已經內建推理，不必再靠 prompt 硬湊出這個迴圈，但骨架仍然是同一套。
Loop Engineering 的彈性很高，代價是需要一整組防護：MAX_LOOP 上限、token 預算、工具白名單、錯誤保護。因為沒有人能事先保證這個迴圈會在第幾輪停下來——它可能三步就完成，也可能在兩個工具之間來回打轉二十次。
Embabel 走的是另一條路：GOAP Planning。流程被拆成 action、preconditions、postconditions 與 goal，由傳統演算法 A* 依條件搜尋能抵達目標的路徑，每執行一步後重新規劃。Planner 不猜下一步，而是算出下一步。這裡的關鍵設計是：action 內部仍然可以用 LLM，但 action 之間的路徑交給演算法。
Loop Engineering 和 Embabel 最大差別，是「下一步」由誰決定。
Loop Engineering 像把任務交給一位聰明助理：它觀察、推理、選工具、再觀察，直到完成或撞到限制。Embabel 則像先把地圖、交通規則與目的地定義好，再由 planner 找路。Rod Johnson 自己的比喻更精簡：Loop Engineering 像讓一個聰明人自由發揮，Embabel 像給這個人一張地圖和交通規則。
這不是誰完全取代誰。探索式任務適合 loop；企業流程適合 planner。Embabel 仍然可以在單一步驟中使用 LLM，只是不讓 LLM 自己決定整條流程。
| 面向 | Loop Engineering | Embabel（GOAP 規劃） |
|---|---|---|
| 核心機制 | LLM 在迴圈中反覆推理 + 選工具（ReAct） | 非 LLM 的 A* 演算法依型別條件搜尋路徑 |
| 誰決定下一步 | LLM 自主判斷（涌現行為） | Planner 依 preconditions 推導（確定性行為） |
| 流程定義方式 | 寫迴圈邏輯、設定斷路器 | 定義 @Action 簽章與 @AchievesGoal，planner 自動組合 |
| 可解釋性 | 低：每次迭代的選擇可能不同 | 高：每步都能回答「為什麼選這個 action」 |
| 錯誤恢復 | 靠 LLM 自我修正（重試 / 換工具） | Planner 自動 replanning，依剩餘條件重新搜尋 |
| 無窮迴圈風險 | 需要開發者設斷路器防 runaway | 條件不滿足時停在可解釋的失敗點 |
| 擴展性 | 加工具 = 加入迴圈的候選清單 | 加 @Action = planner 自動發現新路徑 |
| 測試 | 難以斷言路徑 | action 可單元測試、plan 可斷言 |
| 代表框架 | Claude Code、LangGraph、CrewAI | Embabel |
因此兩者不是誰全面取代誰，而是適用情境不同。探索式工作可以讓模型多試；生產流程、合規流程、金額計算與審核工作，則更適合 GOAP 這種可解釋、可重跑、可測試的規劃方式。
有一個實務上的判準很好用：當這件事出錯時，你需要向誰交代？ 如果答案是「只有我自己，重跑一次就好」，那 loop 的彈性是淨賺。如果答案裡出現了主管、稽核、客戶或主管機關，那你遲早會被要求說明「為什麼當時走了這條路」——這時候「因為模型這樣判斷」不會是個能過關的答案。
挑一個容易出錯的 agent loop，改寫成 GOAP 的 action 表：每步需要什麼輸入？產生什麼輸出？失敗時停在哪裡？
如果你也想進一步學習如何透過 AI 開發 Spring Framework 應用，讓 AI 協助理解框架、撰寫程式、除錯與驗>證，歡迎到 Hahow 看凱文大叔的最新課程【駕馭 AI 的全端實戰養成班：從零打造企業級智慧應用系統】。一起>學習如何駕馭 AI，提升 Spring 應用的開發效率與品質。
課程連結
iThome鐵人賽
看影片追技術