n8n 中文教程：基础 LLM 链 ​、摘要链与问答链

大家好，我是翔宇。非常高兴能再次通过“翔宇工作流”和大家见面。在自动化和人工智能飞速发展的今天，n8n 作为一款强大的可视化工作流自动化工具，为我们打开了连接万物、自动化繁琐任务的大门 。而 n8n 与 LangChain 的深度集成，更是将前沿的 AI 能力带到了我们触手可及的地方，即使没有任何编程基础，也能构建出强大的 AI 应用 。

很多关注“翔宇工作流”的朋友都是希望利用 n8n 提升效率、解决实际问题的实践者，其中不乏对编程感到陌生的初学者。正是基于这一点，翔宇精心准备了这篇深度教程，目标就是带领零代码基础的读者朋友们，一起探索 n8n（以最新版本为准）中 LangChain 集成里三个非常核心且常用的“链”（Chain）节点：​基础 LLM 链 (Basic LLM Chain)​、摘要链 (Summarization Chain) 和 ​问答链 (Question and Answer Chain)​。

本教程的目标与读者群体

本教程的核心目标非常明确：​帮助零代码基础的 n8n 用户，清晰地理解这三个 Chain 节点是什么、能做什么、如何配置，并最终能够熟练地将它们应用到自己的工作流中，解决实际问题​。我们将从每个节点的基础概念讲起，深入剖析各项参数配置，并结合翔宇自己在实际项目中的使用经验和理解（也就是“翔宇实战理解”），为大家提供最接地气的解读和操作指导。我们还会详细探讨数据如何在节点间流转（数据映射与表达式），如何连接和配置大语言模型（Chat Model）和记忆（Memory）组件（以及它们的局限性），并分享翔宇常用的应用场景、常见的报错及其解决方案，以及使用这些节点时需要注意的事项。特别地，我们还会有一个非常详尽的章节，专门深入探讨与这些链节点（尤其是未来可能配合 Agent 使用时）紧密相关的“工具”（Tool）概念及其在 n8n 中的具体实现，这部分内容会比较深入，篇幅也较长，希望能为大家打下坚实的基础。

核心节点概览

在正式开始之前，让我们先简单了解一下本次教程将要深入探讨的三个主角 ：

1. 基础 LLM 链 (Basic LLM Chain): 这是与大语言模型（LLM）进行交互的最基本、最直接的方式。你可以用它来向 LLM 发送指令（Prompt），让模型为你生成文本、回答简单问题、转换格式等等。它是构建更复杂 AI 功能的基础模块 。
2. 摘要链 (Summarization Chain): 顾名思义，这个节点专门负责“浓缩精华”。无论是长篇报告、网页内容还是多份文档，摘要链都能帮你快速提取核心要点，生成简洁的摘要 。
3. 问答链 (Question and Answer Chain): 这是实现基于自有知识库进行问答（即检索增强生成，RAG）的关键节点。它可以连接到你的知识库（通常是向量数据库 Vector Store），先从中检索相关信息，然后结合你的问题，让 LLM 给出精准的回答 。

需要特别指出的是，在 n8n 的 LangChain 实现中，这三个 Chain 节点本身是不具备“记忆”功能的。也就是说，它们无法记住你和它之前的对话历史。如果你需要构建一个能够进行连续多轮对话、并且能记住上下文的 AI 应用（比如一个真正的聊天机器人），你需要使用 AI Agent 节点 并为其配置 Memory 子节点。这一点我们会在后续章节中再次强调。

学习前提与准备

为了让学习过程更顺畅，翔宇建议大家：

• 对 n8n 有基本了解: 最好已经熟悉 n8n 的界面，知道如何添加节点、用“小面条”把它们连接起来，以及如何查看节点运行后的数据 。如果你是完全的新手，可以先看看 n8n 官方的快速入门指南 或翔宇工作流之前的入门教程。
• 准备 API 密钥: 本教程会涉及到连接外部的大语言模型服务，例如 OpenAI (ChatGPT)、Google Gemini、Anthropic (Claude) 等。你需要提前注册这些服务的账号，并获取相应的 API 密钥 (API Key) 。教程中我们会演示如何在 n8n 中配置和使用这些密钥。

好了，背景介绍完毕。相信大家已经对接下来的学习内容有了初步的期待。n8n 的 AI 功能非常强大且富有潜力 。接下来，就让翔宇带领大家，一步步揭开这些 AI Chain 节点的神秘面纱，掌握在 n8n 中运用 AI 的实用技能！让我们开始吧！

基础 LLM 链 (Basic LLM Chain)

概览

节点定义与核心功能

基础 LLM 链 (Basic LLM Chain) 是 n8n 中 LangChain 功能集里最基础、也是最核心的“链”节点之一 。你可以把它理解为 n8n 工作流与大语言模型 (LLM) 直接对话的“传声筒”和“指令官”。

它的核心功能主要有两个 ：

1. 设置 Prompt (提示): 定义你想让 LLM 执行的任务或回答的问题。这个 Prompt 就是你给 AI 的指令。
2. 处理响应 (可选): 可以选择性地连接“输出解析器”(Output Parser) 来规范和处理 LLM 返回的原始文本响应。

简单来说，当你需要在工作流中直接调用 LLM 完成某项基于文本的任务时，基础 LLM 链节点通常是你的第一选择。

基本用途

由于其基础和直接的特性，基础 LLM 链的应用场景非常广泛，尤其适合执行相对单一、明确的 AI 任务 ，例如：

• 文本生成: 根据特定要求写邮件、生成报告摘要、构思社交媒体文案等。
• 简单问答: 基于通用知识或你在 Prompt 中提供的少量上下文信息回答问题。
• 格式转换: 要求 LLM 将输入文本转换成特定的格式，比如 JSON 或 Markdown。
• 内容改写/润色: 优化现有文本，改进语法、风格或使其更清晰。
• 初步的多模态处理: 结合支持图像输入的 LLM，实现看图说话（生成图片描述）等功能。

与其他节点的关系

一个典型的基础 LLM 链节点在工作流中的位置通常是这样的：

1. 上游节点: 它接收来自上游节点的数据。这些数据可以用来动态构建 Prompt。例如，一个读取了邮件内容的节点可以将邮件文本传递给基础 LLM 链。
2. 自身: 在这里配置如何构建 Prompt (是直接定义还是从上游数据获取)，以及是否需要特定的输出格式。
3. 下游子节点 (必需): 它必须连接一个 Language Model (语言模型) 子节点 。这个子节点才是真正执行 AI 计算的部分，比如 OpenAI Chat Model, Google Gemini Chat Model 等。基础 LLM 链将构建好的 Prompt 发送给这个子节点。
4. 下游子节点 (可选): 如果开启了“要求特定输出格式”，则还需要连接一个 Output Parser (输出解析器) 子节点 。
5. 后续节点: 基础 LLM 链 (或其连接的 Output Parser) 的输出结果，会传递给工作流中的后续节点进行进一步处理，例如发送邮件、保存到数据库等。

理解这个关系很重要，基础 LLM 链本身不进行 AI 计算，它更像是一个协调者，负责准备输入 (Prompt) 并协调与 AI 模型子节点的交互。

参数配置

打开基础 LLM 链节点的配置面板，你会看到几个关键的参数。让我们逐一解析，并结合翔宇的实战经验来理解它们。

Prompt (提示)

这是节点最核心的配置项，决定了你如何向 LLM 发出指令 。它提供了两种主要方式：

1. Take from previous node automatically (自动从上一个节点获取)
   • 功能: 选择此项后，节点会期望从直接连接到它的上游节点获取一个名为 chatInput 的字段，并将该字段的值作为 Prompt 发送给 LLM 。
   • 翔宇实战理解: 这个选项是为聊天机器人类应用量身定做的。当你使用 n8n 的 Chat Trigger (例如 Telegram Trigger, Webhook Trigger 配合聊天前端) 来接收用户消息时，Chat Trigger 通常会将用户的输入放在 chatInput 字段中。这时，将基础 LLM 链的 Prompt 设置为自动获取，就能无缝对接用户的提问 。
   • 翔宇提示: 如果你的上游节点输出的数据里没有 chatInput 这个字段，或者字段名不是这个，工作流执行到这里就会报错 。别担心，你只需要在上游节点和基础 LLM 链节点之间加一个 Edit Fields (Set) 节点，用它来添加一个 chatInput 字段，或者将现有包含用户输入的字段重命名为 chatInput 即可解决 。
2. Define below (在下方定义)
   • 功能: 选择此项后，下方会出现一个 Prompt (User Message) 的文本框，允许你直接在这里编写 Prompt 内容 。
   • 翔宇实战理解: 这是更通用的方式，适用于各种非聊天机器人场景，或者即使是聊天机器人，你也想在用户输入的基础上增加额外指令的情况。
   • 灵活性: 这个文本框非常灵活，你可以：
     • 输入静态文本: 直接写固定的指令，例如 “请将以下英文翻译成中文：”。
     • 使用表达式 (Expressions): 这是 n8n 强大的地方！你可以点击文本框右侧的 “Add Expression” 按钮，或者直接输入 {{ }}，在其中嵌入来自上游节点的数据。例如，如果上游节点输出了一个名为 articleContent 的字段，你可以这样写 Prompt：“请将以下文章总结为 100 字以内：{{ $json.articleContent }}”。这样每次执行时，Prompt 都会动态地包含不同的文章内容。
   • 翔宇提示:​Prompt 的质量是决定 LLM 输出效果的关键！ 翔宇的经验是，Prompt 要尽可能​清晰、具体、无歧义​。明确告诉 AI 它的角色、任务目标、输入是什么、输出要求（格式、长度、风格等）。写 Prompt 就像给一个非常聪明但没有背景知识的新手分配任务，你需要把所有必要的指示都给到。

Require Specific Output Format (要求特定输出格式)

• 功能: 这是一个开关选项。默认关闭。当你打开这个开关时，n8n 会强制你必须为这个基础 LLM 链节点连接一个 Output Parser (输出解析器) 子节点 。
• 为什么需要它? 大语言模型通常返回的是非结构化的自然语言文本。但在自动化工作流中，我们往往需要结构化的数据（比如 JSON 格式的数据）才能方便地进行后续处理（例如，存入数据库、在其他 API 中使用）。这个选项就是为了解决这个问题。开启它，就意味着你告诉 n8n：“我需要 AI 返回特定格式的数据，并且我已经准备好了相应的解析器来处理它。”
• 可连接的 Output Parsers: 当你开启此选项后，可以连接以下几种 n8n 内置的解析器子节点 ：
  • Auto-fixing Output Parser: 尝试自动修复 LLM 输出中轻微的格式错误，使其符合预期。
  • Item List Output Parser: 用于从 LLM 的响应中提取一个项目列表。
  • Structured Output Parser: 要求 LLM 按照你定义的特定结构（通常是 JSON Schema）来输出信息。
