尧图网站建设 
同一个 if/else写进代码和画进一张图区别在哪LangGraph 把智能体逻辑还原成三个原语节点函数、边条件判断、状态共享内存文末附已实跑验证的最小实现。§1 为什么需要图线性 Chain 表达不了「循环」同一个 if/else写进代码里和画进一张图里有什么区别前者是一次性判断。后者是一条可循环、可回放、可在中途插手的路径。你的 Agent 是调一次 LLM 就结束还是自己决定要不要再来一次智能体的核心动作是循环推理。调 LLM看结果决定继续还是结束。LCEL 是线性 DAG只能顺序执行 A→B→C表达不了循环与分支。节点是操作边是跳转规则状态是共享内存代价多轮对话一长状态散落在外层变量里。用户三连问每轮都要带上上一轮结论状态一丢就得重说一遍。官方把旧的 Agent Executor 重构到图上正是看中图能表达的循环结构。LangGraph 用一张图解决。图里只有三个原语加一个 StateGraph 容器就是全部。它也是 LangChain 生态里的独立模块。§2 节点 Node最小操作单元 函数2.1 一个函数一个节点节点是一个 Python 函数。它接收 state 字典返回部分更新字典只需要写自己要改的键。约束有两条。输入输出 schema 必须与 State 对齐。节点本身没有内部状态所有记忆都在外部 State 里。官方文档的最小节点长这样函数名就是图里的节点名from typing_extensions import TypedDict class State(TypedDict): input: str results: str def node_with_runtime(state: State): # 只返回要改的键不必拼整份 state return {results: fHello, {state[input]}!}「只返回要改的键」是 LangGraph 的核心约定。图引擎会把返回值合并进共享状态各节点不需要知道完整状态长什么样。CSDN 实战示例把「部分更新」讲得更直白。一个 double_it 节点只更新自己管的两个键其余不动def double_it(state: dict) - dict: value state.get(value, 0) * 2 history state.get(history, []) [value] return {value: value, history: history} # 只更新两个键其余不动同步异步都支持。函数用 async def 定义LangGraph 会在事件循环里调度它写法上只差一个关键字。2.2 为什么节点必须无状态节点无状态是刻意设计。同一个函数在任何上下文里跑行为都一样图引擎因此能持久化、能回放任意一步。注册方式有讲究。add_node 的两个参数角色完全不同第一个参数是字符串引用名加边时用第二个参数才是函数本体路由时不直接参与名字错了编译期就报错。这层间接很有用想换实现只改 add_node 绑定的函数边和路由都不用动。贯穿示例里的 get_weather 也是这种函数只返回 {“weather”: …} 一个键§5 正式亮相。§3 边 Edge跳转规则 条件判断3.1 两类边边决定执行顺序分两类。无条件边 add_edge(A, B)A 完成必去 B。条件边 add_conditional_edges 让 router 读 state、返回节点名可指回上游。START 是入口END 是出口。END 不是真实节点图走到 END 才停。图3 条件边按 router 的返回值选路node_c 可指回 node_a 形成循环。条件边的第三个参数是映射表。router 的返回值是键映射表告诉引擎该去哪。官方示例 {True: “node_b”, False: “node_c”}返回值与节点名解耦。条件边也能从 START 出发挂图一进来就先路由。3.2 循环是怎么转起来的ReAct 循环是典型用法。模型节点读完 state 后router 决定继续调工具还是结束def should_continue(state) - Literal[tool_node, END]: # router 读 state有工具调用就继续否则结束 if state[messages][-1].tool_calls: return tool_node return END # 条件边按 router 返回值映射到不同节点 builder.add_conditional_edges(llm_call, should_continue, [tool_node, END]) # 普通回边工具执行完回到 LLM循环由此形成 builder.add_edge(tool_node, llm_call)循环的实现拆开看。条件边负责选路真正让图转起来的是一条指回上游的普通边。反复几轮直到模型不再要求调工具条件边返回 END。边把「if 结果正确就下一步否则重试」从代码嵌套变成图的拓扑。juejin 的示例把这条回边写得最清楚tool_node 执行完工具控制权交回模型模型再走条件边决定下一步。映射表本身也很灵活可以省略router 直接返回节点名返回值可以是节点名列表多个分支并行执行两类边一句话区分无条件边add_edge(A, B)A 完成必去 B条件边add_conditional_edgesrouter 读 state 选路可指回上游§4 状态 State全局数据 共享内存4.1 共享 TypedDict 与 reducer状态是贯穿全图的共享 TypedDict节点靠它交互彼此不直接调用。默认覆盖旧值用 Annotated[list, operator.add] 做累加。对话历史、中间结果这类数据靠的就是累加。每次都覆盖多轮上下文就只剩最后一轮。State 的 schema 不只 TypedDict 一种。dataclass、Pydantic BaseModel 都可以约束是节点收发都对齐这份 schema。图4 两个节点只和 State 交互彼此不直接互调。reducer 的覆盖与累加官方文档给过一段对比已在本机实跑验证from operator import add from typing import Annotated from typing_extensions import TypedDict class State(TypedDict): foo: int bar: Annotated[list[str], add] # 累加而非覆盖 # 输入 {foo:1,bar:[hi]} # 节点1 返回 {foo:2} → 状态 {foo:2,bar:[hi]} # 节点2 返回 {bar:[bye]} → 状态 {foo:2,bar:[hi,bye]}foo 被第二次写入覆盖成 2bar 靠 operator.add 累加成两段。4.2 消息场景用 add_messages消息类状态直接用 add_messages它按消息 ID 覆盖或追加。裸 operator.add 会把人工更新也误追加进去这是官方文档特别提醒过的坑。from langchain_core.messages import AnyMessage from langgraph.graph.message import add_messages class GraphState(TypedDict): messages: Annotated[list[AnyMessage], add_messages] # 按 ID 覆盖或追加理解 reducer 的关键在「谁决定合并」。声明了 reducer 的键每次写入都先经过 reducer 再落进状态。合并策略是状态 schema 的一部分跟着类型走不散落在节点里。reducer 决定键的合并方式默认覆盖Annotated 累加。reducer 不只有 operator.add 和 add_messages。它就是一个普通函数输入旧值和新值输出合并结果。想自定义合并规则写个函数声明上去就行机制不变。状态外置带来三个能力可持久化checkpointer 按 thread_id 存状态可回放同一 thread_id 再调一次上下文自动续上可人在回路运行到断点停下等人介入这是「共享内存」能累积上下文的关键也是 LangGraph 相对手写循环的根本差异。§5 贯穿示例查天气 → 推荐穿搭三个原语单独看都简单合在一起才见功力。输入城市输出天气和穿搭建议把「图结构 ↔ 代码」双向映射讲透。图5 查天气到推荐穿搭两个节点、三条边、一个共享字段。from typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): # 状态共享内存三个字段 city: str weather: str recommendation: str def get_weather(state: OutfitState) - dict: # 节点函数 mock {北京: 晴28°C, 上海: 多云24°C, 广州: 雷阵雨30°C} return {weather: mock.get(state[city], 晴25°C)} # 部分更新 def recommend_outfit(state: OutfitState) - dict: w state[weather] # 读共享内存不直接调 get_weather if 晴 in w: return {recommendation: 短袖 防晒紫外线强记得戴帽子} if 雨 in w: return {recommendation: 薄外套 随身雨具} return {recommendation: 薄外套早晚温差带件方便穿脱的} builder StateGraph(OutfitState) # 图容器 builder.add_node(get_weather, get_weather) # 框 add_node builder.add_node(recommend_outfit, recommend_outfit) builder.add_edge(START, get_weather) # 箭头 add_edge builder.add_edge(get_weather, recommend_outfit) builder.add_edge(recommend_outfit, END) graph builder.compile() # 必须编译后才能调用 result graph.invoke({city: 北京}) print(result[weather], →, result[recommendation])图里每个框 一个 add_node每条箭头 一条 add_edgeweather字段 State 共享内存get_weather 只写 weatherrecommend_outfit 只读 weather两者没有任何直接调用信息全部经状态中转。这就是「共享内存」四个字的落点。compile 做结构校验缺边、不可达节点在这里就报错。invoke 传入初始状态 {“city”: “北京”}图引擎按边一路执行返回最终状态。晴28°C → 短袖 防晒紫外线强记得戴帽子这段代码已在本机实跑验证langgraph 1.2.10exit 0输出与预期逐字一致。反向读也一样成立。拿到一段 LangGraph 代码看 add_node 就是图里的框看 add_edge 就是箭头看 State 的字段就是共享数据。图能导出成 mermaid代码能翻译回图双向映射闭环。§6 进阶用条件边加「天气异常 → 人工确认」分支给示例加一个分支天气异常时走人工确认。在 recommend_outfit 后接条件边router 读 weather 判断是否含「雨」。图6 条件边在 recommend_outfit 后分叉异常进人工确认正常直达 END。下面这段是演示变体在 §5 脚手架上追加已在本机实跑验证from typing import Literal from typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): city: str weather: str recommendation: str needs_confirm: bool # 是否需人工确认 def human_confirm(state: OutfitState) - dict: return {needs_confirm: True} def route(state: OutfitState) - Literal[human_confirm, END]: # 含雨视为天气异常需要人工确认 if 雨 in state[weather]: return human_confirm return END builder.add_node(human_confirm, human_confirm) builder.add_conditional_edges( recommend_outfit, route, {human_confirm: human_confirm, END: END}, ) builder.add_edge(human_confirm, END)预期行为北京「晴」直通 END广州「雷阵雨」进 human_confirm。条件边把「要不要人看」变成图的拓扑加分支不动已有节点纪律循环和分支必须最终能结束否则触发 recursion_limitrecursion_limit 是可以调大的但调大只是拖延不解决「循环没有出口」的设计缺陷。调试建议先用小 recursion_limit 快速暴露死循环比一次跑满省时间。往真实系统想一步human_confirm 可以是发给运维的审批消息节点停下来等人工回复再带着回复继续走。人机协作不是另外一套机制只是图里多了一个普通节点和一条条件边。§7 边界与常见错误什么时候别用图compile 会做结构校验。不可达节点、缺 START 入口边、缺 END 出口边、节点名拼写不一致都在编译期报错不会拖到运行期才炸。图7 正确骨架要求 START 入口边与 END 出口边齐全缺一条都过不了 compile。节点名拼写不一致“retreive” vs “retrieve”→ 编译期报错漏了 START 或 END 边→ 编译期报错条件边里写死永真分支→ 循环不停触发 recursion_limit判断标准一句话你的流程会不会回头。不会回头线性链够用会回头、要留状态、要人在中途插手再上 LangGraph。单次问答、无状态转换、纯顺序管道LCEL 更轻。图的价值在「要循环、要共享状态、要中途介入」。compile 之后的图还能导出 mermaid把代码画回图调试和文档都靠它。最小图的四步法顺序固定定义 Stateadd_node 注册节点add_edge 连边、指定 START 入口最后 compile漏一步都会在编译期暴露。§8 最小实现把上面的查天气图原样复制成一份独立脚本存成 outfit.py装好依赖就能跑。pip install langgraph python outfit.pyfrom typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): city: str weather: str recommendation: str def get_weather(state: OutfitState) - dict: mock {北京: 晴28°C, 上海: 多云24°C, 广州: 雷阵雨30°C} return {weather: mock.get(state[city], 晴25°C)} def recommend_outfit(state: OutfitState) - dict: w state[weather] if 晴 in w: return {recommendation: 短袖 防晒紫外线强记得戴帽子} if 雨 in w: return {recommendation: 薄外套 随身雨具} return {recommendation: 薄外套早晚温差带件方便穿脱的} builder StateGraph(OutfitState) builder.add_node(get_weather, get_weather) builder.add_node(recommend_outfit, recommend_outfit) builder.add_edge(START, get_weather) builder.add_edge(get_weather, recommend_outfit) builder.add_edge(recommend_outfit, END) graph builder.compile() result graph.invoke({city: 北京}) print(result[weather], →, result[recommendation])预期输出晴28°C → 短袖 防晒紫外线强记得戴帽子本示例已在 langgraph 1.2.10 下实跑验证退出码 0。换上海输出「多云24°C → 薄外套早晚温差带件方便穿脱的」换广州输出「雷阵雨30°C → 薄外套 随身雨具」。§9 总结三原语收口节点是函数图里最小的操作单元。边是条件判断决定下一步去哪循环靠它实现。状态是共享内存跨节点传数据reducer 决定覆盖还是累加。起步建议先跑通最小实现再加条件边再考虑持久化。「图结构 ↔ 代码」的双向映射是 LangGraph 的心智模型。画图时想到 add_node 和 add_edge写代码时想到节点和箭头。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 LangGraph核心：节点、边、状态的第一性原理
同一个 if/else写进代码和画进一张图区别在哪LangGraph 把智能体逻辑还原成三个原语节点函数、边条件判断、状态共享内存文末附已实跑验证的最小实现。§1 为什么需要图线性 Chain 表达不了「循环」同一个 if/else写进代码里和画进一张图里有什么区别前者是一次性判断。后者是一条可循环、可回放、可在中途插手的路径。你的 Agent 是调一次 LLM 就结束还是自己决定要不要再来一次智能体的核心动作是循环推理。调 LLM看结果决定继续还是结束。LCEL 是线性 DAG只能顺序执行 A→B→C表达不了循环与分支。节点是操作边是跳转规则状态是共享内存代价多轮对话一长状态散落在外层变量里。用户三连问每轮都要带上上一轮结论状态一丢就得重说一遍。官方把旧的 Agent Executor 重构到图上正是看中图能表达的循环结构。LangGraph 用一张图解决。图里只有三个原语加一个 StateGraph 容器就是全部。它也是 LangChain 生态里的独立模块。§2 节点 Node最小操作单元 函数2.1 一个函数一个节点节点是一个 Python 函数。它接收 state 字典返回部分更新字典只需要写自己要改的键。约束有两条。输入输出 schema 必须与 State 对齐。节点本身没有内部状态所有记忆都在外部 State 里。官方文档的最小节点长这样函数名就是图里的节点名from typing_extensions import TypedDict class State(TypedDict): input: str results: str def node_with_runtime(state: State): # 只返回要改的键不必拼整份 state return {results: fHello, {state[input]}!}「只返回要改的键」是 LangGraph 的核心约定。图引擎会把返回值合并进共享状态各节点不需要知道完整状态长什么样。CSDN 实战示例把「部分更新」讲得更直白。一个 double_it 节点只更新自己管的两个键其余不动def double_it(state: dict) - dict: value state.get(value, 0) * 2 history state.get(history, []) [value] return {value: value, history: history} # 只更新两个键其余不动同步异步都支持。函数用 async def 定义LangGraph 会在事件循环里调度它写法上只差一个关键字。2.2 为什么节点必须无状态节点无状态是刻意设计。同一个函数在任何上下文里跑行为都一样图引擎因此能持久化、能回放任意一步。注册方式有讲究。add_node 的两个参数角色完全不同第一个参数是字符串引用名加边时用第二个参数才是函数本体路由时不直接参与名字错了编译期就报错。这层间接很有用想换实现只改 add_node 绑定的函数边和路由都不用动。贯穿示例里的 get_weather 也是这种函数只返回 {“weather”: …} 一个键§5 正式亮相。§3 边 Edge跳转规则 条件判断3.1 两类边边决定执行顺序分两类。无条件边 add_edge(A, B)A 完成必去 B。条件边 add_conditional_edges 让 router 读 state、返回节点名可指回上游。START 是入口END 是出口。END 不是真实节点图走到 END 才停。图3 条件边按 router 的返回值选路node_c 可指回 node_a 形成循环。条件边的第三个参数是映射表。router 的返回值是键映射表告诉引擎该去哪。官方示例 {True: “node_b”, False: “node_c”}返回值与节点名解耦。条件边也能从 START 出发挂图一进来就先路由。3.2 循环是怎么转起来的ReAct 循环是典型用法。模型节点读完 state 后router 决定继续调工具还是结束def should_continue(state) - Literal[tool_node, END]: # router 读 state有工具调用就继续否则结束 if state[messages][-1].tool_calls: return tool_node return END # 条件边按 router 返回值映射到不同节点 builder.add_conditional_edges(llm_call, should_continue, [tool_node, END]) # 普通回边工具执行完回到 LLM循环由此形成 builder.add_edge(tool_node, llm_call)循环的实现拆开看。条件边负责选路真正让图转起来的是一条指回上游的普通边。反复几轮直到模型不再要求调工具条件边返回 END。边把「if 结果正确就下一步否则重试」从代码嵌套变成图的拓扑。juejin 的示例把这条回边写得最清楚tool_node 执行完工具控制权交回模型模型再走条件边决定下一步。映射表本身也很灵活可以省略router 直接返回节点名返回值可以是节点名列表多个分支并行执行两类边一句话区分无条件边add_edge(A, B)A 完成必去 B条件边add_conditional_edgesrouter 读 state 选路可指回上游§4 状态 State全局数据 共享内存4.1 共享 TypedDict 与 reducer状态是贯穿全图的共享 TypedDict节点靠它交互彼此不直接调用。默认覆盖旧值用 Annotated[list, operator.add] 做累加。对话历史、中间结果这类数据靠的就是累加。每次都覆盖多轮上下文就只剩最后一轮。State 的 schema 不只 TypedDict 一种。dataclass、Pydantic BaseModel 都可以约束是节点收发都对齐这份 schema。图4 两个节点只和 State 交互彼此不直接互调。reducer 的覆盖与累加官方文档给过一段对比已在本机实跑验证from operator import add from typing import Annotated from typing_extensions import TypedDict class State(TypedDict): foo: int bar: Annotated[list[str], add] # 累加而非覆盖 # 输入 {foo:1,bar:[hi]} # 节点1 返回 {foo:2} → 状态 {foo:2,bar:[hi]} # 节点2 返回 {bar:[bye]} → 状态 {foo:2,bar:[hi,bye]}foo 被第二次写入覆盖成 2bar 靠 operator.add 累加成两段。4.2 消息场景用 add_messages消息类状态直接用 add_messages它按消息 ID 覆盖或追加。裸 operator.add 会把人工更新也误追加进去这是官方文档特别提醒过的坑。from langchain_core.messages import AnyMessage from langgraph.graph.message import add_messages class GraphState(TypedDict): messages: Annotated[list[AnyMessage], add_messages] # 按 ID 覆盖或追加理解 reducer 的关键在「谁决定合并」。声明了 reducer 的键每次写入都先经过 reducer 再落进状态。合并策略是状态 schema 的一部分跟着类型走不散落在节点里。reducer 决定键的合并方式默认覆盖Annotated 累加。reducer 不只有 operator.add 和 add_messages。它就是一个普通函数输入旧值和新值输出合并结果。想自定义合并规则写个函数声明上去就行机制不变。状态外置带来三个能力可持久化checkpointer 按 thread_id 存状态可回放同一 thread_id 再调一次上下文自动续上可人在回路运行到断点停下等人介入这是「共享内存」能累积上下文的关键也是 LangGraph 相对手写循环的根本差异。§5 贯穿示例查天气 → 推荐穿搭三个原语单独看都简单合在一起才见功力。输入城市输出天气和穿搭建议把「图结构 ↔ 代码」双向映射讲透。图5 查天气到推荐穿搭两个节点、三条边、一个共享字段。from typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): # 状态共享内存三个字段 city: str weather: str recommendation: str def get_weather(state: OutfitState) - dict: # 节点函数 mock {北京: 晴28°C, 上海: 多云24°C, 广州: 雷阵雨30°C} return {weather: mock.get(state[city], 晴25°C)} # 部分更新 def recommend_outfit(state: OutfitState) - dict: w state[weather] # 读共享内存不直接调 get_weather if 晴 in w: return {recommendation: 短袖 防晒紫外线强记得戴帽子} if 雨 in w: return {recommendation: 薄外套 随身雨具} return {recommendation: 薄外套早晚温差带件方便穿脱的} builder StateGraph(OutfitState) # 图容器 builder.add_node(get_weather, get_weather) # 框 add_node builder.add_node(recommend_outfit, recommend_outfit) builder.add_edge(START, get_weather) # 箭头 add_edge builder.add_edge(get_weather, recommend_outfit) builder.add_edge(recommend_outfit, END) graph builder.compile() # 必须编译后才能调用 result graph.invoke({city: 北京}) print(result[weather], →, result[recommendation])图里每个框 一个 add_node每条箭头 一条 add_edgeweather字段 State 共享内存get_weather 只写 weatherrecommend_outfit 只读 weather两者没有任何直接调用信息全部经状态中转。这就是「共享内存」四个字的落点。compile 做结构校验缺边、不可达节点在这里就报错。invoke 传入初始状态 {“city”: “北京”}图引擎按边一路执行返回最终状态。晴28°C → 短袖 防晒紫外线强记得戴帽子这段代码已在本机实跑验证langgraph 1.2.10exit 0输出与预期逐字一致。反向读也一样成立。拿到一段 LangGraph 代码看 add_node 就是图里的框看 add_edge 就是箭头看 State 的字段就是共享数据。图能导出成 mermaid代码能翻译回图双向映射闭环。§6 进阶用条件边加「天气异常 → 人工确认」分支给示例加一个分支天气异常时走人工确认。在 recommend_outfit 后接条件边router 读 weather 判断是否含「雨」。图6 条件边在 recommend_outfit 后分叉异常进人工确认正常直达 END。下面这段是演示变体在 §5 脚手架上追加已在本机实跑验证from typing import Literal from typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): city: str weather: str recommendation: str needs_confirm: bool # 是否需人工确认 def human_confirm(state: OutfitState) - dict: return {needs_confirm: True} def route(state: OutfitState) - Literal[human_confirm, END]: # 含雨视为天气异常需要人工确认 if 雨 in state[weather]: return human_confirm return END builder.add_node(human_confirm, human_confirm) builder.add_conditional_edges( recommend_outfit, route, {human_confirm: human_confirm, END: END}, ) builder.add_edge(human_confirm, END)预期行为北京「晴」直通 END广州「雷阵雨」进 human_confirm。条件边把「要不要人看」变成图的拓扑加分支不动已有节点纪律循环和分支必须最终能结束否则触发 recursion_limitrecursion_limit 是可以调大的但调大只是拖延不解决「循环没有出口」的设计缺陷。调试建议先用小 recursion_limit 快速暴露死循环比一次跑满省时间。往真实系统想一步human_confirm 可以是发给运维的审批消息节点停下来等人工回复再带着回复继续走。人机协作不是另外一套机制只是图里多了一个普通节点和一条条件边。§7 边界与常见错误什么时候别用图compile 会做结构校验。不可达节点、缺 START 入口边、缺 END 出口边、节点名拼写不一致都在编译期报错不会拖到运行期才炸。图7 正确骨架要求 START 入口边与 END 出口边齐全缺一条都过不了 compile。节点名拼写不一致“retreive” vs “retrieve”→ 编译期报错漏了 START 或 END 边→ 编译期报错条件边里写死永真分支→ 循环不停触发 recursion_limit判断标准一句话你的流程会不会回头。不会回头线性链够用会回头、要留状态、要人在中途插手再上 LangGraph。单次问答、无状态转换、纯顺序管道LCEL 更轻。图的价值在「要循环、要共享状态、要中途介入」。compile 之后的图还能导出 mermaid把代码画回图调试和文档都靠它。最小图的四步法顺序固定定义 Stateadd_node 注册节点add_edge 连边、指定 START 入口最后 compile漏一步都会在编译期暴露。§8 最小实现把上面的查天气图原样复制成一份独立脚本存成 outfit.py装好依赖就能跑。pip install langgraph python outfit.pyfrom typing_extensions import TypedDict from langgraph.graph import StateGraph, START, END class OutfitState(TypedDict): city: str weather: str recommendation: str def get_weather(state: OutfitState) - dict: mock {北京: 晴28°C, 上海: 多云24°C, 广州: 雷阵雨30°C} return {weather: mock.get(state[city], 晴25°C)} def recommend_outfit(state: OutfitState) - dict: w state[weather] if 晴 in w: return {recommendation: 短袖 防晒紫外线强记得戴帽子} if 雨 in w: return {recommendation: 薄外套 随身雨具} return {recommendation: 薄外套早晚温差带件方便穿脱的} builder StateGraph(OutfitState) builder.add_node(get_weather, get_weather) builder.add_node(recommend_outfit, recommend_outfit) builder.add_edge(START, get_weather) builder.add_edge(get_weather, recommend_outfit) builder.add_edge(recommend_outfit, END) graph builder.compile() result graph.invoke({city: 北京}) print(result[weather], →, result[recommendation])预期输出晴28°C → 短袖 防晒紫外线强记得戴帽子本示例已在 langgraph 1.2.10 下实跑验证退出码 0。换上海输出「多云24°C → 薄外套早晚温差带件方便穿脱的」换广州输出「雷阵雨30°C → 薄外套 随身雨具」。§9 总结三原语收口节点是函数图里最小的操作单元。边是条件判断决定下一步去哪循环靠它实现。状态是共享内存跨节点传数据reducer 决定覆盖还是累加。起步建议先跑通最小实现再加条件边再考虑持久化。「图结构 ↔ 代码」的双向映射是 LangGraph 的心智模型。画图时想到 add_node 和 add_edge写代码时想到节点和箭头。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】