N8N AI Agent 教程：从简单提示到结构化工作流数据

为什么工作流自动化现在需要超越固定规则

想象一个工作流收到这样一句话：”一个名叫John的新客户在01/06/2026购买了一个gpu server。”一个人读到这句话会立即看到三个有用的值：客户名称、产品和日期。

一个刚性工作流则不会。它可以分割文本、搜索模式和验证格式，但一旦措辞改变——”John刚刚昨天订购了一个GPU server”或”新客户John在6月1日购买了主机”——脆弱的解析就开始崩溃。

这就是经典自动化和AI层之间的分界线。确定性工作流在输入干净后表现出色：路由数据、转换字段、验证记录、调用API和可靠地重复序列。它们在混乱的第一步上失败——解释意图、分类请求、总结非结构化内容或从自然语言中提取字段，然后工作流才能采取行动。

这正是n8n AI Agent变得实用的地方。在本指南中，您首先将获得对n8n AI Agent在工作流内实际是什么的纯英文理解，然后构建一个基础的第一个用例，将自然语言转换为结构化数据。

n8n AI Agent 实际上是什么

在 n8n 中，AI Agent 最好理解为工作流内的一个推理步骤。它是一个节点，使用模型来解释输入、处理上下文，并帮助确定接下来会发生什么。这可能意味着回答提示、提取字段、对请求进行分类或决定如何准备下一个工作流步骤。重要的是，agent 存在于工作流内。它本身不是整个系统。

当你按角色分离时，更容易理解各个组成部分：

模型处理灵活的解释。周围的 n8n 节点仍然拥有结构：数据来自哪里、如何映射、验证什么、哪个节点接下来运行，以及最后写入另一个系统的内容。如果你需要可预测的执行、审批、集成或业务规则，工作流仍然掌控全局。

💡 提示：最清晰的心智模型是这样的：工作流仍然是轨道；agent 是这些轨道内的推理步骤。

这也使得更容易说明 n8n AI Agent 不是什么。它不仅仅是一个聊天机器人节点。它不是魔法般的自主性。它不是每个工作流都需要的东西。如果一个固定规则、简单转换或一个有界的 AI 提示已经能解决问题，添加 agent 层只会增加复杂性。当工作流必须处理歧义才能再次变成确定性时，价值才会显现。

n8n AI Agents 在真实工作流中最有帮助的地方

使用 n8n AI Agent 的最佳位置是在人类歧义进入系统的边界处。

• 支持团队可能需要阅读传入请求并分类它是账单、技术还是紧急问题。
• 运营团队可能会收到纯文本的内部请求，需要在路由前提取字段。
• 销售团队可能想将混乱的潜在客户消息转换为 CRM 就绪的干净数据。
• 文档繁重的工作流可能需要从非结构化文本中提取名称、日期、发票号或服务详情。

在每一种情况下，劳动分工都保持不变。Agent 进行解释、提取、总结或分类。确定性节点随后验证输出、将其路由到正确的分支、创建记录、通知人员或将结果写入另一个系统。这个边界很重要，因为它保留了 AI 的有用部分——灵活的解释——同时不放弃使工作流自动化值得使用的可预测性。

结构化提取是一个特别强大的首选用例，因为它是有界的、可见的，并且在下游立即有用。你可以看到输入句子，定义你想要返回的字段，然后像使用普通工作流数据一样使用这些字段。这使得收益是具体的。与其说”AI 说了有帮助的话”，不如说”工作流现在有了 name、product 和 date，下一个节点可以对它们采取行动”。

这也是保持一个原则的好地方：更多的 Agent 行为不一定更好。如果固定规则或单个提示已经解决了问题，你可能不需要完整的 Agent 层。本文深入探讨结构化提取，因为它展示了真实的工作流价值，而不是假装每个自动化问题都需要广泛的自主权。

我们在本教程中构建的内容

本教程有意教授两个工作流。工作流 A 是最小可能的模式：

Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model -> plain response

它的目的不是给你留下深刻印象。它的目的是使数据路径可见，以便你可以准确看到提示如何进入工作流、到达代理，以及作为普通答案返回。

工作流 B 保持相同的基础，并使用结构化输出解析器和创建发票代码节点进行升级。代理将返回可预测的字段，而不是返回段落。这些字段随后用于构建发票对象，这使输出立即对工作流的其余部分有用。

这个两步进展很重要。首先，你看到代理在最简单的形式中的行为。然后你看到为什么纯 AI 输出对于自动化来说只是故事的一半。真正的回报来自于工作流将自然语言转换为结构化数据。

开始之前：先决条件和准备

在构建工作流之前，准备好三件事：

1. 一个运行中的 n8n 实例
2. 创建和编辑工作流的权限
3. 有效的 OpenRouter API 凭证

如果需要，你可以在 n8n Cloud 中运行相同的逻辑，但本文围绕自托管环境展开，因为当团队想要更好地控制数据、网络或私有集成时，这是常见的 AlexHost 风格用例。

