Pattern Note #07：使用狀態機套件重構 AI Agent

我嘗試用四款 php 開源狀態機套件重構 demo 06

demo-winzou.php — 使用 winzou/state-machine
demo-neuronai.php — 使用 NeuronAI 框架
demo-finite.php — 使用 yohang/finite（PHP Enum）
demo-pocketflow.php — 使用 PocketFlow（Graph-based）

原始碼

https://github.com/howtomakeaturn/ai-agent-pattern-notes/tree/main/patterns/07-state-machine-routing

成果我非常不滿意

我認為程式碼非常難閱讀並沒有比較好維護

知識點

99% 業界 ai agent 都用不到狀態機 library 嗎？

對，差不多是這個意思。

AI agent 的「狀態」跟傳統軟體的狀態機有根本差異：

傳統軟體（訂單系統、審批流程）：

- 狀態是持久化的（存 DB）
- 轉換需要嚴格合規控制（不能從「已退款」跳回「待出貨」）
- 多人操作同一筆資料，需要並發保護
- State machine library 在這裡非常有價值

AI agent：

- 一次對話就結束，狀態活在記憶體裡
- 你控制的是「AI 當前能叫哪些 tool」，不是電商訂單流程
- 沒有多人並發問題
-流程通常是線性的（收集資訊 → 判斷 → 處理 → 結束）
-就算有分支，也就 2-3 個

真正決定 AI agent 走什麼路的是 LLM 自己。你給它 3 個 tool，它挑一個呼叫。這跟「狀態 A 只能轉到狀態 B 或 C」的思維模型不一樣。Demo 06 的 get_available_tools() 本質上只是在做「根據業務階段過濾可用工具」，這件事一個 switch/if 就夠了。

真正需要 state machine 的 AI agent 場景大概是：

- 多輪審批流程（AI 起草 → 主管審核 → 法務審核 → 執行），且狀態要持久化
- 跨 session 的長流程（今天做到一半，明天繼續），需要從 DB 恢復狀態

但這種場景很少，而且到了那個複雜度，你通常會用專門的 workflow engine（Temporal、AWS Step Functions），不是一個 PHP state machine library。

那麼 chatgpt, cursor 這些也都沒用到狀態機嗎？

AI agent 的 tool routing 層：沒有。 ChatGPT、Cursor 的核心迴圈就是：

loop {
    把對話 + 可用 tools 丟給 LLM
    LLM 決定：回文字 or 呼叫 tool
    如果呼叫 tool → 執行 → 把結果塞回對話 → 繼續 loop
    如果回文字 → 結束
}

這就是 demo 06 的模式。LLM 自己就是 router，不需要 state machine 來告訴它「現在能做什麼」。Cursor 的 agent mode 就是不斷讓 LLM 挑工具（讀檔、改檔、跑指令），直到它覺得做完了。

重點是：LLM 本身就是最好的 router。 傳統軟體需要 state machine 是因為程式不會「思考」，你必須寫死規則告訴它能往哪走。但 LLM 會看 context 自己判斷該用哪個 tool。你唯一要做的就是「在不同階段只給它看合適的 tools」，這 demo 06 的 if/else 就做到了。

大多數場景，全開放就夠了。 如果你在做一個「幫我寫 code」的 agent，根本不需要限制它什麼時候能讀檔什麼時候能改檔。

但如果你在做有合規需求的業務系統（先核身 → 再查帳 → 才能操作），動態過濾就有價值。不是怕 LLM 亂來，而是你的產品設計就要求這個順序。

所以有嚴格步驟的用 dynamic routing 與 dynamic tools 就夠了
反正就是別去用狀態機 sdk 是嗎

對。結論就是這樣。

除非你的流程複雜到幾十個狀態上百個轉換（那時候你可能根本不會用 AI agent 來做，而是用 workflow engine），否則 get_available_tools() 裡的 if/else 就是最直覺、最好維護的寫法。

State machine library 不是不好，是解決的問題跟 AI agent 的問題不同。它解決的是「傳統軟體中複雜狀態轉換的管理」。AI agent 的路由本質上就是「這個階段給哪些 tools」，一個 switch 搞定。

即使要幫客戶建立一個 saas 平台
讓用戶可以 DIY 搞節點
後端底層實作也不需要狀態機嗎

啊，這完全是另一回事。這種要用狀態機。

這張圖看起來是像 Vapi 或類似的 AI agent builder SaaS。使用者在前端拖拉節點定義流程，後端要解釋並執行這個使用者定義的流程圖。

當流程是資料驅動（存在 DB 裡的 JSON/graph），你需要一個引擎來解釋執行它。這時候你有兩條路：

1. State machine / workflow engine：把每個節點當 state，每條連線當 transition，使用者畫的圖直接對應 state machine 的 config
2. Graph execution engine：更通用，支援並行、條件分支、迴圈

圖片裡的那種產品，後端大概率是用某種 DAG（有向無環圖）執行引擎，每個節點有自己的 handler（LLM call、API call、條件判斷），邊代表資料流和控制流。State machine 是其中一種實作方式，但更可能是自己寫的 graph executor。

所以結論修正：

- 你自己寫一個 AI agent → 不需要 state machine，if/else 就好
- 你要建一個讓別人定義流程的平台 → 需要某種 graph/state machine 引擎來解釋執行使用者定義的流程

這是「寫程式」和「寫一個讓別人寫程式的平台」的差別。完全不同層次的問題。

流程是程式碼 vs 流程是資料

站長阿川

每週二 YT 直播 Q&A（可 Discord Call-in）
YT：https://www.youtube.com/@codelove_tw
DC：https://discord.gg/fvCF2whZ9D

⭐️ Shopify 接案服務（給品牌）
https://job.turn.tw/shopify-services

⭐️ Shopify 技術教練（給工程師）
https://job.turn.tw/developer-coaching

⭐️ 台灣 Shopify 開發者 LINE 群（非官方）
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA