两条线：LangGraph 如何把状态流和控制流拆开（AI 生成）

两条线：LangGraph 如何把状态流和控制流拆开

一、一个字段被覆盖，一个字段留住了

lab_02 搭的是一张会绕圈的图：draft 先写个初稿，expand 每轮往里补一段，router 看长度够不够，不够就绕回去。我在 State 里定义了三个字段：

class State(TypedDict):
    topic: str
    result: str                                  # 无 reducer
    history: Annotated[list[str], operator.add]  # 有 reducer

两个节点返回的东西长得一样，都是 dict：

return {"result": result, "history": [f"expand_node: 第 {round_no} 轮加工后, len(result)={len(result)}"]}

跑完之后，result 只剩最后一次的值，history 一条不落全在。同一个节点、同一次返回、同一种写法，两个字段两种命运。

中间没有任何提示。没有报错，没有警告，日志里也看不出异常。

所以问题变成了：return 一个 dict，框架到底拿它做了什么？

答案是它没有"设置"你的状态，它把你交上来的东西当成增量，然后按每个字段自己的合并规则处理。而规则不写在节点里，写在 State 的定义里。

这篇文章想讲的就是这件事，以及它的另一半：节点返回值走 reducer 更新状态，router 返回值走 path_map 更新去向。LangGraph 把状态流和控制流拆成了两条线。

二、状态流：State 不是 Context

2.1 Java 里的 Context 是我的

写 Java 状态机的时候，上下文对象是个普通对象。谁都能拿到引用，谁都能 setter。订单状态机里加一个字段，就是在 Context 类上加一行，然后各个 handler 里随手 ctx.setXxx()。

这种写法有一个默认前提：状态是我的，我想什么时候改、改几次、从哪个线程改，都是我的事。

第一次写 LangGraph 节点时，我一开始以为可以这么干：想改消息列表，就 state["messages"].append(...)，然后 return state。逻辑上完全说得通。

但框架不这么看。而且它不会告诉你哪里不对------lab_02 里那个被覆盖的 result，就是这种预期落空之后的样子。

2.2 节点只上报增量

LangGraph 给节点定的契约很短：节点是 state → 增量 dict 的纯函数。你读 state，返回一个 dict 表示"我产生了这些变化"，然后就没有你的事了。

真正的写入者是框架，准确地说是 channel 和 reducer。节点碰不到状态本身，它只能提交一份变更申请。

这条约束看起来只是风格问题，其实不是。

2.3 为什么必须是增量

我一开始以为这是设计洁癖，后来发现至少有三层理由，一层比一层硬。

第一层，所有权。 如果每个节点都能就地改 state，那"当前状态是什么"就取决于哪段代码最后跑。图的执行顺序一旦变化（比如加了个并行分支），结果就跟着变。把写入权收到框架手里，状态才有一个唯一可信的来源。

第二层，并行。 LangGraph 的同一个 super-step 里，多个节点可以并行执行。这时候如果两个节点都在就地 mutate 同一个 dict，就是标准的竞态。让它们各自返回增量、由框架做确定性合并，这个问题从根上消失了。

第三层，持久化。 这一层当时没看懂，到第五章才补齐。stream 逐步回放、checkpointer 断点续跑、时间旅行，这三件事都需要框架在每一步手上有一份"这一步之后的状态"可以存。而它能物化出这份状态，前提是节点告诉了它"这一步变了什么"。增量是提交协议，快照是存储结果，前者是后者的必要条件。

三层里前两层是工程规范，第三层是能力边界。增量提交不是为了好看，是因为不这么做，后面那些功能根本没有实现基础。

2.4 同一个字段的两种命运

回到开头那个实验。result 和 history 的差别只有一行注解：

result: str                                  # 默认 reducer：后写的覆盖
history: Annotated[list[str], operator.add]  # 换成追加

默认 reducer 是"最后一个写入者获胜"。两个节点都返回 result，第二次的值覆盖第一次，前一次就没了。这是大多数人第一次遇到时的预期之外：你以为在累积，其实在覆盖。

加上 Annotated[list, operator.add] 之后，合并策略从"赋值"换成了"List.addAll"。每次返回的 list 被追加进去，历史全留。

add_messages 是消息场景的专用版。它做两件事：新消息追加进列表；如果消息带 id 且已存在，就原地更新那一条而不是再追加一条。第二件事是为流式和 checkpoint 场景准备的，不然一条消息被流式吐成好几段，历史里会出现好几条残片。

