Cloudflare Agents 與 Workflows 的比較，在互動式助手開始執行超出對話時長的工作時尤其有用。智慧體可能需要解釋進展，背景過程則需要應對中斷並等待批准。這些責任相互關聯，卻具有不同的生命週期。
使用 Agents 提供持續互動的身分，接收事件並與使用者交流。當執行模式適合時，使用 Workflows 執行持久的背景步驟序列，包括等待和重試。當對話與長期任務需要獨立推進時，可以組合兩者，並讓外部業務影響始終能夠明確核對。
設想員工申請一項供應商評估。助手詢問缺失資訊並顯示狀態，評估任務收集記錄、準備報告，再等待同事作出決定。關閉瀏覽器不應丟失任務，重新連線也不應再次啟動評估。
本文用這個假設設計解釋邊界，不假定每個助手都需要兩種產品，也不認為持久執行會使所有外部操作都能安全重複。
Cloudflare Agents 與 Workflows：比較生命週期
Cloudflare 的 Agents 與 Workflows 文件 描述了互補角色：Agents 支援持續互動與身分，Workflows 支援持久背景執行。選擇起始模板之前，應先根據這些角色作出選擇。
對於供應商評估，對話有面向員工的生命週期，任務則有業務生命週期。員工可能斷開連線，另一位有權限的同事可能複核結果，而原始聊天結束後，評估仍可能繼續等待。
| 要求 | Agent 的責任 | Workflow 的責任 |
|---|---|---|
| 向員工提問澄清 | 展示問題並接收回覆 | 在適當時等待必需任務輸入 |
| 顯示進展 | 展示目前任務狀態 | 記錄已定義步驟中的進展 |
| 應對瀏覽器關閉 | 將已授權使用者重新連線到任務 | 按執行契約繼續或等待 |
| 處理批准 | 展示精確建議與呼叫者上下文 | 按任務規則執行獲准狀態轉換 |
| 解釋失敗 | 為使用者提供有用下一步 | 保留失敗階段與恢復證據 |
表格描述的是建議分工，並不意味著採用 SDK 就會自動獲得應用權限模型或業務狀態台帳。
從任務記錄開始，而不是聊天記錄
為評估分配穩定的任務編號。以無須重讀對話即可理解的形式，儲存負責人、來源版本、請求結果與目前狀態。聊天記錄可以解釋意圖，但不應成為已接受工作的唯一記錄。
使用者介面應區分正在討論的請求與已被接受的任務。如果員工點擊提交後回應丟失，重連時必須能確認任務是否存在。讓模型從最後一條聊天訊息推斷這一點並不可靠。
定義對流程負責人有意義的狀態，例如等待輸入、收集證據、待複核、已批准、已拒絕和失敗。明確誰可以轉換狀態，以及需要什麼證據。
任務編號應在對話介面改變後仍然有效。之後的郵件或儀表板可以展示同一項已接受評估，但不能成為決定任務行為的第二個權威來源。
讓持久步驟足夠小，以便解釋
Workflows 概覽 介紹了持久的多步驟執行。將這一能力用於輸入、輸出和恢復行為明確的步驟。若一個巨大步驟同時收集來源、生成文字並修改多個系統，失敗時就很難檢查。
對於評估，應將獲取來源記錄、生成報告和執行已批准業務決策分開。記錄報告基於哪些來源版本。來源變化後的重試，應遵循明確策略，不能悄悄生成不同評估。
不能將持久儲存的步驟結果，與外部副作用已經發生的證據混淆。目標系統可能剛接受請求，呼叫程序就丟失回應。應用需要操作編號或其他核對方式來確定發生了什麼。
能夠讓下一步明確的步驟邊界才有用。如果維運人員無法判斷應重試、更新證據還是聯絡複核者，邊界很可能缺少業務上下文。
將批准作為版本化業務事件
批准應對應精確評估版本與擬議後果。如果複核者開啟頁面後，來源記錄或報告發生變化，應要求應用先解決不一致，再繼續執行。
事件到達時，應認證複核者並檢查其任務權限。標識評估的 URL 不足以構成批准權限。不要讓工具結果或生成的句子替代同事批准。
| 批准條件 | 預期回應 |
|---|---|
| 目前報告且複核者有權限 | 接受允許的狀態轉換 |
| 開啟頁面後報告被替換 | 要求複核目前版本 |
| 重複批准事件 | 返回已確認結果，不產生另一次影響 |
| 複核者已無權限 | 拒絕狀態轉換 |
| 評估已被拒絕或取消 | 遵循已記錄的終態策略 |
取消也應類似處理。停止未來步驟，並不一定撤銷外部系統已經接受的請求。向使用者說明哪些工作已停止，哪些結果仍需核對。
從權威狀態重新連線
員工返回時，按其目前權限載入任務狀態，顯示最近記錄的階段與觀察時間。對話摘要可以提供幫助，但不應根據猜測覆蓋任務記錄。
將進展通知與權威狀態分開。錯過通知不應意味著錯過任務狀態轉換；反過來，收到通知也不應授權收件人檢視底層供應商記錄。
測試等待期間、失敗之後，以及另一位同事操作之後的重連。加入試圖提交舊決定的過時瀏覽器標籤頁。這些是跨班次、跨團隊業務流程的正常執行條件。
關於更廣泛的結果測試，我們的智慧體評估指南 解釋了為什麼僅有工具呼叫成功還不夠。這裡的關鍵，是正確任務是否繼續，以及使用者是否看到真實狀態。
選擇滿足需求的最小架構
執行簡短查詢的助手，未必需要單獨背景工作流；定時資料轉換，未必需要對話智慧體。同時新增兩者，會增加需要維護的設定、狀態關係與事故路徑。
| 負載 | 合理起點 | 新增另一層的理由 |
|---|---|---|
| 互動式查詢 | 已認證應用或智慧體 | 工作必須在互動之後繼續 |
| 定時處理 | 背景工作流 | 使用者需要即時任務互動 |
| 批准較多的評估 | 獨立任務狀態與持久處理 | 智慧體可改善澄清和狀態展示 |
| 開放式對話 | 具有有限工具的智慧體 | 某項已接受任務需要獨立執行 |
架構應使責任更清晰。如果沒人能解釋是智慧體還是工作流負責目前任務狀態，應先寫明契約，再增加工具呼叫。
為協調和故障測試編制預算
系統數量、任務轉換、批准角色及外部不確定結果越多，實施成本越高。聊天文字數量不能很好地代表這些工作。
要求 GBP 估算，分別列出任務設計、智慧體互動、工作流執行、目標整合與驗收。計入相依套件版本維護，以及部署時處理已在執行任務的流程。
應為選定服務和負載核實目前用量費用，分別估算等待、重複嘗試、推理、儲存與觀察工作。很少執行的背景任務，仍可能因為業務後果重要而需要細緻支援。
有用的試點應演示關閉瀏覽器、程序中斷、重複批准與目標逾時，並讓維運人員無需重建聊天就能找到評估、確定下一項安全操作。
我們可以透過範圍明確的 AI 整合試點 定義這一契約。請提供任務階段、關聯系統和批准角色，索取智慧體工作流方案 。讓執行時選擇服從團隊實際需要完成的工作。
常見問題
Agents 與 Workflows 是競爭產品嗎？ 兩者優勢不同，也能協同工作。Agents 適合持續互動與身分，Workflows 適合持久背景步驟序列。應根據應用生命週期選擇組合，不能假設每項任務都需要兩者。
每個 AI 助手都需要 Workflow 嗎？ 不是。簡短互動任務可能無需它即可處理。當已接受工作必須獨立繼續、等待事件或透過明確階段恢復時，再考慮持久背景處理。
持久執行能防止重複業務操作嗎？ 仍須仔細判斷外部系統的行為。即使回應丟失，目標仍可能完成請求。對有重大影響的操作，應使用穩定操作編號和已記錄的核對策略。
批准狀態應該存在哪裡？ 存放在關聯精確建議版本和複核者的權威任務記錄中。對話可以展示並解釋決定，但不應成為批准的唯一記錄。
使用者關閉瀏覽器後會怎樣？ 應用應獨立於連線保留已接受工作。使用者返回時，認證使用者並載入目前任務狀態，而不是重啟作業或讓模型猜測進展。
試點應該測試什麼？ 測試正常流程，以及斷開連線、處理中斷、過時批准、重複事件與目標結果不確定。報告應說明每個狀態由哪個元件負責，以及維運人員如何恢復。
組合實現需要多少錢？ 成本取決於任務轉換、系統整合、權限角色與恢復要求。應索取範圍明確的 GBP 估算，分別列出互動、處理、驗收與支援工作，而不是只按聊天功能報價。