self-hosted-ai-starter-kit 拆解：N8N 官方的本地 AI 起步套件
从真实仓库的 Docker Compose 与 Demo workflow 出发，拆解 N8N、Ollama、Qdrant 和 Postgres 如何组成本地 AI 实验环境。
项目定位：把本地 AI 所需的基础件放在一起
n8n-io/self-hosted-ai-starter-kit 是一个真实的 GitHub 项目，仓库地址是 <https://github.com/n8n-io/self-hosted-ai-starter-kit>，核验时星数为 15233★。它的价值不在于发明新的 Agent 框架，而在于把自托管 AI 实验经常需要的 N8N、Ollama、Qdrant 和 Postgres 放进同一套 Docker Compose 配置。对一个只想尽快看到本地模型接入自动化流程的人来说，它减少了分别安装、分别联调的成本。
项目的关键入口是 docker-compose.yml。这个文件描述各服务怎样被组织起来，而不是把所有能力塞进一个容器。这种分工值得学习：工作流编排、模型推理、向量数据与业务状态各有归属，替换某个组件时不必重写整个系统。
四个容器分别做什么
N8N 是操作界面和编排层。触发器接收输入，普通节点进行转换、判断或调用，AI 节点则把整理好的上下文交给模型。它是数据经过的枢纽，但不应被误解为模型本身。
Ollama 承担本地模型的运行与请求接收。N8N 中的模型节点把提示和用户输入送过去，Ollama 返回模型生成的内容。因为推理留在自己的环境，它适合做私有化试验、离线演示与对数据去向敏感的原型。代价是模型质量、运行速度、内存与运维问题都需要自己承担。
Qdrant 的定位是向量存储与检索。当工作流把文档切分并生成向量后，可以将向量、原文和元数据放入 Qdrant；问答时再召回相关片段。但套件里有 Qdrant，不等于导入的每条工作流都自动成为 RAG。切分策略、元数据、权限过滤和更新机制仍然要由使用者设计。
Postgres 负责适合关系型数据库的持久化状态。它与 Qdrant 不是谁替代谁：工作流定义、执行相关状态与向量语义检索是不同问题。理解这条边界，能避免将账号权限、审计状态这类结构化数据错放进向量库。
仓库自带 Demo 的真实节点链路
可验证的 Demo workflow 位于 n8n/demo-data/workflows/srOnR8PAY3u4RSwb.json。仓库 JSON 实际解析出的链路是 Chat Trigger → Basic LLM Chain → Ollama Chat Model，共为三个节点。这条链路非常短，却恰好把 N8N AI 工作流的基本连接关系表达清楚。
Chat Trigger 是用户交互的入口。它将聊天消息变成一次工作流执行的输入。在真实业务中，这个入口周围还应增加身份、限频、输入长度与日志策略；Demo 的任务是证明链路可用，不是代替生产入口的防护。
Basic LLM Chain 处在编排位置。它接收消息，按链的配置组织模型请求，再将结果交还给主流程。“Basic”很重要：这不是一条带工具选择、长期记忆和多轮规划的复杂 Agent。读者应先用它验证输入、模型和输出，再按需求增加检索或工具。
Ollama Chat Model 是为链提供模型能力的节点。在 N8N 的 AI 节点连接语义里，模型节点是链的依赖，而不是另一个聊天入口。这也解释了为什么排查时要同时看主数据连线与 AI 专用连线：页面上看到节点并不代表链已经获得模型。
数据如何流过这套系统
从 Demo 看，数据由聊天入口进入 N8N，被 Basic LLM Chain 组织为模型可用的请求，然后交给 Ollama Chat Model，模型结果沿链返回。Qdrant 和 Postgres 虽然是套件组成部分，但不应被描述成这条三节点 Demo 已经调用的环节。只有在工作流明确增加对应读写时，数据才会进入那些服务。这个区分是“根据仓库说话”的关键，也避免把安装了基础件误写成已完成的业务能力。
怎么跑起来，以及先验证什么
先阅读仓库说明和 docker-compose.yml，确认本地环境满足 Docker Compose 的要求，再按仓库给出的方式启动服务。不要在未阅读配置的情况下盲目复制网上的环境变量，因为分支与本地环境可能不同。启动后先确认各服务健康，然后打开 Demo，检查 Ollama Chat Model 能否被 Basic LLM Chain 正常调用。
验收时应把“容器已启动”和“工作流已可用”分开。前者只证明进程在运行，后者还需要一条可识别的聊天输入、一次成功的模型调用和可读的返回。如果失败，按入口数据、链的映射、模型连接和 Ollama 日志的顺序检查，比反复重启更容易找到边界。
本地模型与云端 API 的取舍
选 Ollama 的核心理由通常是控制力：请求不必默认发给外部模型服务，开发者能在本地反复调试，也不会因每次实验直接产生 API 调用账单。但“本地”不自动意味着更安全：管理界面暴露、弱密码、未限制的网络访问、卷备份和日志中的敏感信息，仍需要通过部署策略解决。
云端 API 的优势是将模型服务运维交给提供方，往往更容易获得稳定的推理能力与成熟模型。它的成本、数据处理条款、网络依赖和限频需要在项目开始时评估。合理做法不是宣布某一边永远更好，而是用同一组业务样本比较回答质量、延迟、资源占用和数据约束，再选择组件。
适合谁，不适合谁
这个套件适合想在本机学习 N8N AI 节点、验证 Ollama 连接、试做 RAG 概念和搭建团队演示环境的人。它也适合作为架构对话的起点：团队可以直观讨论哪些状态进 Postgres，哪些文档片段进 Qdrant，以及哪些内容可以交给模型。
它不适合在没有评审的情况下直接作为生产答案。生产环境还需要身份与权限、密钥管理、网络隔离、持久化备份、恢复演练、可观测性、容量评估与升级策略。Demo 能返回内容，只是起点，不是已经完成这些工程工作的证据。
常见坑与一条实用建议
最常见的误区是把“一键启动”理解成“一键上线”。其他问题包括模型尚未可用就开始调工作流、AI 专用连线未正确连接、修改 Compose 后却没有核对数据卷，以及把测试凭证长期留在可导出的工作流中。最实用的建议是保留这条原始 Demo 作为连通性基线，业务开发在复制出的工作流中进行。当复杂流程出错时，回到 Chat Trigger → Basic LLM Chain → Ollama Chat Model 就能快速判断问题在基础服务，还是在自己新加的逻辑。