嗨各位，
我想要建立一個自訂節點，整合現有的AI Agent 節點與 HTTP Request 呼叫到外部審核層。目標是在代理執行前執行審核檢查，同時仍然重複使用現有的 AI Agent 功能。
有沒有推薦的方式來重複使用或包裝自訂節點內的AI Agent 節點，而不需要重新實作完整的 AI Agent 邏輯？
1個讚
歡迎來到 n8n 社群 @AlexiaBiancaR
我不會嘗試從自訂節點內部包裝或呼叫現有的 AI Agent 節點。
根據我的了解，自訂節點旨在實現自己的執行邏輯，而 AI Agent 節點是一個具有自己連接的模型/工具結構的工作流節點。我認為沒有支援的公用 API 可以在另一個自訂節點內重複使用完整的 AI Agent 內部。
更安全的解決方案是將 AI Agent 作為工作流中的普通節點保留，並在其前面放置審核層。如果您需要這個可重複使用，您可以將該模式包裝在子工作流中，並使用「執行工作流」呼叫它，而不是建立試圖包含 AI Agent 的自訂節點。所以我只會在需要時使用自訂節點進行外部審核呼叫，並將 AI Agent 編排保留在工作流本身中。
1個讚
歡迎加入社群，@AlexiaBiancaR！你正在建立的用例真的很棒。
Tamy 的建議說得完全沒錯：n8n 的 AI Agent 節點並不是設計來從自訂節點內部包裝或以程式設計方式調用的。它的內部結構依賴於在工作流程層級連接的子節點（模型、工具、記憶體），而不是透過可調用的 API。
針對你所描述的情況，最簡潔的架構是：
- 前置審核節點（你的自訂節點或 HTTP Request 節點）- 使用傳入的使用者訊息調用外部審核 API
- IF 節點 - 檢查審核結果，阻止或允許
- AI Agent 節點 - 僅在輸入通過審核時執行
- 後置審核（選用）- 也可以在將代理的輸出返回給使用者之前檢查它
如果你需要在多個工作流程中重複使用這整個管道，將它包裝在子工作流程中，並透過 Execute Workflow 節點調用它，這是最佳做法。這樣可以提供自訂節點包裝所能帶來的模組化，而不需要與 n8n 的架構相悖。
自訂節點在這裡仍然非常有用 - 只是用於審核調用本身，而不是試圖包含代理。
希望這有助於澄清這個模式！如果這個方向對你有效，可以隨意將其中一個回覆標記為解決方案。