如何使用 n8n 构建 AI Agent：从原型到生产环境

1. 什么是 AI Agent？

AI Agent（AI 智能体）是一种利用 AI 模型理解目标、分析下一步应该执行什么，并与外部工具或系统进行交互以完成任务的软件系统。

传统的大语言模型（LLM）交互通常是：

用户 ↓ 提示词 ↓ AI 模型 ↓ 回复

而 AI Agent 在此基础上增加了更多能力：

用户 ↓ AI Agent ├── AI 模型 ├── Memory ├── 业务工具 ├── API ├── 数据库 ├── 知识库 └── 其他 Agent ↓ 执行动作 + 回复

例如，一位潜在客户发送：

我们需要一套能够管理大约 15 个仓库的库存管理系统。你们团队可以提供帮助吗？

普通聊天机器人可能只会生成一段回复。

但 AI Agent 可以进一步：

• 识别客户的具体需求；
• 判断是否缺少重要信息；
• 查询公司的内部服务资料；
• 对销售线索进行分类；
• 在 CRM 中创建客户记录；
• 生成内部销售摘要；
• 在必要时请求人工审批；
• 向客户发送合适的后续消息。

两者之间的区别非常重要。

AI Agent 不只是生成信息，它还能够与真实系统进行交互并执行实际操作。

2. 为什么使用 n8n 构建 AI Agent？

开发者当然可以直接通过应用代码、AI SDK、Agent 编排框架或自定义后端服务来构建 AI Agent。

但 n8n 提供了一个非常实用的抽象层，可以连接 AI 的推理能力与实际业务工作流。

通过 n8n，开发者可以组合：

• AI 模型；
• API；
• 数据库；
• SaaS 应用；
• Webhook；
• 内部工作流；
• 自定义 JavaScript 或代码；
• Memory；
• 向量数据库；
• RAG；
• MCP；
• 审批流程；
• 定时自动化。

因此，n8n 特别适合构建面向业务流程的 AI 自动化系统。

例如：

新销售线索 ↓ AI Agent ↓ 理解客户需求 ↓ 查询公司知识库 ↓ 检查 CRM ↓ 创建 / 更新销售线索 ↓ 生成摘要 ↓ 人工审批 ↓ 发送回复

如果没有类似 n8n 的编排层，开发团队往往需要自行开发并维护大量系统集成。

3. AI Agent 与传统工作流自动化的区别

并不是所有自动化流程都需要 AI。

在设计可靠的生产系统时，理解这一点非常重要。

Traditional Automation

传统自动化依赖预先定义好的规则。

例如：

IF invoice.total > 10,000,000 THEN require manager approval

这种逻辑具有确定性。

相同的输入应该始终产生相同的结果。

AI Agent

当任务需要语言理解、语义分析或推理时，AI Agent 才更有价值。

例如：

客户消息 ↓ AI 判断： - 客户意图 - 紧急程度 - 相关产品 - 缺失信息 - 推荐下一步操作

更合理的生产级架构通常是将两种方式结合起来。

业务规则使用确定性工作流，只有在语言理解或推理真正产生价值的地方才使用 AI。

例如：

AI ↓ 理解客户意图 ↓ 传统工作流 ↓ 验证权限 ↓ 传统工作流 ↓ 检查业务规则 ↓ AI ↓ 生成个性化回复

如果某项决策可以通过普通程序逻辑可靠实现，就没有必要交给 LLM 判断。

4. n8n 中的 AI Agent 架构

一个简化的生产级架构可以是：

用户 ↓ Trigger / API ↓ Webhook / Chat ↓ AI Agent ├── AI Model ├── Memory └── Tools ↓ CRM / API / Database / RAG

对于更复杂的系统，还可以加入：

AI Agent ├── Model ├── Memory ├── Tools ├── RAG ├── MCP ├── Human Approval ├── Guardrails ├── Logging ├── Evaluation └── Monitoring