同一次返回，两条去向：

所以 reducer 不是语法糖，它是字段级的合并策略声明 。你在 State 里写下的每一个 Annotated，都是在告诉框架"这个字段被多次写入时该怎么算"。

Java 里这个位置通常是空的。Context 字段没有合并策略，因为不存在"合并"这个动作，只有覆盖。LangGraph 把这个空缺补上了，代价是你必须显式回答一次。

三、控制流：条件边是图里唯一的求值点

3.1 while 的两个动作

一个 while 循环，每轮干两件事：先求值条件，再决定继续还是退出。

while len(result) < THRESHOLD:
    result = expand(result)

条件表达式是这段代码的求值点。没有它，循环不知道什么时候停。

把这段逻辑搬进图里，会遇到一个问题：图的边是静态的。

3.2 静态边没有求值点

add_edge("draft", "expand") 表达的是"draft 跑完就去 expand"，没有条件。节点返回什么，边都不看。它不参与控制决策。

所以一个只由普通边构成的图，没有任何地方在求值"要不要继续"。它没有循环的出口判断，也就没有循环。框架不给你这个求值点。

要说清楚的是，这不是"绕环就会死循环"。真要拿普通边连成一个环，运行时还有 recursion_limit 兜着，超了会抛 GraphRecursionError，不会真的挂在那里转。准确的说法是：静态边构成的环没有退出条件，框架不提供这个判断，所以循环只能靠条件边来表达。

3.3 path_map：把跳转表变成数据

add_conditional_edges 把条件编译进了边里：

builder.add_conditional_edges("expand", router, {"expand": "expand", END: END})

三个参数各管一件事。第一个是源节点。第二个是 router 函数，读 state，返回一个字符串。第三个是 path_map，把 router 的返回值翻译成目标节点名。

router 本身长这样：

def router(state: State) -> str:
    if len(state["result"]) < THRESHOLD:
        return "expand"
    return END

它只负责判断，不负责跳转。跳转是 path_map 干的。

这个分工在 Java 里对应的是 switch：case "expand": goto expand。区别在于，Java 的跳转表写死在代码里，改一条分支要改代码、重新编译；LangGraph 的跳转表是那个 dict 参数，它是数据。

数据意味着它可以被构造、被替换、被画出来。get_graph().draw_mermaid() 能把整个路由画成图，靠的就是这份数据。

不传 path_map 也能跑。此时 router 的返回值被直接当成节点名。省掉那个 dict 看起来更干净，代价是路由关系不再显式声明，画出来的图会缺边，三个月后的你只能回去读 router 的代码才知道它能去哪。

数据化至少带来三个好处。可视化是最表面的一个。第二个是可测试：router 是纯函数，assert router({"result": "x"*200}) == END 一行就能测，不用跑整张图。第三个是可替换：同一个 router 配不同的 path_map，就是另一条流程。

顺带一句，router 必须无副作用。它会被调用，但它的返回值只进控制流，不参与状态合并。在 router 里改 state 不会有任何效果------这个位置根本没有 reducer 通道。

3.4 两条线在这里分岔

现在可以把这个机制说清楚了。图里有两类返回值，走两条完全不同的路：

• 节点返回 dict → 交给 reducer → 更新状态
• router 返回字符串 → 交给 path_map → 决定去向

前者影响"现在是什么"，后者影响"接下来去哪"。一个管数据，一个管控制。

Java 状态机把这两件事混在一起：handler 改完 Context，紧接着 return 一个 next state，数据和去向在同一条语句里。LangGraph 把它们拆开，各走各的通道。

图里有个容易画错的细节：router 的输入是从合并之后 的 State 来的，不是从节点那个原始返回值来的。它看不到你 return 的那个 dict，它看到的是 reducer 处理完的结果。这也解释了为什么 router 能靠 state["messages"][-1] 判断该不该继续------那条消息是框架合并进去的，不是节点直接递给它的。

这就是标题里那两条线。

四、循环：条件的作者换了人

4.1 while 和 tool calling 的四处不同

tool calling 循环本质上是 while，但有一处根本差异。

	while 循环	tool calling 循环
循环条件	程序员写死的确定性谓词	模型返回的 tool_calls 是否为空
求值点	每轮开头	router，每轮 agent 跑完
确定性	确定	不确定
保险丝	可选	必装

