Dify 中级实验06变量聚合——如何确定性合并多路分支结果Dify 实验系列 · 中级 06/20 | 实验编号DIFY-102-07上篇Dify 中级实验05并行执行——如何让多路任务同时跑1. 实验目的掌握Variable Aggregator变量聚合节点——用确定性方式合并多路分支输出替代上一课的 LLM 合并。理解三种合并心智覆盖后到者赢、深合并对象递归合并、自定义代码节点兜底。适合场景多源数据拼装用户画像、配置合并、日志/结果收集——需要「精确、可预测、不烧 Token」的合并。2. 场景设计并行获取同一个用户的三种数据聚合后生成用户 360 报告分支 A 用户画像user.name/age/levelmetrics.login_count/last_active分支 B 订单数据user.total_orders/avg_order_valuemetrics.return_rate分支 C 客服交互user.ticket_count/satisfactionmetrics.avg_response_time。聚合后同一个user对象里应包含全部字段A/B/C 各自贡献一部分——这正是「深合并」的价值三个分支的数据结构同构、字段互补合并后零丢失。输入user_name可选默认张三输出用户 360 报告身份概览 / 行为画像 / 价值评估 / 服务建议。3. 节点拓扑开始user_name ├─ 用户画像数据Codeobject ├─ 订单数据Codeobject └─ 客服交互数据Codeobject ↓ 聚合多源数据variable-aggregatoroutput_type: string ↓ 生成用户 360 报告LLMmax_tokens 8000→ 结束4. 关键配置4.1 三个数据源分支Code每个分支输出一个 object字段刻意设计成同构互补# 分支 A用户画像defmain(user_name:str)-dict:name(user_nameor张三).strip()or张三return{profile_data:{user:{name:name,age:28,level:VIP},metrics:{login_count:45,last_active:2026-07-21},}}4.2 聚合节点核心聚合器把三个 object 合并成一个output_type: string时输出合并后的 JSON 文本-data:output_type:stringtitle:聚合多源数据type:variable-aggregatorvariables:--cd_profile# 注意variables 是 [[节点id, 字段], ...] 嵌套数组-profile_data--cd_orders-orders_data--cd_service-service_dataid:agg_merge⚠️ aggregator 的variables格式与 LLM 节点不同LLM 是[{value_selector, variable}]对象数组aggregator 是嵌套数组[[节点id, 字段], ...]别搞混。4.3 消费聚合结果的 LLM长报告输出把max_tokens提到 8000prompt 加「直接输出正文」约束DeepSeek 长输出被思考挤空 text 的坑model:completion_params:max_tokens:8000temperature:0.7mode:chatname:deepseek-v4-flashprompt_template:-id:p_reportrole:systemtext:|用户全景数据如下JSON 格式由用户画像/订单/客服交互三路数据源合并而来 {{#agg_merge.output#}} 请生成一份用户 360 报告包括 1. 用户身份概览 2. 行为画像 3. 价值评估 4. 服务建议 直接输出报告正文不要输出任何解释性文字。reasoning_format:separated5. 运行验证检查项预期实测合并后的 user 对象含 name/age/level/total_orders/avg_order_value/ticket_count/satisfaction 全部 7 字段与预期一致合并后的 metrics 对象login_count/last_active/return_rate/avg_response_time 全部保留与预期一致LLM 报告四段式身份概览/行为画像/价值评估/服务建议与预期一致对比实验把聚合策略换成「覆盖」再跑一次——后完成分支会覆盖先完成的同名字段user对象只剩最后一个分支的字段数据丢失。这一对比直观展示「深合并 vs 覆盖」的差异。6. 采坑点坑现象修复同名冲突字段被覆盖并行分支完成顺序不确定「后到者覆盖」不可预测设计阶段约定冲突策略字段互补本实验或代码节点自定义合并加后缀把聚合当数值累加期望 total_orders 相加实际是对象合并合并 ≠ 累加数值统计求和/均值必须走代码节点aggregator 的 variables 格式写错用 LLM 的[{value_selector, variable}]格式校验报错用嵌套数组[[节点id, 字段], ...]长报告输出 text 为空DeepSeek 把内容写进思考/解释部分max_tokens 被挤空max_tokens 提到 8000 prompt 明确「直接输出正文」校验脚本在 aggregator 上崩check_dsls.py 报AttributeError: list object has no attribute get脚本局限已修非 DSL 错误——aggregator 格式以本文为准 选型心法要「精确、可预测」→ variable-aggregator要「理解语义、自由组织」→ LLM 合并。两者不冲突聚合器负责结构JSON 全字段保留LLM 负责叙事把 JSON 讲成人话。7. 实验文档及源码获取实验文档完整操作步骤DIFY-07变量聚合——多路分支结果合并.md源码可直接导入dify102_07_多源数据合并器.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 中级实验07子工作流——如何把公共逻辑做成可复用积木 Dify 中级实验（06）：变量聚合——如何确定性合并多路分支结果？
Dify 中级实验06变量聚合——如何确定性合并多路分支结果Dify 实验系列 · 中级 06/20 | 实验编号DIFY-102-07上篇Dify 中级实验05并行执行——如何让多路任务同时跑1. 实验目的掌握Variable Aggregator变量聚合节点——用确定性方式合并多路分支输出替代上一课的 LLM 合并。理解三种合并心智覆盖后到者赢、深合并对象递归合并、自定义代码节点兜底。适合场景多源数据拼装用户画像、配置合并、日志/结果收集——需要「精确、可预测、不烧 Token」的合并。2. 场景设计并行获取同一个用户的三种数据聚合后生成用户 360 报告分支 A 用户画像user.name/age/levelmetrics.login_count/last_active分支 B 订单数据user.total_orders/avg_order_valuemetrics.return_rate分支 C 客服交互user.ticket_count/satisfactionmetrics.avg_response_time。聚合后同一个user对象里应包含全部字段A/B/C 各自贡献一部分——这正是「深合并」的价值三个分支的数据结构同构、字段互补合并后零丢失。输入user_name可选默认张三输出用户 360 报告身份概览 / 行为画像 / 价值评估 / 服务建议。3. 节点拓扑开始user_name ├─ 用户画像数据Codeobject ├─ 订单数据Codeobject └─ 客服交互数据Codeobject ↓ 聚合多源数据variable-aggregatoroutput_type: string ↓ 生成用户 360 报告LLMmax_tokens 8000→ 结束4. 关键配置4.1 三个数据源分支Code每个分支输出一个 object字段刻意设计成同构互补# 分支 A用户画像defmain(user_name:str)-dict:name(user_nameor张三).strip()or张三return{profile_data:{user:{name:name,age:28,level:VIP},metrics:{login_count:45,last_active:2026-07-21},}}4.2 聚合节点核心聚合器把三个 object 合并成一个output_type: string时输出合并后的 JSON 文本-data:output_type:stringtitle:聚合多源数据type:variable-aggregatorvariables:--cd_profile# 注意variables 是 [[节点id, 字段], ...] 嵌套数组-profile_data--cd_orders-orders_data--cd_service-service_dataid:agg_merge⚠️ aggregator 的variables格式与 LLM 节点不同LLM 是[{value_selector, variable}]对象数组aggregator 是嵌套数组[[节点id, 字段], ...]别搞混。4.3 消费聚合结果的 LLM长报告输出把max_tokens提到 8000prompt 加「直接输出正文」约束DeepSeek 长输出被思考挤空 text 的坑model:completion_params:max_tokens:8000temperature:0.7mode:chatname:deepseek-v4-flashprompt_template:-id:p_reportrole:systemtext:|用户全景数据如下JSON 格式由用户画像/订单/客服交互三路数据源合并而来 {{#agg_merge.output#}} 请生成一份用户 360 报告包括 1. 用户身份概览 2. 行为画像 3. 价值评估 4. 服务建议 直接输出报告正文不要输出任何解释性文字。reasoning_format:separated5. 运行验证检查项预期实测合并后的 user 对象含 name/age/level/total_orders/avg_order_value/ticket_count/satisfaction 全部 7 字段与预期一致合并后的 metrics 对象login_count/last_active/return_rate/avg_response_time 全部保留与预期一致LLM 报告四段式身份概览/行为画像/价值评估/服务建议与预期一致对比实验把聚合策略换成「覆盖」再跑一次——后完成分支会覆盖先完成的同名字段user对象只剩最后一个分支的字段数据丢失。这一对比直观展示「深合并 vs 覆盖」的差异。6. 采坑点坑现象修复同名冲突字段被覆盖并行分支完成顺序不确定「后到者覆盖」不可预测设计阶段约定冲突策略字段互补本实验或代码节点自定义合并加后缀把聚合当数值累加期望 total_orders 相加实际是对象合并合并 ≠ 累加数值统计求和/均值必须走代码节点aggregator 的 variables 格式写错用 LLM 的[{value_selector, variable}]格式校验报错用嵌套数组[[节点id, 字段], ...]长报告输出 text 为空DeepSeek 把内容写进思考/解释部分max_tokens 被挤空max_tokens 提到 8000 prompt 明确「直接输出正文」校验脚本在 aggregator 上崩check_dsls.py 报AttributeError: list object has no attribute get脚本局限已修非 DSL 错误——aggregator 格式以本文为准 选型心法要「精确、可预测」→ variable-aggregator要「理解语义、自由组织」→ LLM 合并。两者不冲突聚合器负责结构JSON 全字段保留LLM 负责叙事把 JSON 讲成人话。7. 实验文档及源码获取实验文档完整操作步骤DIFY-07变量聚合——多路分支结果合并.md源码可直接导入dify102_07_多源数据合并器.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 中级实验07子工作流——如何把公共逻辑做成可复用积木