相比简单地将聊天机器人连接到 LLM API，这种架构更适合真实的生产环境。

5. 我们将构建什么？

在本教程中，我们使用一个简化但贴近真实业务的示例：

AI Sales Assistant

它负责处理潜在客户的软件项目咨询。

整体工作流大致如下：

接收客户消息 ↓ 理解需求 ↓ 查询相关公司信息 ↓ 补充缺失信息 ↓ 对销售线索分类 ↓ 保存至 CRM ↓ 生成内部摘要 ↓ 人工审批 ↓ 发送后续回复

这个案例涵盖多个重要的 AI Agent 概念，同时也符合真实企业的销售工作流程。

6. 准备工作

在开始创建工作流之前，需要准备以下组件。

n8n

可以使用：

• n8n Cloud；或
• 自托管的 n8n。

AI Model

例如：

• OpenAI
• Anthropic
• Google Gemini
• Azure OpenAI
• Amazon Bedrock
• Mistral
• Groq
• DeepSeek
• Ollama

最合适的模型取决于你的业务负载、延迟要求、隐私需求以及预算。

Business Data

例如：

• 服务说明；
• 价格信息；
• 案例研究；
• 公司资料；
• FAQ；
• CRM 数据。

Optional Infrastructure

对于更复杂的生产实现，还可以准备：

• PostgreSQL；
• Redis；
• 向量数据库；
• Object Storage；
• Monitoring 工具。

7. Step 1：创建 Workflow 和 Trigger

每个 n8n Workflow 都从 Trigger 开始。

Trigger 的类型取决于用户如何与 AI Agent 进行交互。

常见方式包括：

• Webhook；
• Chat Trigger；
• Telegram；
• Slack；
• Email；
• Scheduled Trigger；
• Application API。

如果 AI Assistant 运行在网站中，一个常见架构是：

网站 ↓ Backend API ↓ n8n Webhook ↓ AI Agent

在 n8n 前增加自己的应用后端，可以让你更灵活地控制：

• 身份验证；
• Rate Limiting；
• 请求验证；
• 安全策略。

8. Step 2：添加 AI Agent

在 Workflow 中添加一个 AI Agent 节点。

Agent 是整个系统的编排层，它负责判断：

• 应该如何响应用户；
• 是否需要调用工具；
• 应该调用哪个工具。

从概念上可以理解为：

Input ↓ AI Agent ├── Model ├── Memory └── Tools ↓ Output

Agent 的质量主要取决于三个部分：

• 使用的模型；
• System Prompt；
• Agent 可以访问的工具。

给 Agent 更多工具并不意味着它一定会变得更强。

实际上，过多的工具权限反而可能增加系统复杂度与安全风险。

9. Step 3：连接 AI Model

接下来，将 Chat Model 连接到 AI Agent。

例如：

AI Agent └── OpenAI Chat Model

或者：

AI Agent └── Gemini

并不是所有任务都需要使用最强大的模型。

更合理的生产级系统可以根据任务类型选择不同模型。

例如：

意图分类 ↓ 小型 / 快速模型

复杂推理 ↓ 高能力模型

Embedding 生成 ↓ Embedding Model

这种设计可以显著降低 AI 系统的运行成本。

10. Step 4：设计 System Prompt

System Prompt 定义了 Agent 应该如何工作。

应避免过于宽泛的 Prompt，例如：

你是一个乐于助人的 AI 助手。

对于生产环境，System Prompt 应该更加明确。

例如：

角色 你是一家软件开发公司的 AI Sales Assistant。 目标 帮助潜在客户了解公司的服务，并收集销售团队所需的项目资料。 职责 - 理解客户需求。 - 判断项目是否缺少重要信息。 - 必要时查询公司知识库。 - 在适当情况下创建或更新 CRM 销售线索。 - 为销售团队生成简洁的客户摘要。 限制 - 不得虚构价格。 - 不得声称公司具备知识库中不存在的能力。 - 不得泄露内部信息。 - 未经明确授权，不得删除或修改客户记录。 - 在执行敏感操作之前必须请求人工审批。 输出要求 回复应简洁、专业并保持自然的对话方式。

