第 15 章

构建 AI Agent 工作流

第 15 章：构建 AI Agent 工作流

从 n8n v1.x 开始，AI Agent 节点正式进入核心功能集。与普通 LLM 节点"问一答一"不同，Agent 节点具备工具调用（Tool Use）和多步推理能力：它能自行决定是否调用计算器、查询数据库还是发起 HTTP 请求，然后将结果融入下一步推理，直到完成最终目标。本章从三种 Agent 类型讲起，深入讲解工具配置与记忆模块，最后通过客服 Agent 和研究 Agent 两个完整案例，演示 n8n AI Agent 的真实能力边界。

15.1 n8n AI Agent 节点概览

n8n 的 AI Agent 节点位于节点面板的"Advanced AI"分类下。它本质上是一个带有"推理循环"的 LLM 封装——每次循环中，模型判断是否需要调用工具，若需要则执行工具并将结果作为上下文继续推理，直至得出最终答案。

与 Basic LLM Chain 节点相比，Agent 节点多了三个核心组成部分：

Tools（工具）：Agent 可以调用的外部能力，如 HTTP 请求、计算器、代码执行等
Memory（记忆）：跨轮次保留对话历史，让 Agent 具备上下文感知能力
Agent Type（推理策略）：决定模型如何规划和执行任务

版本要求： AI Agent 节点（以及 Langchain 集成节点）需要 n8n v1.19.0 或更高版本。自托管用户请确认 N8N_EXPERIMENTAL_FEATURES=AI 环境变量已启用（v1.30+ 已默认启用，无需手动设置）。

15.2 三种 Agent 类型详解

n8n 目前内置三种 Agent 推理策略，适用于不同复杂度的场景：

类型	推理方式	适用场景	Token 消耗
Conversational Agent	单步工具调用，维护对话历史	客服问答、聊天机器人	低
ReAct Agent	Reason + Act 循环，逐步推理	研究任务、多步骤数据处理	中
Plan-and-Execute Agent	先规划全局步骤，再逐步执行	复杂长链任务、项目分析	高

Conversational Agent

最轻量的 Agent 类型。它在每一轮对话中决定是否调用工具，并将所有历史消息保留在上下文窗口内。适合对话轮次较少（不超过 20 轮）、任务相对简单的场景。客服 Bot、FAQ 助理是典型应用。

ReAct Agent

ReAct（Reasoning + Acting）是目前工业界最常用的 Agent 推理模式。每一步的思维过程是：Thought（思考）→ Action（行动）→ Observation（观察），循环往复，直至给出 Final Answer。n8n 的 ReAct Agent 会将每一步的 Thought 和 Observation 写入执行日志，便于调试。

Plan-and-Execute Agent

先调用规划器（Planner LLM）生成完整的执行步骤列表，再依次执行每个步骤。规划和执行可以使用不同的模型（例如规划用 GPT-4o，执行用 GPT-4o-mini 以节省成本）。适合需要全局把控的长链任务，如竞品分析报告生成、多数据源汇总。

15.3 工具（Tools）配置

工具是 Agent 的"手脚"。n8n 中，将子节点连接到 AI Agent 节点的 Tool 端口，即可将其注册为可调用工具。

Calculator 工具

处理数学计算，避免 LLM 直接计算时的幻觉问题。无需配置，直接连接即用。当用户问"这个月销售额同比增长多少"时，Agent 会自动调用 Calculator 而非依赖模型内部估算。

Code Tool

允许 Agent 编写并执行 JavaScript 或 Python 代码片段。使用场景包括数据格式转换、正则提取、复杂字符串处理等。配置时需设置允许执行的语言，并可限制最大执行时间（默认 10 秒）。

安全提示： Code Tool 在沙箱环境中执行，但建议对输入数据进行校验，避免注入风险。生产环境中建议将可执行代码限定为特定语言，并设置严格的超时时间。

HTTP Request 工具

最强大的工具之一。你可以将任何 REST API 封装为 Agent 工具。配置时需提供：工具名称（供模型识别）、描述（告诉模型何时使用此工具）、请求方法和 URL 模板。

// HTTP Request Tool 节点配置示例
{
  "name": "search_products",
  "description": "Search product catalog by keyword. Use when user asks about product availability, price, or specs. Input: search query string.",
  "method": "GET",
  "url": "https://api.yourstore.com/products/search",
  "authentication": "headerAuth",
  "parameters": {
    "q": "={{ $fromAI('query', 'The search keyword') }}",
    "limit": "5"
  }
}

注意 URL 参数中的 $fromAI() 函数——这是 n8n v1.x 专为 Agent 工具设计的特殊表达式，告诉 Agent 该字段的值由模型动态填写，并附带说明文字帮助模型理解应该填什么。

自定义工具

除内置工具外，你可以将任意 n8n 节点通过 Tool Workflow 节点封装为 Agent 工具。这意味着你可以把整个子工作流（查询数据库 → 过滤 → 格式化）打包成一个工具供 Agent 调用，极大扩展了 Agent 的能力边界。

15.4 记忆（Memory）模块

Memory 模块决定 Agent 如何在多轮对话中保持上下文。n8n 提供两种主要记忆类型：

Window Buffer Memory

保留最近 N 轮对话的消息（用户消息 + Assistant 回复）。N 值越大，上下文越完整，但 Token 消耗也越多。推荐起始值为 10 轮。这是最常用的记忆类型，适合大多数客服和问答场景。

