AI代理成效不彰?IBM研究:關鍵更在於流程設計
IBM最近就發表一項研究,點出這種關鍵差異不在模型本身,而在於整個流程設計。
AI不只是回答問題,而是在跑流程
這項研究指出,一個AI代理在執行任務時,通常會執行多個步驟,例如先理解問題、再進行資料檢索(RAG)、接著呼叫工具,甚至執行程式碼,最後再驗證結果是否正確。
這些步驟的順序、是否需要重複,以及在什麼情況下觸發,都會直接影響最終結果的品質與成本。換句話說,AI代理之間的差異,不只是模型能力,而是這條流程如何被設計。

最佳解不在兩端,而在中間的「半動態」
但目前,大多數團隊在流程設計上,仍停留在兩種極端。
一種是將流程全部寫死,例如固定先查資料、再讓模型回答。這類方式雖然穩定,但缺乏彈性,難以應對不同任務情境。另一種則是完全交由AI自行決定下一步,雖然靈活,卻容易出現不必要的操作,例如重複查詢或過度使用工具,進而導致成本上升,也較難控管錯誤。
IBM認為,更有效的設計應該介於兩者之間,也就是「部分固定、部分動態」的半動態流程。例如,先定義整體任務框架,但允許AI在特定步驟中,自行判斷是否需要查資料、是否呼叫工具,或是否進行額外驗證。這樣的設計,在維持可控性的同時,也保有彈性。
在許多AI Coding與多代理(multi-agent)系統中,也已出現類似做法,例如讓AI先根據規格(spec)規畫步驟,再決定是否生成程式碼或呼叫工具。
不只是提示詞,流程才是影響結果的關鍵
研究也指出,目前許多團隊仍將重心放在提示詞(Prompt)優化,但實際上,影響系統表現的更大因素,是整體流程(Workflow)本身。
這包括AI代理在執行任務時,如何選擇與調度工具、如何使用記憶體、何時該停下來或再試一次等。換句話說,AI表現好不好,不只是模型能力,而是整個系統如何運作。
舉例來說,當AI在完成一個任務時,可能會先嘗試直接回答;若不確定,再去查資料或呼叫工具輔助。在這個過程中,它需要持續做出判斷:什麼時候該用工具、要不要保留前面的資訊,以及出錯時應該重試還是停止。
而這些判斷,其實就是流程設計的核心。
從「看結果」走向「看過程」的優化方式
另一方面,IBM歸納了AI代理的流程優化方法,包括任務指標(Task-specific metrics)、驗證機制回饋(Verifier feedback),以及使用者偏好(Human preferences)等。這些方法,可用來調整AI代理系統行為,進而影響整體流程設計。
其中,驗證機制不只能用來檢查結果正確性,還會進一步影響流程本身。例如,在程式生成或問答場景中,當答案未通過驗證時,系統可自動觸發重新生成、補充檢索,或改變推理路徑,形成一種持續修正的回饋迴路。
此外,IBM也特別強調對執行過程(Trace)的分析。透過拆解AI每一步的決策與行為,可以判斷錯誤發生在哪個環節,比如是檢索內容不準確、工具選擇錯誤,還是推理過程出現偏差。
更重要的是,這些過程資訊不只能用來除錯,還能變成優化指標,用來調整整體流程設計,甚至影響後續決策策略。
這也意味著,AI系統的優化方式,正從單純的檢視最終輸出結果,轉向分析整個決策過程。
評估AI:不只看有沒有答對,還要看怎麼做到
除了設計方法,IBM還提出新的評估模式。過去,開發者評估AI系統,多半聚焦準確率和回應速度,但這篇研究認為,開發者應該進一步評估整體流程。
例如流程是否過於複雜、是否產生過多不必要的工具呼叫、在不同任務下是否仍能穩定運作,以及Token成本是否隨流程設計而放大。也就是說,評估AI代理,不只看有沒有答對,還要看「它怎麼做到的」。
IBM總結,AI代理的表現,不只取決於模型本身,也和整個任務流程怎麼安排有關,包括是否需要查資料、何時使用工具、怎麼利用記憶,以及如何驗證等。比起過去著重在單次輸出或提示詞(Prompt)的調整,最近越來越多研究把重點放在整體執行流程(Execution process),也就是AI在完成任務時,每一步的串接與協作。
From Static Templates to Dynamic Runtime Graphs: A Survey of Workflow Optimization for LLM Agents
Large language model (LLM)-based systems are becoming increasingly popular for solving tasks by constructing executable workflows that interleave LLM calls, information retrieval, tool use, code execution, memory updates, and verification. This survey reviews recent methods for designing and optimizing such workflows, which we treat as agentic computation graphs (ACGs). We organize the literature based on when workflow structure is determined, where structure refers to which components or agents are present, how they depend on each other, and how information flows between them. This lens distinguishes static methods, which fix a reusable workflow scaffold before deployment, from dynamic methods, which select, generate, or revise the workflow for a particular run before or during execution. We further organize prior work along three dimensions: when structure is determined, what part of the workflow is optimized, and which evaluation signals guide optimization (e.g., task metrics, verif
arxiv.org
Comments (0)