https://yennj12.js.org/yennj12_blog_V4/tags/statemachine/Recent content in StateMachine on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-3-state-machine-dag-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-3-state-machine-dag-zh/核心定義：DAG 是把 Agent 的「下一步由 LLM 在執行期決定」改成「下一步由工程師在編譯期定義」，讓系統的行為空間可靜態分析、可稽核、可成本管控。 大多數人把 Agent 做成 ReAct 迴圈——因為它最快能跑起來； 少數人在第一次工具呼叫爆炸後改成有守衛的迴圈； 更少人從一開始就把行為編碼成 DAG，把路由邏輯放在 Python 而非 prompt； 最少的人能說清楚為什麼這樣做可以把工具呼叫從 12 次壓到 4 次。 面試情境：「我們的 AI 文件審核系統上線後，有使用者反映處理速度極慢，有時要等 3–4 分鐘；後來發現有些 run 觸發了 25 次以上的 LLM 呼叫，導致每個 query 成本從預計的 $0.01 飆升至 $0.08。如果請你重新設計這個系統的 Agent 架構，你會怎麼做，以及如何確保這個問題不再發生？」 一、為什麼面試官問這個 面試官問這個問題，真正在測試的不是你會不會用 LangGraph API，而是你是否理解 Agent 系統的確定性邊界問題。當 LLM 自己決定下一步時，系統的行為空間在執行前是無界的——相同輸入在不同推論溫度下可能走不同路徑，工具呼叫次數無法預測，成本預算無從管控。在一個 LLM 呼叫每次耗費數十毫秒和若干 Token 費用的世界裡，這不是學術問題，是直接打中 P&L 的工程問題。 面試官測試三個層次： 概念層：你能否清楚說明 ReAct 和 DAG 的本質差異，而不只是說「DAG 有節點有邊」 工程層：你是否知道反思迴圈為何需要雙重收斂條件，以及 State Schema 如何防止跨節點狀態污染 量化層：你能否用具體數字說明影響——工具呼叫次數、Token 成本、收斂延遲 弱答案的特徵：「DAG 就是有向無環圖，LangGraph 可以幫你把 Agent 畫成圖。」只描述工具特性，沒說清楚「為什麼要這樣做」和「不這樣做的具體代價」。