我想要一个真正能对话、而不是只会响应斜杠命令的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集成,在真正需要更重量级方案之前,到底能走多远。