Agent 的記憶不是字串 Map，而是可推導的物件狀態

今天要解決的問題

• Blackboard 保存 action 產物
• 方法參數是 precondition
• 回傳型別是 postcondition

觀念圖解

Blackboard 可以想成「這次任務的工作桌」，每個 action 做完都把產物放上去。

重點是它不是亂塞資料的 Map。當 action 回傳 ActivitySummary，Blackboard 就多了一個明確型別的物件；下一個需要 ActivitySummary 的 action 才會被視為可執行。

這讓流程有了可推導的記憶：不是靠 prompt 文字說「請記得上一段摘要」，而是由 Java 型別與方法簽章把資料邊界說清楚。

在 Embabel 裡，action 之間不是用魔法字串互傳資料，而是透過 Blackboard 保存物件。當某個 action 回傳 ActivitySummary，Blackboard 就多了一個 ActivitySummary；下一個需要 ActivitySummary 參數的 action 才有機會被 planner 選中。

這種 type-driven binding 是 JVM 生態的優勢。Java record、class 與方法簽章不只是程式碼，也成為 agent planning 的資料邊界。你不需要在 prompt 裡描述『下一步要拿上一步的摘要』，因為方法簽章已經說清楚了。

設計時要避免把所有東西塞進 Map<String,Object>。那會讓 planner 看不到真正條件，也讓測試失去型別資訊。好的 Embabel agent 應該把重要中間結果設計成明確的 domain record。

程式碼補充

這一段把焦點放在 Blackboard 與型別流動，cost / @Cost 則對應 action 的選路概念。

從 Blackboard 角度來看，動態成本之所以能成立，是因為 planner 可以讀到目前任務狀態。也就是說，成本不是憑空計算，而是根據 blackboard 上已經存在的資料，決定某個 action 現在適不適合走。

只看型別流動就夠了

@Action
TravellerActivity fetchActivity(CustomerQuery query) { ... }

@Action
ActivitySummary summarize(TravellerActivity activity) { ... }

這裡最重要的不是方法內容，而是 fetchActivity(...) 回傳的 TravellerActivity 會進 Blackboard，下一步 summarize(...) 因為剛好需要同型別，所以 planner 才看得懂這兩步能接起來。

今日實作 / 思考任務

把 CustomerQuery、TravellerActivity、ActivitySummary、OfferDraft、ReviewedOffer 寫成資料邊界清單，標註它們由哪個 action 產生。

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