n8n會不會很快發布DeepSeek工具呼叫的官方修復？

問題
, , , ,
1

Hi n8n 團隊，

我是 Jay（Nguyen Thieu Toan），一位認證的 n8n 創作者，我想提出一個日益影響許多用戶和客戶的問題，他們試圖在 n8n 中採用 DeepSeek 進行生產環境 AI Agent 工作流程。

目前，每當 DeepSeek Chat Model 與 AI Agent + 工具一起使用時，我們都會持續遇到「思考模式中的 reasoning_content 必須傳回 API」的錯誤。根據我在最近的討論串和 GitHub 問題中看到的內容，這已被確認為 reasoning_content 處理方式中的已知限制（當代理調用工具時），但尚未發布可見的修正。實際上，這意味著對於嚴肅的代理使用案例（工具至關重要的地方），DeepSeek 在官方 n8n 節點內實際上不是可行的選項。

令我擔憂的是，社區開始依賴非官方的 DeepSeek 節點或自訂補丁來解決這個問題，這對某些人解決了錯誤，但帶來了新的風險：行為不一致、更難維護，以及對想要將 n8n 標準化為其主要自動化和 AI 平台的團隊來說信心不足。這不再只是「錦上添花」；DeepSeek 已成為許多建構者和客戶積極偏好而不是 OpenAI 或 Gemini/Vertex 的真正替代品，而目前的限制阻止他們與代理和工具一起正確使用它。

您能否請提供一個關於 DeepSeek + AI Agent 工具調用的官方修正狀態（reasoning_content 處理）的更新，以及是否有估計的發布時間窗口我們可以向用戶和客戶傳達？即使是像「計劃中且正在為即將推出的次要版本進行中」這樣的粗略指示，也已經能幫助我們中很多人決定是等待官方實現還是繼續投資於社區層級的解決方案。

感謝您事先提供任何澄清，代表日益增長的希望以穩定、一流的方式使用 DeepSeek 的 n8n 用戶群體。

2

你可以只使用 HTTP 請求嗎？

3

嗨 @achamm AI Agent 的聊天模型沒有這個選項。:frowning:

4

@nguyenthieutoan 你現在可以使用社群節點或不同的代理程式，我建議建立 GitHub issue，這樣 n8n 開發團隊可以著手處理

5

根本原因在於 n8n/LangChain 在工具執行迴圈期間如何將訊息附加到歷史記錄；DeepSeek 對於在後續 API 呼叫中接收其自身生成的 reasoning_content 要求很嚴格，否則會出現 400 錯誤。

6

感謝 @sergeys - 這是對根本原因的精確解釋。所以修復需要在 LangChain 訊息歷史層進行，也就是 n8n 在工具呼叫之間剝除或保留 reasoning_content 的地方。這不是我們可以在節點層級修補的東西，除非改變 AI Agent 如何組織其訊息歷史。我會開啟一個 GitHub 議題，附上這個根本原因的詳細資訊，好讓核心團隊有明確的目標。

7

這是OP的快速更新，在深入研究並使用AI Agent + tools進行大量生產測試後。

我已經構建並發布了一個專用的社區節點，完全避免了DeepSeek在n8n中的reasoning_content錯誤。在我的測試中，這個問題並不真正是LangChain或n8n的bug，而是來自DeepSeek設計和驗證其思考模式和工具調用的方式：一旦模型進入思考模式並發出reasoning_content，它就會對在任何涉及工具的後續調用中看到相同的reasoning_content變得非常嚴格；否則，它會返回400錯誤。

因此，我決定現在採取更簡單、更可預測的方法：完全禁用agent使用案例的思考模式，並防止DeepSeek首先生成任何reasoning_content。這樣，就沒有什麼可以在工具循環中重放的，AI Agent可以調用工具而不會觸發DeepSeek的嚴格驗證規則。

結果是一個社區節點，你可以安全地用於生產環境中的AI Agents + tools：

使用方法（自託管）：

  • 前往設定 → 社區節點

  • 安裝套件：n8n-nodes-deepseek-chat-model

  • 安裝後重啟n8n容器

  • 在你的AI Agent中，從此社區節點選擇DeepSeek Chat Model作為聊天模型

  • 確保在節點選項中禁用思考模式，然後照常配置你的工具

一個重要的警告：即使reasoning_content問題解決了，DeepSeek在工具調用方面仍然有點棘手。你仍然可能遇到以下行為：

  • 在單一推理步驟中重複進行工具調用

  • 在複雜提示或很長上下文中難以控制的工具循環。

因此，如果你需要agent + tools工作流具有非常高的可靠性，我建議：

  • 使用此DeepSeek社區節點並關閉思考模式以避免reasoning_content 400錯誤

  • 在工作流級別添加防護措施（最大工具調用計數、重複使用相同工具前的條件、每個循環的詳細日誌記錄）

  • 根據你的使用案例，在可預測性絕對關鍵時仍考慮使用更成熟的模型進行工具調用

希望這對任何在嘗試讓DeepSeek與n8n AI Agents協作時找到此帖子的人有所幫助。如果n8n團隊中有人想了解該節點如何應對DeepSeek怪癖的詳細信息，我很樂意分享更多背景和測試案例。