n8n AI Agent搭建教程：自动邮件+PostgreSQL记忆

n8n 的工作流自动化能力，配合 AI Agent 节点和外部记忆存储，可以做出一个"发邮件给自己"的智能问答助手。一位 YouTube 创作者（频道 kayum 698）用 Google Gemini 作为聊天模型、PostgreSQL 作为记忆后端，串联起一条从提问到收件的完整链路。整个流程在 n8n 画布上由四个节点组成：Chat Message 触发输入，AI Agent 调用模型并读写记忆，Send Email 节点负责投递结果。下面拆解这条工作流的构成逻辑和配置要点。

四个节点如何串成一条闭环

工作流从提问到投递邮件的执行链路

整条工作流的结构并不复杂，但每个节点承担的角色很明确。Chat Message 节点是入口，用户在这里输入问题——比如"印度有多少个邦"或"印度当前人口是多少"。AI Agent 节点居中调度，它挂载了两项关键配置：Chat Model 选择 Google Gemini，Memory 选择 PostgreSQL。PostgreSQL 实际运行在一个 Docker 容器里，独立于 n8n 本体，这意味着对话历史不会随工作流重启而丢失。最后 Send Email 节点接收 AI Agent 输出的 json.output 字段，通过 SMTP 把答案发到指定邮箱。

这种"提问→推理→投递"的模式，适合需要异步获取 AI 回答的场景。比起盯着聊天窗口等回复，把结果送进邮箱更符合某些工作习惯——比如把 AI 当成一个后台助理，提问后继续做别的事，回头查收邮件即可。

n8n 是一款开源的工作流自动化工具，采用「节点即步骤」的可视化画布设计。用户把不同功能的节点拖到画布上，用连线定义数据流向，即可构建出无需编写代码的自动化流程。n8n 的节点分为触发节点（如定时、Webhook、聊天消息）和执行节点（如 HTTP 请求、数据库操作、邮件发送），数据以 JSON 对象的形式在节点之间传递。相比 Zapier 等 SaaS 工具，n8n 支持自托管，可以部署在本地服务器或 Docker 容器中，对数据隐私和成本控制更友好。本文的工作流正是利用 n8n 的节点编排能力，把大语言模型、数据库和邮件服务这几类原本独立的组件拼接成一条自动化链路。理解「节点接收上游 JSON、处理后输出新 JSON」这一数据流模型，是读懂后续各节点配置的前提。

PostgreSQL 做记忆：为什么不用内置存储

AI Agent 节点调用 Gemini 模型并读写 PostgreSQL 记忆

n8n 的 AI Agent 节点本身支持多种记忆方案，创作者选择 PostgreSQL 并非偶然。内置的 Window Buffer Memory 只在单次执行会话内有效，工作流一旦结束，上下文就清空了。PostgreSQL 作为持久化存储，可以把对话轮次写入数据库表，下次触发同一 Agent 时继续读取历史。

对于需要"记住"之前聊过什么的场景，这个区别很关键。用户第一次问"印度有多少个邦"，第二次问"那它的人口呢"，如果记忆被清空，第二个问题就失去了指代对象。PostgreSQL 的存在让多轮对话在多个工作流执行之间保持连贯。创作者把数据库跑在 Docker 容器里，也说明这套方案对本地部署环境友好，不依赖云数据库服务。

**AI Agent 的 Memory（记忆）**指的是让大语言模型在多轮对话中保持上下文连贯的机制。大语言模型本身是无状态的，每次调用只处理当前输入的提示词，不会自动记住之前的对话。为了让模型「记得」聊过什么，需要在每次请求时把历史对话一并塞进提示词，而 Memory 组件负责的就是存取这段历史。n8n 的 AI Agent 节点支持多种 Memory 后端：Window Buffer Memory 把历史保存在内存里，仅限单次执行会话；PostgreSQL、Redis 等外部存储则可以把历史落盘，实现跨会话、跨重启的持久化。选择哪种 Memory，本质上是在「简单但易失」和「持久但需维护」之间权衡。历史对话通常按轮次或按 token 数量窗口截断，避免提示词无限膨胀导致超出模型的上下文长度限制或推高调用成本。

模型输出如何变成一封邮件

Send Email 节点通过表达式提取 AI 输出并配置 SMTP

Send Email 节点的配置是整条链路里最容易卡住的一步。创作者在邮件正文的 Text 字段中使用表达式 {{ $json.output }}，把 AI Agent 的回复内容直接映射为邮件正文。这个表达式的前提是 AI Agent 节点的输出结构里确实有 output 字段——不同版本的 n8n 或不同的 Agent 配置可能产生不同的输出路径，需要根据实际运行结果调整。

SMTP 配置方面，创作者使用的是 Gmail 的默认主机 smtp.gmail.com，SSL 端口保持启用。这里有一个容易踩的坑：密码字段必须填 Google App Password，而不是 Gmail 账号的登录密码。Google App Password 需要在 Google 账号的安全设置里单独生成，普通密码在 SMTP 认证中会被拒绝。邮件主题、发件人等字段则按常规填写即可，创作者在示例中把主题设为与 n8n 相关的标识，方便在收件箱里快速筛选。

Google App Password 是 Google 为不支持 OAuth 2.0 的旧式客户端（如 SMTP、IMAP 客户端）提供的替代密码方案。自 Google 收紧账号安全策略后，普通 Gmail 登录密码无法再直接用于 SMTP 认证，会返回「用户名和密码不被接受」的错误。App Password 是一串 16 位、由空格分隔的字符，需要在 Google 账号的「安全性」设置中开启两步验证后才会出现生成入口，且每台设备或每个应用应生成独立的密码以便单独撤销。另一个相关概念是 SMTP（简单邮件传输协议），它是发送邮件的事实标准协议，默认明文端口为 25，加密端口为 465（SSL）或 587（STARTTLS）。n8n 的 Send Email 节点需要填写 SMTP 主机、端口、用户名、密码及加密方式，任何一项不匹配都会导致认证失败或投递超时。

实测效果与已知限制

模型执行完成后投递到沙箱邮箱的邮件内容

从创作者演示的三次提问来看，工作流能稳定跑通。"印度有多少个邦"的回答是 28 个邦加 8 个联邦属地；"印度当前人口"给出的数值在 14.3 亿到 14.4 亿之间；"全球有多少个国家"的回答是 195 个，并补充说明了巴勒斯坦、台湾、科索沃等争议地区的计数差异。这些回答的质量主要取决于 Gemini 模型本身，n8n 在这里扮演的是管道角色。

需要留意的是，创作者在演示中提到的部分数据带有时间标记，实际使用时模型给出的数值可能因训练数据截止时间而不同。另外，PostgreSQL 记忆虽然持久，但也意味着对话历史会不断累积，长期运行需要考虑数据库表的清理策略。SMTP 方案依赖 Gmail 的发送限额，高频使用可能触发限制。

这套方案适合谁

如果你已经在用 n8n 做自动化，并且希望把 AI 能力接入现有的邮件通知体系，这条工作流提供了一个可复用的模板。它的价值不在于技术复杂度，而在于把几个成熟组件——Gemini、PostgreSQL、SMTP——用 n8n 的节点编排能力组合成了一个有状态、可持久化的 AI 助理。创作者表示后续会发布完整的搭建教程视频，对于想复现的读者来说，先理解每个节点的职责分工，比照搬配置更重要。