n8n + Ollama 本地化AI自动化：PDF摘要不上云实战

想让AI帮你读文档、生成摘要，又不愿意把敏感文件上传到别人的服务器？这篇教程给出了一个完全本地化的方案：把PDF丢进一个文件夹，n8n自动把内容交给Ollama处理，摘要再写回同一个文件夹。整个过程不需要API Key、没有调用额度限制，因为模型就跑在你自己的硬件上。

下面按照原始教程的思路，拆解完整的搭建流程、六个节点的工作流配置，以及最容易踩坑的四个问题。

方案概览：为什么选择本地优先

这套方案的核心诉求是数据不出本机。文件处理全程发生在本地容器与本地模型之间，天然规避了云端上传带来的隐私风险。

技术栈依赖两样东西：Docker，以及一个叫 self-hosted AI starter kit 的开源仓库。这个仓库把 n8n、Ollama、Qdrant 和 Postgres 打包进一个 compose 文件，开箱即用。其中 Postgres 在幕后负责保存 n8n 自身的工作流和执行数据。

关于许可证需要留意：starter kit 仓库本身是 Apache 2.0，但 n8n 核心采用自己的 Sustainable Use License——个人使用和企业内部使用没问题，但不允许转售。录制时对应的版本为 n8n 2.41 和 Ollama 0.35。

模型方面选用的是 Llama 3.2 3B，下载文件约 2GB，普通笔记本就能跑得动。starter kit 的官方文档里也恰好把「安全的PDF摘要」列为示例用例，所以这不是硬凑的场景。

Qdrant 是一个用 Rust 编写的开源向量数据库，专门用于存储和检索高维向量（即文本或图像经过 embedding 模型转换后的数值表示）。与传统关系型数据库按关键字精确匹配不同，Qdrant 支持「语义相似度」查询——你可以用一段自然语言描述去搜索含义相近的文档片段，而不必依赖文档中出现完全相同的词语。在本方案里，Qdrant 随 starter kit 一同启动但并非核心流程的必需组件，它主要为进阶场景（即把文件向量化并实现本地语义搜索）预留接口，无需额外安装配置。

安装与环境配置

安装过程很快：克隆 starter kit 仓库，cd 进目录，然后把示例环境文件复制一份（cp .env.example .env），填入自己的密钥和密码。

复制env示例文件为env

启动命令取决于硬件：

纯CPU：docker compose --profile cpu up（没有N卡也完全够用）
NVIDIA GPU：docker compose --profile gpu-nvidia up
Linux + AMD显卡：docker compose --profile gpu-amd up

Mac 用户这里有个大坑：Docker 根本无法透传 GPU。解决办法是把 Ollama 装在 Docker 之外、原生运行，然后让 n8n 通过 host.docker.internal:11434 指向它。在 .env 里设置好 OLLAMA_HOST，再执行不带任何 profile 的 docker compose up。

还有一个版本提醒：请继续使用 npm 和 npx。n8n 在 3.0 版本（十月）会移除 npm 安装路径，但 compose 方式在那之后依然可用，这也是建议从 compose 起步的原因。

首次启动要给它一点时间，因为 Ollama 还在后台拉取模型。完成后打开 localhost:5678 就能进入界面。可以手动先拉模型：docker exec -it ollama ollama pull llama3.2:3b（Mac 原生安装的用户去掉 docker exec 部分）。

配置 Ollama 凭证

进入 n8n 后，打开 Credentials 添加一个新的 Ollama 凭证。默认 Base URL 是 http://localhost:11434，但多数情况下需要修改。

在n8n中添加Ollama凭证

原因在于 Docker 内部每个容器都有自己的 localhost，直接用默认值往往连不上。几种情况分别处理：

用本 stack 里的 Ollama 容器：把地址指向容器名 ollama
Mac 原生安装：填 host.docker.internal:11434
远程 Ollama 走代理：额外填入 API Key；无代理无鉴权就留空

所以这个凭证本质上就两个字段——一个 Base URL，加一个可选的、给带鉴权代理用的 API Key。

如果遇到 ECONNREFUSED，可能是机器优先走 IPv6 而 Ollama 监听的是 IPv4，把 URL 里的 localhost 换成数字回环地址即可解决。

六个节点搭出完整工作流

整条流水线由六个节点组成，顺序是：触发 → 读取 → 提取 → LLM处理 → 转换 → 写回。

节点一：Local File Trigger。监听文件夹的变化。三项设置：Trigger On 选 changes involving a specific folder；Watch For 选 file added；Folder to Watch 填 /data/shared。

