Agent 可以從對話理解需求，也能呼叫工具完成任務，但企業流程不能只靠聊天紀錄判斷「目前做到哪裡」。只要流程跨越多輪對話、需要人工核准，或可能因故障重新啟動，對話上下文就不足以承擔流程狀態。

可靠的 Agentic Workflow 必須先定義 state、合法 transition 與持久化方式，再決定每個階段要交給 LLM、規則引擎或工具處理。

對話記憶不等於流程狀態

對話記憶保存的是使用者與模型交換過的內容；流程狀態則要準確描述目前階段、已完成動作、等待條件與下一步權限。

如果只靠 prompt 中的一句「使用者已經同意」，會遇到幾個問題：

• 對話被截斷或摘要後，關鍵資訊可能消失。
• 模型可能誤解語意，把討論方案當成正式核准。
• 服務重新啟動後，無法確定工具是否已經執行。
• 兩個 worker 同時處理同一流程，可能重複提交。
• 稽核時無法回答何時、由誰、依據什麼規則改變狀態。

因此，state 應儲存在資料庫或具備一致性保證的持久層，而不是只放在模型上下文。

先畫出狀態與合法轉移

以需要人工核准的企業任務為例，可以先定義以下狀態：

Draft
  → Validated
  → PendingApproval
  → Approved
  → Executing
  → Completed

失敗路徑可以進入 Failed；若外部操作已經部分完成，則進入 Compensating，執行對應的補償動作。

狀態名稱不必很多，但每個 transition 都要回答四個問題：

1. 哪些來源可以觸發？
2. 需要滿足哪些 guard condition？
3. 轉移時會執行哪些 side effect？
4. 成功與失敗後分別進入哪個狀態？

例如 PendingApproval → Approved 只能由具備核准權限的人觸發；Approved → Executing 則要先確認版本仍一致、核准尚未過期，而且相同 idempotency key 沒有執行紀錄。

不合法的 transition 必須明確拒絕

若流程仍在 Draft，就不應直接進入 Executing；已經 Completed 的流程也不能因模型再次產生相同 tool call 而重跑。

檢查 transition 的責任應放在 workflow engine 或 domain service，而不是請 LLM 自行判斷。模型可以提出下一步建議，但真正改變狀態前，系統仍要驗證權限、前置條件、版本與冪等性。

這個邊界很重要：LLM 負責處理模糊語意，確定性的流程規則則交給程式碼執行。

State 至少要保存哪些欄位

一筆可追蹤的 workflow state 通常包含：

{
  "workflow_id": "wf_20260919_001",
  "status": "pending_approval",
  "version": 4,
  "correlation_id": "req_8f31",
  "requested_by": "user_123",
  "approved_by": null,
  "updated_at": "2026-09-19T10:30:00+08:00",
  "idempotency_key": "expense-20260919-001"
}

version 可用於 optimistic locking，避免兩個 worker 同時覆寫；correlation_id 用來串起 log、trace 與外部系統事件；idempotency_key 則防止重試造成重複執行。

實際業務還要保存輸入資料版本、核准依據、錯誤代碼與 transition history。敏感資料不必全部放進 state，但應保存可追溯的引用。

Checkpoint 讓長流程安全續跑

企業流程可能等待數小時甚至數天。等待人工核准時，不應讓 worker 或模型 session 一直存活；流程應寫入 checkpoint，釋放運算資源，等事件到達後再從明確狀態恢復。

恢復時要重新檢查：

• state version 是否仍是預期值。
• 核准是否有效且尚未過期。
• 外部資源是否已被其他流程修改。
• 前一次 tool call 是尚未執行、執行失敗，還是已成功但回應遺失。

最後一點不能只靠重新呼叫工具解決。涉及付款、寄信、建立帳號等 side effect 時，必須搭配 idempotency key 或外部交易 ID 查核結果。

測試 happy path 之外，也要測非法路徑

狀態機的測試至少應涵蓋：

• 正常流程能從 Draft 走到 Completed。
• 未核准時不能進入 Executing。
• 過期核准會被拒絕。
• 相同事件重送不會重複執行 side effect。
• 兩個 worker 同時更新時，只允許一方成功。
• 執行到一半失敗時，能進入 Failed 或 Compensating。
• checkpoint 恢復後，能從正確位置繼續。

測試重點不只是最後狀態，也要驗證 transition sequence、拒絕原因與外部動作次數。

結論

Agentic Workflow 的可靠性不是來自更長的 prompt，而是來自清楚的狀態模型。對話可以協助理解意圖，卻不應成為流程進度、核准事實或執行結果的唯一來源。

把 state、transition、guard condition、checkpoint 與 idempotency 寫成明確契約，流程才能在重試、併發與服務重啟後維持一致。下一篇將把自然語言需求轉成 Typed Intent，讓模糊輸入能安全進入可驗證的流程。

參考資料

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