不是每個 action 在任何狀態都應該開放

今天要解決的問題

• Condition 是顯式前置條件
• SpEL 可做動態條件
• 條件比 prompt 約束更可測

觀念圖解

不是每個 action 在任何時候都應該開放，這正是 preconditions 的價值。

如果 blackboard 上還沒有需要的資料，該 action 就不應該被選中。這比讓 LLM 自己猜「現在可不可以做」更穩，因為條件寫在方法簽章、狀態或明確規則裡。

Guardrails 則處理另一種問題：就算 action 可以執行，輸入或輸出也可能不安全、不合規或不完整。條件決定能不能走這一步，護欄決定這一步的內容能不能被接受。

Preconditions 不只來自型別，也可以來自顯式條件。當 action 需要滿足業務狀態、權限、設定開關或資料內容時，@Condition 與 SpEL 可以讓 planner 在規劃階段就知道某些 action 目前不可用。

這比在 prompt 裡寫『如果不符合條件就不要做』更可靠。Prompt 是模型指令，Condition 是工程約束；前者可能被忽略，後者可以被測試，也能在流程圖與稽核資料中被看見。

設計上要避免條件散落在 action 內部才爆錯。若某個 action 本來就不該被選中，就把條件往規劃層拉。讓 planner 少走錯路，比事後用例外修流程更乾淨。

程式碼補充

這一段往前推進到 action 條件與 guardrail，讓流程控制從「能啟動」進一步變成「能否安全執行」。

條件控制才是這一段的重點：不是應用能啟動就代表每個 action 都能執行。action 應該透過輸入型別、狀態或明確條件，限制它何時可以被 planner 選中；不符合條件時，流程應該停在可解釋的位置。

一個最小 @Condition 就能表達門檻

@Condition
boolean isHighSpender(TravellerActivity activity) {
    return activity.totalSpend() > 5000;
}

這裡沒有把條件藏進 prompt，也沒有等 action 跑到一半才丟錯。planner 在規劃時就能知道：如果 TravellerActivity 不存在，或存在但消費金額不足，這條路現在就不該走。

那寫完 @Condition 之後，要怎麼用在 action 上

• @Condition 方法本身是給 planner 在規劃時判斷用
• 簡單條件常直接寫成 @Action(pre = {"spel:..."})
• 複雜或可重用的邏輯，適合抽成 @Condition 方法

@Condition
boolean isHighSpender(TravellerActivity activity) {
    return activity.totalSpend() > 5000;
}

@Action(pre = {"spel:activitySummary.highSpender == true"})
OfferDraft proposeUpgrade(ActivitySummary activitySummary, Ai ai) {
    return ai.withDefaultLlm().createObject("...", OfferDraft.class);
}

這裡可以分成兩層看：

第一層，isHighSpender(...) 是「怎麼判斷」高消費客戶的規則，適合放在可重用的 Java 方法裡。
第二層，proposeUpgrade(...) 是「什麼 action 只在特定條件下開放」，因此直接在 pre 寫 SpEL，告訴 planner：只有當 blackboard 上的 activitySummary.highSpender == true，這個 action 才能被選中。

如果你的條件只是單純比對某個欄位，直接用 SpEL 最短也最好讀；如果條件牽涉多個欄位、計算或之後會被多個 action 共用，就抽成 @Condition 方法比較合理。

今日實作 / 思考任務

為 reviewOffer 加上條件設計：哪些情況可以審核？哪些情況必須先補資料或走人工？

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