本教程的实际来源是在 AlexHost VPS 上运行的 n8n 2.26.8 上观察到的。如果你在尝试 AI 部分之前仍需要部署 n8n，请使用此处的单独 AlexHost 指南：n8n automation tutorial for Ubuntu: from zero to flow。

📓 注意：继续之前有一个小的术语说明：较新的文档可能会将 Set 节点显示为 Edit Fields (Set)，但本演练保持更简单的 Set 措辞，因为这是实际来源所使用的。

本文从 Manual Trigger + Set 而不是 Chat Trigger 开始的原因很简单：它使输入明确，使映射易于检查，并为首次构建消除了一层混淆。你正在学习 AI Agent 节点如何适应工作流，以及该工作流如何从自由形式的提示转移到结构化的、自动化就绪的输出。

实践第1部分：构建最小的n8n AI Agent流程

这个第一个工作流在要求它做任何更有用的事情之前证明了基本模式。您将创建一个可见的输入，将其传递到AI Agent中，连接一个OpenRouter模型，并确认工作流返回正常的文本响应。

1.0 添加触发器和输入节点

首先在画布上放置一个Manual Trigger节点和一个Set节点。这样可以保持入口点简单，并为您提供一个清晰的字段来传递到代理中。

此时，您还没有做任何”AI特定”的事情。您正在准备干净的工作流输入，以便下一个节点有明确的内容可以读取。

1.1 配置Set节点

打开Set节点，将其切换到Manual Mapping，创建一个名为prompt的字段，并粘贴下面的启动文本。这为工作流提供了一个可见的值，您可以稍后将其替换为更具业务性的句子。

Hello, who are you?

这样做很简单但很重要：您不是将提示隐藏在AI节点内，而是将其保留在正常的工作流数据中。这使输入路径更容易理解和重用。

2.0 放置AI Agent并连接聊天模型

现在添加一个AI Agent节点，并将OpenRouter Chat Model连接到其Chat Model输入。用初学者的术语来说，可见的输入意味着：Chat Model是代理用来响应的模型，Memory是跨轮次持续的可选上下文，Tool是可选连接，允许代理调用外部功能。在这个第一个工作流中，只连接了模型，因为目标是理解最小的工作模式。

一旦这个到位，角色分割就变得可见：工作流携带输入，代理将处理解释步骤。

2.1 配置OpenRouter模型

选择您的OpenRouter account凭证，并选择源工作流中显示的相同模型：deepseek/deepseek-v4-flash。对于这第一次尝试，您不需要额外的调整。

📝 注意：可用的OpenRouter模型可能因账户而异，即使此处的真实来源示例使用deepseek/deepseek-v4-flash。

如果您的账户显示不同的列表，工作流模式仍然比确切的模型名称更重要。

3.0 将prompt字段映射到AI Agent中

连接Set节点输出到AI Agent，将Source for Prompt (User Message)设置为Define below，并使用下面的表达式将工作流值映射到提示字段中。这告诉代理从上游数据中读取prompt值，而不是使用节点内硬编码的消息。

{{ $json.prompt }}

该映射是正常n8n数据和AI步骤之间的关键桥梁。一旦它点击，教程的其余部分就变得更容易遵循。

3.1 执行工作流

运行工作流，使数据通过完整链移动：Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model。您验证的不仅是模型是否响应，而是工作流是否干净地将提示从一个节点传递到下一个节点。

如果执行成功，您现在有证明代理可以使用工作流数据，而不仅仅是在其自己的界面内自由输入。

3.2 查看响应

打开输出并检查结果。在这个阶段，AI Agent对提示返回正常的文本答案。这是最简单形式的基本模式：提示输入，响应输出。

第一个工作流很重要，因为它证明了管道。它还清楚地显示了限制：一个段落对于交互来说很好，但对于下游自动化来说很尴尬。下一步是工作流变得更有用的地方。

实践第2部分：将响应转换为结构化工作流数据

现在我们保持相同的基础工作流并更改目标。我们不再要求代理提供一般回复，而是要求它提取可预测的字段，下一个节点可以像普通JSON一样使用这些字段。

4.0 更改提示并要求特定格式

返回Set节点，用下面的商务风格句子替换随意的问候。然后在AI Agent中启用Require Specific Output Format，使工作流停止追求散文形式，开始追求结构化提取。

A new client named John bought a gpu server on 01/06/2026

这是用例变成现实的时刻。该句子包含人类可以立即理解的数据，工作流现在被教导以机器可用的形式返回该数据。

4.1 添加结构化输出解析器

将Structured Output Parser连接到AI Agent的Output Parser输入。此解析器是为模型提供目标结构而不是让它以自由文本形式回答的关键。

📝 注意：Structured Output Parser适合这个第一个演示，但官方n8n指南指出，在更高级的工作流中，代理上的直接解析可能不太可靠。对于这个初学者模式，它仍然是正确的教学步骤，因为它使数据形状变化易于看到。