• 翔宇实战理解: 这个功能对于我们这些追求自动化的“懒人”来说太有用了！想象一下，你让 AI 从一段简历文本中提取姓名、电话、邮箱和工作经历。如果直接输出自然语言，你可能需要写复杂的正则表达式或代码来解析。但如果开启这个选项，连接一个 Structured Output Parser，并定义好需要的 JSON 结构，你就可以在 Prompt 里指示 AI：“请提取以下信息，并严格按照指定的 JSON 格式返回：{…schema…} \n\n 简历文本：{{ $json.resumeText }}”。这样，输出解析器会帮助你得到干净、结构化的 JSON 数据，极大地简化了后续操作 。
• 一个重要的观察: n8n 提供这个明确的开关以及配套的 Output Parser 节点，恰恰说明了直接处理原始 LLM 输出对于非技术用户来说是一个普遍的痛点。LLM 的强项在于理解和生成自然语言，但它们的输出天然是“自由”的。n8n 通过这种方式，将“强制输出结构化”这个复杂任务，变成了一个可视化的节点连接操作，大大降低了在工作流中使用 AI 并获得可用数据的门槛。这对于零代码基础的用户尤其友好。

Chat Messages (聊天消息 – 仅适用于 Chat Model)

这一部分参数只有在你为基础 LLM 链节点连接了 Chat Model (聊天模型) 子节点（例如 OpenAI Chat Model, Gemini Chat Model 等）时才会生效。如果连接的是普通的文本补全模型，这些设置会被忽略 。

聊天模型与普通文本补全模型的主要区别在于，它们是基于“对话历史”进行交互的。因此，你可以通过设置不同角色的消息，来更好地引导模型的行为或提供上下文示例。

• System (系统消息):
  • 功能: 在这里输入的文本会作为一条系统层级的指令，通常在对话开始前发送给模型，用于设定模型的整体行为、角色或规则 。
  • 翔宇实战理解: 这是塑造 AI “人设”的关键。比如，你可以设置：“你是一位资深的 n8n 技术客服，请用专业且耐心的语气回答用户问题。” 或者像官方例子那样：“Always respond talking like a pirate.” (总是像海盗一样说话)。System 消息对于控制 AI 的语气、风格和回答问题的角度非常有效。
• User (用户消息):
  • 功能: 提供一个用户输入的示例。通常与下面的 AI 消息配合使用 。
  • 输入类型:
    • Text: 最常见的，直接输入示例文本消息 。
    • Image (Binary): 如果你的 Chat Model 支持多模态输入 (如 GPT-4o, Gemini Pro Vision)，你可以选择这个选项，并指定上游节点输出的包含二进制图片数据的字段名。例如，上游节点读取了一个图片文件，输出字段为 data，这里就填 data。
    • Image (URL): 同样适用于多模态模型，可以直接提供图片的 URL 地址 。
  • Image Details (图片细节 – 仅适用于图片输入):
    • Auto: 模型自动判断使用低分辨率还是高分辨率处理图片。
    • Low: 使用 512×512 的低分辨率版本，消耗 Token 少 (约 65 tokens)，响应快，适用于不需要高细节的场景。
    • High: 模型会先看低分辨率版本，再根据需要处理更高分辨率的细节图块 (每个图块 512px，消耗更多 tokens，约 129 tokens per crop)，适用于需要识别图像细节的场景。
    • 翔宇实战理解: 图片输入功能开启了视觉问答、图片描述生成等激动人心的可能性！但要注意，处理图片会消耗额外的 Token，尤其是高分辨率模式，这会影响 API 调用成本和响应速度。需要根据实际需求权衡选择。
• AI (AI 消息):
  • 功能: 提供一个与上面 User 消息对应的 AI 回复示例 。
  • 翔宇实战理解:User 和 AI 消息对一起使用，构成了所谓的 Few-Shot Prompting (少样本提示)。通过提供一两个“输入-输出”的范例，可以极大地提升模型在执行特定、复杂或需要遵循特定格式的任务时的表现。例如，你想让 AI 扮演客服角色，可以提供一个用户抱怨和一个理想的 AI 回复作为示例，模型会学习这种交互模式。

数据映射与表达式

理解数据如何在 n8n 节点间流动，以及如何使用表达式动态处理数据，是掌握 n8n 的关键，对于 AI 节点尤其如此。

输入数据处理

基础 LLM 链节点如何获取其需要的数据 (主要是 Prompt 内容)？

1. 来自上游节点: 这是最常见的方式。上游节点执行完毕后，其输出数据会传递给基础 LLM 链。你可以通过 n8n 的表达式来访问这些数据。
   • 常用表达式:
     • {{ $json.fieldName }}: 访问当前输入项 (item) 中名为 fieldName 的字段值。这是最常用的方式。
     • {{ $node["Node Name"].json.fieldName }}: 访问名为 “Node Name” 的节点输出的第一个输入项中名为 fieldName 的字段值。当你需要引用非直接上游节点的数据时使用。
     • {{ $items("Node Name").json.fieldName }}: 访问名为 “Node Name” 的节点输出的所有输入项中的第一个项的 fieldName 字段值。
   • 应用场景:
     • Take from previous node automatically: 节点自动查找 $json.chatInput。
     • Define below (Prompt 文本框): 你可以在这里嵌入表达式，动态构建 Prompt。例如，上游节点是读取邮件的节点，输出了 subject 和 body 字段，你可以这样写 Prompt:请根据以下邮件内容生成一个简短回复建议： 主题：{{ $json.subject }} 正文：{{ $json.body }} ​
     • Chat Messages (Text 类型): 同样可以在 System, User, AI 消息中使用表达式。
2. 直接定义: 对于 Define below 的 Prompt 或 Chat Messages 中的静态文本，数据就直接来源于你在配置界面输入的内容。

输出数据结构

基础 LLM 链节点执行完毕后，它的输出数据是什么样的？

• 主要输出: 其核心输出是 ​LLM 返回的响应文本​。
• 数据结构:
  • 当前推荐/修复后版本 (如 v1.85.3+, v1.84.2+): 输出通常是一个包含 text 字段的 JSON 对象。你可以通过 {{ $json.text }} 来访问 AI 生成的文本 。 JSON[ { "json": { "text": "这是 AI 生成的回复文本。" } } ] ​
  • 曾出现问题的版本 (如 v1.85.0 – v1.85.2): 输出曾被错误地包裹在一个额外的 response 对象中 。在这种版本下，你需要用 {{ $json.response.text }} 来访问。 JSON[ { "json": { "response": { "text": "这是 AI 生成的回复文本。" } } } ] ​
• Output Parser 的影响: 如果你开启了 Require Specific Output Format 并连接了 Output Parser，那么最终的输出结构将由该 Output Parser 决定。例如，Structured Output Parser 会直接输出你定义的 JSON 结构。
• 关于输出结构变化的思考: 这个 response 包裹问题的出现和修复过程 给我们带来了一个重要的启示：即使是 n8n 的稳定版本更新，有时也可能因为内部代码的调整（比如重构）而无意中改变节点的行为或输出格式，哪怕节点本身的“版本号”看起来没有变化。这对于依赖特定数据路径的自动化流程来说是有风险的。因此，翔宇强烈建议大家：
  1. 关注 Release Notes: 每次更新 n8n 前，都应该大致浏览一下新版本的发布说明，特别是与你常用节点（尤其是 AI 节点）相关的改动。
  2. 建立测试环境: 对于生产环境中的重要工作流，最好有一个独立的测试环境。在测试环境中升级 n8n 并充分测试现有工作流，确认无误后再升级生产环境。
  3. 做好版本控制 (如果可能): 对于自托管的 n8n，考虑使用 Docker 镜像标签等方式固定 n8n 版本，在有充分准备和测试后再进行升级。

表达式应用实例

让我们看几个在基础 LLM 链中使用表达式的例子：

• 动态 Prompt:
  • 上游节点 (名为 “Read Product Info”) 输出: { "json": { "productName": "智能降噪耳机", "features": ["主动降噪", "蓝牙5.3", "30小时续航"] } }
  • 基础 LLM 链 Prompt (Define below):为产品“{{ $json.productName }}”写一段吸引人的广告语，突出特点：{{ $json.features.join(', ') }}。 ​
• 动态 System Message:
  • 上游节点 (名为 “Set Tone”) 输出: { "json": { "tone": "活泼幽默" } }
  • 基础 LLM 链 Chat Messages – System (Define below):请用 {{ $json.tone }} 的语气回答问题。 ​
• 处理列表输入 (需要注意): n8n 的节点通常会为输入的每个 item 执行一次。如果上游节点输出了一个包含多个产品的列表，基础 LLM 链默认会对每个产品执行一次 Prompt。
  • 上游节点输出: JSON ​
  • 基础 LLM 链 Prompt: 介绍产品 {{ $json.product }}
  • 结果: 节点会执行两次，分别输出产品 A 和产品 B 的介绍。

掌握数据映射和表达式是灵活运用基础 LLM 链的关键，它能让你的 AI 调用不再是固定的模板，而是能根据实时数据动态适应。

Chat Model 连接与配置

基础 LLM 链节点本身只是一个“指令官”，它需要一个真正的“士兵”——也就是 Language Model 子节点——来执行 AI 计算。

连接方式

连接 Language Model 非常简单。在基础 LLM 链节点的底部，你会看到一个标有 + Language Model 的连接点。点击它，n8n 就会弹出可选的 Language Model 子节点列表，选择你想要使用的模型即可 。

常用 Chat Models

n8n 支持多种 Language Model，其中 Chat Model (聊天模型) 是目前的主流，因为它们通常在对话和指令遵循方面表现更好。以下是一些 n8n 中常用的 Chat Model 子节点 ：

• OpenAI Chat Model: 连接 OpenAI 的 GPT 系列模型 (如 GPT-3.5-turbo, GPT-4, GPT-4o)。这是目前最常用、能力也较强的选择之一，但需要 OpenAI API Key 并且是付费的 。
• Google Gemini Chat Model: 连接 Google 的 Gemini 系列模型 (如 Gemini Pro, Gemini Flash, Gemini 1.5 Pro)。提供了强有力的竞争选项，同样需要 Google Cloud API Key 或 MakerSuite API Key，有免费额度但超出需付费 。
• Anthropic Chat Model: 连接 Anthropic 的 Claude 系列模型 (如 Claude 3 Sonnet, Claude 3 Opus, Claude 3 Haiku)。以其强大的长文本处理能力和安全性著称，需要 Anthropic API Key，付费使用 。
• Ollama Chat Model: 这是连接本地运行的开源模型的节点！如果你在自己的电脑或服务器上通过 Ollama 运行了像 Llama 3, Mistral, Phi-3 等模型，可以使用这个节点来调用它们。优点是​免费、数据隐私性高​，缺点是需要自己配置和维护 Ollama 环境，且对硬件有一定要求 。
• 其他模型: n8n 还支持 Mistral AI Cloud, Cohere, AWS Bedrock, Azure OpenAI 等多种模型服务，你可以根据自己的需求和可用的 API 权限来选择 。

