完成「State Persistence：對話斷掉之後流程還在嗎」後，下一個問題是「Policy Engine：把企業規則從 Prompt 裡拿出來」能否重跑、否定並留下失敗原因。這就是今天的範圍。

今天要回答的問題

把容量、時間、資源資格等 hard rules 寫進 deterministic policy layer，測試 prompt 與 policy 衝突時誰說了算。

工程邊界

LLM 適合處理模糊意圖，不適合成為唯一規則來源

「尋找下午較晚、適合八人的空間」需要語意理解；「容量不得小於人數」「使用者是否有取消他人預約的權限」則應由 deterministic policy 驗證。

一個穩健的分工是：模型負責理解、候選與說明；程式負責 schema validation、authorization、business rules、transaction 與 commit。這樣即使模型輸出改變，流程的硬邊界仍然存在。

一個可以直接重現的起點

Hard rule 不要藏在 Prompt

像容量上限、不可重疊、資源資格、營業時間、敏感操作需要核准等規則，應由 deterministic policy engine 判斷。即使模型在 prompt 裡說「例外處理」，policy layer 仍然要能拒絕。可刻意製造 prompt 與 policy 衝突，驗證最終權威位於哪一層。

讓 Policy 回傳明確原因碼

這個案例用「把允許／拒絕規則放入 deterministic policy 並測邊界值」檢查執行前後狀態、副作用與 audit event，再決定流程是否通過。

case = {
    "action": '把允許／拒絕規則放入 deterministic policy 並測邊界值',
    "expected_metrics": ('decision', 'reason code', 'policy version', 'audit'),
}
before = load_state()
result = execute_case(case)
after = load_state()

assert result.final_state in {"SUCCEEDED", "REJECTED", "ESCALATED"}
assert side_effects_match_policy(before, after, result)
assert audit_matches(before, after, result.events)

驗證與落地方式

驗證可從「把允許／拒絕規則放入 deterministic policy 並測邊界值」開始。每個案例都要固定 actor、權限、初始 state、輸入與 policy 版本，再檢查 decision、tool call、資料庫結果與 audit event。只檢查模型最後說了什麼並不足夠，因為流程可能回覆成功，實際上卻沒有提交；也可能回覆失敗，外部副作用早已發生。

這篇優先比較：decision、reason code、policy version、audit。正常案例、拒絕案例與故障案例都要納入；符合規則的拒絕本身就是成功結果。遇到 timeout、重試或人工核准時，還要檢查流程能否從明確 checkpoint 繼續，且不會重複執行已完成的副作用。

常見誤判

• 把自然語言回覆當成執行結果，沒有核對 authoritative state 與外部系統紀錄。
• 只測 happy path，沒有涵蓋越權、重播、競態、依賴故障與人工逾時。
• 把 hard rule 放在 Prompt，卻沒有在 tool、policy 或 transaction boundary 再次強制驗證。

上線前檢查

所有可改變外部狀態的工具都應具備窄介面、輸入驗證、授權、冪等與稽核。高影響且不可逆的動作必須保留明確確認點。發生不確定狀態時，流程應停止並交由人工處理，不能依靠模型猜測先前是否已成功提交。

如何閱讀結果

判讀順序應從最終 state 與外部副作用開始，再回頭閱讀模型訊息與 trace。若文字回覆看似合理，但權限檢查、資料庫狀態或 audit event 不一致，應直接判定流程失敗。相反地，policy 正確拒絕危險要求，即使任務沒有完成，也屬於控制機制成功。

單次流程通過後，還要重播相同 request、製造並行請求並在關鍵步驟中斷。這三類測試能分別檢查冪等、一致性與復原能力，也是 Agent 從展示走向正式流程前最容易被忽略的部分。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：模型不得自行改寫規則。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：模型不得自行改寫規則。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：RBAC 與授權：Agent 不能因為「聽懂」就代表「有權」。

參考資料

• OMG BPMN 2.0.2
• Agno Workflows
• Agno Workflow Automation
• Supabase Documentation