搜尋意圖： 如果你在找「狀態機模型 是什麼」或「狀態機模型 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 狀態機模型是一種計算模型，系統在任何給定時間都處於有限數量的狀態之一，並根據輸入在狀態之間轉換。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
你有沒有看過 app 一直在登入、載入、錯誤之間切換？
你可以把它想成把系統行為寫成狀態轉移圖。 狀態機模型 的重點是 狀態機模型是一種計算模型，系統在任何給定時間都處於有限數量的狀態之一，並根據輸入在狀態之間轉換。 它重要，是因為流程會變得可預測，也比較好除錯。
容易混淆
狀態機模型 vs AI 代理 狀態機模型：偏向 用有限狀態描述流程 AI 代理：偏向 會根據狀態做行動的系統 最關鍵的區別：狀態機模型看的是「用有限狀態描述流程」，AI 代理看的是「會根據狀態做行動的系統」。
狀態機模型 vs 馬可夫決策過程 狀態機模型：偏向 用有限狀態描述流程 馬可夫決策過程：偏向 描述決策流程的數學框架 最關鍵的區別：狀態機模型看的是「用有限狀態描述流程」，馬可夫決策過程看的是「描述決策流程的數學框架」。
記住這句就好
先看現在狀態，再看觸發條件。
實際案例
案例：登入流程有未登入、驗證中、已登入 狀態清楚，出問題時比較好追
案例：客服機器人有等待、處理中、轉人工 每一步都能知道下一個分支在哪裡
算法與應用
狀態要有限，轉移規則要清楚 事件一來，就知道要切到哪個狀態 很適合流程控制、互動流程和裝置邏輯
中英對照與組成要素
| 中文 | 英文 | 說明 |
|---|---|---|
| 狀態機 | state machine | 統稱 |
| 有限狀態機 | finite state machine（FSM） | 狀態數量有限的狀態機，最常見的一種 |
| 狀態 | state | 系統目前處在的情況 |
| 轉移 | transition | 從一個狀態換到另一個狀態的規則 |
| 事件 / 觸發 | event / trigger | 造成轉移的輸入 |
| 動作 | action | 轉移時要執行的事情 |
一台有限狀態機由五個東西定義：所有可能狀態的集合、所有輸入的集合、轉移函數、起始狀態、結束狀態。
用訂單流程舉例：狀態是「待付款、已付款、已出貨、已完成、已取消」，事件是「付款成功、出貨、簽收、取消」，轉移規則規定「待付款」收到「付款成功」會變成「已付款」。關鍵是沒有定義的轉移就是不允許的，「已完成」收到「取消」不會有任何事發生。
為什麼在 AI agent 上又變重要
大型語言模型天生是自由發揮的，這在需要可靠流程的場合是問題：它可能跳過必要步驟、重複執行、或在該結束時繼續講話。
把流程建成狀態機能解決這件事，做法是讓模型負責「判斷」，狀態機負責「控制」。
模型決定往哪走，狀態機決定能不能走。 模型輸出「使用者想取消訂單」，狀態機檢查目前狀態允不允許取消。不允許就不執行，並讓模型改口，而不是讓模型自己判斷合不合法。
每個狀態可以配不同的提示與工具。 在「收集資訊」狀態只給查詢工具，在「執行變更」狀態才開放寫入工具。這比在一個大提示裡寫滿規則可靠得多。
狀態是可稽核的。 出問題時能看出卡在哪一步，而不是只看到一段對話。
LangGraph 這類 agent 框架的核心抽象就是圖與狀態，本質上是在寫狀態機。工作流程自動化工具（n8n、Temporal）也是同一個想法。
判斷什麼時候該用： 流程有明確步驟、有不可跳過的關卡、有不可逆的動作，就該用狀態機框住。純粹的問答與創作則不需要，硬套只會綁死。
情境判斷
Q1（直覺題）： 登入失敗後應該直接回首頁嗎？ → 通常不是，狀態機會先看當下是驗證失敗還是網路錯誤，再決定下一步。
Q2（判斷題）： 一個流程如果一直改規則，還適合用狀態機嗎？ → 看情況，如果狀態和轉移很不穩，硬用狀態機反而會讓維護更麻煩。
常見問題
什麼時候該用狀態機？
當流程有明確階段，而且每個階段的下一步都很規則時，狀態機最有用。
和流程圖有什麼不同？
流程圖偏重步驟順序，狀態機偏重現在在哪個狀態，以及什麼事件會改變它。
它適合拿來建模 AI 嗎？
適合建流程型 AI 或代理的控制層，但不適合拿來直接描述複雜語言能力本身。