langgraph流式运行图

原创于 2025-12-11 17:22:49 发布 · 642 阅读

CC 4.0 BY-SA版权

文章标签：

一.背景

LangGraph 作为 LangChain 生态中聚焦大模型应用流程编排与状态管理的核心框架，其原生的 “一次性执行” 模式（即从起始节点到结束节点完整运行整个图流程，一次性返回最终结果），在企业级大模型应用场景中逐渐显现出局限性。而 “流式运行图（Streaming Run Graph）” 能力，本质是将图的执行过程拆解为多个连续的数据流片段，实时输出每个节点的执行状态、中间结果与流程流转信息，而非等待全流程结束后返回最终结果。这一能力的需求源于传统非流式运行模式在交互性、实时性、可控性上的核心痛点，也是 LangGraph 适配大模型应用 “实时交互、渐进式输出、动态干预” 企业级诉求的关键升级。

1.LangGraph 非流式运行图的核心痛点

在流式运行能力出现前，LangGraph 采用的是 **“全流程阻塞式执行”** 模式：用户触发流程后，需等待所有节点执行完成（包括大模型调用、数据处理、分支决策等），才能获取完整结果。这种模式在处理复杂大模型流程（如多轮对话、多智能体协作、长文本生成、分步数据分析）时，暴露出诸多难以解决的问题：

1. 交互体验差，用户等待时间过长

大模型流程的执行往往涉及耗时操作（如大模型生成长篇文本、向量数据库检索海量数据、多智能体依次协作），非流式运行模式下，用户需等待数十秒甚至数分钟才能获取结果：例如，智能报告生成流程需调用大模型生成数千字的分析报告，用户需全程等待流程结束，期间无任何反馈，易产生 “卡顿”“无响应” 的负面体验，尤其在 C 端应用（如智能客服、内容生成工具）中，这种体验缺陷会直接降低用户留存率。

2. 中间结果不可见，故障排查与调试难

非流式运行模式下，流程执行过程是 “黑盒”：仅能获取最终结果，无法查看每个节点的执行状态（如 “意图识别节点是否完成”“大模型调用是否超时”“分支决策触发了哪个路径”）与中间结果（如 “知识库检索返回了哪些文档”“大模型生成的初稿内容”）。若流程执行失败或结果不符合预期，开发人员无法定位故障发生在哪个节点，只能通过日志逐行排查，调试效率极低；即使流程成功执行，也无法追溯中间环节的逻辑是否正确，难以优化流程细节。

3. 无法动态干预流程，灵活性不足

非流式运行模式下，流程一旦启动便按预设逻辑执行至结束，用户或系统无法在执行过程中动态干预：例如，智能客服流程中，用户在大模型生成回答的过程中补充了新的信息，非流式模式无法中断当前节点并利用新信息重新执行；多智能体协作流程中，运维人员发现某智能体的执行结果错误，无法暂停流程并修正问题，只能等待全流程结束后重新运行，资源浪费严重且无法适配实时变化的业务场景。

4. 与大模型流式输出能力脱节，资源利用率低

主流大模型（如 GPT-3.5/4、Claude、通义千问）均支持流式输出（即逐字 / 逐段返回生成结果），但非流式运行的 LangGraph 会等待大模型生成完整结果后再继续执行后续节点，浪费了大模型的流式能力：一方面，用户无法实时看到大模型的生成过程，另一方面，流程后续节点（如 “内容校验节点”）需等待完整结果生成才能启动，导致节点间的资源调度出现空窗期，集群资源利用率降低。

5. 大流量场景下易引发系统瓶颈

在高并发场景中（如数万用户同时触发智能问答流程），非流式运行模式会导致大量请求积压：每个请求需占用资源直至流程结束，服务器需同时处理大量阻塞的请求，易引发内存溢出、接口超时等问题；而流式运行可将请求处理拆解为多个小片段，实时释放部分资源，大幅提升系统的并发处理能力。

2.LangGraph 流式运行图的核心价值

LangGraph 流式运行图能力通过 **“节点执行 - 数据推送 - 状态持续化”** 的循环机制，将流程执行过程转化为可实时输出的数据流，解决了非流式模式的痛点，核心价值体现在：

1. 实时输出结果，提升用户交互体验

流式运行图可将流程的执行结果按节点或步骤拆分为多个片段，实时推送至用户端：例如，智能报告生成流程中，先推送 “数据采集完成” 的状态，再推送 “数据分析结果”，最后逐段推送大模型生成的报告内容；智能客服流程中，大模型生成回答时逐字返回内容，用户无需等待全流程结束即可看到渐进式的结果，大幅缩短了感知等待时间，提升了用户体验。这种能力尤其适配 C 端应用与需要长文本生成的场景，是大模型应用从 “功能可用” 走向 “体验优秀” 的关键。

2. 全程可视化执行过程，降低调试与运维成本

流式运行图会实时输出每个节点的执行信息：包括节点名称、执行开始 / 结束时间、输入 / 输出数据、异常信息（若有）、分支决策依据等。开发人员可通过这些实时数据，直观看到流程的流转路径与中间结果：例如，排查故障时，可直接看到 “大模型调用节点超时” 或 “知识库检索节点返回空数据”，快速定位根因；优化流程时，可分析每个节点的执行耗时，针对性地优化耗时节点（如更换向量索引、优化 Prompt），调试与运维效率提升 80% 以上。

3. 支持动态干预，提升流程灵活性

