n8n把一個對話式構建器放到了其工作流自動化平臺的核心位置，而真正值得留意的細節不在演示裡，而在計費方式上。n8n Assistant並不會在畫布上畫出工作流後就撒手不管：它會實際執行、開啟執行資料、判斷哪裡出了問題，然後再試一次。而每一次嘗試都在消耗套餐中附帶的AI額度。一次就跑通的請求成本低廉，需要來回修上四輪的請求則不然。
核心要點
- n8n Assistant根據自然語言請求生成標準且可編輯的n8n工作流，並且不是把未經驗證的結果丟給使用者，而是自行執行並除錯。
- 它完全取代了此前的AI Workflow Builder，其開銷從各套餐已有的AI額度中單獨計量。
- 新建的n8n Cloud例項預設啟用；自託管的Docker使用者需要2.36及以上版本並自備模型金鑰，企業版目前不在支援範圍內。
最後留在手裡的是什麼
用一句話生成自動化，早已不再是差異化優勢。n8n強調的是可延續性：讓程式設計智慧體去接一個整合，你會接手一堆需要有人託管和維護的程式碼；而一個只管把活幹完的開放式助手，在執行結束後什麼也不會留下。這兩種結果，都不容易交給當時不在場的同事。
Assistant產出的東西刻意顯得平平無奇——與人工搭建別無二致的節點圖，位於同一個專案中，帶著同樣的執行記錄。這讓團隊裡任何人都能檢視，可以做版本管理，也能在不追溯模型當時作何判斷的情況下把它講清楚。對於一個始終以"邏輯看得見、歸你所有"來對抗託管式無程式碼競品的平臺來說，把這一屬性延伸到生成的工作流上是一條前後一致的路線，而非一句營銷話術。
生成是便宜的那一半
大部分工程量都落在畫布填滿之後。Assistant會執行自己構建的內容，並讀取開發者會去檢視的那些逐節點的輸入、輸出與報錯——這與"因為產出了東西所以算成功"是性質不同的說法。一旦失敗，它會診斷、給出修復方案、應用補丁並再次執行，中間無需匯出JSON，也不用在工具之間來回複製貼上。
面對含糊的指令，它給出的是提問而不是猜測：一句籠統的"把表單回覆分流出去"，會換來"哪個表單、發到哪裡"的追問。憑據也不在一開始就索要，而是在某個節點需要時才請求，這意味著看到第一個結果之前無需做任何配置。有兩個動作被留在明確的人工確認之後——授予憑據訪問許可權，以及啟用工作流——這可以避免這套迴圈在生產環境裡悄悄開啟某個開關。
誰能用，以什麼條件
可用範圍分三種情況。新建的n8n Cloud例項無需任何操作即為開啟狀態；Enterprise Cloud被排除在這一預設之外，更廣泛的企業版支援只被描述為在路線圖上；自託管則需要Docker、n8n 2.36或更新版本、自備模型金鑰以及若干額外的環境變數。
在團隊裡有人開始試用之前，最該算一算的是額度賬。已有配額不受影響，這裡的用量也與被取代的構建器分開統計，因此已經排好的預算不會變化——但消耗量會隨著一次構建所需的修復輪數而上升，而充值選項還要等上幾週。把真正棘手的整合交給Assistant的團隊，可能會發現計量表轉得比演示中暗示的要快。
它明確不做的事
這次釋出對自身短板說得相當坦率。它產出的任何內容都不保證可直接投入生產，稽核結果仍是人的責任。它無法憑空給你開通一個尚未註冊的服務賬號，所以第三方配置並沒有消失，只是挪到了更合適的時點。它是被動響應而非主動出擊：不監控例項、不學習使用偏好、也不會主動提建議。它只針對單個例項工作，不會觸碰你的瀏覽器或機器，不過藉助瀏覽器完成憑據配置正在探索之中。
後市觀察
預覽標記意味著功能仍在積極開發，而不是要排隊等候，而且它已經預設送到了雲端使用者手中。真正的考驗在於，修復—重跑這套迴圈能否在遠大於演示規模的工作流上收斂；在那種規模下，智慧體可能一輪輪嘗試始終不到位的修復，把額度白白燒掉。如果它站得住腳，更有意思的是方向性的啟示：產出可留存、可複核的成果而非一次性執行的智慧體工具，今年在設計為無人對話時仍持續工作的智慧體身上也能看到同樣的思路。配置細節可參閱n8n Assistant官方文件。
常見問題
n8n Assistant會取代AI Workflow Builder嗎？
會，而且是完全取代。n8n指出的區別在於，此前的構建器生成工作流後便告一段落，而Assistant還會執行自己的產出、讀取執行資料並持續迭代改進。
自託管的n8n使用者能用上Assistant嗎？
版本在2.36及以上的Docker部署可以啟用。與n8n Cloud不同，自託管需要先自備模型金鑰並設定額外的環境變數。
把它直接對準生產系統安全嗎？
請把它產出的一切當作草稿。憑據訪問與啟用都需要你本人確認，n8n也明確表示首次生成的工作流不保證可投入生產。在啟用任何關乎業務的流程之前，先讀節點、核對憑據、檢查日誌。