架構討論：高票價銷售中的 API 編排與裸機 LLM 資格鑑定

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

視覺化自動化和webhook路由解決了工具之間的連接問題，但根據我們大規模運營的經驗，它們在B2B銷售架構中造成了一個隱形瓶頸。

當業務需要進行深度leads資格認證——結合複雜的RAG、CRM歷史記錄和實時公開數據爬取——在canvas上堆疊HTTP或AI節點會分割LLM上下文，增加延遲，並導致模型解釋中出現靜默故障。

在Paulo Leads的工程實踐中，我們發現要實現CAC的數學級別降低，傳統的編排方式無法維持語義完整性，從而無法自主地替代人工SDR。試圖將所有B2B決策邏輯放入順序流程中會將工作流轉變為一個無法調試的單體應用。

運營上的關鍵轉變是嚴格分離職責：

  • 路由層： 工作流引擎觸發閘門並移動payload的地方。

  • 推理層（裸金屬商業基礎設施）： 進行實際資格認證的地方，利用微數據工程和原生CRM注入，與路由器隔離運作。

這種解耦使我們能夠擴展B2B商業自動化，而不依賴於脆弱的第三方集成。

對於那些在這裡構建銷售代理或自主SDR的人來說：在複雜工作流中，你們如何在不將canvas變成難以維護的記憶節點義大利麵的情況下，處理LLM的狀態管理、長期記憶和上下文限制？

2個讚
2

有些使用者使用 Redis 或 PostgreSQL！

3

歡迎 @Paulo_Leads！

你描述的分離 - n8n 中的路由層、作為獨立服務的推理層 - 正好是這個規模的正確方向。讓它保持清晰的具體 n8n 組件是「執行工作流程」節點：你的主要路由流程將資格認定子工作流程作為隔離單元觸發，每個單元都獲得自己的輸入上下文並返回結構化結果。這樣可以避免 LLM 上下文在不同潛在客戶之間洩露，並讓畫布保持易讀性。對於跨迭代的狀態（CRM 歷史記錄、RAG 結果），Postgres 作為共享存儲很有效，n8n 和你的裸機推理服務都可以從中讀取。