n8n合并节点深度解析：智能体工作流中分支数据汇合的三种模式

1. 为什么合并节点才是智能体工作流里最容易被小看的角色先讲一件我自己身上发生的事。去年底我把一套客服自动化工单系统从“规则分支”改成 n8n 智能体驱动流程里放了好几个 AI Agent 节点分别处理意图识别、资料检索、风险提示。一开始我压根没考虑合并节点觉得 Agent 各自返回结果、后面直接用表达式引用就完了。结果一跑起来就发现下游节点永远只能拿到最后一条分支的数据或者两个分支的数据互相覆盖生成的结果时好时坏。排查了两天最后发现问题不在大模型、不在提示词而是所有分支都汇到一个节点时少了合并这一步。在 n8n 智能体开发里合并节点就是这样一个被严重低估的“汇合路口”。很多教程讲 Agent 节点的工具调用、讲提示词工程却很少把 Merge 节点拿出来单独讲透。但只要你做的工作流里有两个及以上并行分支最后想把结果凑在一起交给下一步处理合并节点基本就是绕不开的环节。它本身不调用模型、不碰外部 API看起来像个简单的“数据管道配件”可它决定了后续所有节点拿到的数据长什么样。绝大多数智能体工作流出问题不是模型没返回内容而是分支数据在你没想到的位置“断流”或者“互相踩踏”了。合并节点的适用场景也很直接两个 Agent 并行处理同一个任务的不同侧面然后汇总成一份完整上下文一个 Agent 调用多个工具工具返回结构不同需要归一化后再给下一个模型读取循环多轮生成内容要把每一轮结果堆叠起来做最终聚合。接下来我会从数据行为讲到实际配置再给出一套可以直接抄的双 Agent 调研工作流以及我踩过的一堆坑。1.1 智能体节点天然是“分叉容易、汇合困难”单个 Agent 节点的工作方式本质上是在同一批输入数据上执行一次决策然后可能调用多个工具产生多个输出分支。这些分支在 n8n 的可视化画布上看起来非常清爽——从 Agent 节点拖出几条线各自连到不同的处理节点——但设计者往往忽略了另一件事智能体的上下文往往需要“归一”。打个比方你让一个 Agent 负责查资料让另一个 Agent 负责做合规风险判断。单独看它们各自返回的内容都很完整一个是调研报告一个是风险提示列表。可如果你想让第三个 Agent 基于它们生成最终答复就必须把这两团数据重新放到同一条消息里。n8n 的节点执行是按数据流进行的下游节点默认只接收它的直接上游输入不会自动“看到”远处分支节点的输出。想在两个并行分支之后继续加工你就得用合并节点把它们再接回来。这也是为什么我常说画工作流的时候不要只关心“从哪分”还要先想好“在哪合”。分支做得再漂亮最后汇合点要是糊的整个工作流都不可信。1.2 Merge 节点和“写代码时合并对象”不是一回事很多有编程背景的人第一次用 Merge 节点会下意识把它想成代码里的Object.assign或者list.extend。结论是方向对了但细节完全不同。n8n 里节点处理的数据是 Items也就是 JSON 对象数组。Merge 节点做的是在数组层面上的合并而不是语言层面的同步。它不保证两个分支的执行先后顺序也不像 Promise.all 那样替你管理异步任务——它只按照你选择的模式把上游两个输入口传入的 items 重新组织成一份新的 items 数组。这个特点让它在智能体开发中特别好用因为 Agent 分支的耗时不可控Merge 节点在不同模式下恰好能处理“谁先到、谁后到、还是必须两个都到”的问题。还有一个容易被忽略的特性合并操作是确定性的。同一份输入数据只要配置不变多次执行得到的输出结构一定一致。对于要跑企业级部署的工作流来说这个确定性比什么都重要——排查日志、复现故障、写自动化测试都依赖它。2. Append、Combine、Wait三种模式背后是完全不同的数据行为在 n8n 画布上把两个节点的输出口连到同一个 Merge 节点之后你会在节点配置里看到三种模式Append追加、Combine合并、Wait等待。初次使用的人很容易直接选 Combine以为那就是“把数据拼在一起”的意思。实际上三种模式的数据行为差异很大选错了输出结构会完全变样。模式数据行为智能体开发中的典型场景Append两个输入口的 items 串成一个更大的数组把多个 Agent 的平行结果归档、批量入库Combine两个输入口的 items 按规则合成新的对象把调研结果、风险提示合并为同一个上下文对象Wait等待满足条件后才放行数据并行分支中某个 Agent 调用工具较慢需要对齐时机2.1 Append把数据一节一节接上去适合“归档”不适合“融合”Append 的行为最简单它不做任何字段级别的合并而是把输入 A 的 items 和输入 B 的 items 按顺序首尾拼接。比如 Agent A 返回了 3 条结果Agent B 返回了 2 条结果Append 之后输出的就是一个长度 5 的 items 数组其中前 3 条来自 A、后 2 条来自 B。这个模式的价值在于“保留原始结构”。如果你要把多个 Agent 的结果分别存进向量数据库、写入表格、或者送给下游做批处理Append 是安全的选择。它不会丢字段、不会覆盖字段只要下游能处理数组基本不会出错。但它不适合用来“捏合成一个上下文”。假如你想让最终回答 Agent 一次性看到“调研结论”和“风险提示”放在同一个上下文里Append 给你的仍然是一堆相互独立的记录模型得自己去翻哪条是调研、哪条是风险。数据多了之后这种结构既不直观也容易超出模型上下文窗口。还有一点要注意Append 的输出顺序取决于两个分支实际执行结束的时间先结束的先拼接。如果你依赖顺序就得在分支里额外加时间戳或序号字段后面想按顺序处理再做排序。2.2 Combine把两个分支的字段揉进同一个 JSON 对象Combine 模式下Merge 节点会把两个输入口的数据合并成一条或按索引对应成多条新的 JSON 对象。这是智能体开发里最常用的模式因为你可以让 Agent A 输出research_results让 Agent B 输出risk_level合并之后直接得到类似这样的对象{ user_issue: 客户上传文件时提示权限不足, research_result: 已定位到权限模型中的角色配置项可能与存储桶策略冲突相关, risk_level: 中风险建议优先验证存储桶策略 }这个对象就可以直接作为最终生成 Agent 的上下文输入不需要再做字符串拼接。这里有个关键经验两个分支的字段名一定要提前规划好尽量避免同名。Combine 虽然会合并字段但当两个输入拥有完全相同的键名时后到达的一方会覆盖先到达的一方而你很难快速看出是谁覆盖了谁。更稳妥的做法是在每个 Agent 的输出提示词里就明确指定唯一的输出结构比如一个要求输出research_result另一个要求输出risk_level让合并结果天然不冲突。Combine 模式还有个选项叫“当所有输入都有数据时”When both inputs have items默认一般有“两者都有”和“至少一侧有数据”这类选择。意思很直白是必须等两个分支都返回数据再合并还是任意一个分支返回了就先继续。选“两者都有”能保证合并对象完整但如果某个分支因为工具超时没有返回任何数据整个流程就会卡住或者报错。选“至少一侧有数据”则更宽容但后面引用缺失字段时就要做空值兜底。这个选项没有绝对正确答案完全取决于你对分支稳定性的判断。2.3 Wait不是合并数据而是把执行时机“对齐”Wait 模式不生产新的合并对象它更像是给流程装了一个“等一下”的闸门。它的典型用途是两个并行分支执行耗时差异很大你希望两边都跑完再继续下一步而不是让速度快的分支先冲进下游节点导致下游节点拿到一半数据就慌忙执行完毕。配置上你可以设置一个超时时间。如果两个分支在超时时间内都到达了Wait 节点正常放行如果其中一个迟迟没有到达超时到了之后它会根据你的设置决定是否继续。这个机制在 Agent 调用外部工具时很有用因为工具响应时长经常波动比如有的第三方 API 平时 200 毫秒返回高峰时却能拖到 40 秒。不加 Wait下游节点可能在第 3 秒就跑了导致结果里缺了一块加了 Wait至少给慢分支留出缓冲窗口。但我得提醒一句Wait 模式并不解决数据缺失它只解决时机错乱。如果分支最终就是没产出数据Wait 超时之后你还是要在下游做空值处理。别把 Wait 当成容错手段它只是把问题延后到了你能控制的位置。3. 双 Agent 调研再汇总一条可以照抄的合并路径说再多原理不如直接上一套能跑通的工作流。下面是我在项目里反复使用的一个模板两个 Agent 并行处理同一个问题一个负责“调研事实”一个负责“风险提示”最后用 Merge 节点合并成统一上下文交给第三个 Agent 做最终回复。整套流程在 n8n 画布上大约需要这些节点Start 节点接收用户问题Set 节点把用户问题标准化成一个字段Agent A调研 AgentAgent B风险 AgentMerge 节点Combine 模式Agent C最终生成 AgentHTTP Response / 输出节点拓扑结构很直观Set 节点之后分出两支分别进 Agent A 和 Agent B两支的出口都接到 Merge 节点Merge 的输出再进入 Agent C。3.1 分支前的准备输入统一与 credentials 配置很多工作流跑不通其实不是在合并阶段出错而是分支前的数据就没统一。上面这个模板里Set 节点的作用就是把用户传来的原始内容规整成同一个字段名比如issue。这样 Agent A 和 Agent B 拿到的是相同的输入格式后续输出结构也更容易保持一致。别小看这一层少了它Agent A 读到的可能是json.queryAgent B 读到的可能是json.user_message合并之后字段对齐就乱了。在跑任何智能体工作流之前还有一件不能省的事确认所有节点用到的 credentials 都已经在 n8n 里配置好。特别是 Agent 节点使用 OpenAI、Anthropic 或本地模型 API 时对应的 API Key 凭证缺失分支会直接报错合并节点连输入都等不到。工具类节点也一样比如 HTTP 请求节点要接第三方平台就得先在 Credentials 里配置对应的认证方式。我的习惯是凡是涉及外部 API 的高风险节点先单独跑一次用例确认凭据有效再把它接进完整工作流。否则你会在调试时看到非常奇怪的场景——明明 Merge 配置没问题却因为没有凭据导致某个分支输出空数组看起来特别像合并逻辑的锅。3.2 在 Merge 节点上做 Combine 的配置关键连接好输入输出后双击 Merge 节点按下面这样设置模式选 Combine合并模式选择“合并两个输入”当所有输入都有数据时选“两者都有”或“至少一侧有数据”。在这个模板里我通常选“两者都有”因为缺少任何一方的调研结果最终答复都会不完整如果你希望两个分支返回多条 items 时按顺序一一对应可以把合并方式设置为按索引合并配置完后可以先手动执行一次观察 Merge 节点的输出。如果 Agent A 返回的是{ research_result: ... }Agent B 返回的是{ risk_level: ... }Merge 的输出就应该是同时包含这两个字段的对象。如果你发现输出里只有其中一个字段大概率是另一个分支没有拿到输入或者分支节点把数据输出成了数组套数组需要在分支出口加一个 Set 节点做拍平。3.3 拿到合并结果后在 Prompt 里的引用方式合并完成之后进入 Agent C 的 Prompt 就可以用表达式引用合并后的字段了。假设 Workerflow 里 Merge 节点叫“合并调研与风险”那么在 Agent C 的 System Prompt 或 User Message 里可以这样写用户问题{{ $json.issue }} 调研结论{{ $json.research_result }} 风险提示{{ $json.risk_level }} 请基于以上信息给出最终处理建议。这里用的$json引用的是当前节点接收到的合并对象字段。如果你用的是老版本 n8n也可能会见到{{ $(合并调研与风险).item.json.research_result }}这种引用方式。两种都好用前者更简洁后者更适合跨节点引用。关键在于有了 Merge 节点你就不再需要手忙脚乱地挨个节点拼接字符串了所有字段都在同一个上下文对象里Agent C 的信息完整性要稳定得多。4. 智能体接入合并节点之后最容易踩的六个坑原理和示例都讲完了接下来这部分才是真正能帮你省时间的部分。以下六个坑我基本都实际踩过并且每个都花过不少时间排查。整理出来希望你能绕开。4.1 分支 B 完全没输出Combine 却继续了第一次踩这个坑是在一个双 Agent 合规审核工作流里。Agent A 正常返回审核意见Agent B 偶尔因为上下文太长返回空结果。我当时的 Merge 设置是 Combine “至少一侧有数据”结果流程继续跑了但最终输出里完全没有 Agent B 的意见。表面上看不出哪错了因为不报错模型也不会主动告诉你“少了一部分信息”。后来我强制把“当所有输入都有数据时”改成了“两者都有”同时在上游给 Agent B 加了一个失败兜底分支如果它超时或返回空就返回一条固定的“风险提示暂未得到有效信息”。这个兜底内容虽然不好看但至少保证了上下文完整最终 Agent 不会因为缺失信息而编造内容。从这里得到的教训是宁可让流程慢一点、或者显式提示数据缺失也不要让合并节点在静默状态下丢掉整块上下文。4.2 两个分支字段同名合并后互相覆盖这个坑在字段结构设计不当时非常隐蔽。比如两个 Agent 都被要求输出summary字段合并之后你发现summary只有其中一个的内容。因为 n8n 的 Combine 在合并两个对象时同名 key 会互相冲突默认处理方式往往是后者覆盖前者。你明明写了两个 Agent 的总结第二个 Agent 的总结却把第一个覆盖了看起来就像第一个 Agent 没执行一样。解决办法有两种要么在分支出口用 Set 节点把字段重命名比如把summary改成research_summary和risk_summary要么在各个 Agent 节点的输出配置里就写明“你的输出必须是 JSON 对象字段名为 xxx”。我现在更倾向于后者因为字段名从源头统一流经整个工作流时都不会乱。4.3 三个分支不能直接插同一个合并节点n8n 的 Merge 节点默认只有两个输入口。如果你画了三个并行分支想一股脑全塞进同一个 Merge 节点画布上根本连不上。我见过不少新手在这个地方卡住以为是 n8n 版本问题。解决办法是“串联合并”先把 A 和 B 合并成一个数组再把合并结果与 C 合并形成一个新的数据结构。注意第二级 Merge 的输入 B 拿到的是前一级合并后的对象如果你用的是 Append 模式二级合并会把“已经是一组 dataset”和“C 的结果”再拼成更大数组。所以三个分支以上时你要提前想清楚最终输出到底想要一个大的扁平数组还是一个嵌套结构。两种方式都能跑通但下游表达式的写法会完全不同。4.4 合并后的数据顺序不稳定影响输出质量Append 模式的输出顺序取决于分支完成顺序。如果两个分支并行执行先返回的先拼后返回的后拼。对某些场景来说顺序无所谓但对多轮投票、候选结果排序这类依赖顺序的任务这个问题会直接导致每次执行输出顺序不一致看起来像“随机”。排查时你甚至会在执行日志里看到两次输出顺序相反。我的建议是不要依赖合并顺序去表达业务优先级。如果先后顺序有意义在分支里加一个seq字段比如 0、1、2合并后再用排序节点按seq排序。这样可以获得完全不依赖执行时序的稳定输出。4.5 Wait 模式超时设置与实际处理时长不匹配Wait 节点默认超时时间如果设置得太短比如几秒在 Agent 调用外部工具时几乎一定会出问题。很多模型 API 单次请求就可能超过 10 秒工具链再一长整体耗时轻松超过 30 秒。设置 Wait 超时时要结合上游最慢节点的历史耗时来判断而不是拍脑袋填一个数字。我一般先在测试环境跑三次取最慢的那次耗时再加 50% 的余量。宁可多等也不要让节点在临界状态下强行继续因为一旦继续数据缺块的问题就会传导到下游所有节点。4.6 合并后大量 items 直接丢给 LLM上下文爆了这是把合并节点用得“太狠”导致的。Append 模式可以把几百条 items 一次性传给下游 Agent。如果下游节点是一个上下文窗口有限的模型这些 items 很可能超过 token 限制轻则直接报错重则模型只截取前面一部分输出质量崩坏。合并节点本身不关心数据量它只负责把数据整合好但消耗有多大得你来控制。常规做法是在 Merge 之后加一步聚合处理把同类型的多条 items 先用文本节点或代码节点压缩成摘要再进入模型。5. 把 Merge 放进循环和多轮场景更高级的聚合思路单次并行合并只是基础智能体开发里另一个高频场景是多轮生成与循环聚合。比如你要做一轮多个 Agent 交叉审阅或者让同一个 Agent 迭代生成多版草稿最后把每一版结果汇总起来投票或打分。这时候 Merge 节点可以和循环类节点配合承担一个不断“积累结果”的职责。以一次三版本生成任务为例循环节点控制生成次数每次迭代让生成 Agent 产出新版本然后 Merge 节点用 Append 模式把当前版本追加到已有结果数组里。循环结束时你会得到一个包含三轮输出结果的数组后续再用聚合节点计算平均分、选出最佳版本、或者统计各 Agent 的选择比例。实现上有一个细节要注意Append 模式本身是在每次执行时把输入 A 和输入 B 拼起来如果你在循环里希望结果持续累积必须让“上一轮合并后的输出”作为本轮的一个输入否则每轮都只会从零开始。我实际做过一个多 Agent 评审工作流每次循环让三个 Agent 各自打分用两个 Merge 节点把三个分数拼成一行再用变量节点保存轮次结果最后把多轮结果合并排序。这里 Merge 节点看似只是拼数据但它在多轮流程中起到了“保持状态形状”的作用——没有它每一轮结果都散落在不同节点里后续排序和汇总会难写到怀疑人生。在多轮场景里我更推荐把合并、聚合、排序拆成三步。合并负责“汇”聚合负责“减”排序负责“定序”。不要试图用一个节点完成所有事。n8n 单节点职责划分得越细出问题时越容易定位。企业级部署尤其如此工作流一旦进入多人维护阶段节点职责清晰比节省几个节点更宝贵。6. 关于合并节点的调试习惯这些小设置能省很多排查时间最后聊几个我长期养成的使用习惯它们和 Merge 节点的功能其实关系不大但价值很高。第一一定给 Merge 节点起一个能看懂的名字不要叫“Merge 1”“Merge 2”。我的习惯是“合并A/B调研结果”“循环轮次聚合”这种带业务语义的名称。执行日志里节点名是你第一眼看到的线索。名字起得清楚排查速度能快一倍。特别是企业级部署后一个工作流可能有几百个节点没人愿意逐个点开看节点内容去猜它是干嘛的。第二在分支里给数据打标签。比如两个 Agent 本来就是不同的职责在各自出口用 Set 节点加一个source: research或者source: risk字段。合并之后哪怕中间被人改动过你也能从字段值快速判断数据来源。这个习惯在多人协作时尤其有用因为别人改工作流时不一定知道你原来是怎么设计字段的。第三合并节点最好在搭建工作流的早期就占好位。先放一个 Merge 节点在预期汇合点后续再加并行分支时把新分支的输出口接上去就行。要是等跑通了再临时插节点你往往得重连后面所有节点非常浪费时间。我自己现在搭任何有两个以上分支的工作流第一件事不是画分支而是先把“汇合点”找出来放一个 Merge 节点。回到最开始的那个问题为什么合并节点在智能体开发里这么重要因为它决定了智能体的“眼界”。每个 Agent 都只能看到自己分支里的数据而最终做决策、做输出、做记忆更新的 Agent恰恰需要看到全部上下文。合并节点就是那个把所有分支视野拼在一起的枢纽。把它的几种模式、字段冲突、时序问题理解透你的智能体工作流会稳定不止一个档次。