流式运行图的每个数据片段输出后，流程会保留当前的执行状态（基于 LangGraph 的 Checkpoint 机制），用户或系统可在此时触发动态干预：例如，用户在看到大模型生成的初稿后，发送 “补充北京地区的数据”，系统可中断当前的 “内容生成节点”，更新上下文数据后重新执行该节点；运维人员在监控到 “智能体协作节点” 执行异常时，可暂停流程并手动修正参数，再恢复流程执行。这种 “实时输出 - 动态干预 - 继续执行” 的闭环，让流程能够适配实时变化的业务需求，灵活性远超非流式运行模式。

4. 无缝集成大模型流式输出，优化资源调度

LangGraph 流式运行图可与大模型的流式输出能力深度融合：大模型节点在接收到流式输出的每一个片段时，可实时将其传递给后续节点（如 “内容校验节点” 可逐段校验大模型生成的内容），无需等待完整结果生成。这种 “节点间流式传递” 的机制，消除了节点间的资源空窗期，提升了集群资源利用率；同时，用户可实时看到大模型的生成过程，与大模型的交互更自然。

5. 提升系统并发处理能力，适配高流量场景

流式运行图将每个请求的处理拆解为多个独立的数据流片段，服务器可分批次处理这些片段：处理完一个片段后，可暂时释放部分资源用于处理其他请求，避免大量请求同时阻塞。在高并发场景中，这种处理方式可将系统的并发承载能力提升数倍，有效避免因请求积压引发的系统瓶颈；同时，流式输出还能支持请求的 “断点续传”，若用户端网络中断，恢复后可从最后一个接收的片段继续获取结果，提升了系统的鲁棒性。

3.LangGraph 流式运行图的典型应用场景

C 端内容生成工具：如智能文案写作、报告生成、视频脚本创作工具，流式运行图可实时输出大模型的生成内容，用户可逐段查看并实时调整需求，提升内容创作的效率与体验。
企业级智能客服系统：客服对话流程中，流式运行图可实时输出意图识别结果、知识库检索片段、大模型的回答内容，用户可在对话过程中补充信息，系统可动态调整回答逻辑，提升客服响应的实时性与准确性。
多智能体协作流程：如合同审查、项目评估、数据分析的多智能体流程，流式运行图可实时输出每个智能体的执行状态与中间结果，运维人员可实时监控并干预异常节点，保证流程的高效执行。
大模型驱动的数据分析工具：如用户行为分析、业务数据监控工具，流式运行图可实时输出数据采集结果、统计分析片段、可视化图表生成状态，数据分析师可实时看到分析过程并调整分析维度。
高并发智能问答平台：如电商平台的智能导购、政务平台的智能咨询系统，流式运行图可拆解高并发请求，提升系统的并发处理能力，同时实时返回回答内容，降低用户等待时间。

4.关键优势总结

LangGraph 流式运行图的核心价值，是将大模型流程的执行从 “阻塞式的黑盒操作” 转化为 “透明化的流式交互过程”：既解决了非流式模式下用户体验差、调试难、灵活性不足的痛点，又无缝集成了大模型的流式能力，优化了资源调度与系统并发处理能力。这一能力让 LangGraph 能够适配 C 端用户交互、高并发企业服务、复杂多智能体协作等多样化的企业级场景，是大模型应用从 “生产可用” 走向 “体验最优” 的关键技术支撑。

综上，LangGraph 流式运行图的需求，源于企业对大模型应用 “实时性、交互性、可控性” 的核心诉求：解决了传统非流式运行模式的诸多痛点，支撑内容生成、智能客服、多智能体协作等核心场景，为复杂大模型应用的规模化落地提供了高效、灵活的技术路径。

二.具体实现

1.引入依赖

import sys
import io
# 设置标准输出编码为UTF-8，解决Windows中文乱码问题
if sys.platform == 'win32':
    sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')
    sys.stderr = io.TextIOWrapper(sys.stderr.buffer, encoding='utf-8')

from IPython.display import Image, display
from langgraph.constants import START, END
from langgraph.graph import StateGraph
from langgraph.graph.state import CompiledStateGraph
from typing_extensions import TypedDict
import threading
import time
from apscheduler.schedulers.blocking import BlockingScheduler
import datetime
from langgraph.types import interrupt
from langgraph.types import Command
from langgraph.checkpoint.memory import MemorySaver

2.定义状态类

# 1. 定义状态
class EventState(TypedDict):

    count_status: int  #累计计数状态

3.定义节点1，节点2

def first_node(state: EventState) -> EventState:

    state["count_status"] += 1

    print("当前计数状态：", state["count_status"])

    return state   


def second_node(state: EventState) -> EventState:

    state["count_status"] += 3

    print("当前计数状态：", state["count_status"])

    return state

4.构建图

    graph = StateGraph(EventState)
    graph.add_node("first_node", first_node)
    graph.add_node("second_node", second_node)
    graph.add_edge(START, "first_node")
    graph.add_edge("first_node", "second_node")
    graph.add_edge("second_node", END)

    memory = MemorySaver()
    graph = graph.compile(checkpointer=memory)

5.updates模型流式执行

    state = {"count_status": 0}

    config = {"configurable": {"thread_id": "thread-133"}}

    for chunk in graph.stream(state,stream_mode="updates",config=config):
        print(chunk)

结果如下：

6.debug模式流式执行

    for chunk in graph.stream(state,stream_mode="debug",config=config):
        print(chunk)