跳到主要內容
NTPU AI Learn

AI 302 · 模組 2

State、Loop 與 State Machines

系統要可靠運作，必須知道「現在在哪裡」。

開始第一節
  • 時長60 分鐘
  • 難度架構
  • 先備知識建議先完成 AI 302 模組 1；建議完成 AI 202（Agentic AI Planning & Reasoning）
已完成 0 / 7
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 說明 State，並區分 Workflow state、Agent state 與 Execution state
  • 區分 Ephemeral state 與 Persistent state，並決定該用哪一種
  • 用 State Machine 把 Workflow 表示成 States、Transitions 與 Transition condition
  • 設計 Terminal state、Error state 與 Human review state
  • 針對每個 State 回答六個 State 設計問題
  • 設計有明確停止條件的受控 Execution loop，並避免無界限的 Loop
  • 用模擬資料把 Agentic workflow 轉換成 Agent State & Transition Map

問題與需求

8 分鐘

當沒有人知道 Run 進行到哪裡

在模組 1 中，你看到 Harness 控制一次 Run 如何被執行。這些控制都倚賴同一件事：系統必須知道 Run 現在在哪裡。核心問題是：系統要可靠運作，如何知道自己目前在哪裡？

工作情境（模擬）

一個 Agent 處理供應商的發票：讀取發票、對應採購單、檢查金額，再準備付款申請。Run 停了下來。有人問：發票已經對應了嗎？金額檢查過了嗎？付款申請是在等人，還是根本沒有建立？Agent 答不出來，因為進度的唯一紀錄在它自己的對話裡，而對話已經消失。團隊只能讀完整段歷史來猜。

  • 如果 Run 沒有明確的位置，就無法有把握地暫停與 Resume
  • 如果下一步只由模型來選，同一次 Run 每次可能走向不同的路
  • 如果失敗與審閱不是被命名的情況，它們就只能靠臨場應變處理
  • 如果沒有人說得出 Run 在哪裡，就沒有人能說該由誰來處理

注意

把進度記在一段很長的對話裡是很脆弱的。讓 Run 的位置成為明確、有名稱的 State 是一個設計決定，也是本課程其餘部分的基礎。

重點: 可靠的執行從知道 Run 在哪裡開始。讓 Run 的位置成為明確的 State，而不是藏在對話裡的東西。

State

9 分鐘

什麼是 State？Workflow、Agent 與 Execution state

State 是系統為了能正確地繼續，必須記住的關於某次執行的資訊。有三種容易混淆，各自回答不同的問題。

三種 State（模擬的發票範例）
種類它回答的問題範例
Workflow stateRun 在設計好的流程中位於哪裡？發票已對應；金額檢查進行中；付款申請尚未建立
Agent stateAgent 目前手上握有什麼來做決定？工作筆記、下一步的計畫、從發票擷取出的事實
Execution stateRun 本身作為一個執行中的系統，正在做什麼？Run 於 09:02 啟動；金額檢查第 2 次嘗試（共 3 次）；正等待採購單系統回覆

Workflow state：地圖上的位置

  • 屬於設計好的流程
  • 是一小組有名稱的值，例如 MATCHING 或 AWAITING_REVIEW
  • 決定接下來可以發生什麼

Agent state：工作記憶

  • 屬於 Agent 與它的推理
  • 內容豐富且經常變動，例如筆記與擷取出的事實
  • 影響 Agent 的選擇，但本身並不定義 Run 在哪裡

資訊

常見的錯誤是讓 Agent state 取代 Workflow state。Agent 也許會寫下「我想我快做完了」，但 Harness 需要的是一個可讀取、可檢查、可依據行動的有名稱 State，例如 VERIFYING。
自我檢測

紀錄寫著「金額檢查，第 2 次嘗試（共 3 次），等待採購單系統回覆」。這主要是哪一種 State？

紀錄寫著「金額檢查，第 2 次嘗試（共 3 次），等待採購單系統回覆」。這主要是哪一種 State？

重點: Workflow state 是 Run 在流程中的位置，Agent state 是 Agent 使用的資料，Execution state 是執行中系統正在做的事。請把它們分開。

9 分鐘

Persistent 與 Ephemeral state

並不是所有 State 都需要撐過中斷。Persistent state 會被保存，讓它比程序與對話活得更久。Ephemeral state 只在某個步驟執行期間存在，可以遺失或重建。決定哪個屬於哪一類是設計選擇，它也決定了 Run 能從什麼狀況中復原。