配置传递与分离

需要理解的是，配置是分离的：

• 基础 LLM 链节点: 负责配置 Prompt 和 Chat Messages (如果使用 Chat Model)。这些内容定义了 ​发给模型什么信息​。
• Language Model 子节点: 负责配置 ​模型本身的参数​，例如：
  • Model: 选择具体的模型版本 (如 gpt-4o, claude-3-sonnet-20240229)。
  • Temperature: 控制输出的随机性/创造性 (值越高越随机)。
  • Max Tokens: 限制模型生成响应的最大长度。
  • Credentials: 配置连接该模型服务所需的 API Key。
  • 其他模型特有参数 (如 Top P, Top K, Frequency Penalty 等)。

基础 LLM 链会将它准备好的 Prompt 和 Chat Messages 传递给连接的 Language Model 子节点，子节点再结合自身的参数设置，去调用相应的 AI 服务 API。

翔宇提示: 选择哪个 Chat Model 对你的工作流的成本、速度和最终效果有决定性影响。

• 能力: GPT-4/Opus/Gemini Advanced 通常能力最强，但成本也最高。GPT-3.5/Haiku/Gemini Flash/Mistral-small 等更经济，但能力稍逊。
• 成本: 注意各模型按 Token 计费的方式，长 Prompt 和长输出都会增加成本。
• 速度: 有些模型响应更快 (如 Gemini Flash, Groq 上的模型)。
• 本地模型 (Ollama): 如果数据隐私是首要考虑，或者想完全免费使用 (不计硬件和电力成本)，Ollama 是个好选择。但本地模型的配置和性能调优相对复杂 。你需要确保 n8n 能够访问到运行 Ollama 的服务地址 。

Memory 注意事项

这是使用 Chain 节点时一个非常关键、也容易让初学者混淆的地方。

关键限制：Chain 节点无记忆！

翔宇必须再次强调：n8n 中的所有 Chain 节点，包括我们正在讨论的基础 LLM 链，本身不具备记忆 (Memory) 功能。

这意味着什么？当你连续多次通过同一个基础 LLM 链节点与 AI 交互时，每一次交互都是独立的。AI 完全不记得你上一次问了什么，或者它上一次回答了什么。它每次都只根据当前这一次接收到的 Prompt 来生成回应。

为什么 Chain 没有 Memory？

这主要是 n8n 对 LangChain 概念的一种实现选择。在 LangChain 的原始框架 (Python/JS 库) 中，Chain 是可以被赋予 Memory 组件的。但在 n8n 的可视化节点实现中，为了区分 Chain 和 Agent 的功能，n8n 将 Memory 功能主要与 Agent 节点绑定 。

• Chain: 设计为执行一系列预定义的、通常是无状态的 LLM 调用序列。
• Agent: 设计为更智能的实体，能够根据当前情况和历史交互 (Memory)，自主决定下一步行动 (调用哪个 Tool)。

替代方案：AI Agent + Memory

如果你确实需要构建一个能够进行多轮对话、记住上下文的应用，你应该学习和使用 AI Agent 节点。

AI Agent 节点允许你连接各种 ​Memory 子节点​，例如 ：

• Simple Memory (原 Window Buffer Memory): 在 n8n 运行内存中保存最近 N 轮对话历史。简单易用，但 n8n 重启后内存会丢失，且在 Queue Mode 下不可靠 。
• Redis Chat Memory: 使用 Redis 数据库存储对话历史。速度快，可持久化，适合生产环境 。
• Postgres Chat Memory: 使用 PostgreSQL 数据库存储对话历史。同样适合持久化存储，如果你的系统已经在使用 Postgres 会很方便 。
• 其他 Memory: 如 MongoDB, Xata, Zep 等。

通过为 AI Agent 连接 Memory 子节点，Agent 就能够在每次执行时加载之前的对话历史，并将其与当前的用户输入一起发送给 LLM，从而实现有记忆的对话。

翔宇提示: 切记！不要期望基础 LLM 链能帮你记住对话。 如果你的应用场景是用户需要和 AI 进行连续的多轮问答或交流，请务必转向学习 AI Agent 节点及其 Memory 配置。将基础 LLM 链用于它最擅长的一次性、无状态的 AI 任务。

常用应用场景

虽然基础 LLM 链是“基础”节点，但它的应用场景非常广泛且实用。以下是翔宇在实际工作中经常使用基础 LLM 链的一些场景：

1. 邮件/消息草稿生成:
   • 场景: 需要快速回复邮件或 Slack 消息，但想先让 AI 生成一个草稿。
   • 流程: 读取邮件/消息内容 -> 基础 LLM 链 (Prompt: “请根据以下信息，以专业语气起草一封回复邮件/消息：{{ $json.messageContent }}”) -> 输出草稿供人工审核或直接发送。
2. 内容摘要 (简单版):
   • 场景: 对于不太长的文本（能放入 Prompt 的 Context Window 内），需要快速生成摘要。
   • 流程: 获取文本 -> 基础 LLM 链 (Prompt: “请将以下文本总结为三个要点：{{ $json.textContent }}”) -> 输出摘要。
   • 注意: 对于非常长的文本，应使用后面会讲到的 Summarization Chain 节点。
3. 文本格式转换:
   • 场景: 将一段非结构化的文本转换成 JSON 格式，方便后续处理。
   • 流程: 获取文本 -> 基础 LLM 链 (开启 Require Specific Output Format, 连接 Structured Output Parser, Prompt 指示按 JSON 格式提取信息) -> 输出结构化 JSON 数据 。
   • 翔宇实例: 从网页抓取的招聘信息文本中，提取职位名称、公司、地点、薪资范围，并输出为 JSON。
4. 内容改写与润色:
   • 场景: 对已有的文案进行风格转换、语法修正或使其更简洁/更详细。
   • 流程: 获取原始文案 -> 基础 LLM 链 (Prompt: “请将以下段落改写得更通俗易懂：{{ $json.originalText }}” 或 “请检查并修正以下文本的语法错误：{{ $json.draftText }}”) -> 输出修改后的文案。
5. 关键词提取:
   • 场景: 从一篇文章或用户评论中提取核心关键词。
   • 流程: 获取文本 -> 基础 LLM 链 (Prompt: “请提取以下文本的 5 个核心关键词，用逗号分隔：{{ $json.inputText }}”) -> 输出关键词列表。
6. 简单分类/打标签:
   • 场景: 根据文本内容将其归入预定义的几个类别之一。
   • 流程: 获取文本 -> 基础 LLM 链 (Prompt: “请判断以下评论属于 ‘好评’, ‘中评’, 还是 ‘差评’？\n评论：{{ $json.comment }}\n类别：”) -> 输出类别名称。
   • 注意: 对于更复杂的分类任务，n8n 提供了专门的 Text Classifier 节点 。
7. 生成代码解释或注释:
   • 场景: 需要理解一段代码的功能或为其添加注释。
   • 流程: 获取代码片段 -> 基础 LLM 链 (Prompt: “请解释以下代码的功能：\n{{ $json.language }}\n{{ $json.codeSnippet }}\n” 或 “请为以下代码添加必要的注释：…”) -> 输出解释或带注释的代码。
8. 多模态初步应用 – 图片描述:
   • 场景: 需要为图片生成描述性文字。
   • 流程: 获取图片 (URL 或 Binary) -> 基础 LLM 链 (连接支持图片输入的 Chat Model, User Message 类型设为 Image, Prompt: “请描述这张图片的内容。”) -> 输出图片描述 。

翔宇实例分享: 翔宇曾经搭建过一个工作流，用于自动处理客户反馈。工作流首先从表单接收反馈文本，然后使用基础 LLM 链判断反馈的情绪（正面/负面/中性），接着根据情绪将反馈路由到不同的处理流程（例如，负面反馈自动创建 Trello 卡片并通知相关人员）。这个简单应用就很好地体现了基础 LLM 链在工作流中作为 AI 判断和处理环节的作用。

基础 LLM 链就像是 n8n AI 工具箱里的瑞士军刀，虽然简单，但用途广泛，是许多复杂 AI 工作流不可或缺的起点。

常见报错及解决方案

在使用基础 LLM 链节点时，你可能会遇到一些常见的错误。了解这些错误的原因和解决方法，能帮你更快地排查问题。

• 错误信息:No prompt specified error 或 Parameter "Text" is required
  • 可能原因 1: 你将 Prompt 参数设置为 Define below，但是下方的 Prompt (User Message) 文本框是空的，或者你使用了表达式但该表达式没有成功生成任何文本 (结果为 null 或 undefined)。
  • 解决方案 1: 确保在 Prompt (User Message) 文本框中输入了有效的静态文本，或者检查你的表达式是否能正确引用上游数据并生成非空字符串。
  • 可能原因 2: 你将 Prompt 参数设置为 Take from previous node automatically，但是连接到该节点的上游节点输出的数据中，没有名为 chatInput 的字段，或者该字段的值是 null。
  • 解决方案 2: 检查上游节点的输出，确保它包含一个名为 chatInput 且值不为 null 的字段。如果字段名不对或不存在，可以在中间添加一个 Edit Fields (Set) 节点来创建或重命名字段 。
• 错误信息:Cannot read properties of undefined (reading 'message')
  • 可能原因: 这通常发生在连接的 Language Model 子节点未能成功返回响应时。具体原因可能是：
    • 模型 API 服务暂时不可用或出现问题。
    • 你使用的免费模型额度耗尽或服务过载 (社区帖子中提到 DeepSeek 免费模型可能出现此问题 )。
    • API Key 无效或配置错误。
    • 网络连接问题。
  • 解决方案:
    • 检查你的 Language Model 子节点的配置，特别是 Credentials (凭证) 是否正确且有效。
    • 检查你的模型服务提供商的状态页面，确认服务是否正常运行。
    • 如果你使用的是免费模型，尝试切换到一个付费模型或等待服务恢复 。
    • 检查你的网络连接。
    • 在 Language Model 子节点中尝试选择不同的模型版本。
• 错误信息:Request failed with status code 503
  • 可能原因: 503 Service Unavailable 错误通常表示你尝试连接的 AI 模型服务暂时无法处理请求，可能是因为服务器过载或正在维护。
  • 解决方案:
    • 稍后重试工作流。
    • 检查 AI 模型服务提供商的状态页面。
    • 确认你没有超出该服务的 API 请求频率限制 (Rate Limits)。如果请求过于频繁，可能需要加入 Wait 节点来控制速率 。
• 错误信息: (输出数据结构错误，例如多了 response 层)
  • 可能原因: 这是 n8n 特定版本 (大约在 v1.85.0 附近) 引入的一个 Bug，后来已被修复。
  • 解决方案:
    • 最佳方案: 将你的 n8n 更新到包含修复的版本 (官方提到 v1.85.3 或 v1.84.2 应该已修复)。
    • 临时方案 (如果无法更新): 修改你后续节点中访问输出数据的表达式，从 {{ $json.text }} 改为 {{ $json.response.text }}。但翔宇强烈建议更新 n8n 以避免潜在的其他问题。
