n8n的AI Agent节点允许模型在已配置的工具中作出选择。这种灵活性会增加非确定性和故障面，因此只有在更简单的确定性路由不足时，才应使用智能体。
本文介绍一套潜在客户分流设计：接收潜在客户信息、检索获准使用的背景资料、提出评分和回复草稿、验证结果，再转入人工审核。它不是可直接导入的工作流，也不是已经取得的运行结果；下文的验收测试说明了它在端到端可用前还需完成哪些工作。
本文假设你已安装n8n（在服务器上自托管或使用n8n Cloud），并拥有可用的Claude或OpenAI API密钥。如果你刚开始接触n8n，请先完成其基础教程。
该设计也遵循OWASP关于过度自主权的警告：尽量缩小工具权限和自主范围，并由工作流强制审批会产生后果的操作。如果潜在客户数据来自第三方或将用于主动联系，在导入数据或发起联系之前，应核实数据来源、告知义务、合法依据、拒绝联系名单和渠道规则；欧盟委员会说明，从第三方取得的数据并不能自动用于营销。
不要让第一个版本自动向真实潜在客户发送回复。在你具备日志、幂等性、评分阈值，并审核过足够多次运行、确认工作流能够应对混乱输入之前，请将草稿交由人工审核。
我们要构建什么
工作流如下：
- 新的潜在客户通过webhook进入（可能来自表单、活动或CRM等）。
- 智能体使用网页搜索补充该客户的公司信息。
- 智能体从三个维度为客户评分：匹配度、意向和紧迫度。
- 智能体起草个性化回复。
- 根据评分，智能体会：
- 对置信度高且匹配度高的潜在客户，把回复和CRM提案加入审批队列；
- 对中等评分的潜在客户起草回复供人工审核，并发送Slack通知；
- 或者对匹配度低的潜在客户仅做记录和通知，不予回复。
这套模式的部分做法可以用于后果较轻的分流任务，但每个新领域都需要重新分析数据、错误、公平性和专业审查要求。不要把销售评分设计直接用于雇佣、医疗、法律、金融、儿童安全或建筑决策。
本文链接的配套JSON schema定义了接收数据的载荷。请先用它验证webhook输入，再让AI Agent节点接收数据。
添加智能体前置验证关卡
webhook不应将任意表单数据直接传给智能体。请在触发器与智能体之间添加验证步骤：
| 字段 | 规则 | 失败时的处理方式 |
|---|---|---|
email | 必填；去除首尾空格并验证，谨慎规范化域名；除非所属提供商定义了更严格的规范化，否则保留本地部分 | 拒绝并通知负责人 |
message | 必填、非空、限制最大长度 | 拒绝或转交人工审核 |
source | 必填枚举，例如website-form、event、crm | 拒绝未知来源 |
timestamp | 必填ISO时间戳，或由webhook生成 | 使用接收时间并添加标记 |
lead_id | 必填的稳定ID，或生成的幂等键 | 处理前去重 |
这个关卡可以防止格式错误的提交、webhook重复重试，以及藏在表单字段中的提示词注入内容直接进入后续流程。智能体仍然可以读取消息，但应由工作流判断记录是否符合处理条件。
思维模型：智能体 = LLM + 工具 + 循环
开始构建前，先了解这个概念。
2026年所说的“智能体”，是指能够使用工具的LLM。模型不只生成一次回复，还会决定调用哪些操作（称为“工具”）。每次工具返回结果后，模型会看到结果并决定下一步做什么——调用另一个工具、执行另一个步骤，或给出最终答案。
n8n的AI Agent节点实现了这个循环。你需要为模型提供：
- 系统提示词（对其行为的指令与语气）。
- 用户提示词（本次运行的输入）。
- 一组工具（模型可以调用的其他n8n节点或子工作流）。
模型决定调用哪些工具、按什么顺序调用，以及使用什么参数。每个工具返回后，模型会重新判断。当模型认为任务已经完成时，就会返回最终答案。
这与静态工作流存在根本区别，因为步骤的顺序由模型而不是由你决定。设计智能体的关键在于：
- 为模型提供合适的工具（不能太少，也不能太多）。
- 编写限定其行为范围的系统提示词。
- 添加护栏，防止智能体偏离正轨。
- 设计输出，让下游节点能够可靠使用。
第1步：触发器
打开n8n并创建一个新工作流。触发器配置如下：
- 节点： Webhook
- HTTP方法： POST
- 响应模式： “When last node finishes”
- 路径： 例如
/lead-triage
这个webhook将接收潜在客户提交的数据。n8n会提供一个URL，你可以将其配置为表单提交或CRM出站webhook的目标地址。
测试时，先保存一次工作流，让webhook URL生效，并准备一个示例payload。典型的潜在客户webhook payload可能如下：
{
"name": "Anna Lehtinen",
"email": "anna@somecompany.fi",
"company": "Some Company OÜ",
"role": "Head of Marketing",
"message": "Interested in your AI consulting services. We have a team of 10 and need help with prompt engineering training.",
"source": "website-form",
"timestamp": "2026-05-15T14:30:00Z"
}
点击“Test step”并提交测试payload，即可查看数据流入工作流。
第2步：AI Agent节点
在webhook后添加一个AI Agent节点。配置如下：
- Agent / Tools Agent： 当前n8n AI Agent节点（1.82及以上版本）不再显示Agent Type下拉框，而是以Tools Agent运行。连接一个聊天模型和下文的工具。在仍显示Agent Type的旧模板中，选择Tools Agent；Conversational等旧类型已被移除。
- 聊天模型： Claude（Anthropic）或OpenAI。先使用提供商当前的通用模型；只有在评估结果证明值得时，才改用更快或更强的层级。推理模式会为每一步智能体循环增加延迟和成本。
- 记忆： 对无状态分流设为None（每个潜在客户互相独立）。对于多轮智能体对话，请使用记忆节点。
- 系统消息： 智能体的行为在这里定义。使用下面的模板。
- 用户消息： 从webhook中提取潜在客户数据。
系统消息：
你是[Your Company Name]的潜在客户分流智能体，该公司是一家AI咨询公司。
你的任务是处理收到的潜在客户，并生成结构化的分流决策。
对于每位潜在客户，你必须：
1. 使用`enrich_lead`工具收集该公司的背景信息。
2. 从三个维度为潜在客户评分：
- 匹配度：潜在客户是否符合我们的理想客户画像？
- 从事B2B、制造业或专业服务，规模为10-200人的公司。
- 职位属于市场营销、运营、工程管理层或高管。
- 意向：这次问询有多认真？
- “只是好奇”与“正在积极评估”与“准备购买”。
- 紧迫度：是否明确或暗示了时间要求？
3. 使用`score_lead`工具记录评分。
4. 使用`draft_response`工具生成个性化回复。
5. 使用`propose_route`工具，并从以下选项中选择一个："review_priority"、"human_review"、"log_only"。
路由规则（按此顺序判断，首个匹配项生效）：
- 如果匹配度 >= 7/10且意向 >= 7/10，则选择"review_priority"。回复会得到优先人工审核。
- 如果匹配度 >= 5/10或意向 >= 5/10，则选择"human_review"。发送前将由人工检查。
- 如果匹配度 < 5/10且意向 < 5/10，则选择"log_only"。我们只做跟踪，然后继续处理其他工作。
切勿编造信息。如果某项信息不明确，请在评分理由中标记[unclear]。
最后必须返回一个JSON对象：
{
"fit_score": <1-10>,
"intent_score": <1-10>,
"urgency_score": <1-10>,
"reasoning": "<2-3 sentences>",
"drafted_response": "<the email body>",
"routing": "<review_priority|human_review|log_only>"
}
请留意其中的结构。我们提供了：
- 清晰的任务说明。
- 明确的流程（第1–5步）。
- 明确的评分标准。
- 明确的路由逻辑。
- 必须遵守的输出格式。
智能体不一定每次都能完美遵循。但系统消息越具体，它每次执行相同流程结构的可靠性就越高。
仅有JSON对象还不够。请在AI Agent节点后添加验证步骤；如果缺少评分、路由值不在允许的枚举范围内，或回复草稿为空，则拒绝该次运行。
第3步：工具
智能体需要可以调用的工具。在n8n中，工具在AI Agent节点下配置，可以是：
- 子工作流。
- HTTP请求。
- 内置工具节点。
下面为智能体构建四个工具。
工具1：enrich_lead
创建一个子工作流：
- 接收公司名称和电子邮箱域名作为输入。
- 使用其条款允许此用途的已批准搜索或公司数据API。
- 返回带有规范来源URL和检索日期的结构化陈述；无法确认的规模或身份应保持未知。
工具描述（智能体会读取它，以决定何时调用该工具）：
检索获准使用的潜在客户公司公开背景。输入：公司名称和电子邮箱域名。输出：带来源URL和检索日期的已核验陈述，以及歧义或错误。没有来源时，不要推断身份、规模或新闻。
工具2：score_lead
这是一个确定性验证工具：
- 接收拟议评分，检查类型、范围、必填理由和允许的标签。
- 返回验证错误或规范化的评分对象。
- 不持有数据库、表格、CRM、电子邮件或其他写入凭据。
只有智能体的最终输出通过同一套服务端schema后，才将其保存。
工具描述如下：
验证拟议的潜在客户评分，但不进行持久化。输入：fit_score、intent_score、urgency_score和rationale。输出：
{valid, errors, normalized_scores}。本工具不能写入记录或发送消息。
工具3：draft_response
创建一个子工作流，接收潜在客户背景信息和评分，并生成个性化电子邮件草稿。这个子工作流会在内部调用另一个AI节点，并使用专门的起草提示词：
为B2B问询起草个性化回复。输入：潜在客户的原始消息、公司信息补充摘要，以及匹配度/意向/紧迫度评分。
语气：热情、直接，不使用空洞的企业套话。回应客户的具体需求。仅在信息补充中的陈述有来源且相关时引用，否则省略。最后提出一个供人工审核的下一步。
长度：80–120个英文单词。
工具描述如下：
为潜在客户起草个性化电子邮件回复。输入：潜在客户消息、信息补充摘要和评分。输出：电子邮件草稿。
工具4：propose_route
该工具记录三种拟议路由之一；它不会发送电子邮件或写入CRM：
review_priority：把草稿放入优先人工审核队列。human_review：把草稿放入标准人工审核队列。log_only：记录分流结果，不准备出站操作。
schema验证后的确定性Switch节点会强制执行允许的枚举，并把review_priority和human_review送入审批队列。只有一个独立且受审批约束的子工作流持有面向客户的写入能力。
把该工具实现为无副作用的子工作流，并让它返回提案对象。Agent节点结束后，由确定性schema验证节点和Switch节点决定哪个分支可以持久化提案。没有独立审批工作流时，任何分支都不得抵达发送节点。
工具描述如下：
提出路由。输入：路由决策（
review_priority、human_review或log_only）、评分、理由与草稿。输出：供确定性schema验证的内存提案对象。本工具不能持久化、发送电子邮件或更新CRM。
第4步：测试智能体
完成智能体配置并连接四个工具后，使用示例payload进行测试。
你应该会在n8n的执行视图中看到：
- Webhook接收payload。
- AI Agent启动。
- 智能体调用
enrich_lead——你可以看到工具执行并返回结果。 - 智能体选择下一步（能否看到中间轨迹取决于模型和设置）。
- 智能体调用
score_lead。 - 智能体调用
draft_response。 - 智能体调用
propose_route，并传入三个路由选项之一。 - 智能体返回最终JSON。
如果出现问题，n8n的调试面板会显示智能体与工具之间的消息。最常见的问题包括：
- 工具描述不够具体。 模型无法推断工具适用的时机。请让描述更加具体。
- 工具输入/输出schema不匹配。 智能体无法传入正确的参数。请明确说明schema。
- 智能体无限循环。 它不断调用工具，无法结束。请设置最大迭代次数限制，并重新检查系统提示词。
第5步：添加护栏
未经防护的智能体不适合用于生产环境。信任它处理真实流量前，需要添加以下六项护栏：
1. 最大迭代次数。 根据成功评估案例所需的最少步数设置有限上限。测试触及上限时应转交人工，且不能留下未完成的外部操作。
2. 每份拟议回复的审批关卡。 review_priority只改变队列顺序，并不授权发送。面向客户的沟通应始终在经过身份验证的人工审批后才能发出，除非另有正式批准的政策；也不能仅凭系统已经运行了几周，就推断它是安全的。
3. 出站操作白名单。 配置CRM工具和电子邮件工具，使其只能操作符合预期模式的记录。这样可防止智能体将电子邮件发到错误地址，或为并非潜在客户的对象创建记录。
4. 日志记录。 为每次运行记录获批准的元数据：稳定的运行/客户引用、工作流和模型版本、工具名称与结果、验证结果、路由、审批人、重试和错误。潜在客户原始输入、信息补充结果、草稿和工具参数包含个人或机密数据，需要单独决定目的、脱敏、访问与保留期限。
5. 成本限制。 设置有限的智能体迭代次数和工作流超时，并在模型提供商处配置支出/速率提醒或上限。n8n套餐限制记录在执行与功能条款中；不要假定n8n Cloud会为自带的提供商密钥强制每日预算。跟踪提供商用量，并测试停止开关。
6. 决策归属。 模型可以建议review_priority、human_review或log_only，但最终规则应由工作流执行。将路由枚举、评分阈值和审批要求放在提示词之外，使其可测试、可见。
第6步：生产加固
下面这些模式能将可运行的原型转变为值得信赖的系统：
幂等性。 确保同一个潜在客户被处理两次时（例如webhook重试或人工重新运行），不会创建重复记录或消息。先查询再写入的检查仍可能出现竞态：应在数据库中以原子方式占用唯一键，并让所有下游写入使用同一个键。遵循原子占用、租约、审批令牌与outbox设计。
错误处理。 为每个工具调用添加错误处理。如果信息补充不可用或公司身份存在歧义，工作流应标记缺失数据并转交人工审核；它不能为了完成草稿而编造个性化事实。
可观测性。 跟踪关键指标：平均运行时间、工具调用频率，以及分配到各路径的百分比。异常情况应触发调查。
试点审核。 在经同意且边界明确的试点中，对照客户原始信息审核每次运行。试点规模应覆盖来源类型、语言、缺失字段、公司歧义、注入尝试和优先级类别。跟踪错误的信息补充、评分、路由、截止时间和草稿。固定的50条记录不能证明某个可靠性水平。
可强制执行的停止开关。 在模型之外约束执行和每个副作用分发器，使获授权的操作员无需重新部署即可暂停新启动或恢复执行的运行。测试禁用状态能阻止队列中及执行中的发送；仅由智能体“检查”的提示词指令或变量并不是停止开关。
最重要的设计决策：为智能体提供哪些工具
决定智能体质量的最大因素是工具集。常见的失败模式有两种：
工具太少。 智能体无法完成任务。它会尝试假装自己具备缺失的能力，通常导致编造内容。
工具太多。 智能体会感到困惑、选错工具，或浪费迭代次数进行探索，质量随之下降。
一条实用原则是：从最小可行工具集开始，只有在智能体明确表现出需要时才添加工具。
对于潜在客户分流，我们选择的四个工具基本合适。你还可以添加：
- “lookup_existing_customer”工具，用于检查潜在客户是否已经是现有客户。
- “schedule_meeting”工具，用于与你的日历集成。
- “translate”工具，用于处理多种语言的潜在客户信息。
但每增加一个新工具，智能体就多一个需要做出的决策。每个工具都应该真正证明自己的价值。
可推广的模式
相同的控制思路可能有助于其他分流工作流，但下列标签与操作未经领域审查不可直接移植：
支持工单分流。 检索获准使用的客户历史并提出类别/优先级；账户、安全、退款、权益与客户消息等操作仍置于政策和人工关卡之后。
雇佣工作流。 不要把潜在客户评分改造成面试/拒绝自动化。雇佣决策可能产生法律与歧视风险，需要合格的HR/法律审查、无障碍控制、偏差评估、向员工/申请人保持透明，以及有实质意义的人工决策。
媒体问询处理。 将信息补充替换为“lookup_publication”，将路由替换为按优先级回复。
客户反馈转交。 将信息补充替换为情感分析和产品分类。
采购申请。 将信息补充替换为供应商查询，将评分替换为政策合规性，将路由替换为审批流程。
一种可以复用于后果较轻任务的流程是：验证入站事件 → 检索最低限度且获准使用的背景 → 请求结构化提案 → 确定性验证 → 按既定规则并由获授权人员决策 → 通过幂等且受控的工具执行。模型只提出建议，不掌握会产生后果的决定权。
何时不应使用智能体
有些工作流并不能从智能体中受益。如果逻辑完全确定——“始终先执行A，再执行B，然后执行C”——不使用智能体的常规n8n工作流会更快、更便宜，也更可靠。
在以下情况下，智能体才能体现价值：
- 可能采用的路径很多。
- 正确的路径取决于判断，而不是严格规则。
- 某些决策需要综合多个来源的信息。
如果你的决策树只包含几条if-then-else语句，直接使用if-then-else节点即可。把智能体留给if-then-else变得难以管理的情况。
在实际工作中构建一次
n8n中的AI智能体是一种允许模型在已配置工具中作出选择的工作流。生产设计会约束这种选择，并让可问责的人与确定性政策掌控会产生后果的决定。
只有通过重复交付测试、无效输出测试、提供商超时测试、审批拒绝测试，并确认发送节点在无审批时不可达，这套设计才算完整。应在自己的实例上测量构建时间、延迟、纠正率与成本；本文不承诺设置时长或生产结果。
先用合成或经同意的非生产记录构建并测试。可以复用控制模式——用途明确且范围受限的工具、schema、幂等性、停止规则与审核关卡——但每个新工作流都要重新做领域和风险分析。