Persistent 與 Ephemeral state（模擬的發票範例）
Persistent stateEphemeral state
意義保存在執行中程序之外，因此能撐過中斷只在步驟執行期間持有，步驟停止就會遺失
範例目前的 Workflow state、發票編號、哪些動作已經生效、每次 Verification 的結果寫到一半的草稿、暫時的計算、目前的模型對話輪次
遺失時Run 無法有把握地繼續，可能重複或跳過動作通常可以重新執行該步驟，不會造成傷害
成本需要儲存空間與細心處理，因為可能包含敏感資料，有時需要保護便宜且簡單，但事後不能倚賴它
  • 保存為了正確繼續所需的東西：位置、已做的決定、外部已經發生了什麼
  • 不要把所有東西都保存。儲存每一點零碎資訊會讓 State 變大、變貴，也更難保護
  • 對於敏感文件，寧可保存參照，也不要保存副本；不需要的東西絕不儲存
  • 可以從 Persistent state 重建的資訊，通常可以維持為 Ephemeral

資訊

在選定的點保存 State、讓 Run 得以 Resume 的 Checkpoint，是後面模組的主題。這裡的目標只是針對每一項資訊，決定它是否必須撐過中斷。
自我檢測

一次 Run 已經把付款申請送到外部系統。「付款申請已送出」這項事實，最好怎麼處理？

一次 Run 已經把付款申請送到外部系統。「付款申請已送出」這項事實，最好怎麼處理？

重點: 保存 Run 為了正確繼續所需的東西，尤其是外部已經發生的事。其餘維持為 Ephemeral，並盡量少儲存敏感資料。

State Machines

9 分鐘

State Machines：States 與 Transitions

State Machine 把 Workflow 描述成一組有名稱的 States，以及它們之間允許的 Transitions。每個 Transition 只有在說明過的條件成立時才會發生，因此下一步由明確的規則決定，而不是碰運氣。State Machine 的每個 State 裡仍可包含 Agent 的推理，它所固定的是 Run 的形狀。

模擬發票 Run 的 State Machine
  1. START：Run 由 Trigger 建立
  2. PLANNING：Agent 決定如何處理這張發票
  3. EXECUTING：Agent 執行一個步驟，例如對應採購單
  4. VERIFYING：Harness 檢查結果，接著會出現四種 Transition 之一
  5. PASS 前往 NEXT：繼續下一步，或在 Terminal state 結束
  6. RETRY 回到 EXECUTING：在限制內再試一次該步驟
  7. HUMAN 前往 REVIEW：由人審閱或決定
  8. FAIL 前往 FAILED：Run 以失敗結束

文字版說明：Run 從 START 開始，往下移到 PLANNING，再到 EXECUTING。從 EXECUTING 移到 VERIFYING。VERIFYING 是分岔點，有四條往外的 Transition。如果結果通過，Run 移到 NEXT，開始下一步或在 Terminal state 結束 Run。如果結果應該再試一次，Run 回到 EXECUTING，這就形成一個 Loop，而這個 Loop 必須有限制。如果需要由人決定，Run 移到 REVIEW 並等待。如果結果無法被接受，也無法重試，Run 移到 FAILED 並停止。每一個箭頭都有條件，每一個 State 都至少能被一個箭頭到達。

State Machine 的組成
組成意義範例
StateRun 可以處於的、有名稱的情況EXECUTING
Transition從一個 State 到另一個 State 的允許移動VERIFYING 到 EXECUTING
Transition condition這個移動必須成立的規則檢查發現問題，且嘗試次數低於上限
Terminal state沒有出口的 State；Run 在此結束DONE 或 FAILED
自我檢測

在這個 State Machine 中，VERIFYING 這個 State 的主要目的是什麼？

在這個 State Machine 中，VERIFYING 這個 State 的主要目的是什麼？

重點: State Machine 命名 States、允許的 Transitions，以及每一個的條件。它讓下一步成為明確的規則，而且必須有 Terminal states。

9 分鐘

Error states、Human review states 與設計問題

設計順利的路徑時，有兩種 State 很容易被忘記：出錯時的 State，以及有人參與的 State。如果它們沒有被命名，就只能靠臨場應變處理。

Error states

  • 為發生了哪一種失敗命名，例如 FAILED 或 BLOCKED
  • 說明 Run 能否復原，還是必須停止
  • 保留原因，讓人能看見哪裡出了問題

Human review states

  • 為 Run 等待人的那個點命名，例如 AWAITING_REVIEW
  • 說明人要決定什麼，以及他們需要看到什麼
  • 為每種答案定義接下來的事：核可、駁回或修改
對每個 State 提出的六個設計問題（模擬：State AWAITING_REVIEW）
問題AWAITING_REVIEW 的範例答案
需要哪些資訊？發票編號、檢查結果，以及請求審閱的原因
允許哪些動作？審閱者可以核可、駁回或退回；Agent 不可以行動
什麼會造成 Transition？審閱者的決定；或兩個工作天後逾時
失敗時會發生什麼？如果審閱者沒有及時回應，通知一位指定的人並繼續等待
State 是否被保存？是，因為等待可能持續很久，必須撐過中斷
執行能否在此安全地 Resume？能，因為在這個 State 中還沒有發生任何外部動作

資訊

