Workflow 与 Agent 有什么区别：从 LangChain 流水线到智能体决策

前言
[1. 为什么需要区分 Workflow 和 Agent](#1. 为什么需要区分 Workflow 和 Agent)
[2. AI Workflow：把智能嵌入固定流程](#2. AI Workflow：把智能嵌入固定流程)
- [2.1 Workflow 的本质](#2.1 Workflow 的本质)
- [2.2 LangChain 中的管道式工作流](#2.2 LangChain 中的管道式工作流)
- [2.3 招聘筛选 Workflow 示例](#2.3 招聘筛选 Workflow 示例)
[3. Agent：围绕目标动态选择行动](#3. Agent：围绕目标动态选择行动)
- [3.1 Agent 的三个核心能力](#3.1 Agent 的三个核心能力)
- [3.2 旅游规划 Agent 示例](#3.2 旅游规划 Agent 示例)
[4. Workflow 与 Agent 的核心区别](#4. Workflow 与 Agent 的核心区别)
- [4.1 从工程维度进行对比](#4.1 从工程维度进行对比)
- [4.2 "确定执行"与"不确定探索"的边界](#4.2 “确定执行”与“不确定探索”的边界)
[5. Agent 与 Workflow 如何组合](#5. Agent 与 Workflow 如何组合)
- [5.1 用 Workflow 提供骨架，用 Agent 处理开放环节](#5.1 用 Workflow 提供骨架，用 Agent 处理开放环节)
- [5.2 企业落地必须补上的控制机制](#5.2 企业落地必须补上的控制机制)
[6. 实际项目应该如何选择](#6. 实际项目应该如何选择)
总结

前言

在大模型应用开发中，Workflow 和 Agent 经常被放在一起讨论。它们都能调用大模型、连接工具并完成任务，因此从最终效果来看，似乎都是"让 AI 干活"。但如果观察任务的执行过程，就会发现两者采用了完全不同的控制方式。

Workflow 更像一条提前设计好的生产流水线：输入从一个节点流向下一个节点，分支条件、执行顺序和异常处理都由开发者预先定义。Agent 则面向一个目标，根据当前环境决定下一步做什么，可能查询资料、调用工具、修改计划，也可能提前结束任务。

Workflow 的核心是预定义流程，Agent 的核心是动态决策。 前者优先追求稳定、可控和可复现，后者优先解决路径无法在开发阶段完全确定的问题。

这并不意味着 Workflow 完全没有智能，也不意味着 Agent 可以不受限制地自由行动。一个 Workflow 节点可以调用大模型，一个 Agent 也必须受到工具权限、执行步数和业务规则的约束。理解二者的关键，不是看"有没有调用 LLM"，而是看谁在决定下一步行动。

1. 为什么需要区分 Workflow 和 Agent

传统软件擅长处理规则明确的问题。例如报销审批可以写成"金额小于 5000 元由直属主管审批，否则增加财务审批"；订单系统也可以按照支付、库存、发货等状态依次流转。这类任务的路径在开发阶段已经清楚，使用普通流程引擎就能稳定运行。

大模型出现以后，流程中的某些节点获得了处理非结构化信息的能力，例如总结文本、识别图片、抽取简历字段和生成回复。于是，一个传统流程可以变成 AI Workflow：它的路径仍然由系统规定，只是部分节点由 AI 完成。

然而，旅游规划、复杂检索和故障排查等任务很难事先列出所有步骤。用户的预算、实时天气、机票价格和签证要求会改变下一步动作，开发者无法为每种情况画出完整流程图。这类问题需要系统在运行时观察环境并调整方案，Agent 因此出现。

判断问题	Workflow	Agent
谁决定下一步	开发者预先定义的流程	模型结合目标与当前状态动态决定
路径何时形成	开发或配置阶段	任务运行阶段
主要优势	稳定、可控、容易审计	灵活、能应对未知情况
主要代价	难以覆盖大量动态分支	成本、时延和结果波动更大

2. AI Workflow：把智能嵌入固定流程

2.1 Workflow 的本质

Workflow 是一套预先定义的任务编排。它接收输入，让数据按照既定规则经过多个节点，最终产生输出。每个节点通常只负责一种能力，例如调用 LLM、查询数据库、执行条件判断、生成图片或等待人工审核。

一条常见的 AI Workflow 可以表示为：

text 复制代码

用户输入
   ↓
参数校验
   ↓
调用 LLM 提取结构化信息
   ↓
条件判断 ── 不满足条件 ──→ 人工处理
   ↓ 满足条件
调用图片生成模型
   ↓
内容安全检查
   ↓
返回结果

在 Coze 等可视化平台中，开发者通过拖拽输入、判断、LLM、图片生成和输出节点来构建这种流程。在代码环境中，也可以使用 LangChain 的 Runnable 接口连接不同处理步骤。无论采用图形化界面还是代码，核心思想都相同：节点完成局部工作，边决定数据如何流转。

从图结构看，一个 Workflow 通常由以下元素组成：

节点（Node）：执行一次具体操作，是流程的基本工作单元。
边（Edge）：连接节点，描述执行顺序和数据流向。
状态（State）：保存输入、中间结果、错误信息和最终输出。
分支与循环：根据规则选择路径，或在满足条件前重复执行。
失败处理：负责重试、降级、超时和人工接管。

这里所说的"固定"是指编排关系固定，不是每个节点的结果都固定。如果某个节点调用了大模型，即使输入相同，输出仍可能受模型版本、上下文和采样参数影响。工程上通常还需要结构化输出、结果校验和低随机性配置来提高稳定性。

2.2 LangChain 中的管道式工作流

LangChain 为 Prompt、模型、输出解析器和工具提供了统一的 Runnable 接口。只要一个组件可以接收输入并返回输出，就能通过 pipe() 与下一个组件组合。

下面的示例把"主题"依次传给 Prompt 模板、创意模型和字符串解析器：

javascript 复制代码

import "dotenv/config";
import { ChatOpenAI } from "@langchain/openai";
import { PromptTemplate } from "@langchain/core/prompts";
import { StringOutputParser } from "@langchain/core/output_parsers";

const storyPrompt = PromptTemplate.fromTemplate(`
请围绕"{topic}"写一个 200 字左右的中文段落。
要求观点明确，包含一个具体应用场景。
`);

const creativeModel = new ChatOpenAI({
  // 通过环境变量切换兼容的模型，避免把部署配置写死在业务代码中
  model: process.env.MODEL_NAME,
  temperature: 0.8,
});

const outputParser = new StringOutputParser();

const creativeChain = storyPrompt
  .pipe(creativeModel)
  .pipe(outputParser);

const result = await creativeChain.invoke({ topic: "AI" });
console.log(result);

运行示例需要安装以下依赖：

bash 复制代码

pnpm i dotenv @langchain/core @langchain/openai

依赖	作用
`dotenv`	从 `.env` 加载模型名称、API Key 等环境变量
`@langchain/core`	提供 Prompt、输出解析器和 Runnable 组合能力
`@langchain/openai`	提供兼容 OpenAI 接口的聊天模型适配器

这段代码中的每个对象都是一个工作节点。storyPrompt 将 { topic: "AI" } 转换成模型可以理解的提示词；creativeModel 调用大模型并返回消息对象；StringOutputParser 再从消息中提取纯文本。invoke() 从链的入口启动一次执行，上一个节点的输出会成为下一个节点的输入。

pipe() 的含义不是"同时运行"，而是按照连接顺序传递数据。它类似传送带或水管：每一段只处理自己负责的数据，然后把结果交给下一段。

这条链不会在运行时自行插入"搜索资料"或"检查事实"步骤。即使模型认为应该先查询信息，它也没有改变流程的权力。需要新增节点时，必须由开发者修改链条，这正是 Workflow 的控制方式。

2.3 招聘筛选 Workflow 示例

招聘初筛具有明确的输入、处理步骤和输出格式，很适合使用 Workflow。系统可以按照下面的流程处理简历：

text 复制代码

PDF 简历
   ↓
解析 PDF 文本
   ↓
提取技能、工作经历、教育经历
   ↓
从岗位知识库检索要求（RAG）
   ↓
匹配硬性条件并计算分数
   ↓
排序并生成理由
   ↓
人工复核

第一步负责把 PDF 转成可处理的文本；第二步使用模型或解析规则生成结构化字段；第三步通过 RAG 检索岗位要求，避免只依赖模型记忆；第四步执行企业明确规定的匹配规则；最后输出候选人排名和评分依据，并交由招聘人员复核。

这个流程可能包含条件分支，例如"解析失败则转人工录入""缺少毕业时间则要求补充材料"。但分支条件仍然由系统预先设计，所以它仍属于 Workflow，而不是 Agent。有判断和循环不等于 Agent，关键在于判断规则由谁制定。

3. Agent：围绕目标动态选择行动

3.1 Agent 的三个核心能力

Agent 接收的通常不是一串完整步骤，而是一个需要完成的目标。为了到达目标，它需要形成"观察、决策、行动、再观察"的闭环。

感知环境：理解用户输入、图片、文件、工具列表、历史消息和工具返回结果。
规划路径：分析目标并选择下一步行动，必要时拆解子任务、调整顺序或放弃无效方案。
执行行动：调用搜索、数据库、代码执行器等工具，把执行结果重新加入上下文，再决定是否继续。

记忆经常被称为 Agent 的另一项能力，但它更准确地说是对状态的管理。短期记忆保存当前任务的消息和工具结果，长期记忆保存跨任务的用户偏好与历史经验。没有可靠的状态，Agent 就无法根据前一步结果调整后续行动。

一个简化的 Agent 循环如下：

javascript 复制代码

const messages = [userMessage];

for (let step = 0; step < MAX_STEPS; step += 1) {
  // 模型不仅生成文字，还可以选择一个已授权工具及其参数
  const decision = await modelWithTools.invoke(messages);
  messages.push(decision);

  const toolCalls = decision.tool_calls ?? [];

  if (toolCalls.length === 0) {
    return decision.content; // 模型认为信息已经足够，结束任务
  }

  for (const toolCall of toolCalls) {
    validatePermission(toolCall); // 执行前校验工具、参数和权限
    const observation = await tools[toolCall.name].invoke(toolCall.args);
    messages.push(toToolMessage(toolCall, observation));
  }
}

throw new Error("Agent 超过最大执行步数");

这段代码是用于说明原理的简化伪代码。modelWithTools 每轮都能看到目标、历史行动和最新工具结果。如果信息足够，它直接返回答案；如果信息不足，它生成工具调用；工具结果被追加到 messages 后，模型进入下一轮判断。

Workflow 的下一步通常由代码中的连线决定，而 Agent 的下一步由 decision 在运行时产生。这是二者最核心的技术差异。

3.2 旅游规划 Agent 示例

假设用户提出："帮我规划国庆从上海出发的五天旅行，预算 8000 元，希望天气凉爽，不想转机。"这不是一个只靠固定模板就能完成的任务，因为实时价格、天气和用户偏好会共同影响方案。

Agent 可能先搜索符合气候要求的目的地，再查询直飞机票和酒店。如果发现某个目的地机票上涨导致预算超支，它会放弃原方案并查询其他城市；如果目的地临时出现极端天气，它还需要重新规划。另一次执行中，Agent 也可能先检查预算，再缩小目的地范围。

text 复制代码

目标：生成满足偏好和预算的五天行程
   ↓
思考：先筛选天气凉爽的候选城市
   ↓
行动：调用天气工具
   ↓
观察：城市 A 有暴雨，城市 B 天气合适
   ↓
思考：检查城市 B 的直飞机票和酒店总价
   ↓
行动：调用机票、酒店工具
   ↓
观察：总价超出预算
   ↓
调整：更换日期或探索城市 C

这种路径无法在开发时完全写死。Agent 的价值正是根据观察结果动态改变下一步。不过，它仍应遵守明确边界：预算不能擅自修改，订票前必须让用户确认，支付工具需要单独授权，搜索轮数也要设置上限。

4. Workflow 与 Agent 的核心区别

4.1 从工程维度进行对比

对比维度	Workflow	Agent
控制中心	流程图、代码规则或状态机	大模型的运行时决策
执行路径	提前定义，通常可枚举	根据环境动态生成
LLM 的角色	完成某个具体节点	决定下一步行动，必要时也生成内容
工具调用	在指定节点调用指定工具	从允许的工具集合中选择工具
稳定性	较高，容易复现和测试	相对较低，路径可能变化
可解释性	能直接查看节点和分支	需要记录决策、工具调用与状态变化
成本与时延	通常比较容易估算	受循环轮数和工具调用次数影响
异常处理	预设重试、降级和人工节点	可以动态调整，但仍需硬性保护机制
典型场景	审批、抽取、批处理、标准客服流程	复杂搜索、研究、规划、故障诊断

用一个直观比喻来说，Workflow 像一条路线清晰的高速公路：入口、出口和岔路都提前修好，车辆可以高效到达既定终点。Agent 更像一名知道目的地的司机：它可以根据拥堵、施工和天气调整路线，但必须遵守交通规则、车辆能力和用户要求。

这个比喻强调的是决策方式，而不是能力高低。对于每天重复上万次的发票抽取任务，自主改道并不会带来价值，反而增加成本和风险；对于开放式市场调研，强行画出所有分支又可能让系统极其复杂。

4.2 "确定执行"与"不确定探索"的边界

把 Workflow 概括为"确定的执行"、把 Agent 概括为"不确定的探索"有助于快速入门，但工程实践中需要进一步拆开两种不确定性：

不确定性	具体含义	Workflow 是否可能存在	Agent 是否可能存在
路径不确定	下一步执行哪个节点无法提前确定	较少，通常由固定条件控制	核心特征
输出不确定	相同输入可能得到不同文本	调用 LLM 的节点会存在	同样存在

因此，一条包含 LLM 的 Workflow 仍可能生成不同文案，但它始终按照"Prompt → 模型 → 解析器"的顺序执行。相反，一个使用低温模型的 Agent 即使每轮输出很稳定，也仍然可能根据工具观察结果选择不同路径。

判断系统属于哪一种，不要只看它是否使用大模型、是否调用工具，或者是否包含条件判断，而要追问：模型能否根据当前状态自主选择下一项行动？

5. Agent 与 Workflow 如何组合

5.1 用 Workflow 提供骨架，用 Agent 处理开放环节

真实企业应用往往不会在 Workflow 与 Agent 之间二选一，而是组合两者。外层 Workflow 负责稳定的业务阶段、权限和审核，内层 Agent 只处理难以提前定义路径的局部任务。

以招聘系统为例，整体仍然按照固定流程运行，但"补充候选人公开项目背景"可以交给一个受控 Agent：

text 复制代码

Workflow：接收简历
   ↓
Workflow：解析并脱敏
   ↓
Agent：在授权数据源中调研项目经历
   ↓
Workflow：校验 Agent 输出格式和证据链接
   ↓
Workflow：根据固定评分规则计算结果
   ↓
Workflow：提交人工复核

Agent 不直接决定录用结果，也不能访问未授权数据。它只负责搜索路径不固定的调研环节，并把结构化结果交回 Workflow。这样既利用了 Agent 的灵活性，又保留了业务流程的可控性。

更准确的说法是：Workflow 是系统的骨架，Agent 是其中可动态决策的执行单元。 Agent 不一定是整个系统唯一的"大脑"，关键业务规则、权限边界和最终责任仍应掌握在确定性代码与人类手中。

5.2 企业落地必须补上的控制机制

Agent 的自主性越高，越需要明确边界。一个可上线的混合系统通常需要以下保护机制：

工具白名单：Agent 只能看到并调用完成当前任务所需的工具。
参数校验：使用 Schema 检查工具参数，拒绝危险或无效输入。
权限隔离：查询、写入、支付和删除使用不同授权等级。
预算限制：限制模型 token、工具调用次数、执行时长和总费用。
过程记录：保存节点状态、工具参数、工具结果和错误，便于审计。
人工确认：付款、发送外部消息、删除数据等高风险动作必须确认。
回退策略：模型失败、工具超时或结果置信度不足时转入固定流程。

这些限制不会削弱 Agent 的价值，而是定义它可以安全探索的空间。企业购买的不是一个"想做什么就做什么"的模型，而是一套能在业务责任边界内完成目标的系统。

6. 实际项目应该如何选择

选择方案时，可以先问四个问题：任务步骤能否提前写清楚、错误代价是否可接受、是否需要审计每个环节、环境是否会频繁变化。

任务特征	推荐方案	原因
步骤固定、规模大、重复执行	Workflow	成本可估算，便于测试和监控
合规要求高、错误代价大	Workflow + 人工审核	关键决策路径清晰，责任边界明确
路径难以枚举、需要多轮搜索	受控 Agent	能根据中间结果改变计划
大部分流程固定，局部需要探索	Workflow + Agent	在稳定流程中引入有限自主性
只是一次 Prompt 调用	普通函数或简单 Chain	没有必要引入完整 Agent 循环

一个实用原则是：能用普通代码解决，就先用普通代码；路径固定时使用 Workflow；只有下一步确实需要模型在运行时判断时，才引入 Agent。 Agent 会增加评测、监控、安全和成本控制的复杂度，不应该只因为概念热门就成为默认选项。

对于流程性强的工作，例如审批、数据清洗、批量抽取、标准化客服回复，Workflow 通常更合适。对于复杂资料搜索、策略规划、跨工具故障排查等开放任务，可以采用 Agent。大多数成熟系统最终会形成混合架构：确定性代码守住边界，Workflow 编排主流程，Agent 在指定范围内处理变化。

总结

Workflow 与 Agent 的本质区别，不在于是否使用大模型，而在于下一步行动由谁决定。Workflow 在开发阶段定义节点、顺序、分支和异常处理，擅长稳定地执行流程化、重复性任务；Agent 在运行阶段根据目标、当前状态和工具结果动态选择行动，擅长处理路径无法提前穷举的开放问题。

LangChain 的 pipe() 可以把 Prompt、模型和输出解析器组合成清晰的数据流水线，体现了 Workflow 的节点式编排方式。Agent 则在此基础上增加"观察---决策---行动"的循环，让模型能够选择工具并根据新信息调整计划。但自主性也会带来成本、时延、审计和安全风险，因此必须设置工具白名单、权限控制、执行上限与人工确认。

真正实用的 AI 工程通常会结合两者：用 Workflow 提供稳定的业务骨架和确定性边界，用 Agent 处理少量需要动态探索的环节。这样构建出的系统既能获得大模型的灵活性，也能满足企业对可靠性、可控性和可追踪性的要求。