Jeremiah Lowin 如何用 Prefect 重做可恢復的 AI 工作流？

Jeremiah Lowin 如何用 Prefect 重做可恢復的 AI 工作流？

工作流真正困難的時刻不是第一次成功，而是在第五次重試、worker 突然消失、資料版本改變或人工介入之後，系統仍知道接下來該做什麼。Jeremiah Lowin 創辦 Prefect，將 failure、state 與動態 Python 工作放在編排中心；近年的 FastMCP 與 Horizon 又把同一思路延伸到 AI agent 的 context 與工具層。

Jeremiah Lowin 的起點：從風險模型到自動化

Prefect 官方人物故事記錄 Jeremiah Lowin 曾從事市場風險與機器學習工作，也參與 Apache Airflow。當既有排程無法靈活處理資料科學產生的大量動態任務時，他先建立內部工具，並在 2018 年創辦 Prefect。

這段背景解釋 Prefect 對 failure 的關注。風險管理不假設所有事情都順利，而是辨識狀態、曝險與恢復手段。資料與 AI 自動化同樣不能只記錄 success 或 fail，還要知道失敗發生在哪個邊界、哪些副作用已完成。

Prefect 將普通 Python 函式提升為 flow 與 task

開發者可以用 decorator 標記 flow 與 task，保留熟悉的 Python control flow，同時取得 orchestration state、retry、log 與觀測。這比要求使用者先學一套大型 DSL 更容易漸進導入。

普通 Python 的自由也帶來責任。分支、迴圈與動態 task 數量可能依資料變化，部署前無法完全畫成固定 DAG。平台必須在 runtime 追蹤實際 graph，並對無界 fan-out、遞迴與外部副作用設限制。

Flow run 與 task run 是可恢復身分

函式定義描述可以做什麼，run 才代表某次具體執行。每個 run 應有唯一 ID、參數、code version、開始時間與狀態歷史。重跑不能只覆蓋舊紀錄，否則事故原因與產物關係會消失。

AI pipeline 再加入 model、dataset、prompt、tool policy 與 environment digest。只有把這些綁定 run，才能知道某個向量索引或評估結果如何產生。名稱相同不代表 artifact 相同。

State model 比布林成功更能描述真實世界

工作可能 Scheduled、Pending、Running、Completed、Failed、Cancelled、Crashed 或等待重試。這些狀態區分程式錯誤、基礎設施中斷與人工取消，讓自動化能選不同恢復路線。

狀態轉換必須可稽核且單調受控。Worker 遺失時，控制面不能立刻假定 task 沒有完成副作用；先將 outcome 視為 unknown，再以 idempotency record 或外部 read-back 判定。錯把未知當失敗會造成重複寫入。

Retry 的前提仍是冪等

Prefect 可以設定 task retry、delay 與條件，但框架無法自動讓任意程式變冪等。資料庫 insert、雲端資源建立、通知與模型 API 都可能在 timeout 前已成功。

每個副作用使用 operation ID，執行前寫 durable intent，完成後記錄 response hash。重試先查目前狀態；若外部結果未知，停在 repair queue 而不是盲目再送。對不可逆操作加入人工核准。

Cache key 要綁定真正的輸入語意

Task caching 能重用先前結果，節省昂貴計算。但只用參數表面值做 key，可能漏掉程式碼、環境、模型或外部資料版本。錯誤 cache 比重新計算更危險，因為看起來快速且成功。

AI 任務的 cache key 應包含 normalized input、model revision、prompt hash、processing version 與安全 context。權限不同的租戶不可共享私有結果。Cache hit 要在觀測中明示，並有失效與刪除政策。

Result persistence 需要完整 artifact 契約

大型結果不應全部塞進 orchestration database。可將資料寫入物件儲存、資料庫或 artifact store，控制面只保存 URI、serializer、hash 與 metadata。下游讀取前重新驗證。

Serializer 是安全邊界。不可信 pickle 可執行程式，應優先使用 schema 化格式；若必須使用原生物件，只允許受控來源與隔離環境。Artifact 加密、保留與租戶位置也要符合政策。

Deployment 把程式、排程與參數固定成可操作單位

同一 flow 可以有多個 deployment，對應不同 schedule、work pool、參數與環境。這讓測試、每日執行與回填共享程式，但保有不同資源與治理。

部署應綁 source commit、image digest 與設定版本。只保存「latest」會讓重跑使用不同程式。Promotion 從 staging 到 production 時驗證相同 artifact，不在目標環境重新 build 未知內容。

Work pool 與 worker 分離控制面和執行面

控制面排程與追蹤 run，worker 從 work pool 取得工作並在 process、container、Kubernetes 或雲端基礎設施執行。這讓敏感運算留在客戶環境，同時使用集中觀測。