• 错误信息: (来自 Language Model 子节点的错误，如 429 Too Many Requests, Insufficient Quota, API Key Invalid 等)
  • 可能原因: 这些错误直接来源于你连接的 AI 模型服务，与基础 LLM 链节点本身关系不大，但会在这里显现出来。原因包括：
    • API 请求频率超限 (Rate Limit)。
    • 账户余额不足或未绑定支付方式。
    • API Key 错误、过期或权限不足。
  • 解决方案:
    • 仔细阅读错误信息，它通常会指明具体问题。
    • 登录你的 AI 模型服务提供商的控制台，检查账户状态、账单信息、API Key 管理和用量限制。
    • 对于 Rate Limit 问题，可以在工作流中加入 Wait 节点或使用 Loop Over Items 配合 Wait 来分批、延时处理数据 。
    • 确保在 n8n 的 Credentials 中配置了正确的 API Key。
• 错误信息: (节点长时间执行/加载，不返回结果或最终超时)
  • 可能原因:
    • 连接的 AI 模型响应缓慢 (特别是本地模型或某些云服务在高峰期)。
    • 处理的输入数据量过大 (例如 Prompt 非常长)。
    • 网络连接不稳定或延迟高。
    • n8n 实例资源不足 (CPU/内存)。
    • 某些模型组合可能存在兼容性问题 (如社区提到 Cohere 模型曾出现问题 )。
  • 解决方案:
    • 尝试更换响应更快的 AI 模型。
    • 检查网络连接。
    • 优化 Prompt，减少不必要的长度。
    • 如果处理大量数据项，考虑分批处理 (但对于单个长 Prompt，分批无效)。
    • 增加 n8n 实例的资源。
    • 检查是否有已知的模型兼容性问题，或尝试更换模型组合。
    • 检查 Language Model 子节点是否有 Timeout 配置项可以调整 (如 OpenAI Chat Model )。

遇到错误不要慌，仔细阅读错误信息，结合翔宇上面列出的常见原因和解决方案，一步步排查，通常都能找到问题所在。同时，n8n 社区论坛 (community.n8n.io) 也是寻求帮助的好地方 。

注意事项

在使用基础 LLM 链节点时，有几个重要的点需要牢记在心：

1. 成本意识: 调用大多数商业 LLM 服务 (如 OpenAI, Google Gemini, Anthropic) 都是按量付费的，通常是根据输入和输出的 Token 数量计费。频繁调用或处理长文本可能会产生不小的费用。务必了解你所使用模型的计费规则，并在服务商后台监控你的用量和花费。
2. Token 限制: 每个 LLM 都有其上下文窗口 (Context Window) 的限制，即它一次能处理的 Token 总数（包括输入 Prompt 和生成的输出）。如果你的 Prompt 过长，或者你期望模型生成非常长的回复，可能会超出这个限制，导致请求失败或输出被截断。你需要根据所选模型的具体限制来设计 Prompt 和预期输出。
3. 无记忆性 (再次强调): 基础 LLM 链是无状态的，它不记得之前的交互 。不要用它来尝试构建需要连续对话的应用。如需记忆，请使用 AI Agent + Memory 节点。
4. 版本兼容性: AI 领域和 n8n 平台本身都在快速迭代。新版本的 n8n 或 LangChain 节点可能会带来功能增强，但也可能引入行为变化甚至 Bug (如之前讨论的输出格式问题 [Insight 2])。保持关注更新，并在升级后进行测试，对于依赖 AI 节点的工作流尤为重要。
5. Prompt 工程的重要性: 基础 LLM 链的输出质量高度依赖于你提供的 Prompt。写出好的 Prompt 是一门艺术，也是一门技术，通常需要反复尝试和优化才能达到理想效果。”Garbage in, garbage out” 在这里同样适用。
6. 数据隐私与安全: 当你将数据（尤其是敏感数据）通过基础 LLM 链发送给外部 AI 服务商时，需要仔细考虑数据隐私和安全问题。确保你了解服务商的数据使用政策。如果数据高度敏感，优先考虑使用本地部署的模型 (如通过 Ollama Chat Model 节点) ，或者寻找提供更强隐私保障的企业级 AI 服务。
7. 幻觉 (Hallucinations): LLM 有时会“一本正经地胡说八道”，即产生看似合理但实际上是错误或捏造的信息。对于基础 LLM 链生成的关键信息，尤其是在没有提供明确上下文的情况下，需要持谨慎态度，必要时进行事实核查。

掌握基础 LLM 链是踏入 n8n AI 世界的第一步。理解它的功能、配置、限制和注意事项，将为你后续学习更复杂的 AI 节点和构建强大的自动化流程打下坚实的基础。

摘要链 (Summarization Chain)

概览

节点定义与核心功能

摘要链 (Summarization Chain) 节点是 n8n 中专门为文本摘要任务设计的 LangChain 节点 。它的核心使命就是将冗长的文本内容（可以是一篇长文，也可以是多个文档的集合）浓缩成简洁、精炼的摘要。

与基础 LLM 链相比，摘要链内置了处理长文本和多文档的逻辑，特别是通过不同的摘要方法 (Summarization Method) 来应对超出单个 LLM 上下文窗口的挑战。

基本用途

摘要链的主要应用场景就是从大量文本信息中快速提取核心要点 ，例如：

• 总结网页内容: 快速了解一篇在线文章或博客的主要观点。
• 阅读报告/文档: 无需通读全文即可把握报告或技术文档的关键信息。
• 处理会议纪要/邮件: 从冗长的讨论记录或邮件串中提取重要决策和行动项。
• 新闻聚合: 将多篇相关新闻报道整合成一个简短的概要。
• 学术论文速读: 帮助研究人员快速筛选和理解大量文献的核心内容。

与其他节点的关系

摘要链节点在工作流中通常扮演“信息处理器”的角色：

1. 上游节点/数据源: 它可以直接接收来自上游节点的文本数据 (JSON 或 Binary 格式)，例如 HTTP Request 节点抓取的网页 HTML，或者 Read Binary File 节点读取的 PDF 文本内容。或者，它可以连接 Document Loader (文档加载器) 子节点来加载特定来源的数据，比如从 Google Drive 读取文件 ，或者从 GitHub 仓库加载文档 。
2. 自身: 配置数据来源、文本分块策略 (Chunking Strategy)、摘要方法 (Summarization Method) 以及可选的自定义 Prompt。
3. 下游子节点 (必需): 与基础 LLM 链一样，摘要链也必须连接一个 Language Model (语言模型) 子节点来执行实际的摘要生成任务 。
4. 下游子节点 (可选 – 用于分块): 如果选择了 Advanced 的分块策略，则需要连接一个 Text Splitter (文本分割器) 子节点 。
5. 后续节点: 摘要链生成的摘要文本 (text 字段) 会传递给后续节点，用于发送通知、保存记录、生成报告等。

摘要链通过内置的逻辑和对子节点的协调，简化了原本复杂的长文本摘要流程。

参数配置

让我们深入了解摘要链节点的各项配置。

要摘要的数据

这个参数决定了你要摘要的文本内容从哪里来 。

1. Use Node Input (JSON):
   • 功能: 处理从上游节点传入的 JSON 数据。你需要指定哪个字段包含了要摘要的文本。
   • 翔宇实战理解: 适用于上游节点已经将文本提取好并以 JSON 格式输出的情况。例如，你用 HTTP Request 获取了 API 返回的 JSON，其中某个字段是长篇描述。
2. Use Node Input (Binary):
   • 功能: 处理从上游节点传入的二进制数据。通常用于处理文件内容，如 PDF、Word 文档等。n8n 会尝试自动提取二进制数据中的文本。
   • 翔宇实战理解: 当你需要摘要上传的文件或从 Google Drive 、本地读取的文件内容时，这个选项很方便。但要注意，n8n 对复杂格式 (如图文混排的 PDF) 的文本提取能力有限，对于扫描版 PDF 可能完全无法提取。处理复杂文档可能需要先用专门的 OCR 或文档解析工具处理。
3. Use Document Loader:
   • 功能: 不直接处理上游节点的输入，而是连接一个 Document Loader 子节点。由该子节点负责加载数据。
   • 翔宇实战理解: 这是处理多个文件或特定数据源 (如 GitHub ) 的标准方式。例如，你可以连接 Google Drive Loader 来加载指定文件夹下的所有文档，然后让摘要链对它们进行批量摘要。

翔宇提示: 根据你的数据来源选择最合适的方式。处理单个、简单的文本流，用 Node Input；处理文件、多个文档或特定服务的数据，用 Document Loader。

分块策略

当 Data to Summarize 选择 Use Node Input (JSON) 或 Use Node Input (Binary) 时，这个选项才会出现。因为单个 LLM 的处理能力 (上下文窗口) 有限，对于超过几千个 Token 的长文本，必须先将其分割成小块 (Chunks)，然后才能进行摘要 。

1. Simple (Define Below):
   • 功能: 提供最基础的文本分块方式。你需要手动设置：
     • Characters Per Chunk (每块字符数): 定义每个文本块的最大长度（按字符计算）。
     • Chunk Overlap (Characters) (块重叠字符数): 定义相邻两个文本块之间内容重叠的字符数。
   • 翔宇实战理解: 这是最简单的分块方法，适用于结构简单的纯文本。设置块大小需要权衡：太小可能导致上下文丢失过多，太大可能超过 LLM 的处理限制。重叠 (Overlap) 很重要，它能让模型在处理当前块时，看到上一块结尾和下一块开头的部分内容，有助于保持摘要的连贯性。通常可以设置块大小的 10%-20% 作为重叠。例如，块大小 1000 字符，重叠 100-200 字符。
2. Advanced:
   • 功能: 不使用简单的字符分割，而是允许你连接一个专门的 Text Splitter (文本分割器) 子节点来实现更智能、更复杂的分块逻辑 。
   • 可连接的 Text Splitters:
     • Character Text Splitter: 按指定的单个字符（如换行符 \n）分割文本。
     • Recursive Character Text Splitter:​推荐使用！ 这是更智能的分块器。它会尝试按一组预定义的、有优先级的分割符（如 \n\n, \n, 等）进行递归分割，尽可能保持句子或段落的完整性，效果通常比简单按字符数分割要好。
     • Token Splitter: 按 Token 数量进行分割（需要配合特定的 Tokenizer 使用，配置相对复杂）。
   • 翔宇实战理解: 对于包含 Markdown、代码、或者段落结构比较重要的文本，强烈推荐使用 Advanced 模式并连接 ​Recursive Character Text Splitter​。它能更好地尊重原文的语义结构，分割出的块更有意义，有助于提高摘要质量。你仍然可以在 Text Splitter 子节点中配置块大小 (Chunk Size) 和重叠 (Chunk Overlap)。

节点选项

通过点击 Add Option -> Summarization Method and Prompts，你可以配置摘要的核心逻辑 。

