SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

LangGraph 和工作流引擎:一个画分镜,一个管剧场

搭建 Agent 系统时,团队容易把 LangGraph 和工作流引擎放在一起比拼。但 LangGraph 是帮你定义 Agent 的决策图、状态流转和工具调用逻辑的框架,工作流引擎是运行和调度这些流程的基础设施。选框架和选跑道是两次独立的判断。

寓言

编剧室和剧场后台

一座新剧场建好后,运营团队开始筹备首演。编剧组负责写剧本:角色什么时候上场,什么时候对话,什么时候独白,遇到观众不同反应时走哪条支线。后台组负责剧场运转:幕布升降、灯光切换、道具调度、演员候场叫号。

制作人第一次开会时把两件事写在了同一张采购清单的同一行里,标题叫“演出系统”。他找了三家供应商比价,其中一家报价低是因为它的后台自动化系统很强,但剧本工具几乎不能用;另一家剧本编辑体验极佳,后台调度却很原始。制作人按总价排序选了第一家。

首演前一周联排崩溃了。演员按照新改的剧本需要做一个快速的情绪转折——前一句还在争吵,下一句要切换到独白。编剧组的工具完全支持这个跳跃,但后台的灯光系统反应不过来,从争吵光切换到独白追光需要四秒。四秒的空白里,演员站在台上等灯,观众席的窃窃私语盖过了台词。

复盘时灯光师说了一句大实话:你写的剧本可以在一秒内切换十次情绪,但我的聚光灯电机最快也要三秒到位。两个系统的速度上限不一样,按同一行比价,便宜的那个把慢系统当成了整体成本锚点。

制作人改了流程。以后所有演出立项,剧本工具和后台系统分两轮评估。第一轮只比剧本工具的图表达能力、分支编辑和多版本管理——不管后台。第二轮只比后台系统的并发调度、延迟和容错——不管剧本。两轮各自排出前三名,最后再交叉配型。

配型时发现了一个意外的好组合:选了一家专注非线性叙事编辑的剧本工具,配了一家做工业自动化出身但稳定性和延迟控制很扎实的后台系统。两者从未在同一张报价单里出现过,分开评估才浮出水面。

后来剧场的运营手册里有一条铁律:创作工具和运行基础设施的采购决策不能合并。合并会让其中一个系统的短板压住另一个系统的长处,最终买到的是一个妥协方案,不是最佳组合。

LangGraph

一个用于构建有状态、多步骤 Agent 应用的框架,通过图结构定义 Agent 的决策逻辑、状态流转和工具调用路径。回答“Agent 该怎么思考、怎么行动”。

工作流引擎

承载工作流定义并负责调度、执行、监控和容错的基础设施。回答“流程在什么环境下跑、怎么保证可靠性”。

故事对应

  • 编剧组写剧本和分支逻辑:LangGraph,定义 Agent 的状态图和决策路径
  • 后台组管幕布升降和灯光切换:工作流引擎,负责流程的执行调度
  • 制作人把剧本和后台写在同一行采购:合并选型让其中一个系统的短板拖累另一个
  • 分开评估再交叉配型:框架和运行时各自独立选型能得到最优组合

落到 Agent 架构选型里

Agent 系统架构评审时把“用什么框架定义 Agent 行为”和“用什么引擎运行和调度这些流程”分成两轮决策。框架选型比的是图表达能力、状态管理和工具集成;引擎选型比的是并发吞吐、延迟分布、故障恢复和运维成熟度。两轮结果各自出短名单,不合并打分。预算上也是两条线:框架按开发效率算 ROI,引擎按运行时资源算 TCO。