LangGraph 的 StateGraph 怎么设计？State、Node、Edge 到底各负责什么

面试官问：“你说项目用了 LangGraph，那你这张图到底是怎么设计的？”

如果回答只是“State 是状态，Node 是节点，Edge 是边”，这道题基本只答到了框架名词。面试官真正想确认的是：为什么任务需要一张有状态的图，哪些数据应该进入 State，节点之间怎样分工，分支和循环由什么条件决定，以及图跑错时能不能回放到具体一步。

很多 Agent 项目一开始只有一个 while 循环。模型决定工具，程序执行，再把结果交回模型。这个最小循环很重要，因为它让人看清 Agent 的本质。但当流程出现计划、执行、反思、重试、人工确认等多个阶段后，所有判断继续塞在一个循环里，状态会越来越散，异常出口也越来越难解释。StateGraph 的价值，就是把这些隐含在代码里的状态和控制流显式化。

先给出 30 秒回答

LangGraph 的 StateGraph 可以理解为一张会携带共享状态运行的流程图。State 保存任务目标、计划、已完成步骤、工具结果、错误和控制字段；Node 是只负责一类状态变换的处理单元；Edge 定义固定跳转，Conditional Edge 根据当前状态选择下一节点。设计时我会先写业务完成条件和失败出口，再设计最小状态，最后拆节点与边，而不是先按框架示例堆 Planner、Executor、Reflector。关键节点要做到输入输出清楚、重复执行可控，循环必须受步数、时间和业务条件约束，并通过 Trace 记录每次状态变化。

这段回答里有四个关键词：共享状态、状态变换、条件路由、受控循环。把这四件事讲清，才算真正理解 StateGraph。

放大查看图解 ↗

这张图的用途，是让状态、责任和跳转条件都能被检查，而不是增加架构装饰。

为什么一个普通循环会逐渐失控

先看一个研究助手。用户给出一个问题，系统先制定计划，再调用搜索或访问工具，检查结果是否足够，最后生成回答。刚开始可以写成下面的逻辑：

while not finished:
    action = model_decide(messages)
    result = execute(action)
    messages.append(result)

这段代码能跑，但很多重要问题没有显式答案：当前执行到计划的第几步？工具失败后是重试、换工具还是结束？已经得到哪些证据？谁判断结果足够？如果模型连续选择同一个动作，在哪里阻止？如果需要人工确认，暂停点放在哪里？

开发者通常会继续加入 if：如果是搜索就走一个分支，如果需要反思就走另一个分支，如果错误次数过多就退出。再过一段时间，计划、消息、工具结果、重试次数散落在不同局部变量里。最终答案错了，只能看到循环结束后的文本，很难确认是哪次状态更新把任务带偏。