企業 AI 的 agentic workflow 在做什麼

IBM 把 agentic workflow 定義得很直白：AI 代理可以自己做決策、採取行動，還能協調任務。講白了，就是它不只會回話，還會做事。這差很多。像客服、營運、財務這些流程，常常不是「答對就好」，而是要一路處理例外狀況。

你可能會想問，這跟一般 chatbot 差在哪。差別就在於，前者照腳本走，後者會看情況改路線。當第一個方法失敗時，它可以重試、換工具，甚至重新拆解任務。這種能力，才是企業現在真正想要的。

IBM 的 agentic AI 文章也提到，這類系統已經從 demo 走向 production。說真的，這很合理。因為企業最怕的不是 AI 不會答題，而是 AI 遇到髒資料、缺欄位、權限不足時就當機。

什麼才算 agentic workflow

Agentic workflow 的核心，是 AI 代理能把一個大任務拆成很多小步驟。它會先規劃，再選工具，再看結果，最後決定要不要改路。這跟傳統自動化很不一樣。傳統流程像一條固定跑道，走錯一步就卡住。

拿 IT helpdesk 來說最有感。傳統腳本可能先問幾個固定問題，然後直接分類。Agentic workflow 則可以多問幾句，查 log，呼叫內部 API，甚至根據回傳結果換一條處理路徑。這就是它比較像「會思考的流程」。

企業工作本來就充滿例外。密碼重設很簡單，但網路斷線、帳單爭議、採購資料不一致，這些才是日常。規則寫得再完整，也很難涵蓋所有邊角。

所以 agentic workflow 不是把流程變神奇，而是讓流程有彈性。它能在第一步失敗後，不用人類立刻插手，先試著找出下一步。這點很重要，因為人工介入的成本其實很高。

• 它會先規劃，再執行。
• 它能呼叫工具，不只靠模型記憶。
• 它能根據回饋修正路線。
• 它能處理多步驟任務，不只單輪問答。

為什麼它跟 RPA 不一樣

RPA 很適合固定流程。像填表、搬資料、複製欄位，這些工作它做得很穩。問題是，RPA 很怕介面一改。按鈕位置換了、欄位名稱變了、頁面載入順序不同，它就可能失手。

Agentic workflow 的方向不一樣。它不是死背一條路，而是會判斷現場狀況，再決定下一步。這讓它更適合處理「流程長、變數多、例外多」的工作。企業裡很多事情就是這種型態。

Google 執行長 Sundar Pichai 在 2017 年 I/O 演講說過一句很有名的話：

“The role of AI is not to replace humans, but to augment human capabilities.”

實務上，這代表什麼。客服不必一開始就人工翻 log。財務不必每張單據都從頭比對。採購也不用每次都靠人眼檢查供應商資料。AI 先做前處理，人類再看最後結果，效率通常會好很多。

我覺得這種分工才健康。因為企業真的不缺「會講話的 AI」，缺的是「能把事情做完的 AI」。

它靠哪些元件運作

IBM 的說法很實際。要做出 agentic workflow，你需要模型、工具、記憶、規劃、回饋。少一個都不太行。只有 LLM，頂多是聊天機器人。加上工具後，才有機會變成能辦事的系統。

LLM 負責理解語意和生成內容。工具負責查資料、呼叫 API、跑腳本、讀寫資料庫。記憶負責保存狀態，讓系統知道前面做過什麼。規劃則是把大任務拆成可執行的小步驟。沒有這些組件，流程就只是看起來很會講。

回饋機制也很重要。高風險場景最好有人審核。低風險場景則可以讓系統自己修正。多代理架構也常見，一個代理做事，另一個代理檢查。這種設計雖然麻煩，但比較不容易出包。

下面這幾個工具，現在都很常被拿來做 agent workflow：

• IBM watsonx：企業 AI 基礎建設。
• LangChain：串接模型與工具。
• LangGraph：做有狀態的流程圖。
• crewAI：多代理協作。
• BeeAI：IBM 的開源代理框架。

這些工具不是誰取代誰，而是看情境選。客服、寫程式、採購、審核，需求完全不同。權限、稽核、記錄方式也都不同。企業如果一開始就想「一套打天下」，通常會踩雷。

哪些場景最先用得上

IBM 提到的場景很多，像客服、營運、財務、醫療、人資、行銷、採購、revops、銷售、供應鏈。這個清單很長，但邏輯很一致。只要工作有固定目標，又常出現例外，agentic workflow 就有機會派上用場。

客服是最直覺的例子。AI 可以先整理案件、抓帳號歷史、彙整對話，再把重點交給真人。財務也很適合。像發票缺件、金額不一致、附件不足，AI 可以先檢查，再決定要不要退件。

供應鏈也很吃這套。延遲、缺料、運輸異常，這些都是多步驟判斷。AI 可以先監控，再摘要，再建議下一步。對軟體團隊來說，agentic coding 也很像這個模式。它可以看 code、跑 test、修正錯誤、再驗證一次。

這裡有個很實際的比較：

• 客服：先收集上下文，再回應。
• 財務：先檢查缺件，再進入審批。
• HR：先分類請求，再產生草稿回覆。
• 營運：先監控異常，再通知處理人員。
• 工程：先跑測試，再修 code。

Andrew Ng 也提過一個例子。AI 工具先搜尋失敗，接著換成 Wikipedia 搜尋，最後還是把任務做完。這種 fallback 行為很關鍵。因為真實世界裡，工具壞掉比模型答錯更常見。

企業導入前要先看什麼

說真的，demo 很會騙人。畫面漂亮不代表 production 能跑。只要 agent 能動手做事，風險就會跟著上來。權限、紀錄、資料品質、失敗回退，全部都要先想好。

如果你在評估導入，先挑低風險工作。像內部 IT 協助、文件分流、工單整理、發票檢查、狀態更新，這些都很適合。因為輸入和輸出比較清楚，也比較容易量化效果。

不要一開始就碰高風險場景。像會影響金流、法遵、醫療判斷的流程，最好先有人審核。agentic workflow 不是萬能藥。它比較像一個很會跑流程的同事，但還是會犯錯。

我會建議團隊先看三件事：第一，任務能不能拆步驟。第二，失敗後能不能安全退回。第三，有沒有清楚的稽核紀錄。這三件事過不了，先別急著上線。

產業脈絡也很清楚。過去十年，企業自動化多半在做規則搬運。現在的壓力變成，資料來源更多、系統更多、例外也更多。只靠 RPA 已經不夠用了，因為真實工作不是固定表單而已。

所以 agentic workflow 的價值，不在於把人完全拿掉。它的價值，是把人從重複查核裡解放出來，讓人去做判斷、協調、例外處理。這才符合企業現場的樣子。

接下來會怎麼走

我猜接下來 12 到 24 個月，最先落地的還是那些「不性感但有用」的流程。客服分流、內部 IT、文件審查、採購比對，這些最容易先看到效果。原因很簡單，ROI 好算，風險也能控。

如果你是開發者，現在就可以開始想一件事：你手上的流程，哪一段最常卡在例外處理。那一段，很可能就是 agentic workflow 最有價值的地方。別先想做全自動。先想怎麼讓它少出錯、少叫人救火。

企業 AI 接下來比的，不是誰的模型會講更多話，而是誰的流程能在失敗後繼續往下走。這才是真正有用的地方。