Edge 和 Conditional Edge：让流程根据状态分支

上一篇文章里，我们讨论了 Node 应该怎么设计。

一个重要结论是：

Node 最好职责明确，输入输出清楚。

但有了 Node 之后，还差一步：

节点之间怎么连接？

这就是 Edge 的作用。

在 LangGraph 里，Edge 不只是把两个节点连起来。

它更像是流程控制的路由规则。

如果再加上 Conditional Edge，就可以让系统根据 State 决定下一步走哪里。

这篇文章就讨论：

Edge 和 Conditional Edge 为什么重要？它们如何让 Agent Workflow 变得灵活又可控？

Edge 的作用是什么？

最简单的 Edge，就是固定连接。

例如：

节点 A
↓
节点 B
↓
节点 C

这种情况适合线性流程。

比如：

接收问题
↓
格式化输入
↓
调用模型
↓
整理输出

Edge 的作用是定义流程方向。

它告诉图：

这个节点执行完，接下来应该去哪里

如果没有 Edge，Node 只是孤立函数。

有了 Edge，Node 才组成流程。

Conditional Edge 解决什么问题？

很多 Agent 流程不是固定路径。

它要根据当前状态决定下一步。

比如：

判断用户问题类型
├─ 普通问答
├─ 知识检索
├─ 工具调用
└─ 人工确认

这时候如果还用固定 Edge，就不够了。

你需要 Conditional Edge。

它的本质是：

根据当前 State 的内容，选择不同的下一条边

比如：

如果 need_retrieval = true，走检索节点
如果 need_tool = true，走工具节点
如果 need_human = true，走人工确认节点
否则直接结束

这就是 Agent Workflow 的灵活性来源。

分支是 Agent 复杂度的第一来源

Agent 为什么比普通 Chain 难？

很大一部分原因就是分支。

例如一个问题进来后，系统可能先判断：

是知识问题吗？
是执行问题吗？
是风险操作吗？
需要继续追问吗？

每个判断都可能导致不同流程。

如果没有 Conditional Edge，就只能在一个节点里写大量分支判断。

这样会让节点越来越重。

更好的方式是：

判断节点负责给出状态
Conditional Edge 负责选择路径
后续节点负责各自任务

这样职责更清楚。

Conditional Edge 不只是 if else

有些人会觉得 Conditional Edge 就是把 if else 挪到图里。

不完全对。

它的价值在于：

判断逻辑显式化
流程路径显式化
状态驱动显式化

这和把条件塞进某个 Node 里有本质区别。

因为图结构能让你一眼看出：

什么状态会走哪条路
哪些分支是可能的
哪些路径可以回环
哪些路径会结束

这对调试和维护很重要。

一个简单例子

假设做一个 RAG Agent。

流程可以这样设计：

接收用户问题
↓
判断是否需要检索
├─ 需要：检索知识库
└─ 不需要：直接回答

检索之后再判断：

判断检索结果是否足够
├─ 足够：生成答案
└─ 不足：改写问题或追问用户

这整个流程就是靠 Edge 和 Conditional Edge 连接起来的。

它把“下一步去哪里”的决策从代码块中抽出来了。

Edge 的设计要和 State 绑定

Conditional Edge 的判断依据，通常来自 State。

比如：

need_retrieval
need_tool
need_human_review
retry_count
is_answerable

这些状态字段决定流程往哪走。

所以 Edge 设计不是独立问题。

它必须和 State 设计一起考虑。

如果 State 没设计好，Edge 也很难设计好。

路由条件要尽量简单、明确

一个好的条件边，最好判断清晰。

比如：

retry_count > 3
need_human_review == true
retrieval_results is empty

不要让路由条件依赖太模糊的文本。

比如：

如果感觉不太对就重试
如果模型好像答得不稳就转人工

这种规则不利于维护，也不利于测试。

更好的做法是把判断结果结构化。

例如：

confidence_score = 0.42
should_continue = false
need_more_context = true

这样 Conditional Edge 就能更稳定地工作。

回边和循环边也很重要

Edge 不只是向前走。

很多 Agent 还需要回边。

比如：

检索结果不足
↓
改写问题
↓
重新检索

或者：

工具调用失败
↓
重试
↓
再次调用工具

这些回边让系统具备循环能力。

但回边必须有边界。

否则就会变成死循环。

所以循环边通常还要结合：

最大重试次数
最大步数
超时控制
兜底路径

这也是为什么 Graph 比线性流程更适合 Agent。

Edge 要帮助你读懂图

好的 Edge 设计，不只是让程序跑通。

它还应该让图更容易读。

比如一个客服 Agent：

intent_classification
↓
conditional routing
├─ knowledge_search
├─ order_query
├─ refund_flow
└─ human_review

这比一段包含大量 if else 的函数清楚得多。

一眼看过去，你就知道系统有哪些主要路径。

常见误区

第一个误区，是所有流程都只用固定 Edge。

这样流程太死，不像 Agent。

第二个误区，是所有判断都塞进节点里。

这样节点会越来越乱。

第三个误区，是条件过于模糊。

路由条件应该尽量结构化。

第四个误区，是循环没有边界。

能回去，不代表可以无限回去。

第五个误区，是图画得很复杂，但没人看得懂。

Edge 的目标是清晰，不是炫技。

总结

Edge 是 LangGraph 里把节点串起来的基本结构。

Conditional Edge 则让流程能根据 State 动态分支。

它们的价值，不只是连接节点，而是让 Agent Workflow 具备：

分支能力
循环能力
路由能力
恢复能力

如果说 Node 是做事的人，那么 Edge 就是决定去哪里的路线。

下一篇文章，可以继续讨论 Reducer。

因为一旦流程开始分支或并行，多个节点就可能同时更新同一份 State，这时候就需要明确如何合并。