一文全面解读LangGraph中Reducer的概念作用与原理使用详解

前情回顾：LangGraph 入门要点速览

1. LangGraph 基础入门与核心概念全解析

Reducer（归约器），本质上就是一个函数，专门解决一个核心难题：当多个节点都想修改 State 中的同一个字段时，究竟该如何合并才算公平合理？

说得更通俗一点：Reducer 决定了 State 中某个字段的更新策略——是简单粗暴地直接覆盖？还是规规矩矩地追加到末尾？或者累加到一起？甚至可以完全自定义一套规则。

从实际问题出发，深入理解 LangGraph Reducer

核心矛盾：多个节点同时写入同一个字段

在 LangGraph 的架构中，多个节点按顺序依次执行，每个节点都可能顺手修改一下 State。这就引出了一个经典矛盾：

假设有两个答案摆在你面前：

1. 2（后一个节点把前一个彻底覆盖掉）—— 这是 LangGraph 默认的处理方式
2. 3（1 + 2 累加起来，谁也别想抹掉谁）—— 这是使用 Reducer 之后的结果

Reducer 就是那个帮你做出明智选择的关键工具。

默认行为 vs Reducer 行为：对比分析

默认行为：覆盖（Override）

如果不指定 Reducer，LangGraph 的默认机制非常霸道：后来者居上，后写入的值直接覆盖前者。

class MyState(TypedDict):counter: int# 没有 Reducername: str # 没有 Reducer

执行流程示意如下：

初始状态：counter = 0节点 A 返回：{"counter": 1}→ 状态变为：counter = 1节点 B 返回：{"counter": 2}→ 状态变为：counter = 2（节点 A 的贡献直接被抹掉）最终结果：counter = 2

这种默认模式适合什么场景？就是那些只需要最终值的场合，比如用户名、当前状态标志等，谁最后写入就用谁的，没问题。

Reducer 行为：合并（Merge）

一旦指定了 Reducer，整个处理逻辑就变了：

class MyState(TypedDict):counter: Annotated[int, operator.add] # 使用加法 Reducer

执行流程变成了这样：

初始状态：counter = 0节点 A 返回：{"counter": 1}→ 状态变为：counter = 1节点 B 返回：{"counter": 2}→ 状态变为：counter = 3（1 + 2 = 3，把前面的贡献累加上了！）最终结果：counter = 3

这种模式适合需要累积的场景，比如计数器、总分、消息列表——每个节点的贡献都不可或缺。

Reducer 的本质：一个普普通通的函数

Reducer 其实没什么魔法，它就是 Python 里一个普通的函数，接收两个参数：

def reducer_func(current_value, new_value) -> final_value:"""current_value：当前 State 中该字段的值new_value：节点返回的该字段的新值return：合并后的最终值"""# 在这里定义你的合并逻辑return merged_result

LangGraph 已经内置了几个常用的 Reducer，直接拿来用很方便：

用生活实例彻底搞懂 Reducer 的用法

场景：记账本

你和室友共用一本账本，记录每天的开销。这个场景够熟悉吧？

没有 Reducer（覆盖模式）：

周一：小明记了"吃饭 50元" → 账本：[吃饭 50元]周二：小红记了"打车 30元" → 账本：[打车 30元]← 周一的内容被覆盖了！周三：你们吵架了，因为周一的账找不到了

有 Reducer（追加模式）：

周一：小明记了"吃饭 50元" → 账本：[吃饭 50元]周二：小红记了"打车 30元" → 账本：[吃饭 50元, 打车 30元]← 追加在后面周三：月底算账，清清楚楚

在这个例子中，add 就是一个 Reducer，它的规则很简单：新来的记录追加到旧记录的后面，而不是替换掉它。

为什么 LangGraph 需要 Reducer？

原因一：图并非线性执行

在 LangGraph 中，图可能存在分支和循环，路径不是一条直线那么简单：

┌→ 节点 B ─→┐START ─→┤├→ 节点 D └→ 节点 C ─→┘

节点 B 和节点 C 都可能修改同一个字段。如果没有 Reducer，后执行的节点会毫不留情地抹掉前一个节点的修改。有了 Reducer，两者的贡献就能共存，谁也不会被覆盖。

原因二：循环需要累积

节点 A → 条件判断 → 未满足 → 回到节点 A（循环）

在循环中，每次经过节点 A 都可能产生新数据。Reducer 确保这些数据是累积的，而不是每次循环都重置一遍，否则循环就失去了意义。

原因三：可预测的状态变化

Reducer 让状态变化变得透明且可预测。你清楚每个字段的更新规则是什么，不会出现“咦，这个值怎么不见了？”的困惑。

实战演练：自定义 Reducer

当内置 Reducer 不能满足需求时，自己动手写一个即可：

示例1：限制列表长度

def last_n_reducer(n: int):"""只保留最近 n 条记录"""def reducer(old: list, new: list) -> list:combined = old + newreturn combined[-n:]return reducerclass MyState(TypedDict):recent_logs: Annotated[List, last_n_reducer(10)]# 只保留最近10条

示例2：字典合并

def dict_merge(old: dict, new: dict) -> dict:"""合并两个字典，新值覆盖旧值"""merged = old.copy()merged.update(new)return mergedclass MyState(TypedDict):metadata: Annotated[Dict, dict_merge]# 字典合并

示例3：取最大值

def max_reducer(old: float, new: float) -> float:"""保留最大值"""return max(old, new)class MyState(TypedDict):max_score: Annotated[float, max_reducer]# 保留最高分

Reducer 的完整工作流程

为了让你彻底搞懂，这里把 LangGraph 内部处理 Reducer 的完整流程拆解开来：

1. 节点执行完毕，返回一个字典，比如 {"counter": 5}2. LangGraph 遍历这个字典的每个键值对3. 对于每个键（比如 "counter"）： a. 查找 State 定义中这个键有没有 Reducer b. 如果有 Reducer：- 获取当前 State 中 "counter" 的旧值（比如 3）- 调用 Reducer 函数：reducer(旧值=3, 新值=5)- 把 Reducer 的返回值（比如 8）写入 State c. 如果没有 Reducer：- 直接用新值（5）覆盖旧值（3）4. 更新后的 State 传递给下一个节点

面试级总结

一句话记住

现在你应该能理解，为什么 messages: Annotated[List, add_messages] 这么重要了吧？没有它，你的聊天 Agent 永远只能记住最后一句话。