重要的想法不是额外的节点本身。而是你正在将”AI响应”转变为”工作流契约”。

4.2 从JSON示例定义输出架构

在解析器中，将Schema Type设置为Generate From JSON Example并使用下面的确切示例。这为代理提供了一个清晰的架构，包含工作流期望返回的三个字段。

{
  "name": "Alex",
  "product": "VPS hosting",
  "date": "21/6/2026"
}

定义该示例后，你不再是在要求模型”说一些有用的东西”。你是在要求它返回一个具有name、product和date的可预测结构。

4.3 检查结构化结果

再次执行工作流并检查AI Agent输出。这一次，结果应该以字段形式返回，而不是段落。

该形状变化是真正的升级。结构化输出不仅仅是更漂亮的格式。它是使结果足够可靠以供下游逻辑使用而无需猜测的关键。

4.4 在JavaScript发票节点中使用解析的字段

现在将结果传递到Create invoice JavaScript节点。本演练中的关键真实来源细节是解析的对象从$input.first().json.output读取，这意味着代码直接使用结构化代理输出。

// Input data
const order = $input.first().json.output

// Parse the order date
const [day, month, year] = order.date.split("/");
const orderDate = new Date(`${year}-${month}-${day}`);

// Generate a pseudo unique invoice ID (8 chars)
function generateId() {
  return Math.random().toString(36).substring(2, 10);
}
const invoiceId = generateId();

// Calculate payment due date (7 days later)
const dueDate = new Date(orderDate);
dueDate.setDate(orderDate.getDate() + 7);

// Build invoice record
const invoice = {
  invoice_id: invoiceId,
  customer: order.name,
  product: order.product,
  order_date: orderDate.toISOString().split("T")[0],
  due_date: dueDate.toISOString().split("T")[0],
  status: "Pending"
};

// Print invoice
console.log("Invoice Generated:");
for (const [key, value] of Object.entries(invoice)) {
  console.log(`${key}: ${value}`);
}

// If inside n8n Function node, return JSON
return [{ json: invoice }];

这是工作流停止表现得像聊天演示并开始表现得像自动化的地方。代理提取了字段，下一个节点像任何其他结构化输入一样使用它们。

4.5 查看生成的发票数据

打开最终输出并检查发票对象。你应该看到可用的字段，如invoice_id、customer、product、order_date、due_date和status。

这是本文一直在构建的完整生命周期：自然语言句子 -> 结构化提取 -> 发票记录。一旦结果具有该形状，工作流就可以将其传递到后续步骤，就像任何其他JSON有效负载一样可靠。

这两个初始工作流实际证明了什么

综合来看，这两个工作流展示了n8n AI Agent的两种不同模式。第一种模式是纯提示-响应：agent接收文本并用文本回答。第二种模式是结构化提取：agent接收混乱的人类语言并返回工作流实际可以使用的字段。

这种差异很重要，因为升级关乎能力，而非外观。文本生成有助于交互。结构化提取有助于自动化。第二种模式是将AI步骤从”有趣”转变为操作上有用的关键。

下表总结了这一转变：

一旦理解了这个升级路径，发票示例就不再是”发票教程”，而是成为可重用的工作流模式。同样的方法可以支持潜在客户捕获、支持intake、订单解析、工单enrichment或内部请求路由。在每种情况下，目标都是相同的：将自然语言转化为结构化数据，然后让确定性工作流节点完成其余工作。

在第一个用例之后尝试什么

最安全的步骤不是自主性——而是保持有界模式并一次升级一个变量。当需要入站输入时，将手动触发器交换为聊天触发器或 Webhook。仅当连续性重要时才添加内存。仅当代理必须查找内容或在节点之外执行操作时才附加工具。然后，如果输出涉及真实系统，添加验证或批准。

当工作流需要私有输入、内部服务访问、可预测的正常运行时间或更严格的控制时，自托管变得至关重要——这里 AlexHost 风格的 VPS 基础设施是设计的一部分，而不仅仅是后台。对于部署，相同的 AlexHost 指南涵盖设置：n8n Ubuntu 自动化教程：从零到流。

📝 注意：指导原则：最小系统启发式。如果结构化提取解决了问题，就停止。除非工作流确实需要，否则不要添加内存、工具或自主性。

从有限的用例开始，而不是自主性炒作

当混乱的人工输入进入系统时，刚性自动化通常会首先崩溃。这就是本文重点关注的差距。现在你既有了心智模型，也有了可行的模式：n8n AI Agent 处理灵活的解释步骤，周围的工作流将该结果转化为结构化和可靠的内容。

这是值得保留的设计规则。从产生工作流就绪数据的受控解释任务开始。只有当真实工作流需要时，才扩展到内存、工具或更丰富的触发器——而不是因为”agent”这个词让更大的自主性听起来更令人印象深刻。