架構

AI 工作流設計：多步驟代理流程的五種模式

作者：IdeaBosque最後更新：2026年9月1日

核心要點

到 2026 年 8 月，透過 OpenAI 的 MCP 工具呼叫達到 1 月水平的 98 倍，僅 8 月就翻了一倍以上（AAIF）——一個使用者請求現在觸發包含多次呼叫的工作流，這使工作流設計而非提示詞設計成為生產紀律。
Gartner 預測到 2028 年每個代理工作流的 AI 推理成本將上升五倍以上——每 token 價格下降的同時每工作流成本上升，因為代理工作流消耗的 token 比聊天高出多個數量級。
MCP 路線圖將 Tasks 改造為官方擴充（SEP-2663），並新增 Multi Round-Trip Requests（SEP-2322），使多步驟流程能在無狀態伺服器上存活——協定現在假設工作執行時間長且跨越多輪。
OpenAI 聲明其失準監控器可能暫停「代理長時間執行的任務」，且 API 任務會停止而非恢復——生產工作流必須能從持久狀態恢復，而不是從活程序恢復。
一個 38 工具的 RFQ 模組在程式碼中執行所有這些模式——由 guard 強制的狀態轉換、15 分鐘 TTL 上的冪等預留釋放、以及報價時凍結的 FX 快照。

據Agentic AI Foundation 的使用分析，ChatGPT 使用者的 MCP 工具呼叫在 2026 年 8 月達到 1 月水平的 98 倍——而且僅 8 月就翻了一倍以上。Resend 的 MCP 流量從供應商一側講述了同樣的故事：4 月 106,719 次呼叫，8 月 1,062,650 次。協定自己的維護者在新的 MCP 路線圖中給出了營運結論：「現代代理工作負載不再適合標準的請求-回應模式。迴圈可以執行更長時間，伺服器可以推送串流結果，並且顯然需要在中途引導工作。」

聊天從來不是難的部分。難的是工作流：一個 RFQ 背後的目錄查詢扇出、必須在 ERP 寫入之前到達的審批、在報價中途逾時的供應商 API、在定價與預訂之間不能漂移的匯率。Gartner 預測到 2028 年每個工作流的推理成本將上升五倍以上，即使每 token 價格在下降，因為代理工作流在多次呼叫中進行推理、談判和自我追問。本文定義了決定多步驟代理流程能否承受這種負載的五種工作流級模式——扇出、檢查點、補償、持久狀態和度量分支——並將每種模式錨定在一個註冊了 38 個 MCP 工具、對接 GraphQL 後端的可用 RFQ 實現上。

工作流是你設計的單元。下面的圖表把五種模式壓縮成一分鐘：並行讀取扇出、帶兩個人工閘門的串列寫入主幹、失敗時的型別化補償，以及將它們聯絡在一起的持久狀態規則。

模式 1：讀取扇出，寫入串行

第一個工作流決策是依賴圖的形狀。大多數多步驟代理流程大部分是並行的：一個 RFQ 需要來自三個供應商目錄的價格檔、五個行項目的批次可用性、以及客戶細分——這些彼此互不依賴。將這些步驟串行化會使延遲按步驟數倍增，也會使任何一次逾時的影響半徑倍增。正確的預設做法是並行發起所有獨立讀取，只串行化寫入鏈——鏈條中每一步都消費上一步的輸出。

報價工作流中的寫入鏈之所以嚴格有序，是出於業務原因而非技術原因：請求確認 → 報價建立 → 可用性預留 → 分期計劃。我們的 RFQ 引擎用程式碼中的 operation guards 強制這一點——RequestOperationGuard 拒絕從未確認的請求建立報價，QuoteOperationGuard 在報價通過可編輯視窗後拒絕行項目修改。工作流模式在所有系統中都相同：批次載入器後面的並行讀取、承載狀態變更寫入的窄串行主幹、以及放在程式碼而不是提示詞中的 guard。一個每次執行都「自行決定」排序的代理，是一個沒有不變量的工作流。

模式 2：人工檢查點是狀態，不是提示詞

第二個模式決定人所在的位置。在僅提示詞的設計中，「提交前詢問使用者」是模型可以遵循也可以不遵循的建議。在工作流設計中，檢查點是持久狀態：流程停在具名狀態中，持久化繼續所需的一切，只有人工操作才能使其向前推進。9 月 1 日，OpenAI 披露其生產失準監控器可以自動停止潛在的未授權活動——並誠實地指出了代價：安全防護「偶爾可能將合法活動標記為潛在網路濫用……這可能包括與網路安全沒有直接關係的工作，或代理長時間執行的任務」——這個區別從此變得具有營運緊迫性。在 ChatGPT 和 Codex 中，使用者會被要求審查暫停的任務；在 API 上，任務直接停止。

為那個世界構建的工作流把暫停視為設計出的狀態，而不是異常：執行記錄顯示完成了什麼、什麼在等待、恢復路徑是什麼。我們 RFQ 引擎的兩個便捷工具——confirm_request_and_create_quotes 和 confirm_quote_and_create_installments——之所以存在，正是因為人工閘門位於它們之間：人工確認，然後多步驟的機械工作作為一次被稽核的呼叫執行。Camunda 對 1,150 名高級 IT 領導者的調查發現 71% 的組織使用 AI 代理，但只有 11% 的用例到達生產；跨越這道鴻溝的工作流，是那些審批作為系統能停留數小時的狀態、而不是系統提示詞裡一句話的工作流。在執行時層執行檢查點的機制位於《Loop Engineering：為什麼代理執行時是新的中介軟體》；工作流模式是：在發布任何東西之前，決定哪些步驟為人停下、流程從什麼狀態恢復。