明确的规则可以让 Agent 的行为更加稳定和可预测。

11. Step 5：连接 Tools

Tools 是 AI Agent 最重要的能力之一。

通过 Tool，Agent 可以与外部业务系统进行交互。

例如：

AI Agent ├── SearchCompanyKnowledge ├── FindCustomer ├── CreateLead ├── UpdateLead ├── GetAvailableServices └── SendEmail

生产环境中有一个非常重要的原则：

只向 AI 提供完成任务所必需的最小权限。

应避免创建类似这样的通用工具：

ExecuteDatabaseQuery

然后允许 Agent 执行任意 SQL。

更好的方式是建立职责明确、范围受限的工具：

FindCustomerByEmail CreateLead UpdateLeadStatus GetInvoice CreateSupportTicket

这样既更容易审计，也能显著降低安全风险。

12. Step 6：添加 Memory

如果没有 Memory，每一轮对话都会从零开始。

例如：

用户： 我的公司有 12 个仓库。 AI： 了解。 用户： 我们需要一套库存系统。 AI： 请问你们有多少个仓库？

AI 已经忘记了前面的信息。

Memory 可以解决这个问题。

架构可以表示为：

用户 ↓ AI Agent ↓ Memory

对于原型系统，简单的 Session Memory 通常已经足够。

生产环境则可以考虑持久化存储，例如：

• PostgreSQL；
• Redis；
• MongoDB；
• 专用 Conversation Storage。

同时还需要明确：

• 对话保存多长时间；
• 保存哪些消息；
• 是否允许存储敏感数据；
• Conversation History 什么时候过期。

不要让 Memory 无限增长。

13. Step 7：添加 RAG

RAG 是 Retrieval-Augmented Generation（检索增强生成）。

它允许 AI Agent 在回答问题之前，先从知识库中检索相关资料。

没有 RAG 时：

问题 ↓ LLM ↓ 根据模型已有知识回答

加入 RAG 后：

问题 ↓ 搜索知识库 ↓ 获取相关文档 ↓ LLM ↓ 基于资料生成回答

例如，一家软件公司可能拥有以下资料：

• 服务介绍；
• 技术栈；
• Case Study；
• 公司政策；
• 项目实施方法；
• 定价规则；
• Support Documentation。

与其将所有资料全部放进 Prompt，不如让 Agent 只检索当前问题所需要的内容。

典型架构：

Documents ↓ Chunking ↓ Embedding ↓ Vector Store

用户问题 ↓ Embedding ↓ Vector Search ↓ Relevant Documents ↓ AI Agent

这种方式通常可以提高回答准确度，同时减少不必要的 Token 消耗。

14. Step 8：连接 MCP

MCP 是 Model Context Protocol。

它为 AI 系统访问工具与外部数据提供了一种标准化方式。

如果没有 MCP，各类集成可能高度耦合：

AI Agent ├── Custom CRM Integration ├── Custom ERP Integration ├── Custom Database Integration └── Custom Internal API Integration

使用 MCP 后：

AI Agent ↓ MCP Client ↓ MCP Server ├── CRM ├── ERP ├── Database └── Internal APIs

当多个 AI 应用都需要访问同一组工具时，MCP 会更加有价值。

例如：

Claude ChatGPT Internal AI Assistant n8n Agent ↓ Shared MCP Server

不过，并不是每个项目都需要 MCP。

如果 Agent 只需要连接少量业务工具，直接使用 n8n Tool 往往更加简单。

15. Step 9：加入人工审批

生产级 AI Agent 最重要的控制机制之一就是：

Human-in-the-loop Approval（人工审批）

AI 不应该默认自动执行所有操作。

某些高影响操作应该要求人工确认。

例如：

