2、n8n 高频节点总览

2、n8n 高频节点总览 2、n8n 高频节点总览 Modified September 28, 2025 3）使用建议（模式） • 主代理（AI Agent）＋多个 AI Agent Tool：主代理先规划再委派；必要时打开 Return intermediate steps 做可观测性。 • 严格输出：工具侧勾选 Require specific output format 并挂 Structured Output Parser，工具→Switch→后续工具/HTTP 更稳定。 (n8n Docs) 4）常见坑 • 在批处理场景忘记设置 Batch processing，导致速率异常； • 工具链路使用了多个子节点表达式，因“只解析首项”导致取值错位（用上游聚合/Set 统一后再传入）。 2、内置 AI 评估（Evaluation 节点 + Evaluations 视图） 1）用途 给 AI 工作流打分与回归测试：把每次输出写回数据集（Google Sheets），并记录指标（正确性、帮助性、字符串相似度、分类是否命中、是否使用了工具等）。适合模型对比、改 Prompt 前后评估和长期监控。(n8n Docs) 2）关键参数/操作 • Evaluation 节点 · Operations ◦ Set Outputs：把评估输出写回 Google Sheets 数据集（需 Google Sheets 凭证）； ◦ Set Metrics：记录评分指标到工作流的 Evaluations 标签页； ◦ Check If Evaluating：判断当前执行是不是“评估运行”，用于在评估时才计算昂贵指标。 • 可用指标（Set Metrics 内置） ◦ Correctness（AI）：1–5； ◦ Helpfulness（AI）：1–5； ◦ String Similarity：0–1； ◦ Categorization：0/1； ◦ Tools Used：0–1； ◦ Custom Metrics：自定义名称/数值（数字）。 3）使用建议（模式） • 在产出节点后串一个 Check If Evaluating →（Yes 分支）计算指标 → Set Metrics，避免生产执行时做多余计算与花费。 4）常见坑 • 忘配 Google Sheets 凭证与数据集映射，Set Outputs 不生效； • 指标值必须是数字，字符串会被拒。 3、Model Selector 节点（模型选择器） 1）用途 在一次执行里按规则动态选择一个已连接的 LLM。常见于：成本/可用性路由、A/B 对比、回退（超时/报错）时换模型。为子节点（sub node），与上游连接多个模型输入。 (n8n Docs) 2）关键参数（官方定义） • Number of Inputs：可接入的模型输入数量； • Rules：按顺序评估，命中即止，选择对应输入的模型。多个规则若都匹配，仅使用第一个匹配。 提醒：作为 sub node，其表达式解析同样受“只解析首项”规则影响。 3）使用建议（模式） • 性能/成本路由：优先 cheap&fast，若 latency 或 quality 不达标，再选更强模型； • 回退：与外层 IF / Evaluation 指标结合，失败或低分→重新走 Model Selector 选备选模型。 (n8n Docs) 4）常见坑 • 规则顺序写反，导致更昂贵模型被优先命中； • 以为能“多模型并发”——该节点是“二选一”路由，不是并行器。 4、Convert to sub workflow（转换为子工作流） 1）用途 把画布上一段“连续且结构合理”的节点，一键折叠为可复用子工作流；原位会被一个 Execute Sub workflow（或同等调用节点）替代，并自动带入必要的入参映射。 (n8n Docs) 2）操作步骤 • 框选要抽取的连续节点（不能含触发器，且最多只允许一个对外输入点和一个对外输出点）； • 右键画布 → Convert to sub workflow； • n8n 会在新标签页生成子工作流，并在原工作流放入调用节点与参数映射。 3）注意事项 • 类型约束需要你在子工作流的 Execute Sub workflow Trigger 与 Edit Fields (Set)（Return）里手动设定； • AI 子节点限制：涉及 AI 工具（sub nodes）时，请一并选上，可能需要复制和专用化共享节点； • 新子工作流默认采用 v1 执行顺序； • first() / last() / all() 这类访问器在转换后可能被改写为带后缀（ firstItem/ allItems），需回归测试。 4）常见坑 • 选择区间跨越了 IF/Merge 的多分支入/出条件（不满足“单入单出”规则）； • 忘了设输入/输出类型约束，导致后续映射混乱。 (n8n Docs) 5、与多代理/MCP/子工作流的组合思路 1）单画布多代理 主 AI Agent（Tools Agent） + 多个 AI Agent Tool（信息检索 / 表格操作 / 知识库问答 / 写作润色），通过描述+Prompt清晰划分边界，必要时为关键子代理启用 Fallback Model。(n8n Docs) 2）跨工作流团队化 把每个“专家代理”转换为子工作流（或用 Call n8n Workflow Tool 暴露为工具），主代理只负责调度与审核；评估时在末尾插入 Evaluation: Set Metrics，跑回归集观察长期质量。(n8n Docs) 3）模型与指标联动 前置 Model Selector 路由到不同模型；末尾 Evaluation 上报 Correctness/Helpfulness/String Similarity，在 Evaluations 页签里把不同模型跑分拉通比较，指导“成本 ↔ 质量”的取舍。(n8n Docs) 6、微型示例（片段型，便于你粘贴改造） 仅示意关键参数映射；导入前请先在你的实例里创建对应凭证与节点名称 1）Model Selector 规则片段 • 规则 1：当 {{$json.latency ms 3000}} → 走 Fast Model • 规则 2：当 {{$json.need coding === true}} → 走 Code Capable Model • 默认：General Model（无匹配则用默认输入 1） （规则顺序即优先级）(n8n Docs) n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs n8n Docs 3）使用建议（模式） • 主代理（AI Agent）＋多个 AI Agent Tool：主代理先规划再委派；必要时打开 Return intermediate steps 做可观测性。 • 严格输出：工具侧勾选 Require specific output format 并挂 Structured Output Parser，工具→Switch→后续工具/HTTP 更稳定。 (n8n Docs) n8n Docs 4）常见坑 • 在批处理场景忘记设置 Batch processing，导致速率异常； • 工具链路使用了多个子节点表达式，因“只解析首项”导致取值错位（用上游聚合/Set 统一后再传入）。 2、内置 AI 评估（Evaluation 节点 + Evaluations 视图） 1）用途 给 AI 工作流打分与回归测试：把每次输出写回数据集（Google Sheets），并记录指标（正确性、帮助性、字符串相似度、分类是否命中、是否使用了工具等）。适合模型对比、改 Prompt 前后评估和长期监控。(n8n Docs) n8n Docs 2）关键参数/操作 • Evaluation 节点 · Operations ◦ Set Outputs：把评估输出写回 Google Sheets 数据集（需 Google Sheets 凭证）； ◦ Set Metrics：记录评分指标到工作流的 Evaluations 标签页； ◦ Check If Evaluating：判断当前执行是不是“评估运行”，用于在评估时才计算昂贵指标。 ◦ Set Outputs：把评估输出写回 Google Sheets 数据集（需 Google Sheets 凭证）； ◦ Set Metrics：记录评分指标到工作流的 Evaluations 标签页； ◦ Check If Evaluating：判断当前执行是不是“评估运行”，用于在评估时才计算昂贵指标。 • 可用指标（Set Metrics 内置） ◦ Correctness（AI）：1–5； ◦ Helpfulness（AI）：1–5； ◦ String Similarity：0–1； ◦ Categorization：0/1； ◦ Tools Used：0–1； ◦ Custom Metrics：自定义名称/数值（数字）。 ◦ Correctness（AI）：1–5； ◦ Helpfulness（AI）：1–5； ◦ String Similarity：0–1； ◦ Categorization：0/1； ◦ Tools Used：0–1； ◦ Custom Metrics：自定义名称/数值（数字）。 3）使用建议（模式） • 在产出节点后串一个 Check If Evaluating →（Yes 分支）计算指标 → Set Metrics，避免生产执行时做多余计算与花费。 4）常见坑 • 忘配 Google Sheets 凭证与数据集映射，Set Outputs 不生效； • 指标值必须是数字，字符串会被拒。 3、Model Selector 节点（模型选择器） 1）用途 在一次执行里按规则动态选择一个已连接的 LLM。常见于：成本/可用性路由、A/B 对比、回退（超时/报错）时换模型。为子节点（sub node），与上游连接多个模型输入。 (n8n Docs) n8n Docs 2）关键参数（官方定义） • Number of Inputs：可接入的模型输入数量； • Rules：按顺序评估，命中即止，选择对应输入的模型。多个规则若都匹配，仅使用第一个匹配。 提醒：作为 sub node，其表达式解析同样受“只解析首项”规则影响。 提醒：作为 sub node，其表达式解析同样受“只解析首项”规则影响。 3）使用建议（模式） • 性能/成本路由：优先 cheap&fast，若 latency 或 quality 不达标，再选更强模型； • 回退：与外层 IF / Evaluation 指标结合，失败或低分→重新走 Model Selector 选备选模型。 (n8n Docs) n8n Docs 4）常见坑 • 规则顺序写反，导致更昂贵模型被优先命中； • 以为能“多模型并发”——该节点是“二选一”路由，不是并行器。 4、Convert to sub workflow（转换为子工作流） 1）用途 把画布上一段“连续且结构合理”的节点，一键折叠为可复用子工作流；原位会被一个 Execute Sub workflow（或同等调用节点）替代，并自动带入必要的入参映射。 (n8n Docs) n8n Docs 2）操作步骤 • 框选要抽取的连续节点（不能含触发器，且最多只允许一个对外输入点和一个对外输出点）； • 右键画布 → Convert to sub workflow； • n8n 会在新标签页生成子工作流，并在原工作流放入调用节点与参数映射。 3）注意事项 • 类型约束需要你在子工作流的 Execute Sub workflow Trigger 与 Edit Fields (Set)（Return）里手动设定； • AI 子节点限制：涉及 AI 工具（sub nodes）时，请一并选上，可能需要复制和专用化共享节点； • 新子工作流默认采用 v1 执行顺序； • first() / last() / all() 这类访问器在转换后可能被改写为带后缀（ firstItem/ allItems），需回归测试。 4）常见坑 • 选择区间跨越了 IF/Merge 的多分支入/出条件（不满足“单入单出”规则）； • 忘了设输入/输出类型约束，导致后续映射混乱。 (n8n Docs) n8n Docs 5、与多代理/MCP/子工作流的组合思路 1）单画布多代理 主 AI Agent（Tools Agent） + 多个 AI Agent Tool（信息检索 / 表格操作 / 知识库问答 / 写作润色），通过描述+Prompt清晰划分边界，必要时为关键子代理启用 Fallback Model。(n8n Docs) n8n Docs 2）跨工作流团队化 把每个“专家代理”转换为子工作流（或用 Call n8n Workflow Tool 暴露为工具），主代理只负责调度与审核；评估时在末尾插入 Evaluation: Set Metrics，跑回归集观察长期质量。(n8n Docs) n8n Docs 3）模型与指标联动 前置 Model Selector 路由到不同模型；末尾 Evaluation 上报 Correctness/Helpfulness/String Similarity，在 Evaluations 页签里把不同模型跑分拉通比较，指导“成本 ↔ 质量”的取舍。(n8n Docs) n8n Docs 6、微型示例（片段型，便于你粘贴改造） 仅示意关键参数映射；导入前请先在你的实例里创建对应凭证与节点名称 仅示意关键参数映射；导入前请先在你的实例里创建对应凭证与节点名称 1）Model Selector 规则片段 • 规则 1：当 {{$json.latency ms 3000}} → 走 Fast Model • 规则 2：当 {{$json.need coding === true}} → 走 Code Capable Model • 默认：General Model（无匹配则用默认输入 1） （规则顺序即优先级）(n8n Docs) n8n Docs 2）Evaluation 指标上报片段 • Set Metrics： ◦ Name=helpfulness，Value={{$json.scores.helpfulness}} ◦ Name=correctness，Value={{$json.scores.correctness}} ◦ Name=tool used，Value={{$json.tool used ? 1 : 0}} （确保数值类型；生产执行前用 Check If Evaluating 分支保护）(n8n Docs) n8n Docs ◦ Name=helpfulness，Value={{$json.scores.helpfulness}} ◦ Name=correctness，Value={{$json.scores.correctness}} ◦ Name=tool used，Value={{$json.tool used ? 1 : 0}} （确保数值类型；生产执行前用 Check If Evaluating 分支保护）(n8n Docs) n8n Docs 3）AI Agent Tool 最小配置 • Description：负责从内部索引检索与问题相关的三段证据，并返回 JSON {evidences:[...]} • Prompt：指令 + 输出 JSON 模式（必要时接 Structured Output Parser） • Options：Max Iterations=3，Return Intermediate Steps=ON（便于调试）(n8n Docs) n8n Docs 参考与延伸 • AI Agent / Tools Agent：节点与工具化范式说明。(n8n Docs) n8n Docs • AI Agent Tool：把代理作为工具接入，含参数与批处理选项。(n8n Docs) n8n Docs • Model Selector：按条件路由到不同模型，顺序匹配、命中即停。(n8n Docs) n8n Docs • Evaluations（总览 & 指标化评估 & Evaluation 节点）：两类评估、内置指标、Google Sheets 数据集、评估运行与回看。(n8n Docs) n8n Docs • Convert to Sub workflow：一键抽取、替换为调用子工作流节点、注意事项。(n8n Docs) n8n Docs 有了这四块“新砖”，你的 Coze × n8n 智能体就能更像“真实团队”：主管会分工（Model Selector + 主 Agent）、专家能接活（AI Agent Tool / 子工作流工具）、结果可量化（Evaluation），而且一切尽量留在同一画布，开发/排障/复用都更顺手。 有了这四块“新砖”，你的 Coze × n8n 智能体就能更像“真实团队”：主管会分工（Model Selector + 主 Agent）、专家能接活（AI Agent Tool / 子工作流工具）、结果可量化（Evaluation），而且一切尽量留在同一画布，开发/排障/复用都更顺手。 13）作业 自己按照sop部署n8n 搭建个人名片n8n工作流，最终发到打卡处。 n8n官网可能会有部分更新，最新的内容结合官方说明文档进行使用，链接：https://docs.n8n.io/ 在右上角进行搜索相关节点名称即可。 如果大家觉得看英文不够方便的话可以结合 谷歌浏览器插件 沉浸式翻译，链接：https://chromewebstore.google.com/detail/%E6%B2%89%E6%B5%B8%E5%BC%8F%E7%BF%BB%E8%AF%91 %E7%BD%91%E9%A1%B5%E7%BF%BB%E8%AF%91%E6%8F%92%E4%BB%B6 pdf%E7%BF%BB%E8%AF%91 %E5%85%8D%E8%B4%B9/bpoadfkcbjbfhfodiogcnhhhpibjhbnh?hl=zh CN&utm source=ext sidebar 把 n8n 当“数字工厂”：触发器是门铃、控制流是传送带切换、数据加工是工位、HTTP 是机械臂、消息节点是喇叭、存储是仓库。 目标：在专业完整的前提下，加一点点“类比幽默”，让每个新同学都能一眼懂、马上用。 把 n8n 当“数字工厂”：触发器是门铃、控制流是传送带切换、数据加工是工位、HTTP 是机械臂、消息节点是喇叭、存储是仓库。 目标：在专业完整的前提下，加一点点“类比幽默”，让每个新同学都能一眼懂、马上用。 1、触发类：Manual Trigger、Schedule Trigger、Interval Trigger、Webhook/Respond to Webhook、Error Trigger、Form Trigger、父工作流触发、聊天信息 类比：门铃 / 闹钟 / 值班电话 类比：门铃 / 闹钟 / 值班电话 2、控制流：IF、Switch、Merge、Split In Batches（Loop Over Items）、Wait、NoOp（占位） 类比：红绿灯 / 立交桥 / 汇合口 / 分餐出锅 / 等待区 / 标识牌 类比：红绿灯 / 立交桥 / 汇合口 / 分餐出锅 / 等待区 / 标识牌 3、数据加工：Set、Code（Run once/Per item）、Item Lists、Move Binary Data、Rename Keys/Keep Keys（等同类操作） 类比：白板便签 / 瑞士军刀 / 去重器 / 变形术 类比：白板便签 / 瑞士军刀 / 去重器 / 变形术 4、网络与 API：HTTP Request、Webhook（入站）、Respond to Webhook（出站响应） 类比：机械臂对外抓取与投递 类比：机械臂对外抓取与投递 5、文件与二进制：Read Binary File、Write Binary File、Move Binary Data 类比：原料入库 / 成品出库 / 形态转换 类比：原料入库 / 成品出库 / 形态转换 6、存储/知识库：Notion、Airtable、Google Sheets、MySQL/Postgres、S3（或本地持久化） 类比：货架与冷库（短存/长存） 类比：货架与冷库（短存/长存） 7、消息与通知：Feishu/Lark（HTTP Webhook）、企业微信（HTTP Webhook）、Slack、Telegram 类比：广播喇叭 & 送达回执 类比：广播喇叭 & 送达回执 1）触发类节点 1. Manual Trigger 1）用途：开发调试时手动启动。 2）关键参数：无。 3）示例： 2. Schedule Trigger 1）用途：按固定时间/频率运行（例：每天 09:00 拉取热点）。 2）关键参数：重复频率（分钟/小时/天/周）、具体时间点、时区（默认跟随 n8n 设置）。 3）示例：每天 09:00 运行；每 10 分钟运行一次。 详细操作方式：https://docs.n8n.io/integrations/builtin/core nodes/n8n nodes base.scheduletrigger/?utm source=n8n app&utm medium=node settings modal credential link&utm campaign=n8n nodes base.cron 4）常见坑： • 忘记时区，结果在服务器时区触发； 方法 1：改 n8n 全局时区（推荐） 如果是 Docker 部署，启动时加环境变量： 如果是本地安装，可以在 .n8n/config 或系统环境变量里加同样的设置。 方法 2：Cron 时间换算 保留默认 UTC 时区，但手动把触发时间换算成 UTC，比如要每天北京时间 9:00，就设成 UTC 1:00（冬令时）或 UTC 1:00（夏令时同）。 保留默认 UTC 时区，但手动把触发时间换算成 UTC，比如要每天北京时间 9:00，就设成 UTC 1:00（冬令时）或 UTC 1:00（夏令时同）。 • 与第三方 API 速率限制冲突（建议配合 Split In Batches + Wait）。 假设目标 API 限制 每秒最多 5 次请求： 用 Split In Batches → 每批 5 条数据（对应 5 个请求） 每批之间加一个 Wait 节点 → 延迟 1 秒 n8n 流程就会变成：5 条 → 等 1 秒 → 5 条 → 等 1 秒 这样就稳定在 每秒 5 次请求，永远不会超。 小贴士：长任务加“执行锁”避免重叠（启动先查锁→无锁创建→结束必删）。 📖 补充（了解即可） 这个“执行锁（execution lock）”其实就是给你的工作流加一把互斥锁，保证上一轮还在跑时，下一轮不要并发进来（避免重复抓取、重复入库、配额被打爆等）。下面把原理和三种落地方案讲清楚，并给出可直接放进 Code 节点的片段。 原理（一句话） 触发时先检查“锁”： • 如果有锁且未过期 → 本次退出（或排队）。 • 如果没有锁或已过期 → 创建锁并继续；结束时释放锁（不管成功还是失败）。 关键点： • 锁要对同一工作流唯一（可带 TTL 过期时间，防止异常终止后永远不解锁）。 • 成功/失败都要走到释放锁步骤（否则会“卡死”）。 方案 A：Workflow Static Data 锁（单实例最简单） 适用：单机/单容器 n8n；数据量小；不跨实例共享。 优点：零依赖；实现最简单。 限制：只在当前 n8n 实例内可见，多实例/集群不共享。 节点编排 Merge 节点用“Wait for Both”（等两路）模式把“正常路径”和“错误路径”汇合后统一释放锁。没有错误分支时也可以直接连到释放锁。 Code：加锁（Check & Acquire） 放在 Code/Function（Run once） 节点： IF：判断是否上锁 条件：{{$json.locked}} == true → 是则结束/回执“稍后再试”；否则进入业务链路。 Code：释放锁（Release） 放在链路末尾（确保总会被执行；关键节点勾“Continue On Fail”让流程能走到这里）： 补充（了解即可） 这个“执行锁（execution lock）”其实就是给你的工作流加一把互斥锁，保证上一轮还在跑时，下一轮不要并发进来（避免重复抓取、重复入库、配额被打爆等）。下面把原理和三种落地方案讲清楚，并给出可直接放进 Code 节点的片段。 原理（一句话） 触发时先检查“锁”： • 如果有锁且未过期 → 本次退出（或排队）。 • 如果没有锁或已过期 → 创建锁并继续；结束时释放锁（不管成功还是失败）。 关键点： • 锁要对同一工作流唯一（可带 TTL 过期时间，防止异常终止后永远不解锁）。 • 成功/失败都要走到释放锁步骤（否则会“卡死”）。 方案 A：Workflow Static Data 锁（单实例最简单） 适用：单机/单容器 n8n；数据量小；不跨实例共享。 优点：零依赖；实现最简单。 限制：只在当前 n8n 实例内可见，多实例/集群不共享。 适用：单机/单容器 n8n；数据量小；不跨实例共享。 优点：零依赖；实现最简单。 限制：只在当前 n8n 实例内可见，多实例/集群不共享。 节点编排 Merge 节点用“Wait for Both”（等两路）模式把“正常路径”和“错误路径”汇合后统一释放锁。没有错误分支时也可以直接连到释放锁。 Merge 节点用“Wait for Both”（等两路）模式把“正常路径”和“错误路径”汇合后统一释放锁。没有错误分支时也可以直接连到释放锁。 Code：加锁（Check & Acquire） 放在 Code/Function（Run once） 节点： IF：判断是否上锁 条件：{{$json.locked}} == true → 是则结束/回执“稍后再试”；否则进入业务链路。 Code：释放锁（Release） 放在链路末尾（确保总会被执行；关键节点勾“Continue On Fail”让流程能走到这里）： 失败场景兜底：再配一个 Error Trigger 工作流，在报错时尝试清锁（见“通用兜底”）。 失败场景兜底：再配一个 Error Trigger 工作流，在报错时尝试清锁（见“通用兜底”）。 方案 B：外部存储锁（多实例/可恢复推荐） 适用：多实例/集群，或你想要更可靠的锁。 思路：把锁存在 Redis / MySQL / Postgres。 优点：跨实例共享、断电可恢复、可观测。 做法（以 DB 为例）： 适用：多实例/集群，或你想要更可靠的锁。 思路：把锁存在 Redis / MySQL / Postgres。 优点：跨实例共享、断电可恢复、可观测。 做法（以 DB 为例）： 1. 建表（MySQL 举例）： 1. 获取锁（HTTP Request → DB，或 Code→HTTP/DB 节点）： ◦ 原子“插入或更新”： ◦ 再查： ◦ 如果 owner == :owner → 你抢到锁；否则被占用。 ◦ 原子“插入或更新”： ◦ 再查： ◦ 如果 owner == :owner → 你抢到锁；否则被占用。 2. 释放锁： Redis 可用 SET key value NX PX <ttl （原子加锁）+ DEL（需验证 value 匹配，避免误删）。 Redis 可用 SET key value NX PX <ttl （原子加锁）+ DEL（需验证 value 匹配，避免误删）。 方案 C：文件锁（单机可用） 适用：Docker 单机；/data 卷共享。 做法：用 Execute Command 节点在挂载卷 /data/locks 里 flock 或创建文件。 • 加锁：bash lc 'mkdir p /data/locks; lock=/data/locks/my.lock; if [ f "$lock" ]; then exit 9; else date +%s "$lock"; fi' • 释放：rm f /data/locks/my.lock • 结合 IF 检查退出码=9 判定“被锁”。 适用：Docker 单机；/data 卷共享。 做法：用 Execute Command 节点在挂载卷 /data/locks 里 flock 或创建文件。 • 加锁：bash lc 'mkdir p /data/locks; lock=/data/locks/my.lock; if [ f "$lock" ]; then exit 9; else date +%s "$lock"; fi' • 释放：rm f /data/locks/my.lock • 结合 IF 检查退出码=9 判定“被锁”。 优点简单，缺点：多实例时不共享（除非挂同一网络存储）。 通用兜底：失败也要解锁 • 关键业务节点尽量勾选 Continue On Fail，保证能走到释放锁。 • 另建一个 Error Trigger 工作流： ◦ 收到错误事件 → 检查对应工作流的锁 → 如果超时/持有者执行已结束 → 清理锁。 ◦ 收到错误事件 → 检查对应工作流的锁 → 如果超时/持有者执行已结束 → 清理锁。 • 锁一定要带 TTL，就算没走到释放步骤也会“自然过期”。 什么时候需要执行锁？ • Cron/Interval 还在跑上一轮，下一轮就触发了。 • 爬虫/入库等长链路任务（尤其调用外部 API 可能很慢）。 • 对外写操作必须幂等（例如下游不允许重复写）。 小结 • 思路：检查→占用→执行→释放（失败也释放/过期自动释放）。 • 单机最快：Workflow Static Data（方案 A）。 • 生产更稳：外部锁（方案 B：DB/Redis）。 • 别忘 TTL 和错误兜底，否则锁一旦“卡死”，就变成了你给自己设的早八门禁。 3. Webhook / Respond to Webhook 1）用途：被动接收外部请求（如 Coze 回调、Http请求），并返回即时响应。 2）关键参数：HTTP 方法（GET/POST）、路径、响应模式（立即返回 / 等最后节点）、安全（凭证/白名单）。 3）表达式示例：直接输入网址，或者从进入的 JSON 取字段 {{$json.text}}（或 {{$json.body?.text?.content}} 视来源而定）。 4）常见坑： • 测试 URL 与生产 URL 不同；发布后未切到 Production； （工作流要是active模式） • 未勾选“Response Data”或 Respond to Webhook 配置不当，客户端超时。 📖 超时根因 很多聊天/IM 平台或第三方回调端超时时间很短（常见 3–5s）。 如果 Webhook 节点用 Last Node（等全链路跑完再回）且链路里有 LLM/外部 API/爬取等慢步骤，对方在超时前收不到响应 → 判定失败/重发/掉消息。 三种响应模式对比（Webhook 的 Response Mode） On Received：Webhook 一接到请求就立即回，工作流继续执行。 Last Node：等最后一个节点跑完，返回它的输出（易超时）。 responseNode（推荐）：需要连接 Respond to Webhook 节点，在流程里任意位置手动决定何时、以什么内容响应；响应后流程可继续跑。 超时根因 很多聊天/IM 平台或第三方回调端超时时间很短（常见 3–5s）。 如果 Webhook 节点用 Last Node（等全链路跑完再回）且链路里有 LLM/外部 API/爬取等慢步骤，对方在超时前收不到响应 → 判定失败/重发/掉消息。 三种响应模式对比（Webhook 的 Response Mode） On Received：Webhook 一接到请求就立即回，工作流继续执行。 Last Node：等最后一个节点跑完，返回它的输出（易超时）。 responseNode（推荐）：需要连接 Respond to Webhook 节点，在流程里任意位置手动决定何时、以什么内容响应；响应后流程可继续跑。 推荐做法（IM 场景） Webhook（responseNode） → Respond to Webhook（立刻 200 回执“收到，处理中…”） → 后台继续：Set/Code/HTTP/LLM/入库/群发等。 这样先保住对方的超时窗口，再慢慢处理结果，必要时二次推送最终答案。 实战建议：IM 场景用 On Received，立刻接一个 Respond to Webhook 回复“收到，处理中…”，后台继续跑主流程。 实战建议：IM 场景用 On Received，立刻接一个 Respond to Webhook 回复“收到，处理中…”，后台继续跑主流程。 📖 Webhook 用 responseNode，结合 Respond to Webhook 在流程早期回 200 和 trace id，确保不超时。 trace id 用 Set 表达式生成：tr <时间戳16进制 <随机片段 ，全版本都认。 后台链路里你可以替换成实际：LLM（JSON Mode）→ Switch 工具路由 → Notion/DB 入库 → 飞书/企微二次推送。 Webhook 用 responseNode，结合 Respond to Webhook 在流程早期回 200 和 trace id，确保不超时。 trace id 用 Set 表达式生成：tr <时间戳16进制 <随机片段 ，全版本都认。 后台链路里你可以替换成实际：LLM（JSON Mode）→ Switch 工具路由 → Notion/DB 入库 → 飞书/企微二次推送。 4. Error Trigger（错误工作流） 1）用途：任一工作流报错时触发，集中告警、记录。 2）关键参数：无。 3）常见坑：忘启用 → 出错没人知道；建议推送到 Slack/飞书并附简要上下文。 5. MCP Trigger（把 n8n 变成可被 Agent 发现与调用的“工具服务器”） 1）用途 让 n8n 暴露一组“工具（tools）”，供外部 MCP 客户端（如 Claude Desktop 等）发现 → 列表 → 调用。 它不是普通触发器的直线输出，而是只连接 Tool 类节点（如 Custom Code Tool、Call n8n Workflow Tool、MCP Client Tool）来对外提供功能目录。 2）关键参数/概念 URLs：节点会给出 Test URL（测试时生效）与 Production URL（工作流激活后生效）。MCP 客户端要连其中一个。 Authentication：支持 Bearer/自定义 Header，强烈建议开启；客户端请求需携带同样的认证。 Tools：必须在触发器下方连接至少一个 Tool 节点，否则客户端只能看到空目录。常见： ◦ Custom Code Tool：自定义 JS 逻辑对外暴露； ◦ Call n8n Workflow Tool：把现有工作流封装为工具； ◦ MCP Client Tool：从 n8n 内部再去调用外部 MCP Server 的工具（级联）。 ◦ Custom Code Tool：自定义 JS 逻辑对外暴露； ◦ Call n8n Workflow Tool：