1. Summarization Method (摘要方法):
   • Map Reduce:
     • 原理: 这是处理大量文档或超长文本的推荐方法。它分两步：
       1. Map (映射): 对分割后的每一个文本块 (Chunk) 独立地调用 LLM 生成一个初步摘要。
       2. Reduce (规约): 将所有这些初步摘要合并起来，再次调用 LLM 生成最终的、全局的摘要。
     • 优点: 可以并行处理各个块（理论上），能够处理任意长度的输入，扩展性好。
     • 缺点: LLM 调用次数较多 (每个块一次 + 合并一次或多次)，成本较高，且最终合并步骤可能丢失一些细节。
     • 翔宇实战理解: 这是最常用也最稳妥的方法，特别是当你不知道输入文本有多长，或者需要处理多个文档时。
   • Refine:
     • 原理: 这是一个迭代优化的过程 。
       1. 对第一个文本块生成一个初始摘要。
       2. 将这个初始摘要和第二个文本块的内容一起发送给 LLM，要求它根据新内容精炼 (Refine) 之前的摘要。
       3. 将精炼后的摘要和第三个文本块的内容再发送给 LLM，继续精炼… 以此类推，直到处理完所有块。
     • 优点: 能够逐步吸收所有块的信息，理论上可以保留更多上下文，摘要可能更连贯。
     • 缺点: 这是一个串行过程，无法并行，处理速度较慢。LLM 调用次数也较多 (每个块一次)。且后面的块对最终摘要的影响可能更大。
     • 翔宇实战理解: 适用于那些需要逐步深入、不断补充细节的摘要场景。但由于其串行特性，对于非常多的块，时间成本会很高。
   • Stuff:
     • 原理: 这是最简单粗暴的方法 。它将所有的文本块（或者如果只有一个块，就是全部原文）直接“塞” (Stuff) 进一个 Prompt 里，一次性发送给 LLM，让它直接生成摘要。
     • 优点: LLM 调用次数最少（只有一次），速度最快，成本最低。能够看到完整的上下文。
     • 缺点:​​严重受限于 LLM 的上下文窗口大小​。如果所有文本块的总长度超过了模型的 Token 限制，这个方法就会失败。
     • 翔宇实战理解: 只有当你确定要摘要的总文本量很小，远小于你所使用 LLM 的上下文窗口时，才可以使用 Stuff 方法。例如，摘要一封短邮件或一条 Slack 消息。对于长文章或多文档，基本不可行。
2. Individual Summary Prompts (独立摘要提示):
   • 功能: (主要用于 Map Reduce 和 Refine 方法) 自定义用于生成每个独立块摘要的 Prompt 模板。
   • 要求: 你的 Prompt 模板中必须包含占位符 "{text}"，n8n 会将每个文本块的内容替换到这里 。
   • 翔宇提示: 你可以在这里加入特定的摘要要求。例如，默认的 Prompt 可能是 “Write a concise summary of the following text: {text}”。你可以修改为：“请提取以下文本的核心论点和关键数据：{text}”。
   • 注意: 社区曾报告过一个 Bug，导致这个选项的描述和提示信息与下面的 Final Prompt to Combine 弄反了 。使用时请留意界面上的实际行为，或者更新到已修复的版本。
3. Final Prompt to Combine (最终合并提示):
   • 功能: (主要用于 Map Reduce 方法) 自定义用于将所有独立块的摘要合并成最终摘要的 Prompt 模板。
   • 要求: 同样必须包含占位符 "{text}"，n8n 会将所有独立摘要拼接后替换到这里 。
   • 翔宇提示: 你可以在这里控制最终摘要的风格、长度或侧重点。例如：“请将以下各部分的摘要整合为一段流畅、连贯、不超过 300 字的总结：{text}”。

理解并灵活运用这些参数，是让摘要链节点发挥最大效能的关键。你需要根据你的数据特性、文本长度、对摘要质量和速度的要求，以及成本预算，来选择合适的分块策略、摘要方法，并精心设计 Prompt。

数据映射与表达式

摘要链节点的数据流转相对直接。

输入数据

• 当 Data to Summarize 设为 Use Node Input (JSON) 时: 节点期望上游传入的数据中包含一个包含文本的字段。你需要确保这个字段存在且有内容。可以使用表达式 { $json.textField } 来引用。
• 当 Data to Summarize 设为 Use Node Input (Binary) 时: 节点期望上游传入的是二进制数据。通常是文件读取节点（如 Read Binary File, Google Drive Download 等）的 data 字段。
• 当 Data to Summarize 设为 Use Document Loader 时: 节点不直接使用上游输入，而是依赖连接的 Document Loader 子节点提供数据。数据结构由 Loader 决定。

输出数据

• 主要输出: 摘要链节点执行成功后，其主要输出是生成的​摘要文本​。
• 数据结构: 通常情况下，输出是一个 JSON 对象，其中包含一个名为 text 的字段，存储着最终的摘要内容。你可以通过 {{ $json.text }} 来访问它。
  • 注意: 社区帖子 中用户遇到的输出是 { "response": { "text": "..." } } 结构。虽然该帖子讨论的是如何包含输入数据，但这个结构本身值得留意。结合基础 LLM 链的类似问题 及其修复，最新版本的摘要链输出结构很可能也已简化为{ "json": { "text": "..." } }。翔宇建议在实际使用时，​务必执行一次节点，并检查实际的输出结构​，以确定访问摘要文本的正确表达式 ({{ $json.text }} 还是 {{ $json.response.text }})。
• Token 使用量: 摘要链节点（及其子节点如 LLM）会消耗 Token。但如社区讨论 指出的，目前在 n8n 中，​无法在同一次工作流执行中直接获取到摘要链节点内部（包括其子节点）精确的 Token 使用量​。这是一个当前的限制。

如何关联输入与输出？

一个常见的需求是：当摘要链处理多个输入项（例如，摘要多篇文章）后，如何将生成的摘要与原始的输入项对应起来？摘要链的输出默认只包含摘要文本，不包含原始输入的任何标识信息。

社区用户提出的解决方案是使用 Merge 节点：

1. 将原始输入数据流也连接到一个 Merge 节点。
2. 将摘要链节点的输出连接到同一个 Merge 节点。
3. 将 Merge 节点的 Mode 设置为 ​**Combine by position (按位置合并)**​。

这种方法依赖于一个假设：n8n 节点处理输入项的顺序是稳定且保持不变的。也就是说，摘要链输出的第一个摘要对应于它接收到的第一个输入项，第二个摘要对应第二个输入项，以此类推。Merge 节点按位置合并，就能将原始输入项和对应的摘要组合到一起。

• 关于顺序稳定性的思考: 正如社区讨论 中提到的，n8n 的核心处理逻辑通常是确定性的，会保持项目顺序。然而，完全依赖位置合并​并非绝对稳健​。如果在摘要链上游的工作流发生变化（例如，增加了过滤步骤，改变了项目顺序），或者未来 n8n 的并行处理机制发生改变，这种依赖位置的合并方式就可能出错。这是一个在设计需要关联 AI 输出和输入的工作流时需要注意的潜在脆弱点。更可靠的方式可能是在输入数据中包含一个唯一的 ID，并想办法（可能需要自定义 Prompt 或使用 Agent+Tool 架构）让 AI 在输出中也带上这个 ID，然后使用 Merge 节点的 Combine by key 模式进行合并。但对于摘要链节点本身，目前 Merge by Position 是最常用的简便方法。

Chat Model 连接与配置

摘要链的核心计算依赖于连接的 Language Model 子节点。

• 连接: 与基础 LLM 链相同，点击节点下方的 + Language Model 连接点，选择所需的模型子节点 。
• 模型选择:
  • 上下文窗口: 选择的模型需要有足够大的上下文窗口来处理文本块 (Chunk) 以及 (对于 Map Reduce 的 Reduce 步骤) 合并后的摘要。
  • 摘要能力: 有些模型可能比其他模型更擅长进行文本摘要。可以查阅模型的技术报告或进行实验比较。
  • 成本与速度: 同样需要考虑。摘要长文本可能涉及多次 LLM 调用，成本和时间会累积。
• 配置: 模型的核心参数 (Temperature, Max Tokens 等) 都在 Language Model 子节点中进行配置。对于摘要任务，通常建议使用较低的 Temperature (例如 0.1-0.5) 以获得更忠实于原文、更少创造性的摘要。Max Tokens 需要设置得足够大，以容纳预期的摘要长度。

Memory 注意事项

• 同样限制: 与基础 LLM 链一样，摘要链节点本身不直接支持 Memory 功能。它不会记住之前执行摘要任务时的任何信息。
• 场景相关性: 对于典型的摘要任务，通常不需要 Memory。摘要是对给定文本的一次性处理。如果你的场景比较特殊，需要基于历史摘要结果进行下一步操作，那么你可能需要将摘要结果存储在外部（如数据库或变量中），或者考虑使用 AI Agent 架构。

常用应用场景

摘要链节点非常实用，翔宇在很多自动化场景中都用到了它：

1. 网页监控与摘要:
   • 场景: 监控特定博客或新闻网站，当有新文章发布时，自动抓取内容并生成摘要，发送到 Slack 或邮件。
   • 流程: RSS Trigger / Schedule Trigger -> HTTP Request (抓取网页) -> HTML Extract (提取正文) -> Summarization Chain (摘要) -> Send Email / Slack Message。
   • 参考: 都有提及网页抓取与摘要的模板。
2. 文档库快速浏览:
   • 场景: 公司内部有大量 PDF 格式的研究报告或项目文档，需要快速了解每份文档的大意。
   • 流程: Google Drive Trigger / Local File Trigger -> Read Binary File / Google Drive Download -> Summarization Chain (摘要) -> Save to Database / Send Digest Email。
   • 参考: 涉及处理文档和 Google Drive 文件。
3. 会议/聊天记录精炼:
   • 场景: 将 Zoom 会议的文字记录或冗长的 Slack 讨论串自动生成摘要和关键行动项。
   • 流程: Get Meeting Transcript / Read Chat History -> Summarization Chain (Prompt 可要求提取行动项) -> Output Summary & Action Items。
   • 参考: 提到了处理 Gmail 邮件并摘要的例子，类似思路可用于聊天记录。 提到了摘要 Slack 线程。
4. 多源信息聚合报告:
   • 场景: 从多个新闻源或 API 获取关于同一主题的信息，整合成一份综合摘要报告。
   • 流程: Multiple HTTP Requests / API Calls -> Merge Data -> Summarization Chain (处理合并后的文本) -> Format Report -> Send Report。
5. 研究论文助手:
   • 场景: 下载一批相关的 PDF 论文，自动提取摘要或关键发现。
   • 流程: Download PDFs -> Loop Over PDFs -> Read Binary File -> Summarization Chain (Prompt 可侧重提取方法、结果) -> Aggregate Results -> Save to Notion/Airtable。
   • 参考: 提到了将文档分解为学习笔记或简报的模板。
