一個 recipe 處理一項任務。一個 workflow 將多個任務串連起來。但有些自動化作業比單一工作流程更龐大——它們需要運行數分鐘甚至數小時、協調多個平行工作流,並需要優雅地從故障中恢復。
Playbooks 是 JieGou 對這類需求的解決方案。它們以非同步背景代理的方式執行工作流程,內建檢查點、故障恢復和並發控制機制。
Playbooks 的獨特之處
標準工作流程執行採用同步方式運行。客戶端會等待結果返回。這對於在幾秒到幾分鐘內完成的工作流程很適合。但對於一個包含 30 個步驟、需要處理一批文件、從三個外部來源豐富數據、等待審核,最後生成報告的自動化作業來說——同步執行會遇到實際限制。
Playbook 執行採用非同步方式。您啟動 playbook 後會立即獲得一個執行 ID。執行會在背景持續進行。您可以隨時查看進度,系統會在完成時通知您。
節點級檢查點
關鍵的架構差異在於檢查點機制。每個步驟成功完成後,playbook 會保存其狀態——包括所有步驟輸出、執行圖中的當前位置,以及任何迴圈或分支的上下文。
如果 playbook 在執行過程中崩潰——伺服器重啟、暫時性基礎設施故障、外部服務超時——它不會從頭開始重新執行。它會從最後一個檢查點恢復,從中斷的地方繼續執行。已完成的步驟不會被重新執行。
這對長時間運行的自動化作業很重要,因為重新執行已完成的步驟會浪費時間和金錢(LLM 呼叫並非免費),還可能造成副作用(您不會想重複發送同一封電子郵件)。
並發控制
Playbooks 能安全地處理平行分支。當 playbook 執行到平行步驟時,每個分支會獨立執行,並有適當的並發管理。資源鎖定機制可防止衝突操作,playbook 會追蹤哪些分支已完成,確保只有在所有分支都完成後,平行步驟才會結束。
進度串流
當 playbook 在背景運行時,UI 會串流即時進度更新。您可以看到:
- 目前正在執行的步驟
- 已完成的步驟(包含輸出預覽)
- 待執行的步驟
- 根據歷史執行數據估算的剩餘時間
這與同步工作流程使用的進度視圖相同,但它是透過輪詢方式非同步更新,而非長連線。
重試與恢復
當 playbook 步驟失敗時,系統會套用標準重試策略(指數退避、可設定的最大嘗試次數)。如果重試次數用盡且步驟永久失敗,playbook 會以錯誤狀態暫停。
從暫停狀態,您有三個選項:
- 重試失敗的步驟(在修復根本問題後,例如被撤銷的 API 金鑰)
- 跳過失敗的步驟,從下一個步驟繼續
- 取消整個 playbook
失敗後能夠恢復執行的能力——而非從頭重新開始——正是讓 playbooks 能實際應用於複雜多步驟自動化作業的關鍵。
何時使用 playbooks 與 workflows
使用標準工作流程的時機:
- 執行時間少於 5 分鐘
- 需要立即獲得結果(同步回應)
- 工作流程由使用者操作觸發,且使用者正在等待輸出
使用 playbooks 的時機:
- 執行時間超過幾分鐘
- 自動化作業涉及許多步驟或大量數據
- 故障恢復很重要(重新開始的成本很高)
- 自動化作業在背景運行(排程、觸發或即發即忘)
分享與分析
Playbook 執行支援與工作流程執行相同的分享模式——私密、部門、帳戶或群組可見性。團隊成員可以根據其存取權限查看進度、檢查步驟輸出並審查已完成的執行記錄。
Playbook 分析顯示執行頻率、成功率、平均執行時間和每次執行的成本。這些數據可幫助您識別哪些 playbooks 最有價值,以及哪些需要優化。
Playbooks 功能適用於 Enterprise 方案。深入了解 playbooks 或聯繫我們以取得 Enterprise 存取權限。