• 发送敏感邮件；
• 修改财务信息；
• 批准退款；
• 删除记录；
• 修改客户合同；
• 执行付款。

工作流可以设计为：

AI Agent ↓ 提议操作 ↓ 人工审批 ↓ 是否批准？ → 执行 / 取消

这在人类决策与 AI 推理之间建立了一道重要的安全边界。

16. 从 Prototype 走向 Production

原型阶段通常只关注一个问题：

这个 Workflow 能不能运行？

但是生产系统需要回答更多问题：

• AI 调用失败怎么办？
• API Timeout 怎么处理？
• 一个操作会不会被重复执行？
• 谁可以访问某个 Tool？
• 如何追踪每一次执行？
• 每次请求需要多少成本？
• 如何发现低质量回答？
• 当流量增加时 Worker 能否扩展？

因此，生产级架构通常需要增加更多基础设施。

Application ↓ API Gateway ↓ n8n ↓ AI Agent ↓ Tools / RAG / APIs ↓ Database Supporting Infrastructure ├── Redis ├── Queue ├── Workers ├── Logging ├── Monitoring └── Alerting

17. Error Handling 与 Retry Strategy

外部服务一定会出现故障。

AI API 可能 Timeout。

CRM API 可能暂时不可用。

数据库连接也可能失败。

因此，你应该假设：

系统故障迟早会发生。

工作流需要实现：

• Retry Policy；
• Timeout Limit；
• Fallback Behavior；
• Error Workflow；
• Alert；
• Idempotency。

例如：

Create CRM Lead ↓ 失败？ ├── No → Continue └── Yes ↓ Retry ↓ 仍失败？ ↓ Error Workflow ↓ Notify Team

Prevent Duplicate Actions

假设 AI Agent 调用了：

CreatePayment

API 实际已经成功执行付款，但因为网络 Timeout，Agent 没有收到成功响应。

如果 Workflow 直接重试，就可能产生重复付款。

因此，生产环境应尽可能采用 Idempotency（幂等性）。

例如：

idempotency_key = workflow_execution_id + action_id

下游服务便可以识别重复请求，从而避免同一个操作被执行多次。

18. Security 与 Credential Management

AI Agent 经常需要访问企业内部的敏感系统。

因此，安全性应该从架构设计阶段就被考虑，而不是系统上线后再补充。

不要把 Credential 放在：

• Prompt；
• JavaScript Source Code；
• Workflow Description；
• Hardcoded Configuration。

应该使用专门的 Credential Management。

同时还应该遵循 Least Privilege（最小权限）原则。

例如：

AI Sales Agent Allowed: ✓ Read customer ✓ Create lead ✓ Update lead status Not allowed: ✗ Delete customer ✗ Export entire database ✗ Change administrator

即使 Agent 被攻击或出现异常，也不应该因此直接危及整个应用系统。

19. Logging、Monitoring 与 Observability

当 AI Workflow 出现问题时，你必须能够知道具体发生了什么。

值得记录的信息包括：

execution_id user_id conversation_id agent model tool_called latency token_usage status error timestamp

例如：

{ "execution_id": "exec_9813", "agent": "sales-agent", "model": "example-model", "tool_called": "CreateLead", "latency_ms": 1320, "status": "success" }

但应避免记录不必要的敏感数据，例如：

• 密码；
• Authentication Token；
• 机密文件；
• Personally Identifiable Information。

良好的 Observability 能帮助团队回答：

• 哪个 Tool 最容易失败？
• 哪类请求最慢？
• Agent 多久会升级给人工处理一次？
• 哪个模型消耗最多 Token？
• 哪个 Workflow 产生最多错误？

20. 扩展 n8n

在规模较小时，可以将所有功能运行在一个 n8n Instance 中：

n8n ├── UI ├── Webhook └── Workflow Execution

随着业务量增长，可能需要将 Workflow Execution 分离出来。

简化后的扩展架构可以是：

Main Instance ↓ Redis Queue ├── Worker ├── Worker └── Worker

