1. 为什么智能体开发绕不开合并节点
做n8n智能体工作流的人，迟早会撞上一个问题：流程跑着跑着，好几条分支的数据怎么汇到一条路上？甚至两条分支都跑完了，后面那个节点却只拿到了其中一条的数据。这时候你就知道，合并节点不是“锦上添花”的复杂技巧，而是智能体流程设计里的基操。
用n8n搭过智能体的人都有这种体会：智能体最烦的不是“没有工具”，而是“工具太多、分支太乱”。一个稍微像样的智能体，通常会有意图识别、多知识库检索、工具调用、结果过滤这些环节。它们天然会拆成多条并行分支。比如用户问“最近三个月华东区的销售额和退单率都怎么样”，智能体至少要同时开两条路：一路查销售数据，一路查售后数据。你总不能让用户等两个流程跑完再自己拼答案——人在聊天框里等不了那么久。
合并节点做的事情，就是把多条分支的所有结果，按你指定的策略汇总成一条数据流，再交给后面的节点继续处理。
这玩意儿放到扣子、Dify、FastGPT这些平台上，有个类似但不太一样的对应逻辑。扣子那边你可能会用“并行节点+变量聚合”，Dify里则是“并行分支的汇聚节点”，n8n里的名字就叫Merge。相比那几个平台，n8n的合并节点更底层、更显式，所有字段和模式都摆在明面上，你控制得越细，越能构建出企业级可复用的稳定智能体工作流。这也是为什么很多人最后从低代码平台回流到n8n的原因——灵活性。
不过别急着高兴，Merge节点虽小，坑却一点不少。合并出来丢数据、字段错位、超时等待、分支卡死，这些我都踩过。这篇我不仅讲清楚核心逻辑，还要把几个高频翻车点掰开揉碎了说，附上可直接抄作业的配置方式。
2. 合并节点的核心逻辑：它凭什么能把多条分支拧成一股绳
2.1 先分清三种等待模式，不然你连关闭按钮都找不到
合并节点最核心的配置项，是“Values to Merge”也就是使用哪种合并方式。很多人一进节点设置页就懵了，控制项特别多。其实真正决定命运的只有两件事：等待多久和按什么规则合并。
等待多久，对应的是“Mode”里的两个选项：
- Wait for all Inputs：等到所有传入连接都至少给出一批数据，才统一合并。适合那些“缺一不可”的场景，比如要同时拿到销售数和售后数，才继续跑汇总分析。
- Wait for first Incoming：只要任何一个传入分支先出了结果，就立刻往下走，不等待其他分支。适合“谁快用谁”的场景，比如两个知识库都在检索，你只需要最快的那份答案。
我在实际项目里用Wait for all比较多，但做智能体问答延迟优化时，Wait for first非常香。因为n8n Community版跑多个串行分支有时候会拖到好几秒，如果业务能容忍“拿一部分结果先回话”，用Wait for first可以把用户等待时间压到一两秒内。
对接策略决定合并的精细程度。n8n里主要有三种：
- Append：把各路数据数组直接拼接成一个大数组。适合各路结果格式本来就一致，你只想汇总的场合。
- Combine：按字段名对齐合并，能做类似数据库JOIN的操作。
- Multiplex：把多个输入当成一组一组的信息，按顺序组成一个容纳多组数据的结构。
新手最常见的错误，是把“Append”当万能选项。Append看起来只是把数组拼起来，但如果上游数据不是数组，而是一个一个的单项JSON，后面节点的循环逻辑很容易翻车。所以我做智能体项目时，习惯在合并节点前后都要加一个“JSON处理”之类的节点，手动确认数据形态。
2.2 合并字段时的“踩坑”集中地：数据形状不对齐
你问十个n8n用户合并节点的坑，九个都会提到数据形状对齐。n8n里每个节点接收到的输入都自带一个结构上下文。你以为两条分支输出的都是“text”字段，结果实际跑起来，一条长这样：
{"text": "华东区销售额总共xxx万元", "source": "sales_system"}另一条是：
{"data": {"reply": "退单率2.1%"}, "meta": {"status": "ok"}}合并时完全不认识对方。这问题尤其常出现在你改过上游节点的“字段重命名”，但下游忘了同步的情况。智能体开发里，因为上游往往挂着大模型节点，大模型的输出字段名字每次微调prompt都可能变，所以字段漂移是常态。
我的习惯做法是：任何分支在进入合并节点之前，先过一个“Edit Fields（修改字段）”节点，把最终要合并的关键字段统一成固定命名。比如所有分支都统一输出成{ "role": "assistant", "content": "..." }这个标准格式。这样不管上游用了什么野字段名，合并进来的都是干干净净的结构，后续接什么节点都不会再被结构问题绊住脚。
3. 智能体场景里合并节点怎么搭？几套可直接抄的配置方案
合并节点在智能体应用里的使用场景非常典型，我把自己做过的几个实用配置方案拆给你看。这些不是从文档里抄来的概念，是我在实际项目里跑通后沉淀下来的。
3.1 方案一：多知识库检索结果汇总
这是智能体标配场景。用户提问后，触发两条分支，分别检索销售数据库和客户反馈库，最后汇总成一份回答参考。
节点结构大致如下：
- 入口节点：接收用户消息
- Switch节点：按消息意图分流（如“查销售”走A，“查反馈”走B）
- 两个知识库检索节点（或HTTP请求节点）
- 合并节点
- LLM节点（负责把合并后的知识生成最终回答）
这里合并节点建议这样配：
- Mode选“Wait for all Inputs”
- 合并策略选“Append”
- 把两个分支输出字段名统一改成
search_result
配置方法：在合并节点之前的每个分支上，都放一个Edit Fields节点，分别把各自的检索结果映射成search_result字段。合并节点输出后，你得到的就是一个包含两条检索结果的数组，后面接LLM节点时用{{ $json.search_result }}引用就好。
这套方案的好处是稳定。你后续想增加第三个知识库，只需要再加一条分支，前面多配一次统一字段名就行，合并节点完全不用动。
3.2 方案二：多工具并行调用之后的结果拼接
智能体场景里经常需要同时调好几个工具。比如查天气、查机票、查酒店，三件事一起发出去，最后拼成一段完整的旅行建议。这时候如果三个工具的返回结构完全不一样，用Combine去强行对齐字段反而麻烦，用Append更省事。
工具返回的JSON五花八门，每个工具节点输出字段都不一样。我的做法是在每个工具节点后面加一个“Code”节点，写一个简单的JavaScript脚本，把响应统一包装成：
return { "tool_name": "weather", "tool_result": $input.first().json, "timestamp": new Date().toISOString() };三条分支出来的都是这个结构，合并节点无论用Append还是Combine，后面的LLM节点都能很好理解。
这里有个小细节。n8n里Code节点直接处理“$input”可能是旧版API的写法。新版（1.x之后）建议用$input.first().json或循环里直接操作item，避免用旧式$input让你在后续升级模板时出问题。
3.3 方案三：反射式“自我反思”循环
智能体进阶玩家一定会碰到的场景：让大模型先生成一个初版回答，再由第二个模型审核，不通过就回炉重造。这种“反射”在工作流里的实现方式，就是靠合并节点兜底。
核心结构：
- 生成节点：产出初版回答
- 审核节点：给答案打分并决定“pass/fail”
- 路由节点：fail 则回到生成节点前，pass 则走到合并节点
- 合并节点：汇集历史生成结果和最终审核结果
这条链路里，合并节点的作用是把“历史生成版本”和“最终版本”拼在一起，方便最终输出节点里既能展示最终结果，也能保留迭代痕迹。很多智能体面试题里问“你做过反射式agent吗”，背后就是这个逻辑。n8n里实现它并不需要写多复杂的代码，重点是合并策略和循环控制。
4. 4个合并节点的高频排障实战
4.1 数据没合并，只拿到一条分支的结果
这是n8n的“标志性”踩坑点。跑到合并节点，你发现输出数据里只有A分支的数据，B分支的完全消失了。排查思路很简单，先在合并节点上方加一个“Debug”节点，逐个查看传入的数据。通常原因就两个：
- 一个分支出错了，错误被n8n捕获为“error item”，合并节点默认忽略error item。解决办法是检查上游分支有没有报错。
- 分支没执行完，超时了，合并节点已经等不了了，按已有数据先走了。方案是调整执行超时时间，或者检查那条分支里有没有卡在等待外部API响应的地方。
4.2 合并之后字段全乱套
之前说过，根源就是字段名不统一。解决办法是在每条分支统一接入一个Edit Fields节点。格式强迫症一点，把字段名写死，比如content、score、status，这比你在后面LLM节点里做一堆兼容判断要省心得多。
4.3 轮询模式下的合并超时
当合并节点前面挂的是Webhook或Sleep节点，你要小心等待时间配置。n8n的合并节点有一个“Timeout”相关设置，如果分支持续超过预设时间没有数据，它会按已收集部分合并，这样可能导致内容不完整。如果是关键数据合并，最好在设计上游节点时，给每个分支都加一个兜底超时，确保最慢的分支也能在合并超时前完成。
4.4 遇到二进制文件合并需求
这一点很多教程不会讲。智能体如果处理的是图片识别或PDF解析场景，合并节点处理的就不再是单纯的JSON，而是二进制数据加附件的组合。n8n的合并节点在遇到二进制文件时，不会自动帮你拼attachment，得自己用Code节点处理，把二进制数组手动合并后再输出。
items.forEach(item => { binaryData.push(item.binary); });如果你发现合并后的输出“有数据没文件”，大概率就是忘了处理binary这块。别指望官方帮你把二进制融合处理了，想省事就直接在上游查文件和元数据先打包成自定义对象。
5. 合并节点设计时的全局思考：建企业级智能体该琢磨的三件事
合并不是一个节点的事，它是一种架构意识。
第一，合并节点的位置必须放在“数据规范化”之后。所有分支在上合并之前，都要保证字段名、数据格式、甚至时区格式一致。企业级智能体对错数据零容忍，与其在合并节点里勉强处理不规范数据，不如在源头就掐死。
第二，合并策略要与下游消费方式匹配。下游是LLM生成提示词？那你用Append拼接的数组式结构最顺手。下游是数据库写入？那你可能需要Combine按主键对齐来形成行结构。你先想清楚“合并之后谁来用”，再决定合并策略，效率会高出很多。
第三，要考虑观测性。合并节点前后一定要留日志或调试节点。我自己的习惯是在合并节点前加一个“Debug”节点，专门记录各分支数据是否到达；合并后再接一个“Log”节点，记录合并结果数量。这样生产环境出了数据缺失问题，排障五分钟就能找到根因，不用翻半天执行历史。
这些习惯看似笨拙，但对比扣子、Dify这些平台里“黑盒式”的自动汇聚处理，n8n这套显式控制反而更适合长期维护的项目。因为你看到每一个处理细节，知道哪些发生了变化，也知道为什么变了。
6. 我的最后建议：先从小流程感受合并节点的“顺滑感”
很多人学n8n合并节点，喜欢一上来就搭复杂流程，然后被各种配置折腾到心态崩溃。我给的建议是，先做一个最小规模的流程：
- 两个Webhook入口节点，各自生成一组数据
- 一个合并节点，设为Wait for all + Append
- 一个输出节点，打印合并后的完整数据
跑通之后，你再去思考：如果我要让其中一个入口的数据里包含另外一组数据的统计信息，我要怎么改合并策略？改成Combine之后字段怎么对齐？什么时候会用到Multiplex？
这样的练习过程会让你慢慢建立对数据流的直觉，然后你再回去做智能体项目，就会发现什么“多工具并行调用”“多知识库汇总”“模型自反馈”都只是合并节点在不同业务下的应用表现而已。
我的个人经验里，最能体现合并节点价值的，是它逼迫你想清楚：哪些数据必须等，哪些数据可以不等；哪些字段必须在合并且前保证一致，哪些字段可以后面再重新映射。这份想清楚的功夫，才是智能体开发里比任何平台技巧都重要的能力。
n8n的门槛不在节点多，而在于琐碎控制点多。它在智能体领域不像扣子和Dify那样“一打开就懂”，但一旦你理解了它的数据流模型，就不会想回去用那种“集成好了但改不动细节”的平台了。合并节点，就是这条理解路径上最好的第一课。
