我想要一個真正可以傾偈、而唔係只會回應斜線命令嘅Discord機械人——於是我用n8n同Anthropic API砌咗一個,完全跑喺自己嘅homelab基礎設施上。
技術棧
- n8n 作為自動化/編排層,自行託管喺
n8n.humfurie.org - n8n入面嘅Discord Trigger節點,透過bot token直接連接Discord(唔需要公開webhook——佢係透過WebSocket連接監聽嘅)
- Claude(Anthropic API)作為處理實際回覆嘅模型——我用咗Haiku以節省成本,因為聊天機械人每條訊息都會觸發一次,token費用累積得好快
- PostgreSQL用嚟持久化對話歷史,咁樣機械人先可以記住最近嘅上下文,而唔係將每條訊息都當作全新開始嚟處理
- 一切都跑喺Unraid上嘅Traefik後面,並透過Let's Encrypt自動簽發SSL證書
運作原理
每當允許嘅頻道入面有新訊息,Discord Trigger就會觸發。n8n由Postgres度攞出最近幾條訊息作為上下文,將成段對話加埋新訊息一齊發畀Claude,再將回覆發返去Discord——而且係以真正嘅線程回覆形式,而唔係頻道入面嘅一條新訊息。早期我用嘅係基於webhook嘅方案,但切換去原生嘅Discord Trigger節點之後,減少咗一層複雜度:唔使管理webhook URL,亦唔使將任何嘢暴露喺公網上,只需要一個直接嘅bot連接。
我唔想學到嘅教訓
有一次,我喺清理homelab另一部分嘅時候跑咗docker compose down -v——而嗰個-v參數將綁定到嗰個compose檔案嘅所有卷都清空咗,包括支撐成套系統嘅Postgres數據庫。所有工作流、所有對話歷史,全部冇咗。
重建就意味住要將成套設定一塊一塊砌返齊:docker-compose設定、n8n工作流本身、Discord機械人嘅憑證,以及(嗰陣時我仲未切換去Discord Trigger)webhook路徑。呢次經歷好好咁提醒咗我,-v唔係可以隨便用嘅參數,而且對任何無人值守運行嘅嘢嚟講,工作流匯出同數據庫備份都唔係可選項。
總結
- 對呢個使用場景嚟講,Discord Trigger勝過webhook——活動部件更少,唔需要暴露任何嘢喺公網。
- 平嘅模型對聊天機械人嚟講完全夠用——Haiku級別嘅模型足以應付日常對話,唔使洗前沿模型嘅價錢。
- 喺你關心嘅嘢附近運行
down -v之前,一定要先備份好compose嘅卷。呢一課我係食咗大虧先學識。
呢個係一個細項目,但佢係一個好好嘅沙盒,等我可以測試一個自行託管、低成本嘅AI整合,喺真正需要更重量級方案之前,究竟可以行得幾遠。