前三条是描述，第四条是后果。

while len(result) < THRESHOLD 这个条件，你能读、能测、能证明它最终会变成 False。if not resp.tool_calls 这个条件，取决于模型这一轮想不想调工具。模型可能连着五轮都在调，也可能第一轮就收工。你没法证明它一定收敛。

决策权交给了不可靠的第三方，所以保险丝从可选变成了必装。

4.2 双层保险丝

lab_02 里我装了一道：

if len(state["history"]) >= MAX_ROUNDS:
    return END

router 里数轮次，到上限就强制退出。这是应用层的保险丝。

框架层还有一道，在 invoke 的 config 里：

graph.invoke(initial_state, config={"recursion_limit": 15})

两道都叫保险丝，但行为完全不同。

而且刻度也不一样，这点很容易忽略。MAX_ROUNDS 数的是 agent 被调用的次数。recursion_limit 数的是图的 super-step，一轮 agent 加 tools 是两步。lab_05 里我写的是 MAX_ROUNDS = 5 配 recursion_limit = 15，五轮最多九步（agent1 → tools1 → ... → agent5，第五轮 router 直接给 END），15 留了余量。

如果把两个数写成一样，比如都写 5，第三轮跑到 tools 节点时框架层就先炸了，应用层的软着陆永远轮不到执行。第二个数要按第一个的两倍往上估，因为它们的单位不是同一个东西。

4.3 熔断语义不一样

应用层那道是软着陆。router 返回 END，图正常收尾，state 完整保留，你能拿到一个"因为轮次到顶所以停下"的合法结果，还能带上已经产生的部分答案。

框架层那道是硬闸门 。recursion_limit 超了直接抛 GraphRecursionError，异常截断，调用方拿到的是 traceback 不是结果。

一个返回状态，一个抛异常。所以两道都不能省：应用层负责体面地停下来，框架层负责在最坏情况下兜底。你只有应用层，写错了就没有第二道；你只有框架层，每次熔断都是一次线上报错。

写到这里时我以为自己装了两道。到第七章会发现并没有。

五、持久化：带时间轴的 Session

5.1 一个真实的报错

给图挂上 checkpointer 之后，如果 invoke 时忘了带 thread_id，会得到这个：

ValueError: Checkpointer requires one or more of the following
'configurable' keys: thread_id, checkpoint_ns, checkpoint_id

这个报错值得记，因为它把一件事说透了：thread_id 不是可选的上下文，是主键。 没有主键，快照无处安放，框架直接拒绝启动。

对照组很说明问题：同一张图，摘掉 checkpointer 再 invoke，不传 config 也照样跑通。所以"必须有身份"这个要求完全是 checkpointer 带来的，不是图本身的要求。

还有个更容易误解的地方：同一个 thread_id 二次 invoke，不是断点续跑。

上一轮已经走到 END 了，没有待执行节点可续。实际发生的是新输入 merge 进旧快照，然后图从 START 重跑一遍。没传的字段沿用快照里的旧值，带 reducer 的字段跨 invoke 继续追加。

换个 thread_id 就是另一个平行宇宙。同一份图、同一份代码，两个会话各数各的，互不串味。多用户隔离靠的就是这个分区键。

顺带一个坑：想让某个 thread 从零开始，传 history=[] 是没用的。operator.add 追加一个空 list 等于没追加。

update_state 也不是解药。它同样走 reducer------实测过：invoke 之后 history 是 ['a']，update_state({"history": []}) 之后再查，还是 ['a']。只有没有 reducer 的字段 才能被 update_state 直接覆盖；带 reducer 的字段，你写进去的东西仍然要被合并一次。

消息字段要清空得用 RemoveMessage。普通 list 没有对应的删除语义，换新 thread_id 最稳。

5.2 Session 存当下，checkpoint 存历史

拿 Java Session 类比很自然，但类比的边界要划清楚。

Session 里存的是当下的状态。用户这次请求进来，你从 Session 读出来，改完写回去。Session 过期了，这份状态就没了，你没有任何办法知道它曾经是什么。

checkpoint 不一样。同一个 thread_id 下，每一次状态变更都存一份，checkpoint_id 递增，串成一条链。你随时可以回到链上任意一个点。

用一句话概括这个差别：Session 过期是"当下没了"，checkpoint 是"历史还在"。

差的那一个维度叫时间轴。Session 是一个键值对，checkpoint 是一条链。