6. 生成学习笔记/简报:
   • 场景: 将一本电子书或长篇教程的关键章节内容，转化为易于复习的笔记或演示文稿要点。
   • 流程: Input Text/Document -> Summarization Chain (Prompt 指示生成笔记/要点格式) -> Output Formatted Notes。
   • 参考:。

翔宇实例分享: 翔宇搭建过一个自动化的竞品信息跟踪系统。工作流每天定时触发，使用 HTTP Request 抓取几个主要竞品官网的博客或新闻页面，提取新发布的内容，然后通过 Summarization Chain 生成每篇文章的摘要，最后将所有摘要汇总，发送一封“竞品动态日报”邮件给自己。这大大节省了每天手动浏览这些网站的时间。

摘要链节点是处理信息过载的利器，能将繁杂的文本信息转化为易于消化和利用的知识精华。

常见报错及解决方案

在使用摘要链时，可能会遇到一些特有的问题，尤其是处理长文本或大文件时。

• 错误信息: (节点执行失败，错误信息提示内存不足、超时，或无明确错误但长时间卡住)
  • 可能原因:
    • 输入文件过大: 读取或处理大型文件（特别是二进制文件如 PDF）本身就可能消耗大量内存，超出 n8n 实例（尤其是 Docker 容器默认配置或 n8n Cloud 基础套餐）的限制 。
    • 分块/摘要过程耗时过长: 对于非常长的文本，即使分块了，Map Reduce 或 Refine 方法也需要多次调用 LLM，总耗时可能超过 n8n 或连接的 LLM 服务的隐式或显式超时限制 。
    • 资源竞争: 如果 n8n 实例同时在执行其他耗资源的任务，也可能导致摘要链任务失败。
  • 解决方案:
    • 优化输入: 如果可能，预处理输入文件，只提取必要的文本部分。
    • 调整分块策略: 尝试减小 Characters Per Chunk 的值。但注意，块太小也可能影响摘要质量。
    • 检查/增加资源: 监控 n8n 实例的内存和 CPU 使用情况。如果是自托管，考虑增加分配给 Docker 容器的内存或升级服务器配置。如果是 n8n Cloud，可能需要升级套餐。
    • 检查超时设置: 查看你使用的 Language Model 子节点是否有 Timeout 参数可以设置，尝试增加该值 (如果模型服务允许)。
    • 选择合适的摘要方法: 如果文本不是特别长，可以尝试 Stuff 方法，它最快。但通常 Map Reduce 是处理长文本最可靠的选择。
    • 分批处理输入: 如果你要摘要的是多个文件，可以考虑使用 Split In Batches 节点将文件列表分成小批次，然后用循环逐批处理，并在每批之间加入 Wait 节点，减轻瞬时压力。
• 错误信息:fetch failed (当连接本地 Ollama 时)
  • 可能原因: n8n 运行环境（如 Docker 容器）无法访问到你本地运行的 Ollama 服务。网络配置问题。
  • 解决方案:
    • 检查网络设置: 如果 n8n 在 Docker 中运行，需要确保容器网络可以访问宿主机的 Ollama 端口 (通常是 11434)。可能需要使用 host.docker.internal (Windows/Mac) 或 172.17.0.1 (Linux 默认桥接网络) 作为 Ollama 的 URL，或者配置 Docker 使用 host 网络模式 (需谨慎)。
    • 使用推荐配置: 社区用户提到，使用 n8n 官方提供的 AI Starter Kit 中的 Ollama 容器配置可以解决此问题 。这通常意味着 n8n 和 Ollama 在同一个 Docker Compose 网络中，可以直接通过服务名访问。
    • 确认 Ollama 服务运行正常: 确保你的 Ollama 服务本身在运行且模型已下载。
• 错误信息:Cannot read properties of undefined (reading 'text') (当使用 Mistral AI Model 时)
  • 可能原因: 这是 n8n 早期版本 (约 1.31.x 之前) 中存在的一个关于 Mistral 模型集成的 Bug。
  • 解决方案: 将 n8n 更新到 v1.32.0 或更高版本，该 Bug 已被修复 。
• 问题: 无法获取 Token 使用量
  • 原因: 如前所述，n8n 目前的设计不直接暴露子节点（如 Language Model）的执行细节（包括 tokenUsage）给主流程。
  • 解决方案 (复杂): 目前没有内置的简单方法。理论上，可以在工作流执行​结束后​，使用 n8n API Node 或 HTTP Request Node 调用 n8n 的 /executions/{id} API 来获取该次执行的完整数据，其中会包含子节点的详细信息。但这无法在同一次执行中实时获取。社区有讨论使用 LangChain Code Node 包装模型调用来尝试捕获信息，但实现复杂且可能不适用于所有场景 。
• 问题:Individual Summary Prompts 和 Final Prompt to Combine 的描述或提示信息颠倒
  • 可能原因: n8n 界面显示 Bug。
  • 解决方案: 理解这两个 Prompt 的实际作用（一个是处理单个块，一个是合并所有块的摘要），根据实际作用来填写内容，或者更新到已修复此界面 Bug 的 n8n 版本。
• LLM 模型相关错误: (同基础 LLM 链部分) 如 API Key 无效、额度不足、模型不支持等。
  • 解决方案: 检查 Language Model 子节点的配置、凭证和对应 AI 服务商的账户状态。

处理摘要链的错误，特别是与长文本和性能相关的，往往需要结合对 n8n 运行环境、LLM 服务限制以及节点配置的综合理解。

注意事项

使用摘要链节点时，除了常规的 AI 使用注意事项外，还有一些针对摘要任务的特别提醒：

1. 成本与 Token 消耗 (尤其注意): 摘要长文档，特别是使用 Map Reduce 或 Refine 方法时，会进行多次 LLM API 调用。这意味着 Token 消耗量可能远超你的直观想象。例如，一个长文档被分成 10 个块，使用 Map Reduce 可能需要调用 LLM 11 次或更多（10 次 Map + 至少 1 次 Reduce）。务必谨慎评估成本。
2. 摘要质量的权衡:
   • 模型能力: 不同 LLM 的摘要能力差异很大。
   • Prompt 设计: 自定义 Prompt 对摘要的侧重点和风格有很大影响。
   • 分块策略: 分块太细可能丢失全局上下文，分块太粗可能超出模型限制。Recursive Character Text Splitter 通常是较好的选择。
   • 摘要方法: Map Reduce 扩展性好但可能丢失细节；Refine 可能更连贯但速度慢且受顺序影响；Stuff 最简单但限制最大。需要根据需求选择和调整。
3. 上下文丢失风险: 任何基于分块的摘要方法（Map Reduce, Refine）都存在丢失跨块上下文信息的风险。虽然块重叠 (Chunk Overlap) 有助于缓解，但无法完全避免。对于高度依赖全局上下文的任务，摘要结果可能不够理想。
4. 事实准确性: LLM 在摘要时也可能产生幻觉，或者错误地理解原文，导致摘要内容不准确或歪曲原意。对于关键信息的摘要结果，最好进行人工核对。
5. 处理时间: 摘要大量或非常长的文档可能需要很长时间才能完成，特别是使用 Refine 方法或 LLM 响应较慢时。需要考虑工作流的执行时间限制。
6. 输入数据预处理: 对于非纯文本的输入 (如 PDF, Word)，摘要链依赖 n8n 的内置文本提取能力。对于格式复杂或扫描版的文档，最好先使用专门的工具进行文本提取和清洗，再将干净的文本输入摘要链，以获得更好的效果。

摘要链是一个强大的工具，但也需要细致的配置和对潜在问题的理解。通过不断实践和调整，你可以让它成为你处理海量信息的得力助手。

问答链 (Question and Answer Chain)

概览

节点定义与核心功能

问答链 (Question and Answer Chain)，在 n8n 的一些文档和界面中也可能被称为 ​Retrieval Q&A Chain (检索问答链)​，是 n8n 中用于实现基于特定知识库进行问答的核心节点 。

它的核心功能是：接收一个用户提出的问题 (Query)，然后通过连接的 Retriever (检索器) 从指定的知识源（通常是 Vector Store，向量数据库）中查找最相关的信息片段 (Context)，最后将问题和检索到的信息一起交给 ​**Language Model (语言模型)**​，由 LLM 生成一个基于这些信息的自然语言答案。

核心用途 (RAG – 检索增强生成)

问答链节点是实现 RAG (Retrieval-Augmented Generation) 架构的基础 。RAG 的理念就是，不让 LLM 仅仅依赖其内部训练数据来回答问题（因为内部数据可能过时、不包含特定领域知识，或者容易产生幻觉），而是让它能够​**先“查找资料”（检索），再“组织答案”（生成）**​。

这使得我们可以构建出能够回答关于​我们自己的数据​（例如公司内部文档、产品手册、特定领域的知识库）的问题的 AI 应用，大大扩展了 LLM 的实用性。

与其他节点的关系

问答链节点在工作流中扮演着 RAG 流程的“指挥官”角色：

1. 上游节点: 通常连接一个接收用户输入的节点，如 Chat Trigger 或 Webhook。该节点提供用户的问题 (Query)。
2. 自身: 配置如何获取用户问题 (Query)。
3. 下游子节点 (必需 – Retriever):​必须连接一个 Retriever (检索器) 子节点 。Retriever 负责根据 Query 去知识库中查找相关信息。最常用的 Retriever 是 ​Vector Store Retriever​，它又需要连接到一个 Vector Store (向量数据库) 子节点 (如 Pinecone, Qdrant, Supabase, Simple Vector Store 等) 。Vector Store 子节点还需要连接 Embeddings (嵌入) 子节点来将文本转化为向量。
4. 下游子节点 (必需 – Language Model):​必须连接一个 Language Model (语言模型) 子节点，通常是 Chat Model 。LLM 负责理解 Query 和 Retriever 返回的 Context，并生成最终答案。
5. 后续节点: 问答链生成的答案 (text 字段) 会传递给后续节点，例如通过 Chat Response 节点返回给用户，或记录到日志中。

可以看出，问答链节点的有效运作高度依赖于其连接的子节点（Retriever 和 Language Model）以及底层知识库（Vector Store）的正确配置和数据质量。

参数配置

相比于摘要链，问答链节点本身的配置参数相对较少，其核心行为更多地由连接的子节点和 LangChain 的底层机制决定。

Query (查询)

• 功能: 定义用户向 RAG 系统提出的问题 。
• 配置方式:
  • Take from previous node automatically: 最常用。选择此项，节点会自动从上游节点（通常是 Chat Trigger）获取名为 chatInput 的字段作为用户问题 。
  • Define below: 允许你在下方的 Query (User Message) 文本框中直接输入问题，或者使用表达式动态构建问题。适用于测试或非聊天交互的场景。
• 翔宇实战理解: 这是 RAG 流程的起点。用户问题的清晰度和具体性会影响检索和生成的效果。

Retriever 连接 (必需)

