--- author: OOMOL author_url: https://oomol.com/zh-tw/about/ datePublished: 2026-10-06 title: AI Agent 時代，我們為什麼還需要工作流程？ description: Agent 也能透過排程執行任務。什麼時候值得使用工作流程？從固定業務規則、人工審核與版本維護出發，探討 Open Flow 如何與 Agent 配合。 lang: zh-TW canonical_url: https://oomol.com/zh-tw/blog/open-flow-agent-era/ markdown_url: https://oomol.com/zh-tw/blog/open-flow-agent-era.md --- ![AI Agent 探索任務路徑，並將確認的方法組織成包含觸發、處理、審核與通知的工作流程](/blog/open-flow-agent-era/zh-tw-cover.webp) 每天早上九點，讓 Agent 分析訂單並傳送報告，設定排程就能啟動。接入事件或 Webhook，也可以讓它在資料變動後開始工作。 如果報告符合預期，處理過程也很簡單，這樣可能就夠了。 執行一段時間後，要求可能變得更具體：退款率必須依統一標準計算，只分析指定範圍的資料，傳送訊息給客戶前必須經過審核。計算規則修改後，還需要查清哪些報告使用了舊版本。 這時要考慮的是：哪些步驟允許 Agent 當場判斷，哪些步驟需要依照已確認的規則執行？任務等待審核時，狀態存在哪裡？換一個人維護，能否看懂它的處理過程？ 工作流程提供了一種組織這些要求的方式。它明確保存步驟、資料關係與審核條件，並由執行系統管理任務狀態。Agent 可以參與建置，也可以在其中處理需要理解與判斷的任務。 ## 已確認的規則，依同一種方式執行 以訂單日報為例，加總金額、分類狀態、篩選時間範圍，都有明確的規則。退款率的分母是全部訂單，還是已付款訂單？依下單時間還是退款時間統計？這些定義一旦確認，就應該寫進程式碼。 Agent 也能呼叫這段程式碼。工作流程進一步保存它與其他步驟的關係：從哪裡取得資料，計算結果交給哪個節點，什麼條件下繼續傳送報告。檢查時，可以逐項核對。 客戶留言表達了什麼、異常可能與哪些情況有關、摘要應該強調哪些內容，則可以交給 AI。例如先用程式碼篩選異常訂單，再將這些紀錄作為模型輸入，最後把摘要交給通知步驟。 這裡的確定性體現在計算規則與執行結構上。模型產生的判斷仍然可能變化，但它接收什麼資料、負責什麼任務，以及輸出用在哪裡，都有明確的位置。 ## 等待審核時，任務不能遺失進度 把情境換成客戶回覆：Agent 已經讀完郵件、查過訂單，也擬好了回覆，接下來等負責人核准。 負責人可能幾個小時後才處理。系統需要保存這次任務使用的輸入、已產生的回覆、完成到哪一步，以及核准或拒絕後該執行什麼。恢復任務時，也應沿用同一次執行的狀態，避免重新執行已完成的步驟。 這些機制可以在 Agent 系統中實作。選擇工作流程平台時，值得檢查的是它已經提供哪些狀態管理能力，能否滿足任務中途等待、人工決定與繼續執行的需要。 Trigger 負責啟動，通知或後續 API 呼叫負責交付結果。排程、事件、Webhook 與輪詢都可以啟動 Agent 或流程；它們是自動化的組成部分。下圖展示啟動後，規則、AI、審核與通知如何連接。 ![排程、事件或輪詢啟動流程，依序取得資料、依規則處理、進行 AI 分析、視需要審核，並通知結果](/blog/open-flow-agent-era/zh-tw-lifecycle.webp) *這是可自行建置的範例流程。觸發方式依任務選擇，審核是選用步驟；實際執行需設定資料來源、模型服務與通知帳號。* Open Flow 的 Approval 與 Wait 節點會持久保存等待狀態，作出決定後可以繼續同一次執行，無需重跑已完成的步驟。對於需要人工介入的任務，這是選擇它時可以具體評估的能力。[查看審核與執行說明](https://github.com/oomol-lab/open-flow/blob/main/docs/README.zh-TW.md) ## 換一個人維護，還能看懂這項工作嗎？ 任務剛開始時，你可能先讓 Agent 試做幾次，逐步確認資料來源、計算標準與報告格式。等其他人也要參與維護，就需要把這些決定留下來。 ![Agent 試做任務後，將固定規則、AI 輸入與審核條件整理成可檢查、可維護的流程](/blog/open-flow-agent-era/zh-tw-collaboration.webp) 維護者需要知道：哪個步驟讀取訂單，退款率在哪裡計算，模型取得了哪些資料，什麼條件下會傳送訊息。流程圖、輸入對應與節點程式碼可以幫助回答這些問題。專案的說明與設定也需要有人維護。 修改之後，還要知道每次執行使用了哪一版邏輯。例如，退款率的計算標準週一調整了，查看上週日報時，就需要找到當時的程式碼與輸入。將執行紀錄連結到具體版本，才能據此核對結果。 如果現有 Agent 系統已經提供這些能力，可以繼續沿用。工作流程平台的價值，是把這些常用機制組織在一起，減少團隊自行建置與維護的工作。 ## 用 Open Flow 保存並執行這些流程 Open Flow 是 OOMOL 開源的工作流程平台。你可以直接在 [OOMOL Flow](https://console.oomol.com/flows) 使用官方託管版，或到 [GitHub 儲存庫](https://github.com/oomol-lab/open-flow)查看原始碼與自行部署說明。讓 Agent 建立 Flow 後，可以在視覺化工作台 Workbench 中查看與修改同一個流程。 Agent 透過 `oo flow` 建立節點、檢查草稿、測試執行並查看結果。打開 Workbench 後，可以檢查它使用哪些資料、某一步的程式碼如何處理，以及分支條件是否符合要求。相容的客戶端也可以透過 Server 提供的 MCP 工具編排與執行流程。 對於前面的日報，Code Task 可以用 JavaScript 計算與轉換資料，LLM Task 產生摘要。如果需要多次工具呼叫，可以使用 Agent Task。輸入與輸出有明確的名稱和型別，重複邏輯可以整理成子流程。 上線後，你還會需要修改流程。Open Flow 發布時會建立帶版本的快照，供 Live 自動化執行。你可以繼續編輯與測試草稿，準備好後再發布新版本。執行歷史會連結對應的修訂版本，便於查明某份報告由哪一版程式碼與流程產生。 讀取外部應用程式的資料與傳送通知，需要設定相應帳號及權限。Open Flow 透過 OpenConnector 等 Connector 執行環境執行這些操作，帳號憑證由 Connector 保管，Flow 引用連線識別碼。[查看 Open Flow 的能力與執行方式](https://github.com/oomol-lab/open-flow/blob/main/docs/README.zh-TW.md) 官方託管版由 OOMOL 負責執行部署。自行部署時，儲存、備份、升級與服務連線由你的團隊管理。專案採用 Apache-2.0 授權，目前處於 Beta。帳號連線與 Agent 設定步驟見 [Flow 入門指南](https://oomol.com/zh-tw/docs/flow/)。 ### 用一項實際任務試試 選一件需要固定規則或人工審核的重複工作，在 [OOMOL Flow](https://console.oomol.com/flows) 打開工作流程，連接所需的資料來源與通知帳號，再把任務交給 Agent： > 為我建立一個訂單日報 Flow：讀取前一天的訂單，依我確認的標準計算金額與退款率，讓 AI 歸納異常，再把報告傳送到指定的團隊群組。先建立草稿並測試，等我檢查結果後再發布。 在 Workbench 中檢查資料、程式碼與輸出，確認流程符合要求。如果排程執行的 Agent 已經夠用，可以繼續沿用；需要更明確的規則、審核與版本紀錄時，再決定啟用這個 Flow。 - **[打開 OOMOL Flow，建立第一個工作流程](https://console.oomol.com/flows)** - 希望自行部署或參與開發？[查看 Open Flow 原始碼與部署說明](https://github.com/oomol-lab/open-flow)。