两条框架经常被放在一起比较，因为后出现的图运行时是在链的组件之上补的一层。真正要分的不是谁更新，而是你的任务会不会在中途改路。
链在做什么
| 问题 | 用链 | 用图 |
|---|---|---|
| 步骤能否在开工前写死 | 能 | 不能，要看上一步 |
| 同一步会不会重复 | 通常不会 | 会，并要有次数上限 |
| 停机写在哪 | 链的最后一段 | 状态里的停机原因 |
| 调试看什么 | 每一段的输入输出 | 每一次节点写下的字段 |
链适合事先能写完的顺序：准备输入，调用模型，必要时检索一段资料，再把文本交回去。提示模板、检索器、工具的参数格式，都可以当成链上的一段。输入输出清楚，调试时按段看日志即可。
发票名录核对如果只做一次查询、一次判断，链就够。把供应商名称交给检索，把命中的名录行交给模型，输出“在名录内”或“不在”，中间没有第二轮决策。
图在做什么
图把一次运行写成一份状态。常见字段是目标、当前步骤、上一步观察、工具名、工具结果、已重试次数和停机原因。每个节点只改自己负责的字段。边根据字段决定下一节点，也可以回到刚才的节点。
同一张发票如果第一次没检索到，就要换一个查询词再查，这就是回路。回路必须带上限。两次仍无依据，就写下停机原因，交给人，而不是让节点互相调用到超时。
不要把分支藏进提示词
有人两套库一起引用，分支却只写在提示词里：“如果不确定就再试一次”。模型是否再试，日志里看不出来，停机条件也无法单测。分支应是一条条件边，条件是状态里的一个字段，而不是一句希望。
选型可以很具体。路径在开工前已经定死，用链。路径取决于上一步的观察，或同一步可能重复，用图。图并不使回答更正确，它只是把重复和停止写成可以检查的结构。
上线前用十张旧单子看一遍
从最近的失败里抽十张单子，不要用演示数据。先标出每张单子实际走过的步骤：哪些是开工前就知道的，哪些是看到上一步结果才决定的。若十张里有八张走同一条直线，就保持链，把那两条例外写成人工出口，不要为了例外上图。
若有一半要回头，再画状态。状态字段先只留目标、观察、次数和停机原因，跑两天再加别的。加字段之前问一句：这个字段会不会改变下一条边。不会，就不要加，否则图和链一样难读。
改完后把同一张失败单子重放。重放应停在你写下的原因上，而不是停在超时。停在超时，说明边的条件没有覆盖这种失败。
常见问题 FAQ
LangChain 和 LangGraph 能一起用吗？
可以。模型封装、检索器和工具格式仍放在链的组件里，循环、分支和停机放到图的边上。
直线的检索问答需要上图吗？
不需要。一次检索、一次生成、没有回头，链更短，也更容易对照日志。
图为什么一定要写重试上限？
条件边允许回到同一节点。没有上限时，检索失败会一直改写查询，直到请求超时。
分支写在提示词里有什么问题？
提示词不会在日志里留下“走了哪条边”。以后无法单测停机条件，也无法统计哪一步在空转。
已有链，怎样判断该不该改成图？
看最近十次失败。如果失败都是中途要换路或再查一次，就值得把那一段改成带状态的节点。