• 要求: 问答链节点必须连接一个 Retriever 子节点才能工作 。没有检索器，它就无法从知识库获取信息，也就失去了 RAG 的意义。
• 如何连接: 点击节点下方的 + Retriever 连接点，选择合适的 Retriever 子节点。
• 常用 Retriever:
  • Vector Store Retriever: 这是实现典型 RAG 的核心检索器 。它负责接收 Query，将其通过连接的 Embeddings 子节点转换为向量，然后在连接的 Vector Store 子节点中执行向量相似度搜索，找出最相关的文档块 (Chunks) 作为 Context 返回。
  • Workflow Retriever: n8n 特有的检索器，允许从其他 n8n 工作流的执行结果中检索信息 。相对少见，适用于特定场景。
  • 其他 Retriever: LangChain 还定义了其他类型的 Retriever (如 Contextual Compression Retriever, MultiQuery Retriever )，n8n 可能逐步支持。
• 翔宇实战理解: 配置的核心在于 Vector Store Retriever 及其连接的 Vector Store 和 Embeddings 子节点。你需要：
  1. 选择并配置好你的 Vector Store (如 Pinecone, Qdrant, Supabase, 或内存中的 Simple Vector Store)。
  2. 选择并配置好生成向量的 Embeddings 模型 (如 OpenAI Embeddings, Ollama Embeddings 等)。关键：写入数据到 Vector Store 时使用的 Embedding 模型，必须和查询时 Vector Store Retriever 连接的 Embedding 模型完全一致！ 否则向量空间不匹配，无法正确检索。
  3. 在 Vector Store Retriever 中，通常可以配置检索返回的文档数量 (top_k)，这个参数需要权衡，返回太少可能信息不足，返回太多可能超出 LLM 上下文窗口或引入噪音。

Language Model 连接 (必需)

• 要求: 问答链节点也必须连接一个 Language Model 子节点 。
• 如何连接: 点击节点下方的 + Language Model 连接点，选择 Chat Model 子节点。
• 翔宇实战理解: LLM 在这里的任务是：接收用户的问题 (Query) 和从 Retriever 获取的相关信息 (Context)，然后基于 Context 来回答 Query。它需要理解两部分内容并将它们融合，生成一个自然、准确、有依据的答案。

Node Options (节点选项 – 可能存在)

n8n 的官方文档 对于问答链节点本身的具体“选项”着墨不多。不同于基础 LLM 链或摘要链可以配置自定义 Prompt 模板，问答链内部处理 Query 和 Context 的 Prompt 可能更多地由 LangChain 的默认实现或底层框架控制。

然而，通常 RAG 流程会有一个类似这样的内部 Prompt 结构（这只是一个示例，具体实现可能不同）：

根据以下信息回答问题。如果你不知道答案，就说不知道，不要编造。

信息：
{retrieved_context}

问题：
{user_query}

答案：

虽然 n8n 界面可能不直接暴露修改这个内部 Prompt 的选项，但你可以通过配置连接的 Language Model 子节点 的 System Message (如果该模型节点支持) 来间接影响 LLM 的行为。例如，在 System Message 中强调“请严格依据提供的信息回答，不要加入外部知识”。

• 关于问答链节点配置的思考: 这个节点本身参数相对简单 ，其复杂性主要体现在外部连接和底层数据上 [Insight 4]。用户配置的重心应该放在：
  1. 知识库构建: 如何将原始数据（文档、网页等）有效地处理、分块、生成 Embeddings 并存入 Vector Store。数据质量和分块策略至关重要。
  2. Retriever 配置: 选择合适的 Vector Store 和 Embedding 模型，调整检索参数 (如 top_k)。
  3. LLM 选择与配置: 选择能很好地理解上下文并遵循指令的 LLM，调整 Temperature 等参数以获得基于事实的回答 (通常用较低的 Temperature )。

问答链节点更像是一个 RAG 流程的“组装框架”，真正的“大脑”（LLM）和“记忆库”（Vector Store）是由连接的子节点提供的。

数据映射与表达式

问答链节点的数据流相对固定。

输入数据

• 主要输入: 用户的问题 (Query)。
  • 如果 Query 参数设为 Take from previous node automatically，则来自上游节点的 chatInput 字段。
  • 如果设为 Define below，则来自配置框中的静态文本或表达式结果。
• 内部数据流: Query 会被传递给 Retriever 子节点。Retriever 返回的 Context 和原始 Query 会被传递给 Language Model 子节点。

输出数据

• 主要输出: LLM 基于 Query 和 Context 生成的最终答案。
• 数据结构: 输出通常是一个 JSON 对象，包含一个名为 text 的字段，存储着答案文本 。你可以通过 {{ $json.text }} 来访问。 JSON ​
• 中间步骤数据: 默认情况下，Retriever 检索到的具体文档块 (Context) 不会直接出现在问答链节点的最终输出中。如果你需要查看检索到了哪些内容（例如用于调试或在答案中引用来源），可能需要更复杂的设置，比如使用 AI Agent 节点的 Return Intermediate Steps 选项 ，或者自定义 LangChain Code 实现。

Chat Model 连接与配置

连接和配置 Language Model 子节点对于问答链至关重要。

• 连接: 点击 + Language Model 并选择合适的 Chat Model 子节点 。
• 模型选择:
  • 上下文理解能力: 模型需要能够很好地理解 Retriever 返回的 Context，并将其与 Query 关联起来。
  • 遵循指令能力: 模型需要能够遵循“基于提供信息回答”的指令，避免自行发挥或引入外部知识（除非你特意允许）。
  • 上下文窗口: 模型的 Context Window 必须足够大，以容纳 Query + Retriever 返回的所有 Context 文本 + 生成答案所需的空间。如果 Context 太长，可能会导致错误或信息被截断。
• 配置:
  • Temperature: 对于基于事实的问答，通常建议设置较低的 Temperature (例如 0 到 0.3 之间)，以减少模型“创造”答案的可能性，使其更忠实于检索到的信息 。
  • Max Tokens: 需要设置得足够大，以容纳可能生成的答案长度。
  • System Message (如果可用): 可以用来进一步强调回答问题的规则，例如：“请仅根据提供的上下文回答问题。如果上下文中没有答案，请明确说明。”

Memory 注意事项

• 同样限制: 问答链节点本身不具备 Memory 功能。它无法记住之前的问答历史。每次提问都是一次独立的 RAG 过程。
• RAG 与 Memory 的结合: 如果你需要构建一个​能够进行多轮对话的 RAG 聊天机器人​（例如，用户可以问后续问题，或者 AI 需要记住之前的对话来理解当前问题），简单的问答链节点是不够的。你需要采用更高级的架构，通常是 AI Agent + Memory 子节点 + Vector Store Tool。
  • AI Agent: 作为对话的控制中心。
  • Memory 子节点 (如 Simple Memory, Redis Chat Memory): 存储对话历史。
  • Vector Store Tool: 让 Agent 能够在需要时查询知识库 (Vector Store)。
• 问答链 vs. Agent+Tool for RAG:
  • 问答链: 适用于单轮、无状态的 RAG 查询。配置相对简单，专注于一次性的“问-查-答”流程。
  • AI Agent + Memory + Vector Store Tool: 适用于需要多轮对话、有状态的 RAG 应用。架构更灵活，Agent 可以根据对话历史和当前问题，决定是直接回答、调用 Vector Store Tool 查询知识库，还是调用其他工具。这是构建复杂 RAG 应用的推荐方式 [Insight 5]。社区的讨论也显示出，将 Vector Store 作为 Agent 的一个 Tool 是一个更现代、更受推荐的做法，因为它提供了更大的灵活性和更好的控制 。

翔宇提示: 如果你只需要做一个简单的“根据我的文档回答问题”的功能，并且不需要连续对话，问答链节点是一个不错的起点。但如果你想做一个能和用户持续聊天的、基于知识库的 AI 助手，那么你需要学习和掌握 AI Agent、Memory 和 Tools 的组合用法。

常用应用场景

问答链 (或其更高级的 Agent+Tool 形式) 是目前 AI 应用中最有价值的场景之一，因为它让 AI 能够利用我们自己的数据。

1. 企业内部知识库问答:
   • 场景: 将公司的规章制度、产品文档、技术手册、历史项目资料等上传到 Vector Store，让员工可以通过提问快速找到所需信息，减少重复询问和查找时间。
   • 流程: 文档预处理 (分块) -> 生成 Embeddings -> 存入 Vector Store (如 Qdrant, Pinecone) -> 配置问答链/Agent -> 提供聊天界面供员工查询。
   • 参考: 描述了类似 RAG 聊天机器人的构建。
2. 产品/技术支持文档查询:
   • 场景: 将产品的用户手册、API 文档、常见问题解答 (FAQ) 等构建成知识库，让用户或内部支持团队能通过自然语言提问来获取帮助。
   • 流程: 类似内部知识库，但知识源是面向外部或支持团队的文档。
   • 参考: 演示了基于 MacBook 维修 PDF 的问答。
3. 特定领域知识助手:
   • 场景: 收集整理某一专业领域（如医学指南、法律条文、金融报告）的文献资料，构建专业知识问答系统。
   • 流程: 领域文献收集与处理 -> Vector Store 构建 -> 配置问答链/Agent -> 提供查询接口。
   • 参考: 提到了用于股票分析的 AI Crew 模板。
4. 个人知识管理 (PKM) 助手:
   • 场景: 将自己的笔记 (如 Notion, Obsidian)、网页剪藏、PDF 文档等个人知识库导入 Vector Store，打造一个能回答关于“我”的知识的 AI 助手。
   • 流程: 个人笔记导出/同步 -> 数据处理与向量化 -> Vector Store -> 配置问答链/Agent -> 通过聊天界面与自己的知识库对话。
5. PDF/长文档智能阅读器:
   • 场景: 上传一份或多份 PDF 文档，然后可以针对文档内容进行提问，快速定位信息或理解复杂概念。
   • 流程: PDF 上传 -> 文本提取与分块 -> Vector Store -> 配置问答链/Agent -> 提问交互。
   • 参考: 提供了 PDF 问答的模板。 讨论了处理 PDF 的相关问题。
6. 客户服务自动化:
   • 场景: 在客服流程中，当用户提出常见问题时，先由 RAG 系统尝试从知识库中查找并提供标准答案，如果无法解决再转接人工客服。
   • 流程: 接收用户问题 -> 问答链/Agent 查询知识库 -> 如果找到答案则回复，否则转人工。

翔宇实例分享: 翔宇正在尝试将“翔宇工作流”发布过的所有 n8n 教程、技巧文章和社区问答精华整理并导入到一个 Qdrant Vector Store 中，然后使用 AI Agent + Vector Store Tool 构建一个“n8n 疑难解答助手”。目标是让关注“翔宇工作流”的朋友们可以直接向这个助手提问关于 n8n 使用中遇到的问题，助手能够根据翔宇分享过的内容给出有依据的解答。这需要精心处理数据、选择合适的 Embedding 模型，并不断优化 Agent 的 Prompt 和 Tool Description。

