上一篇文章里我们讨论了 Edge 和 Conditional Edge。一个重要结论是Edge 让流程可以分支也可以回到前面的节点。但一旦流程变复杂就会遇到另一个问题多个节点如何安全更新同一份 State这就是 Reducer 要解决的事。很多人第一次接触 LangGraph 时会把 Reducer 看成一个不太重要的细节。实际上它非常关键。因为它决定了状态更新是覆盖、追加还是按规则合并。State 更新为什么需要规则最简单的状态更新看起来像这样旧值 新值 新状态但真实流程里情况没有这么简单。比如一个节点追加消息 一个节点更新检索结果 一个节点记录工具调用 一个节点补充人工审核意见如果这些更新都写到同一个 State系统必须知道哪些字段该覆盖 哪些字段该追加 哪些字段该合并 哪些字段不该丢失没有这个规则状态就会乱。Reducer 的作用是什么Reducer 的作用就是定义 State 某个字段的合并方式。简单说当新更新到来时如何和旧状态合并如果没有 reducer很多字段默认可能是覆盖。但在 Agent Workflow 里覆盖并不总是你想要的。比如消息列表通常应该追加而不是覆盖。而某些标量字段比如task_status retry_count need_human_review则可能更适合覆盖或替换。所以不同字段需要不同更新策略。追加型字段和覆盖型字段可以先把 State 字段分成两类。第一类是追加型字段。比如messages logs tool_calls retrieval_candidates notes这些字段通常需要保留历史。第二类是覆盖型字段。比如current_step task_status need_human_review final_answer retry_count这些字段更像当前值。Reducer 的价值就是让这两类字段都能按正确方式更新。为什么消息列表最常见LangGraph 里最常见的 reducer 场景就是消息列表。比如一个对话 Agent每次模型输出都要追加到消息历史里。如果没有合适的合并规则后面的节点只会看到最后一条消息。那系统就失去上下文了。所以消息类字段通常需要“追加”语义。这也是为什么很多 Agent 应用都非常重视 history、messages 或 events 这类字段。它们不是一次性输入而是持续积累的过程。并行更新时Reducer 更重要Reducer 最关键的场景往往出现在并行或多来源更新。比如一个节点返回检索结果 另一个节点返回工具结果 还有一个节点返回人工补充信息这些更新可能都要写回同一个 State。这时候就必须清楚是追加 是合并 还是后者覆盖前者如果规则不明确结果就不可预测。Reducer 让这种合并变得确定。Reducer 让 State 更稳定很多 Agent 出问题不是因为模型不行而是状态被更新乱了。比如检索结果被覆盖 消息历史被截断 工具结果被误删 中间步骤没留下痕迹有了合并规则系统会更稳定。因为每个字段都知道自己应该怎么更新。这对复杂图尤其重要。Reducer 不等于随便拼接一个常见误区是认为 reducer 就是简单把内容拼起来。不是。Reducer 的核心不是“拼”而是“按规则合并”。有些字段适合追加。有些字段适合取最新值。有些字段适合做去重。有些字段适合保留最大值或最可信值。不同字段的语义不同合并策略也不同。如果把所有东西都当成字符串拼接State 很快会变脏。一个简单例子假设有一个字段叫messages。每次节点输出一条消息应该追加到列表里。而如果有一个字段叫attempt_count每次重试应该加一。再比如final_answer通常只在最后写入一次。这三种字段明显不该用同一种更新逻辑。Reducer 的意义就是把这种差异化更新表达出来。Reducer 和可观测性有关Reducer 不只是状态合并问题。它也关系到排查问题。因为如果状态字段被覆盖或丢失你会很难知道是哪一步改掉了什么。如果 reducer 规则清楚后面你就能更容易复盘哪个节点更新了什么 哪个字段被追加 哪个字段被覆盖 哪个状态是最终生效的这会显著降低调试成本。Reducer 设计要和 State 一起做Reducer 不是事后补丁。它应该和 State 设计一起完成。当你设计一个字段时就应该想清楚这个字段是追加型还是覆盖型 多个节点会不会同时写它 如果会应该怎么合并 这个字段要不要保留历史如果这些问题一开始没想清楚后面很容易返工。常见误区第一个误区是以为 reducer 不重要。其实它是 State 正确更新的核心。第二个误区是所有字段都用同一种更新方式。不同字段语义不同规则也应不同。第三个误区是只考虑单节点写入不考虑并行或回边。流程一复杂状态冲突就很常见。第四个误区是 reducer 规则不透明。看不懂规则图就难维护。第五个误区是把 reducer 当成字符串拼接器。它应该是状态合并规则而不是简单连字符。总结Reducer 的作用是定义多个节点更新 State 时的合并规则。它让消息可以追加 日志可以保留 结果可以覆盖 计数可以累加一个复杂 Agent 图如果没有合适的 reducer状态很容易乱。而状态一乱路由判断、调试和恢复都会变得很困难。所以 LangGraph 里State 不只是字段集合Reducer 也不是小细节。它们一起决定了图的稳定性。下一篇文章可以继续讨论 Tool Node。因为 Agent 真正变得有用很大一部分来自工具调用。
上一篇文章里我们讨论了 Edge 和 Conditional Edge。一个重要结论是Edge 让流程可以分支也可以回到前面的节点。但一旦流程变复杂就会遇到另一个问题多个节点如何安全更新同一份 State这就是 Reducer 要解决的事。很多人第一次接触 LangGraph 时会把 Reducer 看成一个不太重要的细节。实际上它非常关键。因为它决定了状态更新是覆盖、追加还是按规则合并。State 更新为什么需要规则最简单的状态更新看起来像这样旧值 新值 新状态但真实流程里情况没有这么简单。比如一个节点追加消息 一个节点更新检索结果 一个节点记录工具调用 一个节点补充人工审核意见如果这些更新都写到同一个 State系统必须知道哪些字段该覆盖 哪些字段该追加 哪些字段该合并 哪些字段不该丢失没有这个规则状态就会乱。Reducer 的作用是什么Reducer 的作用就是定义 State 某个字段的合并方式。简单说当新更新到来时如何和旧状态合并如果没有 reducer很多字段默认可能是覆盖。但在 Agent Workflow 里覆盖并不总是你想要的。比如消息列表通常应该追加而不是覆盖。而某些标量字段比如task_status retry_count need_human_review则可能更适合覆盖或替换。所以不同字段需要不同更新策略。追加型字段和覆盖型字段可以先把 State 字段分成两类。第一类是追加型字段。比如messages logs tool_calls retrieval_candidates notes这些字段通常需要保留历史。第二类是覆盖型字段。比如current_step task_status need_human_review final_answer retry_count这些字段更像当前值。Reducer 的价值就是让这两类字段都能按正确方式更新。为什么消息列表最常见LangGraph 里最常见的 reducer 场景就是消息列表。比如一个对话 Agent每次模型输出都要追加到消息历史里。如果没有合适的合并规则后面的节点只会看到最后一条消息。那系统就失去上下文了。所以消息类字段通常需要“追加”语义。这也是为什么很多 Agent 应用都非常重视 history、messages 或 events 这类字段。它们不是一次性输入而是持续积累的过程。并行更新时Reducer 更重要Reducer 最关键的场景往往出现在并行或多来源更新。比如一个节点返回检索结果 另一个节点返回工具结果 还有一个节点返回人工补充信息这些更新可能都要写回同一个 State。这时候就必须清楚是追加 是合并 还是后者覆盖前者如果规则不明确结果就不可预测。Reducer 让这种合并变得确定。Reducer 让 State 更稳定很多 Agent 出问题不是因为模型不行而是状态被更新乱了。比如检索结果被覆盖 消息历史被截断 工具结果被误删 中间步骤没留下痕迹有了合并规则系统会更稳定。因为每个字段都知道自己应该怎么更新。这对复杂图尤其重要。Reducer 不等于随便拼接一个常见误区是认为 reducer 就是简单把内容拼起来。不是。Reducer 的核心不是“拼”而是“按规则合并”。有些字段适合追加。有些字段适合取最新值。有些字段适合做去重。有些字段适合保留最大值或最可信值。不同字段的语义不同合并策略也不同。如果把所有东西都当成字符串拼接State 很快会变脏。一个简单例子假设有一个字段叫messages。每次节点输出一条消息应该追加到列表里。而如果有一个字段叫attempt_count每次重试应该加一。再比如final_answer通常只在最后写入一次。这三种字段明显不该用同一种更新逻辑。Reducer 的意义就是把这种差异化更新表达出来。Reducer 和可观测性有关Reducer 不只是状态合并问题。它也关系到排查问题。因为如果状态字段被覆盖或丢失你会很难知道是哪一步改掉了什么。如果 reducer 规则清楚后面你就能更容易复盘哪个节点更新了什么 哪个字段被追加 哪个字段被覆盖 哪个状态是最终生效的这会显著降低调试成本。Reducer 设计要和 State 一起做Reducer 不是事后补丁。它应该和 State 设计一起完成。当你设计一个字段时就应该想清楚这个字段是追加型还是覆盖型 多个节点会不会同时写它 如果会应该怎么合并 这个字段要不要保留历史如果这些问题一开始没想清楚后面很容易返工。常见误区第一个误区是以为 reducer 不重要。其实它是 State 正确更新的核心。第二个误区是所有字段都用同一种更新方式。不同字段语义不同规则也应不同。第三个误区是只考虑单节点写入不考虑并行或回边。流程一复杂状态冲突就很常见。第四个误区是 reducer 规则不透明。看不懂规则图就难维护。第五个误区是把 reducer 当成字符串拼接器。它应该是状态合并规则而不是简单连字符。总结Reducer 的作用是定义多个节点更新 State 时的合并规则。它让消息可以追加 日志可以保留 结果可以覆盖 计数可以累加一个复杂 Agent 图如果没有合适的 reducer状态很容易乱。而状态一乱路由判断、调试和恢复都会变得很困难。所以 LangGraph 里State 不只是字段集合Reducer 也不是小细节。它们一起决定了图的稳定性。下一篇文章可以继续讨论 Tool Node。因为 Agent 真正变得有用很大一部分来自工具调用。
