最近蠻多人在問: 「n8n / Dify / Langflow 這些視覺化工作流程工具適合拿來做 AI Agent 應用嗎?」

小編的觀點是: 如果是個人自動化、簡單流程串接，沒什麼問題。但如果你的目標是打造一個能上線、給真實用戶使用的對話型 AI 應用，這條路埋了很多雷。

有個比喻蠻貼切的:

用視覺化平台來做 AI 應用，就像有兩種做菜方式: 一種是廚師親手用原材料烹調；另一種是只能在 7-11 挑現成食品，不能開火，只能用微波爐加熱。

兩種方式都能填飽肚子。如果只是自己吃、圖方便，去超商買沒問題；但如果你想開餐廳、做出讓客人滿意的料理，沒有人會拿超商食品和微波爐來做。

本文適用範圍: 非軟體專業用戶 + 視覺化流程工具 + 開發 Agent 對話應用，三個條件集齊，就是一個完美地雷。

工作流程工具本質上就是編程，只是更糟

視覺化工作流程工具的賣點是「No-Code」，讓不懂程式的人也能串接 AI 流程。但有工程師直接點出了這件事的本質:

工作流程建構器本質上就是編程，只不過更糟。你還在調試邏輯，但它現在被埋在 84 個巢狀節點裡，你必須點擊才能找到。這實際上比寫程式碼還難。抽象化只會讓一切變得更糟，你付出了所有的程式設計努力，卻得不到任何好處。

LangChain 的創辦人 Harrison Chase 也直接說不看好視覺化工作流程建構器，理由是: 視覺化介面門檻其實沒有比較低，而且一旦複雜度提升，維護起來非常麻煩。他們後來推出的 LangSmith Agent Builder 選擇的方向是讓用戶用自然語言來建立和調整 Agent，而不是拖拉節點。

應該先做 Agent，再加入工作流程邏輯

這是整件事最核心的觀念翻轉。

有人提出正確的順序是: 先做一個 Agent，然後再加入工作流程邏輯來具體改善 TTFT（首字延遲）、速度、和可靠度。

錯誤的順序是: 先設計工作流程，把所有你「想像中」可能的情境都節點化。問題在於，這些節點大多數是根據你的猜測設計的，特別是當你沒有工程背景，就更容易「過度設計」——拆了一堆節點，每個節點又多一次 API 呼叫，結果整個系統又慢又貴又難維護。

視覺化工作流程的六大技術反模式

小編整理出來，在實際看過幾個用視覺化工具建出來的 Agent 應用後，最常踩到的問題:

🔴 1. 多餘的 Router 節點

到處加「分類路由」節點，把問題導到下一關，但下一關只是換一個稍微不同的 prompt 來回覆——其實第一關的 Agent 本來就有能力直接回答，根本不需要多跑一次。這種「先判斷，再導流，再回覆」的三段式設計，看起來結構清晰，實際上只是把一個 API 呼叫拆成了兩個，多花錢、多等時間。

結論: 節點越多不代表越聰明，只是越慢、越貴。

🔴 2. 假的結構化輸出，多一個修 JSON 的節點

很多視覺化平台沒有好好支援 structured output（結構化輸出），所以 LLM 輸出的 JSON 有時格式不對，結果你需要再加一個節點，專門用另一個 LLM 呼叫來修 JSON。

這就是用 LLM 的算力來修自己造成的問題，而且成本和延遲都是白白浪費的。

🔴 3. 沒有平行處理，串行到底

需要一次擷取多個 metadata 的場景，正確做法是平行呼叫。但在視覺化工作流程中，通常只能一個接一個串下去，每串一個就多一段等待時間，最後 latency 疊加起來非常可觀。

🔴 4. Prompt Cache 幾乎失效

工作流程平台的架構通常是 output → input 的串接，而不是 append 訊息 的結構。這導致每個節點都在建立一個全新的 system prompt，prompt cache 無法命中。

正確實作 cache 的 Agent，在第二輪對話之後，成本可以剩下不到 1/10。而工作流程方式你以為比較省，實際上根本沒有在省，反而在反覆付全額。

對話歷史也是個大問題: 視覺化工具裡，對話紀錄往往是以「變數」形式插進 prompt 字串，而不是原生的 message 陣列格式。這意味著只要有任何微小差異，cache 就會完全失效。

🔴 5. 沒有設計 handoff，每次都重頭來

缺乏 handoff 設計，導致每次新對話都要重跑全部節點，無法從上下文繼承狀態。這在多輪對話場景特別致命。

🔴 6. 根據問題類型拆節點，而不是根據職能拆 Agent

這是設計哲學上的根本錯誤。

有些人會把「查訂單的問題」「退換貨的問題」「產品諮詢的問題」分別建不同的節點來處理。但用戶在實際對話中，往往一句話同時涉及多個類別——「我買的那個東西壞了，可以換嗎？順便幫我查一下我的訂單狀態。」

這就像傳統電話客服的選單樹: 「請按 1 查詢訂單、按 2 退換貨…」，結果用戶的問題橫跨多個類別，或根本不在選項裡，最後還是要轉真人。

你沒辦法窮舉所有可能性。硬要窮舉，只會得到一個又慢又貴又不實用的系統。

正確的設計思路: 根據 Agent 的職能範圍來拆，而不是根據問題種類拆。相關問題應該由同一個 Agent 處理，用 function calling 本來就有能力處理多重開放性問題。

Workflow 適合確定性任務，Agent 適合動態決策

有一篇文章用機場安檢 vs 醫療診斷來對比這兩個情境:

機場安檢（適合 Workflow）: 步驟固定，擷取身分證號 → 比對照片 → 驗名字。所有步驟可預測，甚至可以平行處理。

醫療診斷（適合 Agent）: 28 歲患者發燒，跟 55 歲患者體重暴減，需要完全不同的診斷路徑。Agent 必須根據每一步的發現動態調整下一步，workflow 根本做不到。

AI 對話應用的本質，更接近醫療診斷，而不是機場安檢。用戶說的話是開放性輸入，不是表單欄位。你設計再多的節點，也無法預測下一句話。

模型在進步，你的節點在退步

還有一個容易被忽略的點: 模型能力在快速進步，很多你以為需要的節點，其實是在補模型的舊缺陷。

  • 多餘的 JSON 整理節點: 因為平台沒有好好用 structured output
  • 多餘的路由節點: 因為以為一個 prompt 處理不了多種情境
  • 多餘的判斷節點: 因為以為 LLM 不夠「聰明」

等到模型能力再提升一代，這些節點不但沒有幫助，反而成了系統裡的阻力。而用程式碼寫的 Agent，可以隨時調整邏輯；視覺化工作流程，每一個「修改」都意味著要點進去找節點、改節點、測試節點，工作量其實不比程式少。

小結

有人說得蠻準的: 「大多數人沒有建立有用代理人所需的那種結構化思維，而那少數有這種能力的人（通常是工程師），比起視覺化編輯器更偏好有更多掌控權。」

視覺化工作流程工具，給了一個「門檻低」的幻覺。但做 Agent 應用，真正的門檻從來不是「會不會拖拉節點」，而是「能不能正確設計 AI 的決策流程、context 管理、和工具呼叫策略」。

這些能力，在視覺化工具裡反而更難培養，因為抽象化把工程細節藏起來了，你不知道自己在做什麼，出了問題也不知道怎麼修。

要真正培養做 AI 應用的能力，我們需要的是會做菜的廚師，而不是學習怎麼在超商挑微波食品。