描述問題/錯誤/問題
描述問題/錯誤/問題
我有一個 AI Agent 節點，附帶了一個 Microsoft SQL 節點作為工具。
SQL 節點在查詢欄位中使用 $fromAI()，以便代理能夠動態建立
查詢。每當代理嘗試調用此工具時，
它都會失敗並出現不良請求錯誤。
錯誤訊息是什麼（如果有的話）？
節點「EXPERTO SQL」中的問題：不良請求 - 請檢查您的參數。
函式「AnalisisAgentes」的架構無效：架構必須是「type: "object"」的 JSON Schema，
得到的是「type: "None"」。
設定
-
節點：Microsoft SQL（執行查詢），在 AI Agent 內用作工具
-
LLM：Azure OpenAI Chat Model
-
查詢欄位值：{{ $fromAI('description') }}
-
工具描述：手動設定
我已經嘗試過的
-
更改 $fromAI 參數名稱：{{ $fromAI('sqlQuery', 'SQL to execute', 'string') }}
-
驗證「工具描述」欄位是否有文字
-
重啟並重新保存工作流程
以上都沒有解決錯誤。架構仍然生成為 type: \"None\"
而不是 type: \"object\"，Azure OpenAI 會拒絕此項。
問題
是否有已知的修復方法或解決方案來強制 MS SQL 工具節點在 AI Agent 內使用時生成
有效的 JSON Schema（type: \"object\"）？
您的 n8n 設定資訊
- n8n 版本： 2.20.6（自託管）
- 資料庫（預設：SQLite）：
- n8n EXECUTIONS_PROCESS 設定（預設：own, main）：
- 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：npm
- 作業系統：Windows Server 2019
歡迎 @jnscb 加入我們的社群！我是 Jay，我是 n8n 認證創作者。
錯誤發生的原因是 $fromAI() 在沒有類型參數的情況下會產生一個包含 "type": null 的架構，而不是有效的 JSON Schema 類型。修正方法：在你的 $fromAI() 呼叫中始終明確指定類型。對於 SQL 查詢字串，應該是：$fromAI('query', 'The SQL query to execute', 'string')。沒有第三個參數，n8n 無法推斷類型，架構驗證就會失敗。另外請確保你沒有用雙層花括號包裝 $fromAI() - 它應該直接在欄位中使用，不使用 {{ }} 語法。
嗨 @nguyenthieutoan，感謝你的回覆！
我按照你提到的兩項更改進行了操作 — 移除了 {{ }} 並明確將類型設定為 'string'。我也試過將工具描述從手動設定切換到自動設定再切回去。但所有情況下的錯誤訊息都完全相同：
Invalid schema for function ‘Microsoft_SQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’。
這是我目前在查詢欄位中的內容：
$fromAI('sqlQuery', 'The SQL query to execute against [CMS].[dbo].[VW_HAGLOG]', 'string')
設定：
- n8n 版本：2.20.6（自託管，npm，Windows Server 2019）
- LLM：Azure OpenAI Chat Model
- 節點：Microsoft SQL（執行查詢），連接為 AI Agent 的工具
無論如何配置，schema 傳送到模型時仍然顯示為 type: "None"。你有其他建議的解決方法嗎？
謝謝！
非常感謝您測試這一切並分享詳細資訊。
鑑於您已經：
而架構仍然顯示為 type: "None"，這看起來真的像是 Microsoft SQL 節點在 AI Agent 內公開其工具架構的方式存在限制/錯誤，而不是您這邊的配置問題。
此時我會考慮兩個選項：
-
嘗試最小化的 $fromAI
首先我會快速測試一個非常簡單的版本，像這樣：
text
{{$fromAI("query")}}
如果這仍然導致 type: "None"，我們可以相當確定這是節點特有的問題，而不是關於 $fromAI 簽名本身的問題。
-
切換至子工作流程 + Call n8n Workflow Tool
對於您想在生產環境中依賴的東西，我會建議：
在子工作流程中：
這樣做您可以：
-
透過工作流程輸入控制架構，而不是依賴於 MS SQL 節點的工具架構
-
獲得更好的錯誤處理，如果模型生成錯誤的 SQL，可以傳回更清晰的訊息
-
輕鬆在其他代理程式/工作流程中重複使用此「SQL 執行器」。
從我這邊來說：您的 $fromAI 使用方式已經有效，剩餘的問題可能在節點/架構層級。在 n8n 推出修復之前，子工作流程 + Call Workflow Tool 模式是我在實際專案中最信任的方法。
選項 1 — 最少的 $fromAI 呼叫
我用最簡單的形式替換了查詢欄位：
$fromAI("query")
出現相同的錯誤：
Invalid schema for function ‘Microsoft_SQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’.
選項 2 — 子工作流 + 呼叫 n8n 工作流工具
我按照你建議的模式構建：
- 子工作流：執行工作流觸發器（定義
sqlQuery 輸入為字串）→ Microsoft SQL（執行查詢）在查詢欄位中使用 {{ $json.sqlQuery }}。
- 主工作流：AI 代理 + Azure OpenAI 聊天模型 + 呼叫 n8n 工作流工具，指向子工作流，將
$fromAI('sqlQuery', '...', 'string') 對應到工作流輸入。
錯誤相同，只有函數名稱改變：
Invalid schema for function ‘executeSQL’: schema must be a JSON Schema of ‘type: “object”’, got ‘type: “None”’.
所以相同的 type: "None" 架構問題在完全不同的工具節點上重現（呼叫 n8n 工作流工具而不是 Microsoft SQL）。這排除了 MS SQL 節點作為根本原因，並指向更深層的問題 — 要麼在 n8n 2.20.6 如何為帶有 $fromAI() 參數的工具生成 JSON 架構，要麼在這些架構如何發送到 Azure OpenAI（它的驗證比標準 OpenAI 更嚴格）。
鑑於兩個不同的工具節點產生完全相同的格式不正確的架構，我傾向於認為這是架構生成層中的高級錯誤，而不是配置問題。我已經開設了一個 GitHub 問題，包含所有詳細資訊和重現步驟。
主工作流
子工作流
感謝你對兩個選項進行了如此全面的測試 — 這真的是非常寶貴的數據。
錯誤同時出現在 MS SQL 節點和 Call n8n Workflow Tool 節點上的事實，確認這 不是節點特定的問題。type: "None" 字串是洩漏到 JSON Schema 序列化中的 Python 風格 null — 這是 n8n <= 2.20.x 與 Azure OpenAI 配對時的已知問題，Azure OpenAI 執行的是比標準 OpenAI 端點更嚴格的結構描述驗證。
根本原因： n8n 的 $fromAI() 結構描述生成器在某些邊界情況下會生成 type: null，但 Azure OpenAI 拒絕任何不是有效 JSON Schema 類型字串的內容。標準 OpenAI 則更寬鬆，通常會忽略它。
確定的解決方案 — 改用 Code 節點作為工具：
與其直接連接 MS SQL 作為工具，改用 Code 節點，該節點：
- 從代理接收 SQL 查詢作為硬編碼字串輸入
- 透過子工作流程中的 MS SQL 節點執行查詢（如同你已有的做法）
- 返回結果
對於「Call n8n Workflow Tool」，關鍵修復是在 Execute Workflow Trigger 節點中將 Workflow Inputs → type 明確設定為 string，然後在 Tool 節點中清楚地設定輸入描述。確保你 沒有在子工作流程觸發器本身使用 $fromAI() — 該欄位應該只使用 {{ $json.sqlQuery }}。
或者，最快的方式：升級到 n8n 2.21+，該版本已修補此結構描述序列化錯誤。
如果現在無法升級，請分享你的 Execute Workflow Trigger 輸入定義螢幕截圖，我可以精確指出 None 在哪裡洩漏。
感謝你的分析，它幫助我知道該往哪個方向尋找。
重要更新：我安裝了最新版本的 n8n，但錯誤仍然完全相同。我找到了官方錯誤報告（n8n 倉庫中的議題 #25276），這清楚地表明更新並不能解決此問題 — 它已在當前版本上確認存在，並且在更新後仍然持續。這也不是 Azure 獨有的：相同的 type: "None" 錯誤也被標準 OpenAI 和 Anthropic 拒絕。根本原因是 n8n 在工具的 input_schema 根部生成了無效的模式，使用 type: "None" 而不是 "object"。
因此，如你所建議的更新到 2.21+ 版本並未解決問題 — 而且從我看到的情況來看，該版本號與此錯誤所在的實際 n8n 版本控制不相符（v2.6.3）。
我現在需要的，這很緊急：你知道有什麼方法可以強制工具模式在根部使用 type: "object" 嗎（某個補丁、設定或中間節點）？我需要工具立即開始工作，降級不是選項。如果有幫助，我可以發給你一張執行工作流程觸發器的螢幕截圖，這樣你可以精確定位 None 是從哪裡洩露出來的。
感謝你深入調查該錯誤報告 - 這確認了這是核心中更深層的 schema 序列化問題，不是單純版本更新就能解決的。
最可靠的解決方案是我之前提到的程式碼節點作為工具的方法。由於程式碼節點不會經過 $fromAI() schema 產生器，就不會有 type: None 洩漏。設定程式碼節點並提供清楚的輸入說明，在程式碼中撰寫 SQL 查詢，然後從子工作流程呼叫 MS SQL 節點。agent 會將查詢作為純字串傳遞，schema 就能保持乾淨。
針對「呼叫 n8n 工作流程工具」路徑 - 確保子工作流程中的「執行工作流程觸發器」將其輸入定義為 string 型別（而非留空）。空白輸入是造成 schema 根目錄出現 type: None 的原因。進入觸發器節點，手動新增一個欄位並將型別設為 string，這樣應該就能解決 schema 拒絕問題，即使沒有 n8n 方面的錯誤修正也行。
更新 — 目前已有修正進行中。
已連結一個提交請求，它解決了根本原因：PR #31681 — fix(Microsoft SQL Node): Allow expressions in the query field（開啟於 2026 年 6 月 3 日，由社群成員編寫）。它與我們回報的問題相關，所以一旦合併並在發布中推出，就會關閉該問題。
提醒各位注意：目前該 PR 已連結/開啟，但尚未合併到穩定版本 — 所以單純更新還不會修正問題。請關注該 PR 和 n8n 更新日誌，等到包含該修正的版本發布後再更新。
暫時可用的解決方案（用於從 AI Agent 使用 MS SQL 節點作為工具）：
- 在查詢欄位中，直接寫入
$fromAI()，不要包含 {{ }} 包裝：$fromAI('sqlQuery', 'SELECT query to run against [DB].[schema].[table]', 'string')
當節點作為工具使用時，n8n 需要原樣解析 $fromAI() 運算式來建立 JSON Schema。將其包裝在 {{ }} 中會導致 schema 輸出為 type: "None" 而不是 "object"。
- 將工具描述設定為自動設定，讓 n8n 從聲明的
$fromAI 引數推導 schema。
- 確保引號是直引號（
'），而不是智慧/排版引號 — 那些也會破壞解析。
這種組合會強制產生有效的 type: "object" 根 schema。一旦 #31681 在某個版本中推出，查詢欄位應該能乾淨地接受運算式，就不需要這個解決方案了。