Main Instance 负责 Workflow 协调，而 Worker 负责执行 Queue 中的任务。

对于需要大量并发 Workflow 的系统，这种架构能够提供更好的扩展能力。

21. Development、Staging 与 Production Environment

不要直接在 Production 中进行重大 Workflow 修改。

更成熟的开发流程应该划分不同环境：

Development ↓ Testing ↓ Staging ↓ Production

Development 可以用于：

• 测试新 Prompt；
• 开发新 Tool；
• 修改 Workflow。

Staging 可以使用：

• Test Credential；
• 接近真实环境的测试数据；
• Pre-production Integration。

Production 则应该使用：

• 受限 Credential；
• 已经过 Review 的 Workflow；
• 完整 Monitoring；
• 受控 Release。

这样，AI Agent 的开发方式就会更加接近成熟的软件工程实践。

22. 如何评估 AI Agent 的质量

传统软件通常可以通过确定性的 Assertion 进行测试。

例如：

2 + 2 = 4

但 AI 输出并不完全确定。

因此，AI 系统需要准备专门的 Evaluation Dataset。

可以设计以下代表性测试：

Test Case

Expected Behavior

用户询问公司服务

返回正确的服务信息

用户询问系统中不存在的价格

不得虚构价格

新客户咨询

创建 CRM Lead

已存在客户咨询

更新现有 Lead

用户要求删除数据

请求人工审批

Prompt Injection 攻击

忽略恶意指令

每当你修改以下内容时，都应该重新执行这些测试：

• Prompt；
• Tools；
• Models；
• Workflows；
• Retrieval Systems。

这样可以在变更进入生产环境之前发现 Regression。

23. 优化 AI 成本

如果 Workflow 设计不合理，AI Agent 的成本可能快速增加。

一次请求可能包含：

Initial LLM Call + Tool Selection + Tool Result Processing + RAG + Additional Reasoning + Final Answer

可以通过以下方式控制成本。

Use Task-Specific Models

并不是所有任务都需要使用能力最强的模型。

简单分类 → 小型模型

复杂推理 → 高能力模型

Reduce Conversation History

如果只需要最近的上下文，就不要每次都向模型发送数百条历史消息。

Use RAG

只检索当前问题需要的信息，而不是每次都将完整文档加入 Prompt。

Cache Stable Information

某些内容并不会频繁发生变化。

例如：

• 公司政策；
• 服务介绍；
• Category List。

这些内容适合缓存。

Use Deterministic Workflows

如果普通 Workflow 就能可靠解决问题，就不要额外调用 LLM。

24. 常见的 AI Agent 设计错误

Giving the AI Too Many Permissions

不推荐：

AI ↓ Full Database Access

更好的方式：

AI ├── FindCustomer ├── CreateLead └── UpdateLeadStatus

Using AI for Deterministic Business Logic

不推荐：

让 AI 判断金额超过 IDR 10,000,000 的 Invoice 是否需要审批。

更好的方式：

if (invoice.total > 10000000) { requireApproval = true; }

对于必须始终产生相同结果的业务规则，应使用代码实现。

Allowing the Agent to Invent Information

如果 Agent 不知道答案，应该明确说明，或者从可信数据源中查询信息。

System Prompt 应明确禁止虚构：

• 价格；
• 公司政策；
• 产品能力；
• 交付周期；
• 法律信息。

No Human Approval

高影响操作默认不应该完全自动化。

No Observability

如果无法解释 Agent 为什么执行某项操作，那么生产事故发生后将非常难以排查。

No Evaluation Dataset

昨天能够正常运行的 Workflow，在更换 Model、System Prompt 或 Tool 后可能表现完全不同。

因此，Regression Evaluation 非常重要。

25. Business Use Cases

使用 n8n 构建的 AI Agent 可以支持多种企业业务。

Sales

Lead ↓ AI Qualification ↓ CRM ↓ Sales Summary ↓ Follow-up

Customer Support

