智能体与工作流：LangGraph 工作流编排的核心概念解析

在构建复杂的大模型应用时，开发者常面临一个选择：用智能体（Agent）还是工作流（Workflow）？B站UP主老肖在最新一期 LangGraph 系列教程中，对这两个概念进行了清晰的拆解，并指出工作流是解决复杂业务场景的关键。本文基于该视频内容，梳理工作流的核心定义、与智能体的本质区别以及 LangGraph 中的状态图实现，帮助你在实际项目中做出合理的技术选型。

工作流与智能体：编排权的归属

工作流是大语言模型和工具通过预定义的代码路径进行编排的系统。这里的关键词是“编排”——程序员将大模型、工具和业务逻辑按照需求组织成一个图，节点之间的流转关系是显式定义的。一个节点的输出作为下一个节点的输入，甚至可以设计循环回到之前的节点，这一切都由开发者掌控。

智能体则不同。它同样由大模型驱动，能够动态指导自身流程和工具调用，但编排决策是由智能体自身做出的。何时调用工具、调用几次、输出传给哪个工具，都依赖大模型对上下文语义的理解来决策。因此，智能体内部没有程序员预设的显式编排。

据老肖在视频中的解释，两者都是构建复杂大模型应用体系的核心组件，但最大区别在于：智能体拥有自主决策整个流程的能力，而工作流的流程由程序员编排决定。

大模型应用中的「编排」概念

编排（Orchestration）源自分布式系统与服务网格领域，原指对多个独立服务之间的调用顺序、数据传递和异常处理进行统一调度。在大模型应用中，编排的对象变成了大模型调用、外部工具（搜索、数据库、API）以及业务逻辑本身。编排的核心问题是：谁来决定「下一步做什么」——是开发者写死的代码路径，还是模型根据上下文实时推理出的决策。这一区分直接决定了系统的可预测性、调试难度和容错能力。工作流把编排权交给代码，行为可复现、易测试；智能体把编排权交给模型，灵活但存在不确定性。理解编排权的归属，是判断两类架构适用边界的根本出发点。

何时选用工作流？复杂业务下的必然选择

面对单一业务，比如简单的派车请求，智能体往往能够胜任。但当业务变得笼统而复杂，例如一个智能政务办公小助手，可能需要处理大量不同的事项，这时工作流更为合适。老肖提到，未来在智能体开发中可能要调用30多个工具，其中不乏功能相似的工具，完全依赖一个智能体去决策，容易出现“决策幻觉”。

有人会想到用多个智能体来分担，但多个智能体之间谁先执行、谁后执行，本身又回到了编排问题。工作流正是为了解决这类复杂业务场景而生。它支持条件分支、循环和定型执行，通过状态图将多个智能体和任务节点组织成可动态调整的流程结构。（来源：B站UP主老肖）

有意思的是，工作流和智能体并非互斥。你可以在工作流中把智能体当作一个节点使用，也可以完全用工作流替代智能体。老肖认为，工作流可以替代智能体，但智能体替代不了工作流。这是因为智能体的自主决策能力依赖于大模型的推理，而工作流同样可以加入大模型节点专门负责思考，只是这种决策的灵活性不如智能体。

什么是「决策幻觉」

决策幻觉指大模型在面临多个可选工具或分支时，基于语义相似性而非真实业务约束做出错误选择的现象。当工具数量增多且功能高度相似（例如多个查询接口仅参数范围不同），模型容易混淆工具描述，调用不该调用的工具，或遗漏必要的前置步骤。与事实幻觉不同，决策幻觉发生在「选择动作」层面，单靠提示词优化难以根治。缓解手段包括：缩小单次决策的工具集合、用工作流把选择逻辑外置为条件分支、在关键节点加入校验节点。这也是复杂业务倾向工作流的重要工程原因。

状态图：LangGraph 工作流的核心抽象

LangGraph 通过状态图（StateGraph）来定义工作流。状态图由三个关键组件构成：状态（State）、节点（Node）和边（Edge）。状态是应用程序当前快照的共享数据结构，本质上是上下文，用于保存数据；节点是处理单一功能的单元，可以是一个 Python 函数、一个智能体或一个工具，它们接收状态作为输入，执行后返回更新后的状态；边则根据状态中的数据决定下一个执行哪个节点，既可以是固定流转，也可以是条件分支。

老肖用了一个生动的类比：智能体是乐高积木，负责实现具体功能；工作流是搭建规则，定义积木如何组合、何时执行。这种设计既保留了灵活性，又能通过状态管理实现大规模系统的可靠运行。

StateGraph 的状态与检查点机制

LangGraph 中的状态通常以 TypedDict 或 Pydantic 模型定义，并通过 reducer（归约函数）规定每个字段的更新方式，例如追加列表还是覆盖值。这一设计使得多个节点对同一状态的并发更新可以被确定性地合并。状态图编译后还可配合检查点（checkpointer）持久化每一步的状态快照，从而支持中断恢复、人工介入（human-in-the-loop）和时间旅行调试。条件边则是一个返回下一节点名称的函数，它在运行时读取状态并决定分支走向——这正是「编排权在代码」的具体体现。

构建工作流的三步流程

在 LangGraph 中构建一个图，首先需要定义状态，然后根据需求添加节点和边，最后进行编译。节点和边（尤其是条件边）本质上都是 Python 函数，自定义节点只需定义一个 Python 函数即可，非常灵活。

状态图将多个智能体和任务节点组织成可动态调整的流程结构，实现有状态、可扩展的任务编排。开发者以搭积木的方式构建复杂 AI 应用系统，每个节点接收状态、处理业务、返回状态，边则负责控制流向。

选型建议：从业务复杂度出发

回到最初的选型问题，老肖的建议很明确：看业务复杂度。单一、明确的任务用智能体更轻量；涉及多工具、多步骤、需要精确控制流程的复杂业务，工作流是更稳妥的选择。LangGraph 将智能体和工作流结合在同一框架下，开发者既可以单独使用智能体，也可以将智能体作为工作流节点，或者完全用工作流实现智能体的效果。理解编排权的归属，是做出合理架构决策的第一步。