當啟用回應串流時，如果用戶端在 AI Agent 仍在串流時斷開連接（瀏覽器重新整理），執行會中止並顯示 { “isArtificialRecoveredEventItem”: true } 和「執行在此節點停止。」我希望即使用戶端斷開連接，執行仍能在伺服器端完成，同時保持串流開啟。
最小重現（原生 n8n，無自訂節點）
- 聊天觸發器（或回應模式為串流的 Webhook）。
- AI Agent 節點，enableStreaming: true，連接到：
- 任何聊天模型（例如 OpenAI Chat Model），
- 任何耗時數秒的工具（例如 HTTP Request 工具呼叫慢速端點—任何能讓代理保持繁忙足夠長時間以進行重新整理的工具）。
- 開啟內建聊天，傳送訊息使代理呼叫工具。
- 在仍在串流時立即重新整理頁面。
- 開啟執行→它已停止，AI Agent 輸出 = { “isArtificialRecoveredEventItem”: true }。
環境
- n8n：Cloud，版本 2.27.4
- AI Agent 節點 v3.1，Webhook v2.1 (responseMode: streaming)
預期 vs 實際
- 預期：用戶端失去串流不應中止執行；代理（以及任何工具的副作用）應在伺服器端完成。
- 實際：串流連接一旦中斷，執行立即中止→已復原/人工項目。
我已嘗試過
- 在 AI Agent 上停用 enableStreaming 可以避免這種情況—但這樣就沒有串流（在任一節點停用串流會回退到要求-回應）。
- 我知道存在立即回應 / 雙 Webhook 非同步模式，但那會失去即時串流。
問題
是否有支援的方法來分離執行生命週期與串流 HTTP 連接—即保持串流開啟，但當用戶端在串流中段斷開連接時讓執行完成（不中止）？任何設定或建議的模式？
您希望我：
- 匯出 1 個最小化工作流程（聊天觸發器 + AI Agent + 1 個模擬緩慢的工具 + LLM）為 JSON 供您附加—立即可重現，大幅增加獲得幫助的機率？
- 還是保留此版本，由您自行填入版本 + 附加圖片？
當啟用回應串流時，如果用戶端在 AI Agent 仍在串流時斷開連接（瀏覽器重新整理），執行會中止並顯示 { “isArtificialRecoveredEventItem”: true } 和「執行在此節點停止。」我希望即使用戶端斷開連接，執行仍能在伺服器端完成，同時保持串流開啟。
最小重現（原生 n8n，無自訂節點）
- 聊天觸發器（或回應模式為串流的 Webhook）。
- AI Agent 節點，enableStreaming: true，連接到：
- 任何聊天模型（例如 OpenAI Chat Model），
- 任何耗時數秒的工具（例如 HTTP Request 工具呼叫慢速端點—任何能讓代理保持繁忙足夠長時間以進行重新整理的工具）。
- 開啟內建聊天，傳送訊息使代理呼叫工具。
- 在仍在串流時立即重新整理頁面。
- 開啟執行→它已停止，AI Agent 輸出 = { “isArtificialRecoveredEventItem”: true }。
環境
- n8n：Cloud，版本 <填入版本>
- AI Agent 節點 v3.1，Webhook v2.1 (responseMode: streaming)
預期 vs 實際
- 預期：用戶端失去串流不應中止執行；代理（以及任何工具的副作用）應在伺服器端完成。
- 實際：串流連接一旦中斷，執行立即中止→已復原/人工項目。
我已嘗試過
- 在 AI Agent 上停用 enableStreaming 可以避免這種情況—但這樣就沒有串流（在任一節點停用串流會回退到要求-回應）。
- 我知道存在立即回應 / 雙 Webhook 非同步模式，但那會失去即時串流。
@sawsew467 這三個都沒有內建的旋鈕，串流執行會將執行綁定到即時連接，因此斷線會導致其關閉（那個恢復的項目是 n8ns 的通用「在完成前被殺死」標記，不是真正的 OOM），而且沒有文件記載如何解耦或重新連接。修正方法是不要在串流執行中運行必須存活的工作，將代理 + 記憶體寫入踢到一個單獨的非串流執行中，該執行在伺服器端完成，並讓客戶端在重新載入時重新讀取歷史。還要從串流中提取有副作用的工具（例如傳送電子郵件），這樣它們就不能在永遠不會持久化的轉向上觸發。
嗨 @sawsew467 ,
那個 isArtificialRecoveredEventItem 標記表示執行崩潰而不是被乾淨地取消。當瀏覽器斷開連線時，TCP socket 會關閉，n8n 的串流分塊發送器內的下一個 res.write() 呼叫會拋出 EPIPE 錯誤。這會透過 LangChain 回呼鏈傳播到工作流程引擎，導致執行在中途崩潰。恢復服務隨後會為任何已啟動但從未保存其輸出的節點填入人工佔位符。
所以 SSE 連線和伺服器端執行在 n8n 目前的串流實現中在架構上是耦合的。沒有設定標誌可以解耦它們。
你的實際選項：
**1. 在 AI Agent 節點上禁用串流：**你已經試過的做法，但值得明確說明：執行在伺服器端完全運行，零斷開風險，當工作流程完成時返回完整回應。UX 的權衡是真實的，但執行是可靠的。
**2. 立即回應，然後輪詢：**使用設定為「立即回應」的 Webhook 節點。它立即返回 executionId，工作流程在背景完全運行而不附加 HTTP 回應（沒有 SSE 連線可以掉線），用戶端輪詢 GET /api/v1/executions/{id} 以獲取結果。緩慢的工具總是會完成。你失去了串流 UX，但獲得了確定性執行。在 Cloud 上，只要你的 HTTP Request 不是極其緩慢，你就在 5 分鐘執行逾時內。
**3. 佇列模式 worker：**僅限自託管，Cloud 上不可用。即便如此，串流寫入失敗是否能完全解耦主流程執行狀態仍不清楚。
針對你的設置，如果你需要工具始終完成，選項 2 可能是更好的路徑。輪詢 UX 沒有 SSE 那麼優雅，但比希望用戶端保持連線要可預測得多。
如果具有斷開容限的串流很關鍵，這需要改變 n8n 如何處理 SSE 寫入錯誤的方式，特別是不將其傳播回執行引擎。
上面的两个回复都说得对，n8n 的内置代理流绑定了工作与活跃的请求，所以断开连接会中止执行，而且现在没有标志可以解耦。但你仍然可以同时获得流式 UX 和服务端完成的保证。诀窍是停止通过 n8n 的请求进行流式传输，将流移到客户端独立订阅的通道上。
可行的架构：
-
将转换视为持久的后台工作。以 PurveshGandhi 的选项 2 为基础：webhook 立即用一个转换 id 进行响应，代理在服务端运行到完成，不附加 SSE，无论如何都会发生内存写入。仅这一点就使必须保存的工作不会因为断开连接而失败。
-
通过将块写入外部通道而不是 HTTP 响应来恢复流式传输。当转换生成输出时，将其写入浏览器可以独立订阅的内容：Supabase 实时行、Redis pub/sub、Ably，或者甚至客户端每秒轮询几次的 partial_response 列。浏览器从该通道读取，永远不从 n8n 的 SSE 读取。现在断开连接只会丢失读取端，执行继续运行，重新加载时客户端重新订阅并从存储的部分赶上进度。这就是拥有两者的答案：工作绑定到工作，流绑定到存储。
-
如果令牌级别的流畅性真的很重要，在 n8n 外部使用一个薄流式处理器来进行模型流式传输（一个小的边缘函数，将模型令牌流式传输到客户端，并将最终文本发送回 n8n 以进行持久内存写入和任何工具）。n8n 保持系统记录，边缘函数只是管道。
-
再一个，本着 achamm 关于产生副作用的工具的观点：保留每个副作用、发送邮件、写入 CRM，任何花钱的事情，都放在已提交的转换后面，并用转换 id 作为关键，这样重试或未完成的转换就不会触发两次。流式传输应该永远不是决定副作用是否发生的因素。
所以你实际上不必选择。将执行绑定到持久工作，将流绑定到外部通道，客户端断开连接就不再重要了。
嗨 
我認為我理解這個問題了——當客戶端連線中斷（瀏覽器刷新/重新連接）時，這是 n8n AI Agent + 串流中很常見的邊界情況。
基本上發生的情況是：
串流的生命週期與執行環境綁定得太緊密了，所以當前端斷開連接時，後端執行要麼被中斷，要麼被不正確地重新初始化了。
我會將其視為目前耦合的兩個生命週期：
-
客戶端串流生命週期
瀏覽器/客戶端連線希望現在取得部分令牌/事件。
-
伺服器執行生命週期
即使客戶端斷開連線，代理程式執行仍可能需要完成。
如果這些被綁定到同一個 HTTP 連線，斷開連線可能會成為執行取消信號。對於長期運行的代理程式，我通常會解耦它們：
- 請求啟動一個工作並返回 job_id；
- 伺服器端工作流程獨立繼續；
- 串流端點只訂閱工作事件；
- 如果串流斷開連線，工作保持執行；
- 客戶端可以用 job_id 重新連線並取得目前狀態/事件/結果；
- 終端狀態為 success、failed、cancelled_by_user、timed_out。
重要的區別是「客戶端消失」對比「使用者刻意取消」。這些應該是不同的狀態。
如果 n8n 的目前串流路徑將斷開連線與中止綁定，更安全的方式是將長期運行的代理程式放在耐久的工作層後面，並將串流視為觀察者，而非執行的擁有者。
一個非敏感的問題：您需要瀏覽器接收每個中間令牌，還是只需要串流狀態/事件並在工作完成時取得最終結果就足夠了？
歡迎 @sawsew467！
這是目前 n8n 的一個架構限制：當啟用串流時，執行生命週期會綁定到推送連線，因此斷開連線就表示中止。目前沒有內建設定可以將兩者解耦。
目前 n8n 中最接近的可用模式是：使用一般 Webhook（不啟用串流）作為進入點，使用「回應 Webhook」節點立即返回 job_id 給用戶端，然後使用「執行工作流程」節點以「在背景執行」模式觸發實際的代理工作作為子工作流程。用戶端使用 job_id 輪詢第二個 GET webhook，在結果寫入資料庫或靜態資料存放區後取得結果。你會失去即時權杖串流功能，但無論用戶端狀態如何，代理執行都會完成 - 這聽起來就像你實際需要的功能。