这条链撑起了三件事：stream 逐步回放、断点续跑、时间旅行。

这里有两个层次，我一开始混成了一个。节点提交的是增量，但框架每一步物化的是一份完整快照。 checkpoint 里存的是 channel_values，源码注释写得很直白：state snapshot at a given point in time。链上每一环都是全量，不是累积的 diff。

那增量协议的意义在哪？在于没有它就生成不出快照。框架要物化"这一步之后的状态"，前提是知道"这一步变了什么"。节点返回增量，框架才有东西可合并、可记录；节点如果就地改状态，框架手上只有一个被改烂的对象，既不知道变化范围，也没法判断这一步该不该单独存一版。

所以第二章第三层的说法要修正一下：不是"存增量才能持久化"，而是 "提交增量，框架才物化得出可持久化的快照" 。存储是快照，协议是增量，两件事。

六、HITL：断点必须活在进程外

人工介入有个天然属性：两次调用之间隔着一个人。

人可能三秒后点确认，也可能第二天才回。这中间进程早就退出了。执行栈、局部变量、内存里的一切，全都没了。

所以断点不能存在内存里，必须落到进程外的持久层。这也是为什么 HITL 和 checkpointer 是绑定关系，而不是"可以一起用"：没有 checkpointer，interrupt() 直接报错，框架不给你这条路径。

lab_04 里我记了三件事。

第一，interrupt(payload) 做的事是存快照加干净退出。 payload 是你递给人的问题单，比如"这个订单金额 8 万，确认放行吗"。它是给人看的，不是给人答的。人给的答案从 interrupt() 的返回值里出来，两者不是同一个东西。

第二，恢复必须用同一个 thread_id，加上 Command(resume=...)。 断点的主键是 (thread_id, checkpoint_ns, interrupt.id) 三元组。thread_id 定位会话，checkpoint_ns 定位子图（HITL 常写在子图里），interrupt.id 定位同一轮里的第几个断点------一个节点可以调多次 interrupt()。三个都对上，才找得到那个待答项。换个 thread 就是换了把钥匙。

第三，resume 会重放节点。 恢复不是从"中断那一行"继续，而是把节点从头再跑一遍，跑到 interrupt() 那里拿到你给的值。

为什么非得重放？因为框架手上只有 state，没有你的执行栈。进程退出那一刻，栈上的局部变量、循环位置、还没返回的调用，全丢了。恢复时它能做的只有一件事：重新执行这个节点。这也意味着 interrupt() 在节点里的位置决定了重放边界------放得越靠后，重放时要重做的事情越多。

所以 interrupt() 之前不能放不可重复的副作用。发邮件、扣库存、调外部接口，重放一次就是做两次。节点得是幂等的。

第三条是这三条里最容易出事的一条，因为它不报错。第一次重放你可能根本没发现，只是某天对账时发现多扣了一笔。

调试的时候，get_state 和 get_state_history 是两个入口：先看 next 里有没有待执行节点，再看 interrupts 里有没有待答项。这两个字段能回答"现在停在哪、在等什么"。

七、从白板到一行

7.1 白板 v1 的四个 bug

W2 收官那天的练习是不看代码、白板手写一遍 agent loop。写完对照正确版本，四个洞：

rounds = 0
while rounds < MAX_ROUNDS:
    resp = llm(messages)
    # ❌ ① 漏了：messages.append(resp)
    if resp.tool_calls is null:        # ❌ ② Java 语法
        break
    for call in resp.tool_calls:
        result = execute(call)
        messages.append(ToolMessage(result, tool_call_id=call.id))
    # ❌ ③ 漏了：rounds += 1

三个洞在代码里，第四个在代码外：只写了应用层这道保险丝，框架层的 recursion_limit 压根没配。

① resp 没入列。下一轮模型看到的历史是"用户提问 + 一堆 ToolMessage"，中间少了那条声明"我要调这些工具"的 AIMessage。有的兼容端点直接拒绝，报 tool_call_id 找不到对应的 assistant 消息；有的默默接受，然后答得莫名其妙。同一个 bug 在不同后端上表现不同，这比直接报错难查十倍。

② is null 是 Java 语法。Python 里它是两个未定义名字的比较，语法合法，跑到这一行才炸。

③ rounds += 1 漏了。rounds 从头到尾是 0，条件 rounds < MAX_ROUNDS 恒真，循环唯一的出口变成了"模型自己不要工具"。模型这轮状态不好一直要工具，程序就跑到你按 Ctrl-C。

