為何 n8n 死了： 在線性 LLM 鏈（n8n 風格）中，下一步主要看到的是前一步的輸出，而該輸出是有限的。 在代理迴圈中，每次工具調用都伴隨著不斷增長的輸入記錄（目標、先前的調用、結果），這些內容可以存放在大得多的上下文窗口中，且通常位於快取中。 n8n 風格的鏈條是為一個不信任模型、且模型無法保留太多上下文的世界而設計的。當時將任務預先拆分為節點，使每個步驟都小、確定且可檢查。 這個前提已過時。現代模型能讀取約 1M 個 token，但它們每次仍只生成較少內容（通常約 64k–128k）。 因此，節點鏈不斷丟棄狀態：節點 N+1 只繼承節點 N 能夠輸出的內容，而非完整的運作集。 代理迴圈讓模型保持一個共享上下文，並在其中追加工具調用與結果。每次調用都能基於大型快取前綴進行條件處理，而非狹窄的交接。 可追溯性無法挽救舊模式。「哪個節點寫入了錯誤值？」與「哪個工具調用寫入了錯誤值？」是同一個問題。 兩者都是歸因問題。圖形讓步驟顯而易見，但若錯誤負載早已存在於串流中，它並不能讓事實更可信。 類比： 節點鏈就像郵件管道。撰寫者發送簡報，藝術家只看到該簡報，編輯只看到到達的內容，沒有人共用一張桌子。 代理則像一塊黑板。撰寫者、藝術家和編輯都在同一塊黑板上閱讀與書寫。黑板就是狀態。工具是這塊黑板上的手，而非密封的信封。 --- 需要明確的是，n8n 作為一款產品並未死亡。真正死亡的是線性 LLM 鏈。 n8n 可以封裝代理，並將工作流程視為工具。 但這並非其用戶常見的使用方式。大多數熱捧 n8n 的人，都是將它當作線性 LLM 鏈來使用。 當模型變得更強大，且如 opencode 之類的工具出現時，人們便不再認為 n8n 對大多數模式仍有必要。