Worker identity 必須最小權限，pool 按環境、租戶或資源類型隔離。Job template 限制可調欄位，不能讓任意 flow 提升網路、service account 或主機權限。控制面訊息也要驗證簽章與過期。

Concurrency limit 保護共享下游

動態 Python 可以快速產生大量 task，但資料庫 connection、模型 API、GPU 與第三方服務都有上限。Global 或 tag-based concurrency limit 能控制同類工作同時執行量。

限制要反映實際資源，而不只是 task 數。長 prompt 與短 prompt 的 token 成本不同，大型 tenant 也可能壟斷。平台加入 per-tenant quota、公平排程與 budget cap，避免單一 flow 拖垮所有使用者。

Mapping 與子流程支援動態資料工作

一個輸入集合可 map 成多個 task，子 flow 可封裝獨立生命週期。這適合依檔案、客戶、模型或評估集平行處理，也能針對失敗項目重跑。

輸入集合必須 bounded。先做 manifest、去重與分頁，限制最大 task 數；每個 child output 以穩定 key 命名。聚合前確認所有必要項目完成，不把部分成功冒充整批完成。

Events 與 automations 讓工作流回應外部狀態

除了 cron，Prefect 可從事件觸發流程、通知或動作。事件應有 resource identity、occurred time、event ID 與 payload schema。Automation 則描述條件和回應。

事件可能重複、延遲或亂序，動作仍需冪等。告警與自動取消要避免回饋迴圈；每項 automation 有 owner、cooldown、最大動作次數與 kill switch。安全敏感動作預設需要人類確認。

Blocks 與秘密設定不可混進程式碼

工作流需要 credential、storage 與 infrastructure config。集中 block 能重用設定，但存取權限應依 deployment 與環境限制。秘密只在執行時注入，不輸出到 log、artifact 或錯誤訊息。

輪替 secret 時，要知道哪些 deployment 依賴它，並可灰度驗證。LLM agent 不得讀取完整 credential；工具執行由可信 runtime 代持，模型只看到必要結果。

Prefect 3.0 強調 transaction 與恢復語意

Prefect 官方介紹把第三代引擎定位為 resilient workflow，包含 transactional semantics、events 與更廣泛的執行能力。交易在工作流層不等於資料庫全域 ACID，而是協調 task 結果、commit 與 rollback hook。

Rollback 也不是魔法。寄出的郵件或外部付款可能無法真正撤回，只能補償。設計時將 side effect 分成可回復、可補償與不可逆，為最後一類加核准與 fresh read-back。

Failure hook 與 callback 不能成為第二個不可靠系統

失敗後發通知、清理暫存或建立工單很常見。但 hook 本身也可能失敗或重複，不能承擔唯一恢復證據。重要操作寫入 durable queue，再由專用流程處理。

通知聚合與去重，避免同一根因產生數千訊息。訊息包含 run URL、state、owner 與安全摘要，不貼秘密或完整資料。修復完成後自動關閉相關事件並保留稽核。

Observability 要保存狀態歷史與資料品質

Run timeline 能顯示 scheduling、queue、execution 與 retry，但 task Completed 不代表資料正確。重要輸出加 schema、row count、freshness、distribution 與 lineage assertion。

Dashboard 同時報 orchestration SLO 與 data SLO。事故可沿 trace_id 從事件、flow、task、artifact 追到下游。Log 以 structured field 記錄版本與識別碼，內容採最小化與遮罩。

Dynamic workflow 對測試提出更高要求

固定 DAG 可以靜態檢查依賴，動態 flow 要用代表輸入探索不同分支。Unit test 純函式，integration test 使用隔離外部服務，orchestration test 驗狀態、retry 與 cancellation。

Property-based test 可生成空集合、極大集合、晚到與重複事件。故障注入在副作用前後終止 worker，確認重跑不會重複。每條不可逆路徑至少有一次 negative test。

取消與 timeout 是正式語意

任務超過時間可能被取消，但底層 subprocess、container 或遠端 job 不一定立即停止。控制面要區分已要求取消與已確認終止，並持續追蹤孤兒資源。

模型訓練保存 checkpoint，取消後清理臨時容量但保留必要證據。遠端 API 若無取消能力，結果回來後依 run state 決定是否採用。Timeout 不能被當成「沒有發生」。

回填與重新部署必須綁定資料版本

使用新 code 重跑舊日期，可能產生與原先不同的結果。這可能是目的，也可能破壞 audit。Backfill manifest 要記錄目標 interval、code、input snapshot、output namespace 與切換計畫。

先寫新版本，不覆蓋目前 production；比較品質後原子切換 alias。若失敗，舊版本仍可讀。對 embedding 或模型評估，回填還要估算 token、GPU 時數與租戶影響。

Prefect 與 Airflow 的差異應回到 workload