④ 保险丝只有一层。上面那道是应用层的，框架层没有。

这四个里，①③④ 一声不吭，② 会报错------但报的是 NameError: name 'null' is not defined。它告诉你有个名字没定义，不会告诉你"这里该写 None"。报错信息指错了方向，有时候比不报错更费时间。

这类 bug 只有亲手写才会长出来。看别人写的正确代码，你看到的是终点，看不到岔路口在哪。

7.2 v2 补的三件事

第二版加了三个东西，都不是白板上原本要求的：

异常包装成观测回喂。 工具炸了不 raise，包成 ERR: xxx 字符串塞回 messages，让模型自己看着办。这是把"工具失败"从异常变成数据，循环不中断。

空回复不判完成。 return Result(resp.text, "done" if resp.text else "empty")。模型返回空字符串和模型正常答完，是两件事。前者要报独立终止原因，不然下游会把"没答出来"当成"答完了"。

token 预算保险丝。 轮数熔断管不住成本，因为一轮可以烧掉几千 token。加一道按 token 计的闸门，比纯轮数更贴近生产。

这三件都不是语法问题，是"知道线上会怎么坏"之后才想得到的东西。

7.3 对账：一行建出的图

手写版在 lab_05_tool_calling.py，228 行，169 行代码。其中真正定义循环骨架的是这五样：State 定义、agent 节点、tools 节点、router、build_graph，合计 52 行代码。

官方模板版是这样：

agent = create_agent(model, TOOLS, system_prompt=SYSTEM_PROMPT)

一行。

跑 get_graph().draw_mermaid()，两张图的拓扑一模一样：START → agent → (条件边) → tools → agent，条件边那条分支指向 END。

节点名一个叫 agent、一个叫 model，边一个实线一个虚线------但把两张图叠起来，形状是同一个。

手写版里的五样东西，模板全包了：State 换成内置 AgentState，agent 节点和 bind_tools 在内部，tools 节点换成内置 ToolNode，router 换成"看最后一条消息有没有 tool_calls"，add_messages 内置。

但有两样模板不给。

一是应用层的 MAX_ROUNDS。模板只有框架层的 recursion_limit，也就是说你失去了软着陆的能力，每次熔断都是异常。

二是可观测性。命中哪个工具、跑了几轮、烧了多少 token，模板不管，要自己打点。

循环的骨架归框架，agent 的业务面归自己。 留给你的就三样：tools、system_prompt、model。

7.4 它并没有更短

这里有个反直觉的账，值得单独说。

裸 SDK 手写版 mini-agent-loop.py 是 83 行，其中 run() 本体 36 行。搬进 LangGraph 之后，建图核心是 52 行。

变长了 16 行。

多出来的是什么？State 类、两个节点拆成独立函数、router 单独一个函数、build_graph 里五处调用。这些在裸 SDK 版里全压在一个 while 循环体里，你不需要给它们起名字。

所以封装的收益不是省行数。省下来的是你不必自己维护的那些不变量：消息成对、增量合并、断点可存。换来的是可中断、可回放、可并行------这三个能力在裸 while 里都不存在。

一行 create_agent 也不是"52 行变 1 行"的意思。它是"52 行里的骨架部分你不用写了"。文件里剩下的 117 行代码（环境配置、模型构建、打印、main）还在，只是不在模板的职责范围里。

7.5 皮在换，骨架没动

还有个细节。旧模板建出来的图，节点叫 agent；新模板叫 model，边也改成了虚线。

名字变了，画法变了，拓扑没变。

create_react_agent 在 LangGraph 1.0 已经标了 deprecated，官方入口迁到 langchain.agents.create_agent，参数从 prompt= 改成 system_prompt=。老教程里那句 import 调下去，会发出 LangGraphDeprecatedSinceV10 弃用警告。

但你手写的那套骨架，一行都不用改。

这件事本身就说明了手写的价值：你学的如果是封装，封装一升级你就得重学；你学的是不变量，皮怎么换都不影响你。

八、八条坑，按怎么发现的分类

下面这些是我这两周真踩过的。按"怎么发现"分三类，因为发现方式决定了它有多贵。

8.1 当场出声型：好查，但暴露版本问题

thread_id 缺失。 上面贴过原文。挂了 checkpointer 就必须给主键，这不是配置疏忽，是设计约束。