Simple Memory（会话内记忆）

仅在单次工作流执行期间保留上下文，执行结束后清空。适合单轮复杂任务（如一次性研究报告），不需要跨执行的持久化记忆。

持久化记忆： 如需跨会话（跨工作流执行）保留记忆，可以将对话历史存入 PostgreSQL 或 Redis，每次执行开始时读取并注入到 Agent 的 System Message 中。这是生产级对话系统的标准做法。

// Window Buffer Memory 配置
{
  "type": "@n8n/n8n-nodes-langchain.memoryBufferWindow",
  "parameters": {
    "contextWindowLength": 10,
    "sessionKey": "={{ $json.sessionId }}"
  }
}

// sessionKey 用于区分不同用户的会话
// 可以使用用户 ID、飞书 openId 等作为 sessionKey

15.5 实战一：客服 Agent——自动回答产品问题并记录到数据库

场景描述：用户通过飞书发送产品咨询，Agent 自动搜索产品知识库、查询库存 API，给出专业回答；同时将每次对话记录到 MySQL 数据库，供后续统计分析。

工作流架构

飞书 Webhook 触发：接收用户消息，提取 openId 和文本内容
AI Agent 节点：类型选 Conversational Agent，挂载三个工具
工具 1 — search_products：HTTP Request 工具，查询产品数据库 API
工具 2 — check_inventory：HTTP Request 工具，查询实时库存
工具 3 — escalate_to_human：当 Agent 无法回答时，调用此工具标记升级
MySQL 节点：将对话记录插入 conversation_logs 表
飞书发送消息节点：将 Agent 回复发回给用户

Agent 系统提示（System Message）

你是「优特 AI」的专业客服助理，负责解答用户关于产品的问题。

行为规范：
1. 优先使用 search_products 工具查询产品信息，不要凭记忆回答产品细节
2. 如果用户询问库存，必须调用 check_inventory 工具获取实时数据
3. 如果问题超出你的能力范围（如退款、投诉），调用 escalate_to_human 工具
4. 回答简洁友好，中文回复，不超过 200 字
5. 如果搜索结果为空，诚实告知用户"暂无该产品信息"

当前用户 ID：{{ $json.openId }}
当前时间：{{ $now.toISO() }}

数据库记录节点配置

INSERT INTO conversation_logs (
  session_id,
  user_id,
  user_message,
  agent_response,
  tools_called,
  tokens_used,
  created_at
) VALUES (
  '{{ $json.sessionId }}',
  '{{ $json.openId }}',
  '{{ $json.userMessage }}',
  '{{ $('AI Agent').item.json.output }}',
  '{{ $('AI Agent').item.json.usedTools.join(",") }}',
  {{ $('AI Agent').item.json.tokenUsage.totalTokens }},
  NOW()
);

15.6 实战二：研究 Agent——搜索网页 + 总结 + 发飞书

场景描述：每天早上 8 点，Agent 自动搜索指定关键词的最新资讯，阅读前 5 篇文章，提炼核心观点，生成每日简报并发送到飞书群。

工作流节点链

Schedule 触发器：Cron 表达式 0 8 * * 1-5（工作日早 8 点）
Set 节点：定义研究主题列表（如：["AI 行业动态", "出海电商趋势"]）
Loop Over Items：遍历每个主题
ReAct Agent 节点：执行研究任务，配备 3 个工具
工具 1 — web_search：SerpAPI 或 Tavily 搜索 API
工具 2 — fetch_webpage：HTTP Request 抓取文章正文
工具 3 — summarize_text：调用 LLM 对长文本做摘要（防止超长文章撑爆上下文）
Code 节点：合并所有主题的简报
飞书 Bot 节点：发送到指定群

// ReAct Agent 节点核心配置
{
  "agentType": "reActAgent",
  "model": "gpt-4o",
  "systemMessage": "你是一名专业的行业研究员。对于给定主题，你需要：\n1. 搜索最新资讯（近 24 小时）\n2. 阅读前 3-5 篇最相关的文章\n3. 提炼 3-5 个核心观点\n4. 输出结构化 Markdown 简报\n不要编造信息，所有观点必须来自实际搜索结果。",
  "maxIterations": 15,
  "returnIntermediateSteps": true
}

15.7 多 Agent 协作架构

对于超复杂任务，单个 Agent 往往力不从心。n8n 支持通过 Execute Workflow 工具实现多 Agent 协作——一个 Orchestrator Agent 将任务分解并分发给多个专家 Agent，汇总结果后给出最终输出。

典型的多 Agent 架构如下：

Orchestrator Agent：负责任务拆解和结果聚合，使用 Plan-and-Execute 类型
Search Agent：专职信息搜索，使用 ReAct 类型，配备搜索和抓取工具
Analysis Agent：专职数据分析，使用 Conversational 类型，配备 Code Tool
Writer Agent：专职内容生成，纯 LLM Chain，无需工具

成本控制建议： Orchestrator 使用 GPT-4o（高智能，负责规划），专家 Agent 使用 GPT-4o-mini 或 Claude 3 Haiku（低成本，负责执行）。这种"大脑 + 手脚"的分层架构可将整体 API 成本降低 60% 以上。

本章评分

4.8 / 5 (16 评分)