节点二：Read/Write Files from Disk，操作设为 read files from disk，File Selector 指向刚被放入的文件路径。

节点三：Extract from File，操作选 extract from PDF，输出即提取出的纯文本，供后续 prompt 直接读取。

节点四：Basic LLM Chain。Prompt 模式设为 define below（另一种模式会自动从上一节点拉取聊天输入，不是我们想要的）。Prompt 很简单：Summarize this file in three bullet points，后面接上提取出的文本。然后挂一个 LLM Chat Model 作为语言模型，选 Llama 3.2 3B。想调整语气可以加 system message；需要结构化输出就挂一个 output parser 子节点。

节点五：Convert to File，操作选 convert to text file，文本输入字段指向上一节点的输出。

节点六：Read/Write Files from Disk（再次使用），操作为 write file to disk，路径填 /data/shared/report-summary.txt，二进制字段为 data。这样摘要就写回到了原文件旁边。

摘要被写回到原文件旁边

保存并激活工作流后，往 shared 文件夹丢一个PDF，盯着执行日志看——每个节点正常跑完会依次亮绿。

Basic LLM Chain 与 Agent 节点是 n8n 中两种截然不同的 AI 调用方式。Basic LLM Chain 是一次性的「输入→输出」管道：你给定 prompt，模型返回文本，流程结束。Agent 节点则引入了「推理-行动」循环（ReAct 模式）：模型可以根据需要自行决定调用哪个工具、调用几次，直到认为任务完成才返回最终答案。正因为 Agent 需要在多轮工具调用之间维持上下文状态，它要求底层模型支持函数调用（function calling）协议；而 Ollama Model 节点封装的接口并不暴露这一能力，所以只能与 Basic LLM Chain 配对使用，Agent 场景则必须切换到支持工具调用格式的 Ollama Chat Model 节点。

最容易踩坑的四个问题

这套流程看着简单，但有四个点特别容易卡住，原始教程专门做了说明：

1. Local File Trigger 默认被禁用。自 n8n 2.0 起需要手动开启：在 Docker compose 的环境变量列表里加上 NODES_EXCLUDE 为一个空数组来清除默认排除。

2. 文件访问被限制在隐藏目录。同样从 2.0 开始，文件访问默认锁在 n8n 的隐藏 files 文件夹内。本工作流用的是 /data/shared，所以要加 N8N_RESTRICT_FILE_ACCESS_TO=/data/shared 到环境变量。

3. Ollama Model 节点不支持工具调用。这是最多人忽略的一点——它必须配 Basic LLM Chain 使用，绝对不能配 Agent 节点。如果要搭 Agent，就得改用 Ollama Chat Model，因为那才是 Agent 节点接受的模型类型。

4. 首次运行毫无反应。多半是模型还在下载。跑 docker compose logs -f 盯着拉取进度即可。

搞定这四点，整条流水线基本就能稳定运行了。

从摘要到行动：进阶方向

如果不满足于只做摘要，想让AI真正「动手」，可以把 Basic LLM Chain 换成 Agent 节点，再挂上至少一个工具节点，由 Agent 自行决定调用哪个。此时 Ollama Chat Model 作为「大脑」，真正的工具挂在它身上。需要注意旧版本里的 agent type 设置在 3.0 中会被移除。

想在自己的文件里做语义搜索，可以加一个 embeddings 节点（比如 nomic-embed-text 的 768 维，或更轻的 all-MiniLM-L6-v2 的 384 维），把向量存进 starter kit 里已经自带的 Qdrant，无需额外安装。

这正是整套方案的意义所在：你的文件、你的模型、你的机器，数据从头到尾不离开本地。

Embedding（嵌入） 是将文本转换为固定长度数值向量的过程，其核心思想是让语义相近的文本在向量空间中距离更近。文中提到的 nomic-embed-text（输出 768 维向量）和 all-MiniLM-L6-v2（输出 384 维向量）都是专门为此设计的轻量模型，与用于生成摘要的 Llama 3.2 是不同类型的模型——前者只负责「编码理解」，不生成新文本。维度越高通常语义表达越精细，但存储和检索的计算量也随之增加；384 维的模型在普通硬件上已能提供相当实用的搜索质量，是资源受限场景下的常见选择。把本地文件的 embedding 存入 Qdrant 后，就可以通过自然语言问句在自己的文档库中做近似检索，整个过程同样不需要访问任何外部服务。