Jeremiah Lowin 曾參與 Airflow，Prefect 後來強調動態 Python、state 與 failure handling。這不是簡單的新舊排序。Airflow 的成熟 DAG 生態與 Prefect 的動態編排各有優勢。

選擇前以同一實際 pipeline 比較開發、部署、backfill、failure repair、觀測與治理。遷移成本包含 operator、歷史 metadata、on-call 習慣與權限，不只把 decorator 換掉。

Prefect 收購 Dagster 後的邊界

Prefect 2026 年官方公告表示將收購 Dagster Labs，並承諾 Dagster 維持原專案與產品。公告把兩者描述為互補：Prefect 聚焦動態、耐故障執行，Dagster 聚焦 asset 定義與驗證。

這是目前外部狀態，不應推論為技術已整合。使用者要依官方 release 與 migration 文件評估，避免預先改架構。兩個生態的長期治理、metadata 與執行互通仍需可驗證產物。

FastMCP 把工作流經驗延伸到工具協議

Prefect 官方近年將 FastMCP 納入產品線，用來建立 Model Context Protocol server。MCP 讓 agent 以結構化工具與資源取得 context，但協議互通不會自動提供授權、租戶隔離或成本控制。

每個 tool 定義輸入 schema、read/write 分級與 idempotency。Server 以實際使用者身分授權，不信任模型自述；輸出限制大小並遮罩秘密。高風險工具走 preview、approval 與 read-back。

Horizon 將 context layer 視為企業控制面

Prefect Horizon 官方介紹把 context layer 定義為 agent 接觸企業資料、工具與工作流的邊界。這與 orchestration 的核心問題相似：系統要知道誰可執行什麼、現在處於哪個狀態、失敗後如何恢復。

Context 不能只是把更多資料塞入 prompt。需要 catalog、版本、provenance、policy 與觀測；對每次 agent run 保存實際資源與工具結果。資料撤權後，cache 與長期記憶也要同步失效。

Agent workflow 需要 durable execution 而非聊天歷史

多步 agent 可能搜尋、呼叫工具、等待人類或數小時後恢復。只保存 messages 無法表示外部副作用、pending approval 與 retry。每一步應形成具狀態 operation，並把模型輸出視為建議或輸入。

恢復時從 durable checkpoint 讀取，不要求模型重新猜過去。工具結果綁 hash 與 expiry，外部狀態在執行前 fresh read。若 approval 之後資料漂移，必須重新評估，不沿用舊許可。

Prompt injection 是 context layer 的資料問題

文件、網站或 tool output 可能包含要求 agent 忽略政策的文字。系統必須把資料與指令分層，外部內容標記來源與信任等級，不讓它提升權限。

工具選擇由 policy engine 驗證，模型無法自行解鎖。敏感動作需要 deterministic checks、參數 allowlist 與人類核准。稽核保存被拒原因，但避免回顯秘密。

供應鏈與執行隔離同樣重要

Flow 可載入任意 Python package，MCP server 也可能執行第三方 code。Dependency compromise 會取得 worker 權限。正式 artifact 需鎖版本、來源與 digest，建立 SBOM 並掃描。

不同信任等級在 container 或 sandbox 隔離，限制網路、檔案與 credential。暫存目錄不跨租戶，完成後清理。Agent 生成的 code 先離線測試，不能直接進具 production secrets 的 worker。

Jeremiah Lowin 留下的可靠性方法

第一，不把 failure 當例外，而把它設計成狀態與恢復路徑。第二，讓 Python 工作可漸進編排，但以 run identity、結果與 policy 補上自由帶來的風險。第三，把相同方法延伸到 agent tool 與 context。

可靠自動化不是永不失敗，而是失敗時不遺失身分、不重複不可逆副作用、能看見未完成狀態並安全繼續。這對資料 pipeline 與 AI agent 都是同一個基礎問題。

導入團隊的分階段路徑

先選一個現有 Python pipeline，以 flow/task 加入 run identity、retry、timeout 與 artifact hash；使用隔離 work pool，故意在副作用前後終止 worker，驗證恢復與冪等。

第二階段加入 event、automation、quota 與 data-quality SLO。最後才把工作流或工具暴露給 agent，先 read-only metadata，再低風險 preview，最後才是有 approval、policy 與完整 read-back 的有限寫入。

延伸閱讀

若想延伸理解資料工作流如何走向Agent協作，可以接著閱讀Harrison Chase與LangChain：從鏈式呼叫到Deep Agents，對照工作流編排、工具協議與代理治理。

官方資料與延伸閱讀

• Prefect：Jeremiah Lowin 創辦歷程
• Prefect 3 官方文件
• Prefect 3.0 官方介紹
• Prefect 收購 Dagster Labs 官方公告
• Prefect Horizon 官方介紹
• Prefect 加入 Agentic AI Foundation