LangGraph 实战总结——图编排 vs 手工调度，什么时候该用哪个

2026.07.08 · 约 2500 字

花了两天，用 LangGraph 搭了一个多 Agent 文档分析流水线。

出发点很简单：我的体系里一直是用 delegate_task 做多 Agent 编排的（Supervisor 拆任务 → 派给 Worker → 聚合结果）。LangGraph 的 StateGraph 是另一种路子——你画一张图，Agent 按图走。我想知道：这两种方式，什么时候该用哪个？

两天实践下来，答案比我想象的清晰。

一、我搭了什么

一个 5 节点的 StateGraph：

Supervisor → Retriever → Analyst → Quality → End

每个节点做什么：

Supervisor — 接收问题，拆解任务
Retriever — 检索知识库。如果结果不足 → 走 Rewrite 改写查询再查
Analyst — 分析文档内容
Quality — 验证结果质量。不过关 → 重试

整个流程跑在阿里云 1.6GB 的小机器上，后端 FastAPI，前端是 entos.top 上的一个交互页面。你可以在这里体验：

🧪 在线体验流水线执行

二、LangGraph 让我觉得好的地方

1. 条件边是真正的"声明式路由"

在 delegate_task 方案里，条件判断是写在 Supervisor 的代码里的。在 LangGraph 里，条件边是一等公民——你看一眼图结构就知道整个流程怎么走的，不需要读代码逻辑。这在复杂流程时价值很大。

2. 状态管理内置

delegate_task 要自己管理状态——Supervisor 记住每个 Worker 返回了什么、当前进度到哪里了。LangGraph 的 State 是图级别的，每个节点读写同一份。这对重试循环场景特别好用。

3. 可观测性基础设施

LangGraph 内置了 LangSmith 集成。每个节点的输入输出、条件边的决策、耗时——开箱即有。我自己搭的方案要手动加日志。

三、LangGraph 让我觉得不爽的地方

1. 静态图就是静态图

StateGraph 要求在编译时把结构定死。部署后就不能改了。而 delegate_task 是运行时动态决定的——Supervisor 可以根据当前对话的上下文实时决定下一步派给谁。动态决策场景不适合静态图。

2. 调试体验不如预期

LangGraph 的图是黑盒推理——你得理解图引擎的执行逻辑才能搞清楚状态怎么流转。delegate_task 的调试思路更直接——就是函数调用链。

3. 小项目太重

3 个节点以下的流程，delegate_task 20 行搞定。LangGraph 要装包、定义 State、注册节点、配置条件边——门槛高得多。

四、最终判断

对比维度	LangGraph	delegate_task
流程确定性	✅ 预先画好的图	⚠️ 运行时动态决定
状态管理	✅ 图级 State 内置	❌ 需要自己管理
条件路由	✅ 声明式	⚠️ 散落在代码里
动态决策	❌ 编译后不可改	✅ 随时决定下一步
调试门槛	⚠️ 需要理解图引擎	✅ 函数调用链
小项目（≤3节点）	❌ 太重	✅ 20 行搞定
复杂流程（≥6节点）	✅ 图结构清晰	⚠️ 代码膨胀
入门成本	2-3 天	0（已在用）

我的结论

不是替代关系，是互补关系。 在我的体系里，Supervisor 先用 delegate_task 做动态决策——"这个问题该走哪个流程？"决策完之后，如果确定是一个预先可知的固定流程图，就交给 LangGraph 按图执行。

LangGraph 的位置： 一个可选的编排引擎，在需要严格按图执行的场景下按需启用。不替代 delegate_task，不替代 Harness，不替代记忆系统。

五、我的选择

目前我的系统里大多数流程是动态决策型的。所以 delegate_task 仍然是我的主力编排方式。

但我给 LangGraph 留了一个位置：对于固定的、已知的多步操作流程，以后用 LangGraph 替代手写 if/else。

换句话说：

对话/交互场景 → delegate_task（动态决策）
管道/批处理场景 → LangGraph StateGraph（静态图）

最后说一句：最好的框架决策，不是"用一个替代另一个"，而是"知道什么时候该用哪个"。