客户问题 ↓ Knowledge Search ↓ AI Answer ↓ 必要时转人工

Finance

Invoice ↓ 信息提取 ↓ 验证 ↓ Accounting System ↓ 人工审批

HR

Employee Request ↓ AI Classification ↓ HR Knowledge Base ↓ 创建内部 Ticket

Operations

Operational Data ↓ AI Analysis ↓ 异常检测 ↓ 生成摘要 ↓ 通知团队

ERP

AI Agent 也可以作为 ERP 系统之上的智能交互层。

例如，用户提出：

显示未来两周内可能出现库存不足的产品。

Agent 可以：

理解需求 ↓ 获取库存数据 ↓ 获取销售速度 ↓ 计算缺货风险 ↓ 生成建议

此时，Agent 并不是取代 ERP，而是成为 ERP 上层的智能编排与交互层。

26. Production Checklist

在将 AI Agent 部署到生产环境之前，建议检查以下内容。

Architecture

• Agent 职责是否清晰；
• Tools 是否具有明确边界；
• 确定性逻辑是否与 AI 推理解耦；
• 是否选择了合适的 Model。

Security

• Credential 是否安全存储；
• 是否采用 Least-privilege Access；
• 敏感 Tool 是否要求审批；
• 是否考虑 Prompt Injection 风险；
• 是否避免记录不必要的敏感数据。

Reliability

• 是否配置 Error Workflow；
• 是否实现 Retry Strategy；
• 是否设置 Timeout；
• 必要场景是否实现 Idempotency。

AI Quality

• System Prompt 是否有完整文档；
• 是否定义 Hallucination 处理方式；
• 是否准备 Evaluation Dataset；
• Tool Behavior 是否经过测试；
• RAG Quality 是否经过测试。

Infrastructure

• PostgreSQL 是否正确配置；
• 必要时是否有 Redis 或 Queue Infrastructure；
• 是否定义 Worker Scaling Strategy；
• 是否配置 Backup。

Observability

• Execution Logging；
• Error Monitoring；
• Token Usage Monitoring；
• Latency Monitoring；
• Cost Monitoring。

Deployment

• Development Environment；
• Staging Environment；
• Production Environment；
• Controlled Workflow Release；
• Rollback Procedure。

27. n8n 是否适合所有 AI Agent？

不一定。

当 AI Agent 需要编排多个业务系统和 Workflow 时，n8n 的优势尤其明显。

例如：

• CRM Automation；
• ERP Integration；
• Customer Support；
• Internal Tools；
• Business Process Automation；
• Document Processing；
• Sales Automation；
• Operations Workflow。

但是，如果你的系统需要：

• 极低延迟；
• 高度专业化的 Agent Runtime；
• 复杂的 Multi-Agent Orchestration；
• 极高的执行吞吐量；
• 自定义 State Management；
• 深度定制的 AI Infrastructure；

那么自定义应用可能更加合适。

即使如此，n8n 依然可以作为整体架构中的一个组成部分。

例如：

Frontend ↓ Application Backend ↓ AI Service ↓ n8n ↓ Business Systems

n8n 不需要取代你的 Application Backend。

它可以专注承担**自动化与系统集成层（Automation and Integration Layer）**的角色。

Key takeaways

• AI Agent 不只是生成回答，它还能够调用工具、读取业务数据并执行真实操作。
• n8n 非常适合作为 AI 推理与企业业务系统之间的 Workflow Orchestration Layer。
• 不要把所有业务逻辑交给 AI。确定性的业务规则应该继续使用传统代码和 Workflow。
• 生产级 AI Agent 必须考虑权限控制、人工审批、错误处理、幂等性、安全、监控和 Evaluation。
• RAG、Memory 与 MCP 可以增强 Agent 的能力，但应该根据实际场景选择，而不是为了技术复杂度而增加复杂度。
• AI 应用于需要理解和推理的部分，而可确定的业务规则应该由传统软件逻辑负责。