HITL 的 API 在 0.x 到 1.x 之间大改。 老教程用 update_state 手工注入人工输入，新版本换成了 interrupt() 加 Command(resume=...)。照着旧文档写，报错会指向一个你根本没调用的方法。

create_react_agent 已废弃。 调用时发出 LangGraphDeprecatedSinceV10 警告。注意它是个 Warning 子类，默认只提醒、不中断，代码照样跑；只有把 warning 提升成 error 才会炸。所以它属于"半静默"------你不管它，它就一直在那里。迁移路径见 7.5。

这三条的共同点是：它当场就出声，错的是你参考的文档版本。 先锁版本再学，比学会再查版本省事得多。

8.2 静默错位型：最贵，测试全绿线上错

resume 重放。 第六章说过，恢复会重跑节点。interrupt() 之前如果有副作用，重放就是重复执行。这条不报错，只在某次对账时暴露。

lab_02 那三个隐患。 一是把轮次寄生在日志字段里，日志一改格式轮次就错位；二是 MAX_ROUNDS 数的是日志条数不是加工轮数，天生差一，多一个写入方就漂移；三是拿 len() 当完成度，字符数既不等于 token 也不等于语义完成。

finish_reason 不是布尔值。 它的取值是 stop / tool_calls / length / content_filter。"没有 tool_calls"只是间接推断，finish_reason 才是 API 直接给的权威信号。尤其是 length------被 max_tokens 截断时必须报独立终止原因，绝不能报 done，否则半句话就进了下游。

这一类的共性是：程序不崩，结果错。 测试跑绿，因为你测的是"有没有异常"，而它压根不抛异常。

8.3 设计缺口型：不报错也不出错，只是迟早付账

框架不防死循环。 保险丝得自己带，理由见第四章。

工具观测在工具边界就会膨胀。 一次检索返回两千字，整段塞回 messages，下一轮 prompt 就涨两千字。而历史每轮重发，成本是复利的。

算笔账。一次检索返回 2000 字，大约 1500 token。这条观测进了 messages 之后，后面每一轮请求都要重发它。跑到第五轮，它已经被计费五次。十个用户各问一个需要五轮的问题，就是五十次。而 token 熔断是事后止损，管不住这个------它只能告诉你"这次超了"，没法阻止那两千字进上下文。

更硬的约束是上下文上限。撞上了直接报 400，整个请求失败。所以裁剪要放在工具返回值那一层：结构化 top-k、每段字符上限、可追溯的引用 id，别留到拼上下文时再做。到那时候成本已经付过了。

这两条不会让程序出错，只会让账单和延迟慢慢变形。

九、回到那个字段

开头那个实验，result 被覆盖、history 留住，原因是两个字段的 reducer 不一样。

现在能说完整了：节点交上来的是增量，reducer 决定怎么合并（状态流）；router 交上来的是字符串，path_map 决定去哪（控制流）。两条线各走各的，互不干扰。

再往外一层，是我手写的 52 行和一行 create_agent 的关系：骨架归框架，业务面归自己。骨架这两周没变过，皮换了两回。

回头看第八章那八条坑，出声型只有三条。剩下五条，加上开头那个被覆盖的字段，全都不吭声。这一行最贵的成本从来不是报错，是它安静地把事情做错。

如果你也在从 Java 转过来，我猜你会在同一个地方卡住：你会下意识觉得状态是你的。 在 Java 里它确实是你的，在 LangGraph 里不是。这个认知切换一旦完成，后面那些机制------增量、reducer、checkpointer、interrupt------都是同一件事的不同侧面。

下一篇会写项目 A：把 W1 的检索包成 @tool 塞进这个循环，做 query 改写、多轮检索和拒答护栏。那是静态 RAG 做不到的部分。

---

附：五道自测题

不看答案，讲一遍。讲不顺的那道，就是没真懂的那道。

0. 节点为什么返回增量 dict，而不是直接改入参？（追问：两个节点都返回同一个字段，最终值归谁？）
1. 没有条件边，为什么造不出 while？（追问：router 的返回值被谁消费？）
2. tool calling 循环和 while 的本质异同是什么？（追问：保险丝为什么从可选变成必装？）
3. checkpointer 为什么必须给 thread_id？（追问：Java Session 这个类比的边界在哪？）
4. HITL 为什么必须先有 checkpointer？（追问：resume 为什么要重放节点？）