LangGraph 节点间的数据传递主要采用四种核心模式：状态传递、参数传递、上下文传递和缓存传递。下面是这四种模式的详细对比和关键区别。
四种核心数据传递模式对比
| 模式类型 | 核心原理 | 常见使用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 1. 状态传递 (Stateful) | 各节点读写共享的全局状态字典，这是官方推荐的设计模式。 | 多节点间需要共享大量数据，如对话历史、用户信息、多轮RAG结果等。 | 数据同步性好 ：任意节点都可访问最新状态； 生命周期长：数据存活整个图的生命周期。 | 全局可访问，需谨慎设计以避免并发写入冲突；需要明确定义 schema。 |
| 2. 参数传递 (Parameterized) | 通过函数参数在调用下一节点时直接传入数据，类似于函数调用传参。 | 传递即用即抛的局部数据，且接收节点是确定的。 | 简单直接 ，无需定义全局schema； 职责单一，数据作用域清晰。 | 扩展性差 ：无法在分支中自动传递； 数据随调用结束而销毁，无法跨步访问。 |
| 3. 上下文传递 (Contextual) | 利用 RunnableConfig 对象在图的整个运行期间传递配置信息。 |
传递只读的元数据，如线程ID、用户权限、API密钥等。 | 安全隔离，配置参数与业务状态分离，避免被意外修改。 | 仅读，节点无法通过此方式将结果返回给调用者。 |
| 4. 缓存传递 (Cache-based) | 节点执行前检查外部缓存，或在节点内将计算结果存入缓存供后续调用。 | 重复的高成本操作，如相同问题的LLM调用、昂贵的知识库查询（RAG）等。 | 大幅降低成本 ，避免重复计算； 显著提升响应速度。 | 引入外部依赖（如Redis）；需设计合理的缓存失效策略。 |
核心区别与适用边界
这四种模式并非相互排斥，选择的关键取决于数据的生命周期和用途：
-
状态传递：管理需要在多个节点间流转的核心业务数据。
-
参数传递：处理仅在两个特定节点间传递的局部临时数据。
-
上下文传递：携带贯穿整个工作流的全局配置，且不应被业务逻辑修改。
-
缓存传递：优化性能，避免重复进行昂贵操作。
如何组合使用：一个智能客服的例子
在一个复杂的客服工作流中，最佳实践是组合使用这四种模式，而非单一依赖某一种：
-
状态传递：存放用户画像和完整的对话历史，供所有节点共享。
-
缓存传递：查询用户问题时，先检查Redis缓存；若命中则直接返回，避免重复调用LLM。
-
上下文传递 ：通过
RunnableConfig传入会员等级和权限标识等只读配置。 -
参数传递：在路由判断节点计算出"是转到人工客服还是继续自助"的路由结果，直接作为参数传递给边进行决策。
延伸：四种流式输出模式 (stream_mode)
除了上述节点间的内部数据传递，LangGraph 还为向客户端输出数据提供了四种流式模式，这也是常被提到的"四种模式"之一。
-
values: 默认模式，每次节点更新后返回完整状态，简单但数据冗余。用于前端需完整状态快照的场景。 -
updates: 仅返回状态变更部分，能大幅降低网络传输量。用于复杂状态、追求前端性能的场景。 -
messages: 专为聊天优化，只提取并流式返回消息列表中的最新消息Token。用于聊天对话、实时文本生成。 -
custom: 在节点内通过StreamWriter自定义数据格式输出。用于流式进度条、中间推理步骤等前端自定义渲染。