Human-AI-Human：Human review state 是流程中刻意設計的一部分，不是失敗的徵兆。由人定義何時需要審閱，Agent 準備審閱者所需的資料，由人決定並負責。
自我檢測

為 Workflow 設置明確的 Human review state，最好的理由是什麼？

為 Workflow 設置明確的 Human review state，最好的理由是什麼？

重點: 為 Error states 與 Human review states 命名。對每個 State 回答六個問題：資訊、允許的動作、Transition、失敗、Persistence 與安全 Resume。

Execution loop

8 分鐘

Execution loop，以及如何讓它有界限

Loop 讓 Agent 系統能夠調整：執行、檢查，然後重試或改變方向。Loop 很有用，但 Loop 也可能讓 Run 永遠循環或浪費成本。原則是使用受控的 Loop，並避免無界限的 Loop。

受控的 Execution loop
  1. Execute：執行目前的步驟
  2. Verify：依照說明過的標準檢查結果
  3. Pass？
  4. 是：繼續下一步
  5. 否：選擇 Retry、Re-plan 或人工審閱，並計入一次嘗試
  6. 達到上限時：離開 Loop，前往審閱或失敗的 State

文字版說明：Loop 從執行一個步驟開始，接著驗證結果。如果結果通過，Loop 結束，Run 繼續。如果沒有通過，Harness 在 Retry、Re-plan 或詢問人之間做選擇，並把嘗試計數器加一。只有在計數器低於上限時，Loop 才被允許重複。當達到上限，Run 必須離開 Loop，前往 Human review state 或 Failed state，不可以再繞一圈。

  • 每個 Loop 都需要 Loop condition、Stop condition，以及上限，例如最大嘗試次數、時間或成本
  • 檢查失敗時要怎麼做必須寫明：重試同一步、Re-plan，或詢問人
  • 計數器屬於 Persistent state，否則重新啟動會重設上限，Loop 又能再跑一輪
  • 兩次嘗試之間沒有任何改變的 Loop，只會重複同樣的失敗

資訊

實作範例（不是唯一的模型）：在像 LangGraph 這類有 State 的框架中，Loop 是一張有循環的圖，由 Conditional edge 把 Run 送回較早的 Node。框架不會替你加上上限，所以計數器與 Stop condition 仍然是你的設計決定。
自我檢測

一次 Run 只要檢查失敗就重複「執行，再驗證」，沒有嘗試上限。主要的風險是什麼？

一次 Run 只要檢查失敗就重複「執行，再驗證」，沒有嘗試上限。主要的風險是什麼？

重點: 使用受控的 Loop：條件、Stop condition 與上限，並讓計數器能撐過重新啟動。達到上限時，交給人或前往 Terminal state。

實作與應用

8 分鐘

實作：Build the State Model

活動 2 要求你把一個 Agentic workflow 轉換成 State model。先用範例練習，再對你在模組 1 選定的系統做同樣的事。請不要在這個練習中輸入真實的公司機密、客戶個人資料或任何未經授權的敏感資訊。

範例（模擬）：供應商發票 Workflow
State類型何時往下移失敗或達到上限時
RECEIVED起點發票已儲存並建立編號前往 REJECTED_INPUT
MATCHING工作中發票與某張採購單相符前往 AWAITING_REVIEW
VERIFYINGVerification金額在核定金額之內最多 Retry 兩次，之後前往 AWAITING_REVIEW
AWAITING_REVIEWHuman review審閱者核可、駁回或退回兩個工作天後，通知一位指定的人
PAYMENT_PREPARED工作中建立付款申請，交給人放行前往 FAILED
DONETerminal有人已放行付款不適用
FAILEDTerminal，錯誤不適用記錄原因；通知一位人員
  1. 列出 States
    針對你的系統，為起始 State、工作中的 States、Verification states、Human review states、Error states 與 Terminal states 命名。
  2. 畫出 Transitions
    對每個 State 寫下它能前往哪裡，以及每個移動的條件。確認每個 State 都能被到達，而且每條路徑都結束在 Terminal state。
  3. 為 Loop 設界限
    標出每一個 Loop，並給它 Stop condition 與上限。說明達到上限時會發生什麼。
  4. 提出六個問題並分類資料
    對每個 State 回答六個設計問題，並決定哪些資訊是 Persistent，哪些是 Ephemeral。

資訊

交付成果：一份 Agent State & Transition Map，呈現你的 States、附條件的 Transitions、Terminal states、Error states 與 Human review states，並附上文字說明。它會成為你的 Agent Harness & Reliability Canvas 的一部分。
自我檢測

哪一個敘述最能說明一份好的 Agent State & Transition Map？

哪一個敘述最能說明一份好的 Agent State & Transition Map？

重點: Human-AI-Human：由人設計 States、Transitions 與審閱點，Agent 在其中工作，由人審閱結果並對結果負責。

另存 PDF

接下來做什麼？