问答链和 RAG 技术极大地扩展了 AI 的应用范围，使其能够真正服务于我们特定的知识和数据需求。

常见报错及解决方案

构建和使用问答链 (RAG) 系统时，遇到的问题往往比基础 LLM 链或摘要链更复杂，因为涉及到更多的组件（Retriever, Vector Store, Embeddings）。

• 错误信息:No prompt specified error
  • 原因/解决: 同基础 LLM 链部分。确保 Query 输入有效。
• 错误信息:A Retriever sub-node must be connected error
  • 原因/解决: 问答链必须连接 Retriever 子节点。点击 + Retriever 添加并配置。
• 错误信息: (无法生成长回复)
  • 原因/解决: 增加 LLM 的 Max Tokens；更换模型；或考虑问题是否过于宽泛，需要拆解。
• 错误信息: (与 Vector Store 或 Retriever 相关的错误)
  • Connection Error / Authentication Failed:
    • 原因: Vector Store 子节点 (Pinecone, Qdrant, Supabase 等) 的连接信息 (URL, API Key, 凭证) 配置错误。
    • 解决: 仔细检查 Vector Store 子节点的凭证和连接参数是否正确。
  • Index/Collection not found:
    • 原因: 在 Vector Store 子节点中指定的索引 (Index) 或集合 (Collection) 名称不存在。
    • 解决: 确认 Vector Store 中已创建了该名称的索引/集合，或者修改节点配置中的名称。
  • Namespace error (特定于某些 Vector Store 如 Pinecone):
    • 原因: 使用了命名空间 (Namespace) 进行数据隔离，但查询时指定的 Namespace 不正确或数据写入时未使用正确的 Namespace。
    • 解决: 检查 Pinecone Vector Store 节点配置中的 Pinecone Namespace 参数是否与数据写入时一致 。
  • 数据格式错误导致无法检索或返回空内容:
    • 原因: 写入 Vector Store 的数据格式与 n8n (LangChain.js) 期望的格式不符。常见于使用 Python 脚本或其他工具写入数据的情况 。LangChain.js 通常期望的格式是 { "content": "...", "metadata": {} }，而 LangChain Python 可能是 { "page_content": "...", "metadata": {} }。
    • 解决: 确保写入 Vector Store 的数据结构符合 LangChain.js 的要求。如果使用外部工具写入，需要调整其输出格式。最好使用 n8n 内置的 Vector Store 节点进行数据写入操作，以保证格式兼容性 。
  • Embedding 模型不匹配:
    • 原因: 查询时 Vector Store Retriever 连接的 Embedding 模型与当初数据写入 Vector Store 时使用的 Embedding 模型不一致。
    • 解决: 必须使用完全相同的 Embedding 模型进行写入和查询。检查两个环节的 Embedding 子节点配置。
  • 检索结果为空或不相关 (即使知道数据存在):
    • 原因:
      • Query 与存储内容的语义相似度计算不准确 (Embedding 模型选择问题)。
      • 数据分块 (Chunking) 策略不佳，导致相关信息被分割到不同的块中。
      • Vector Store 中的数据本身质量不高或与 Query 相关性低。
      • Retriever 的 top_k 参数设置过小。
      • (旧版问题) Q&A Chain 未能正确使用 Retriever 返回的结果 。
    • 解决:
      • 尝试更换不同的 Embedding 模型。
      • 优化数据预处理和分块策略（使用 Recursive Character Text Splitter，调整 Chunk Size 和 Overlap）。
      • 清洗和丰富知识库数据。
      • 适当增加 Retriever 的 top_k 值，但要注意 LLM 上下文窗口限制。
      • 确保使用的是较新版本的 n8n，以避免旧的集成 Bug 。
      • 考虑引入 Reranker (可能需要 LangChain Code Node ) 来对初步检索结果进行重排序，提高相关性。
• 错误信息:message.toJSON is not a function
  • 可能原因: 特定 n8n 版本升级 (v1.28 -> v1.29.1 被报告) 引入的兼容性问题。
  • 解决: 检查 n8n 版本，考虑升级或降级（需谨慎），查阅相关 GitHub Issue 或社区帖子。
• 错误信息:Bad webhook: An HTTPS URL must be provided (当上游是 Telegram Trigger 时)
  • 原因/解决: 同基础 LLM 链部分。这是 Telegram Webhook 的要求，与问答链本身无关，需要配置 n8n 的公网 HTTPS 访问。
• 问题: RAG 回答不准确，或 AI “忽略”了检索到的信息
  • 可能原因:
    • 检索到的信息本身不准确或不相关: 这是数据源或检索阶段的问题。
    • LLM 未能理解或遵循指令: LLM 可能仍然倾向于使用其内部知识，或者未能很好地结合提供的 Context 回答问题。
    • Prompt 问题: 问答链内部的 Prompt (虽然不易修改) 或连接的 LLM 的 System Message 可能不够优化。
    • 模型能力限制: 某些模型（尤其是较小的本地模型）在 RAG 任务上表现可能不如预期 提到 Ollama 模型与 AI Agent 结合时的问题。
    • 任务类型不适合纯 RAG: 对于需要跨多个文档进行计算、比较或聚合的任务 (如“最贵的产品是什么？”)，简单的 RAG 可能效果不佳，因为 LLM 不擅长精确计算，且信息可能分散在不同块中 。
  • 解决方案:
    • 优化检索: 改进数据质量、分块、Embedding 模型、Retriever 参数，使用 Reranker。
    • 优化 Prompt/System Message: 在 LLM 子节点的 System Message 中加强指令，强调必须基于上下文回答。
    • 更换更强大的 LLM: 尝试使用在 RAG 和指令遵循方面表现更好的模型 (如 GPT-4, Claude 3 Opus)。
    • 调整 Temperature: 使用更低的 Temperature。
    • 混合方法: 对于需要计算或精确聚合的任务，考虑结合 RAG 和其他方法。例如，先用 RAG 获取相关产品信息，然后使用 Code Node 或数据库节点进行排序或计算 提到了 SQL 查询的混合方案。
    • 检查 Agent/Tool 交互 (如果使用 Agent): 确保 Agent 正确调用了 Vector Store Tool，并且 Tool 的 Description 清晰无误 。

RAG 系统的调试通常是一个涉及多个环节的迭代过程，需要耐心和细致的分析。

注意事项

构建和使用问答链 (RAG) 系统时，请特别注意以下几点：

1. 知识库质量是基础: RAG 的效果上限很大程度上取决于你喂给它的知识库的​质量、准确性、相关性和时效性​。垃圾进，垃圾出。投入时间和精力进行数据清洗、预处理和定期更新至关重要。
2. 检索与生成的平衡: 需要找到检索信息量 (Retriever 的 top_k) 和 LLM 处理能力 (Context Window) 之间的平衡点。检索太多信息可能会超出 LLM 限制或引入噪音，检索太少则可能信息不足。
3. 成本考量:
   • Embedding 成本: 将知识库数据生成 Embeddings 可能是一次性的，但如果数据量大，调用 Embedding API 也会产生费用。
   • Vector Store 成本: 使用云向量数据库服务 (如 Pinecone, Qdrant Cloud) 通常有存储和查询费用。
   • LLM 调用成本: 每次问答都需要调用 LLM API，同样按 Token 计费。
4. 幻觉与不确定性: 即使有 RAG，LLM 仍然可能产生幻觉，或者对检索到的信息进行错误的解读和组合。对于需要高精度回答的场景，需要有验证机制，或者在回答中体现不确定性（例如，引导用户说“根据文档 X，信息是 Y…”）。
5. 复杂性: 构建一个生产级别的 RAG 系统是一个系统工程，涉及数据工程、模型选择、Prompt 工程、评估和监控等多个方面，其复杂性远超简单的 API 调用。
6. 理解局限性: 认识到 RAG 并非万能。对于需要精确计算、实时交易或跨大量文档进行复杂推理的任务，纯 RAG 可能不是最佳方案，需要结合其他工具或方法 。
7. 问答链 vs. Agent+Tool 的选择: 再次强调，根据是否需要多轮对话和状态管理，选择合适的架构 [Insight 5]。对于需要记忆和更灵活工具调用的场景，Agent+Tool 是更优的选择。

问答链为 n8n 用户打开了利用自有知识进行 AI 问答的大门，是构建智能化应用的强大武器。掌握它，需要对整个 RAG 流程有清晰的理解，并愿意投入时间和精力进行配置、优化和调试。

本教程面向零代码基础的 n8n 用户，聚焦 LangChain 集成的三个核心 Chain 节点：基础 LLM 链、摘要链和问答链，旨在帮助读者理解节点功能、参数配置、数据流转及常见坑点，并能在实际工作流中灵活运用。

基础 LLM 链 (Basic LLM Chain)

功能定位：向大语言模型发送 Prompt，并可选接入 Output Parser 输出结构化结果。

核心参数：Prompt 来源（自动或自定义）、是否要求特定输出格式、聊天模型下的 System/User/AI 消息。

实战技巧：优质 Prompt、表达式动态构建、合理开启输出解析、低温度模式与成本控制。

摘要链 (Summarization Chain)

功能定位：针对长文本或多文档生成摘要，内置分块与汇总逻辑。

分块策略：Simple（字符分割）或 Advanced（递归分割器），推荐使用 Recursive Character Text Splitter 以保留段落结构。

摘要方法：

Map Reduce（并行映射 + 合并规约，扩展性好）；

Refine（迭代精炼，连贯性强）；

Stuff（一次性塞入，适用于短文本）。

常见注意：Token 限制、成本考量、输出结构校验、Merge by Position 关联原文与摘要。

问答链 (Question and Answer Chain / RAG)

功能定位：实现基于向量数据库知识库的检索增强生成 (RAG) 问答。

核心组件：

Retriever（通常为 Vector Store Retriever + Embeddings + Vector Store）

Language Model（Chat Model，用于根据检索上下文回答）

配置重点：保持写入与查询时 Embedding 模型一致，合理设置 top_k 与 LLM 的 Context Window，System Message 用于强化“只基于上下文回答”。

拓展场景：企业知识库问答、技术支持助手、个人知识管理、PDF 智能阅读等。

共同注意事项

无记忆性：所有 Chain 节点均为无状态，若需多轮对话或记忆，请使用 AI Agent + Memory 架构。

成本与性能：关注 API 调用频次、Token 消耗与模型选择对成本和速度的影响。

版本与兼容：及时查看 n8n Release Notes，测试节点输出结构变化，避免因升级导致流程中断。

数据隐私与安全：根据敏感度选择本地模型（如 Ollama）或企业级服务，防范幻觉（Hallucination）。

掌握以上三大 Chain 节点的功能与配置思路，配合良好的 Prompt 工程和知识库管理，即可在 n8n 中快速构建从简单文本生成到复杂 RAG 问答的全栈 AI 自动化流程。祝大家自动化之旅顺利！