模式 3：每個前進步驟都需要補償路徑

第三個模式是教學跳過的那個：什麼來撤銷一個步驟。長時間執行的工作流會在半途失敗——供應商 API 在五行中的第四行返回錯誤、代理正在定價時預留過期、報價已批准但付款計劃失敗。沒有補償鏈的工作流把每次失敗變成手動清理。有補償的工作流把每次失敗變成一個型別化、冪等的反向操作。

報價實現展示了這一解剖結構。可用性預留以 15 分鐘 TTL 過期，失敗面被列舉為型別化錯誤——HOLD_NOT_FOUND、HOLD_ALREADY_EXPIRED、AVAILABILITY_INSUFFICIENT——每個映射到不同的恢復動作：複查、重新取得、或轉給人工。釋放預留是冪等的，因此網路分割後的重試不會雙重釋放，確認預留也絕不會重複扣減。工具呼叫包裹在帶指數退避的重試裝飾器中，每次呼叫的狀態、時長和載荷（超過 400KB 時卸載到物件儲存）都落入稽核記錄。這就是被泛化的模式：前進步驟獲取資源；補償步驟釋放它們；每個補償都可以安全地執行兩次。如果你的工作流說不出每一步的撤銷方式，它就不是工作流——它是一個還沒遇到供應商宕機的演示。

模式 4：無狀態協定，有狀態工作流

第四個模式解決了 2026-07-28 MCP 規範中一個表面上的矛盾。該規範移除了協定級工作階段和初始化交握（SEP-2575、SEP-2567），使伺服器無需保持狀態即可水平擴充；路線圖將 Tasks 改造為官方擴充（SEP-2663），同時 Multi Round-Trip Requests（SEP-2322）取代了伺服器發起的請求，使 elicitation 流程仍能在任務中途工作。協定是無狀態的；承載狀態的是工作流。具體來說：每個請求必須自包含到達，工作流的狀態存放在持久、可檢查的記錄中——而不是伺服器的記憶體裡。

這一架構選擇使上一個模式變得可存活。在我們的 RFQ 引擎中，預留的 hold_token 和 hold_expires_at 直接位於報價行項目上，匯率在報價時用 fx_rate_locked_at 時間戳凍結——是快照，不是活引用。任何伺服器實例都能接手下一個請求；重啟的程序從記錄恢復，而不是從記憶體。Astra 的警告使可恢復性成為平台互動要求，而不只是當機容錯：如果前沿模型的安全防護暫停了你 38 小時的無人值守執行，能存活的工作流是那個把狀態保存在程序之外的工作流。我們在《MCP 無狀態協定：對 B2B 部署意味著什麼》中介紹了無狀態規範的部署機制；在工作流層面，規則很簡單——把每一步都當作暫停前的最後一步來設計，讓下一步可以從稽核軌跡中重建。

模式 5：按測量資料分支，不按模型判斷

第五個模式治理條件分支。多步驟工作流包含決策點——這一行是否有足夠利潤可報價、這一批是否動銷慢到需要標記、這一客戶細分是否解鎖折扣檔。讓模型即興決定這些分支會把變異數重新引入唯一需要確定性行為的地方。工作流的答案是測量閘門：資料攜帶旗標，分支讀取它們。

在 RFQ 引擎中，每個報價行項目攜帶從批次記錄載入的 guardrail_price_per_uom 和 slow_move_item——「按目錄價報價」與「標記為毛利複核」的分支讀取兩個欄位，而不是讓模型估算毛利。折扣規則由四個層級範圍（全域、細分、商品、供應商商品）作為資料組合而成，而不是作為推理步驟。這也是工作流設計與成本相遇的地方：Gartner 的推理分析警告「將任務路由到代理推理模型會使供應商推理成本至少增加五倍」，並推薦「高度最佳化的推理分層、路由與編排」。基於儲存旗標分支的工作流把模型推理保留給需要它的步驟——定價判斷、異常解釋、談判起草——讓型別化資料決定其餘部分。同樣的紀律也出現在資料平台中，Dagster 的編排上下文工作將物化事件視為工作流消費而非重新推導的營運上下文。

五種模式，各一句話

讀取扇出、寫入串行——形狀是業務不變量，用 guard 編碼。檢查點是系統能停留的狀態，因為平台本身就會暫停你。補償是每個前進步驟的一等公民步驟，構造上即冪等。狀態存在於持久記錄中，不在協定或程序裡。分支讀取測量旗標，把模型推理留給為之定價的步驟。這些模式都不需要框架遷移；它們都需要按步驟決定誰擁有它——模型、執行時，還是人。

一個代表性構建

一個每週處理 200 個團體預訂 RFQ、橫跨酒店、航班和活動的中型旅遊運營商，基於這些模式重建了它的報價工作流。讀取並行發起——五個目錄、批次可用性、價格檔——透過一個單一 MCP 模組，該模組在 11 個領域 mixin 中暴露 38 個工具，每個工具的模式都是型別化的，每次呼叫都被稽核。寫入主幹串行：請求確認、組裝報價並在報價時鎖定 FX、以 15 分鐘 TTL 和冪等釋放取得預留、安排分期計劃。兩個人工閘門位於資金承諾之處——請求確認和報價確認——每個閘門都是流程可以停留數小時的持久化狀態。當供應商 API 在定價中途逾時，型別化錯誤將該行路由到複查，而不是破壞報價。報價週轉時間從三天的手動查詢降到四小時以內，每次寫入都有人工批准。結果是為精簡團隊提供了報價能力，而不是替代人力。