需要建議改進 n8n AI 代理工作流程

幫助我建立我的工作流程
1

嗨各位，

我一直在用 n8n 為內部運營建立 AI 工作流程，希望能從處理過類似問題的人那裡獲得一些反饋。

該工作流程會根據上下文處理不同的請求。它會提取數據、路由任務、更新系統，並將工作交接給適當的流程。起初運作得很好，但隨著我們擴展工作流程，代理開始在決定調用哪個工具或工作流程時做出不佳的選擇。

有時它會在應該查詢知識庫時跳過檢索。其他時候它會調用錯誤的分支，或者從記憶中回答而不是使用最新數據。提示詞隨著時間而增長，所以我想知道這是否是問題的一部分，還是整體架構需要改變。

目前我們使用 n8n 與 OpenAI、用於檢索的向量數據庫，以及一些內部 API。我們也一直在測試 Workbeaver 來處理那些無法通過 API 暴露的桌面任務，同時保持 n8n 作為主要編排層。

對於在 n8n 中建立更大型 AI 代理的人：

  • 你是保持單一編排器，還是將職責分散到較小的代理中？

  • 當有多個工具可用時，你如何減少幻覺？

  • 你主要依賴提示詞工程，還是發現架構上的改變更有效？

  • 關於何時代理應該檢索數據而不是直接回答，有什麼最佳實踐嗎？

我很樂意聽聽在你們的專案中哪些方法有效。提前感謝。

2 個讚
2

這聞起來不像是提示詞的問題，倒像是你已經超越了單一協調器的能力。當一個代理掌握所有工具時，它每次輪次都在從一個大菜單中挑選，工具描述加上你擴展的提示詞都在爭奪同一個注意力預算，所以當你增加分支時，工具選擇就變得模糊不清。這正是你描述的模式。

對我有效的是分割它。保留一個精簡的路由代理，其唯一工作就是選擇方向，然後交給小型子代理，每個子代理擁有 2 到 3 個工具。每個代理的決策空間更小，每個提示詞更短，工具選擇的可靠性大大提高。單一的龐大協調器看起來很優雅，但隨著你添加的每個工具，它的性能就會下降。

關於跳過檢索的問題，不要讓檢索成為代理可以選擇跳過的工具。在那些答案必須基於事實的分支上，在代理甚至看到請求之前，將檢索作為固定步驟運行，這樣它總是有新鮮的上下文，無法從記憶中作答。在重要的地方，把這個決定從模型手中奪回。

提示詞工程與架構，超過一定規模後，架構佔上風，而且遠不止如此。提示詞調整有天花板，路由加上範圍明確的子代理才是在表面持續增長時能夠支撐的方案。

我在生產環境中構建過幾個多代理設置，如果對路由結構有幫助的話，我很樂意深入探討。

1 個讚
3

@James198

你遇到了幾乎每個不斷成長的 n8n 代理都會碰到的問題：一個具有龐大提示詞和十幾個工具的協調器。當工具數量和提示詞長度都增加時，模型的工具選擇準確度會急劇下降，所以你看到的症狀（跳過檢索、選擇錯誤分支、從記憶中回答）是預期的失敗模式，不是你可以透過提示調整來解決的問題。

我按順序回答你的問題。

單一協調器 vs 分割。選擇分割。將一個或兩個大型工作流分解成四個或五個較小的工作流，每個都負責單一責任，並透過 webhook 或 Execute Workflow 由協調器呼叫它們。協調器的唯一工作變成路由：對請求分類、交給正確的子工作流、收集結果。它本身不應該進行檢索、更新或接觸 API。每個子代理只會看到與其工作相關的 3 到 5 個工具，而不是整個工具列表，當菜單很短時，模型選擇正確的頻率會高得多。額外的好處是你實際上可以偵錯它，因為故障現在只會隔離在一個小工作流中，而不是埋在龐大系統中。

在有多個工具可用的情況下減少幻覺。有兩個槓桿。首先，按上述方式縮小每個代理的工具集。其次，在決策實際上是確定性的地方，讓模型不做決策。如果分支可以從已知字段透過 Switch 節點選擇，那就這樣做，不要讓 LLM 決策。將代理的判斷保留用於真正模糊的情況。大多數「它呼叫了錯誤的分支」的問題實際上是「我要求模型進行一個規則本可進行的選擇」。

提示詞工程 vs 架構。提示詞調整有其極限，聽起來你快達到了。超過一定規模後，提示詞本身就是問題，而不是解決方案，因為你在推送上下文窗口到足夠遠的程度，使得模型遺忘了早期的指令。一個只有 3 個工具且提示詞簡短的精緻代理，永遠勝過一個有 15 個工具且提示詞龐大的代理。先修復架構，然後在較小的片段內調整提示詞。

決定檢索 vs 直接回答。不要讓模型自行決策，因為「從記憶中回答而不是最新數據」意味著你給了它跳過檢索的選項。在需要新鮮數據的分支中，讓檢索成為流程中的必要步驟，而不是代理可能會或可能不會呼叫的工具。如果它必須通過向量資料庫或 API 才能得到答案，它就無法走捷徑使用記憶。強制執行路徑而不是希望提示詞能說服它。

還有一件值得一提的事情，因為你在生產環境中運行這個：一旦分割成透過 webhook 連結的子工作流，要留意它們之間的無聲失敗。子代理可能會返回成功狀態，同時默默地丟棄工作，而協調器會很樂意繼續使用過時或空的數據。值得在每次交接時監控項目計數。

如果對路由模式有幫助的話，很樂意進一步深入探討。

1 個讚
4

@James198 再補充一點支持拆分的理由，現在你可以針對每個工作（子工作流程）及其工具進行調整，使其適配該工作部分表現最佳的模型。Haiku 在工具呼叫方面表現很差，GPT 4 mini 也是，但 Sonnet 和 GPT 5 在這方面表現驚人。將工作流程的各個部分分離開來，可以讓你真正精準調整並微調輸出結果。

5

錯誤分支問題很有趣。當它選擇了錯誤的路徑時，通常是同一對分支經常被混淆，還是在整個系統中隨機發生？當它從記憶中回答而不是查詢向量存儲時，這是針對特定類型的請求嗎（比如狀態查詢與流程觸發）？

我一直在為這種模式構建評估層，很想知道典型一天的故障率是多少。您提到的子代理分割很有幫助，但通常仍然存在一個分類然後路由的決策，即使在分割後仍然相當脆弱。

6

略過檢索/錯誤分支/從記憶中取得答案這件事是有用的部分。我花五天時間檢查一個生產工作流程，並發送兩到三個重現故障的編輯地圖，加上首次變更和回滾。僅以書面形式。你寫出遺漏和工作流程、付款、刪除編輯痕跡。無通話、無重寫。上次遺漏花了多少成本？