為什麼 Microsoft Agent Framework 的耐久工作流很重要

Microsoft Agent Framework 的耐久工作流，能把脆弱的 agent 串接變成可恢復、可觀測的狀態式系統。

Microsoft Agent Framework 的新工作流模型是對的方向，因為它把容易失敗的 prompt 串接，變成能承受重啟、等待與中斷的狀態式軟體。官方 .NET 文章已經把重點講得很清楚：同一份 workflow 定義可以先在記憶體中跑，之後再切到具備 checkpoint、分散式執行與 dashboard 的耐久 runtime，而且不必重寫 executor。這不是小幅改善，而是把「demo」和「能上線」分開的關鍵差異。

第一個論點：耐久性不是加分項，而是 agent 系統的基本盤

這次更新最重要的不是 graph 語法，也不是 executor 抽象，而是框架承認失敗是常態。在 in-process runner 裡，workflow 只存在記憶體中，程序一當機或重啟，狀態就消失；耐久 runtime 則在每個步驟後自動 checkpoint，讓流程可以接著跑，而不是從頭再來。對多步驟 agent 系統來說，這不是便利功能，是最低要求。

文章中的訂單取消案例很能說明問題：先查訂單，再取消，再寄信，三個步驟各自由 executor 負責。當這條流程被放進 Durable Task Scheduler 後，每一步都會變成可追蹤的 durable activity，dashboard 也能看到執行時間線、輸入與輸出。當客服問「退款步驟有沒有跑」或 PM 問「為什麼審批卡住」，這種可觀測性就是答案。沒有它，agent 系統只是在黑盒子裡賭運氣。

第二個論點：圖狀工作流比零散的 agent 呼叫更接近可維護軟體

MAF 的 workflow builder 不是把 agent orchestration 做得更花俏，而是做得更像工程。typed executors、directed edges、編譯期合約檢查，再加上 sequential chain、parallel fan-out/fan-in、branching 與 human approval，這些都在逼團隊把資料流講清楚。研究顯示，Google 的 DORA 指標長期都在強調可預測性與變更風險控制，而圖狀結構正是把風險顯性化的手段。

fan-out/fan-in 的例子尤其有說服力。文章展示 MAF 直接把 AI agents 當 executor，用 AsAIAgent extension 讓同一份輸入平行送給多個 agent，再等全部完成後往下走。這不是玩具抽象，而是實際架構原語：一個 agent 負責研究，一個負責批判，一個負責摘要，工作流圖就能精確表達。相較之下，手寫 orchestration script 往往只剩下一串 retry、if/else 與 prompt glue，出事時連責任邊界都看不見。

反方可能怎麼說

最強的反對意見是：這又是一層框架。市場上已經有 orchestration system、durable runtime、agent SDK，團隊為什麼還要再學一套 MAF？更現實一點說，workflow abstraction 常常把複雜度往後藏，開發時看起來整齊，到了 production 才發現跨步驟除錯很痛，尤其是涉及模型呼叫、重試與人工作業時。

這個疑慮不是錯的，但只在框架沒有帶來槓桿時成立。MAF 的價值正是把同一份 workflow 定義從 in-memory 直接搬到 Durable Task，hosting 只換一層，executor 邏輯不必重寫。這代表它不是再包一層脆弱抽象，而是在 local 開發與 production durability 之間提供可移植性。限制也很明確：如果你只是做單次、無狀態的模型呼叫，這套東西確實太重；但只要是多步驟、需要 checkpoint、需要人工審核的 agent 流程，耐久工作流就是必要條件，而不是附加選項。

你能做什麼

如果你是工程師、PM 或創辦人，現在就該停止把 agent orchestration 當成 prompt engineering 的延伸。把每個有業務意義的步驟拆成 executor，讓 graph 保持 typed 與顯式，先用 in-memory runner 做本地迭代，等流程一旦牽涉到使用者、金流、審批或 SLA，就切到耐久 runtime。先求可恢復、可觀測，再談更聰明的 agent；這才是把 AI 系統做成產品的正確順序。