别再混为一谈：Workflow 和 Agent 本来不是一回事

故事要从一个纠结的下午讲起

前些日子替朋友搭建简历初筛工具时，我盯着 LangChain 文档研究了一下午，始终拿不定主意：应该用 Chain 拼出一个 Workflow，还是干脆采用 Agent？

现在说来有些丢人，当时我确实觉得两者差别不大 —— 反正都是让 AI 按步骤做完任务，也都要调用大模型、处理输入输出，名称不同又有什么关系？

我凭直觉先实现了 Workflow 版本，仿照平时搭 LangChain 链的方式，把 PDF 解析、信息提取、岗位匹配、打分排序等节点通过 pipe 串联起来。一份简历输入后按流程跑完，结果便直接输出。刚跑通时我还颇为得意，心想事情已经完成，哪里还用得上 Agent。

没想到同事转头便回了一句：“这种简单场景当然看不出区别，你让它做一次市场调研试试？Workflow 马上就会卡死。”

这番话让我愣住了：调研不也是依次搜索资料、整理并总结吗，为什么 Workflow 就做不了？

先谈我的 Workflow 理解：它是一条预先铺好的传送带

于是我回过头，重新梳理 Workflow 的运行逻辑。

简单说，它就像工厂流水线：每一步做什么、接收什么输入、把输出交给谁，都由你预先规定。启动后，物料从入口依次经过各道工序，最终从出口成为成品。过程中不会意外改道；条件满足便进入下一节点，不满足则走指定分支，全部环节都处于你的控制之中。

以我写的那条最简单链为例：

const creativeChain = storyPrompt.pipe(creativeModel).pipe(outputParser)// 就这么三步：拼提示词 → 丢给大模型 → 解析输出// 输入啥输出啥明明白白，不会多干一步也不会少干一步creativeChain.invoke('写一个关于 AI 的故事')

这里的 pipe 就像传送带，把上一步的结果直接递到下一步手里。LangChain 本质上就是帮你快速搭这种流水线的框架，节点多了还能加上条件判断、循环，拼成更复杂的图谱。现在很多工程里的流程自动化，本质也都是这个思路，把重复性的工作串起来，人只需要关注核心逻辑。

放在简历筛选场景中会更加直观： 第一步接收简历 PDF 并解析为纯文本； 第二步提取技能、工作经历和学历等关键字段； 第三步用这些字段匹配岗位 JD； 最后依据匹配度完成打分排序。

因为整套流程都是提前定义的，它既不会突然查询候选人的社交媒体，也不会自行增加面试题环节。其优势在于稳定、可控且便于调试，出现故障时可以迅速查明是哪个节点出了问题。

我之前在 Coze 搭建 AI 照相馆工作流时也是同样的原理 —— 拖入用户上传照片、调用抠图工具、替换背景、生成图片、返回结果等节点。用户付费购买的是稳定流程，总不能任由 AI 发挥，把照片 P 成稀奇古怪的模样。

实际上，多数企业 AI 提效场景的本质都是 Workflow：把原来由人工完成的流程交给 AI 节点执行，速度更快，也不容易出错。若向老板提议此类场景使用 Agent，对方多半会反问：“它万一乱来，由你负责？”那么 Agent 究竟特别在哪里？

过去我一直把 Agent 看作更高级的 Workflow，以为它只是增加了工具调用能力。直到查看 ReAct 的实现逻辑并运行几个 Demo，我才明白两者完全不同 —— 它们的底层逻辑从根本上就存在区别。

Workflow 的道路由你预先铺设，它只负责沿路运行。 Agent 则只接收目的地，具体道路由它自行寻找。

可以把 Agent 看成代驾司机。你只说“去机场”，后续便无需操心：它会查看导航并选择最近路线，遇到堵车就绕行，高速封闭则改走国道；即便中途改口说“不去机场了，改去高铁站”，它也能立即调整路线。

每个转弯和每条车道都不必提前规定。它会自行感知道路现状、规划路线并执行驾驶操作，发现无法通行时还能随时调整。

从技术角度看，一个真正能工作的 Agent 包含三项核心能力。 第一是感知环境，它必须了解当前状况、可用工具及用户真实需求，如同司机需要观察道路、导航与剩余油量。 第二是规划路径，接到需求后不会立即行动，而会先拆解步骤并安排先后顺序；规划也不是固定不变，而是边走边看、持续更新。 第三是执行任务，确定下一步后调用相应工具，取得结果再回到第一步，重新感知并规划后续行动。

以旅行规划为例。 如果用 Workflow 实现，就必须预先固化流程：先搜索出发地到目的地的机票，再查目的地酒店和当地天气，最后计算总价。一旦用户提出中途增加一座城市，整个流程都得修改。

把任务交给 Agent 后则截然不同。你只要提出“帮我规划一下下周去成都的旅行，预算五千，要去看熊猫”。它或许先查机票，发现直飞价格太高便改查高铁；预订酒店时发现熊猫基地附近已满，就转向地铁可直达的区域；甚至还会查看下周成都是否下雨并提醒带伞。

它在整个过程中选择的路线，可能一开始根本不在你的预想之中。这正体现 Agent 的核心特征：自主性和适应性。它不是照着既定剧本执行，而是在真正“想办法完成任务”。

那么 Agent 是什么？它像一名会自行找路的司机

Agent 的特别之处究竟在哪里？

我过去一直认为 Agent 只是高级版 Workflow，无非多出工具调用能力。后来研究 ReAct 实现逻辑，又实际运行几个 Demo，才发现两者并不是同一种东西 —— 从根本上说，它们的底层逻辑完全不同。

你为 Workflow 铺好道路，它只需顺路运行。 对 Agent 而言，你只给出目的地，路线由它自己寻找。

不妨把 Agent 比作代驾司机。你告诉它“去机场”，其余事情都可交给它：查看导航、选择最近道路，堵车时绕行，高速封闭便改走国道；即使途中改成“不去机场了，改去高铁站”，路线也能马上调整。

你无须事先规定所有转弯和车道。它能够自行感知路况、规划路径并执行驾驶操作，路线受阻后还可随时改变方案。

从技术层面看，可执行任务的 Agent 核心包含三件事。 第一件是感知环境，了解目前状况、手中可调用的工具以及用户究竟需要什么，如同司机要观察道路、导航与车辆油量。 第二件是规划路径，收到需求后先拆分步骤、安排先后，而非立刻行动；这份规划还会边走边更新。 第三件是执行任务，确定下一步后调用对应工具，获得结果再回到第一步，重新感知并规划接下来的行动。

还是以旅行规划为例。 使用 Workflow 时，需要预先固定顺序：先查出发地至目的地的机票，再搜索目的地酒店、查询当地天气，最后核算总价。用户只要增加中途前往一座城市的需求，整个流程就需要调整。

若交给 Agent，过程便完全不同。你仅需提出“帮我规划一下下周去成都的旅行，预算五千，要去看熊猫”。它可能查过机票后发现直飞太贵，于是转查高铁；又因熊猫基地附近酒店客满，改选地铁直达区域；甚至会额外确认下周成都是否下雨，提醒你携带雨伞。

它最终选择的完整路径，或许最初根本超出你的预料。这就是 Agent 的核心所在：自主性与适应性。它并非执行写好的剧本，而是在实际“想办法完成任务”。

为了弄清两者的差异，我当时特意画了一张图，大致呈现出这种感觉：

看一段代码就明白：两者的执行逻辑截然不同

概念讲起来难免抽象，直接看代码会最直观。

先看 Workflow 的执行方式，本质就是按顺序调用，并无复杂设计：

// 定义好每个节点的能力const parsePdf = (file) => { /* 解析PDF返回文本 */ }const extractInfo = (text) => { /* 提取简历核心字段 */ }const matchJob = (info) => { /* 匹配岗位JD计算匹配度 */ }const rankScore = (result) => { /* 按分数排序输出 */ }// 串成一条完整流水线const resumeWorkflow = parsePdf.pipe(extractInfo).pipe(matchJob).pipe(rankScore)// 调用一次就跑完，路径完全固定const result = await resumeWorkflow.invoke(resumeFile)

整个过程是线性的（复杂点的就是你定义好的有向无环图），从入口到出口，一遍就走完了。大模型在里面只是某个节点的执行者，不是决策者。

再观察 Agent 的执行逻辑，其本质是一轮循环：

// 简化版伪代码，核心逻辑大差不差async function agentRun(task, availableTools) {let history = []let finalAnswer = nullwhile (true) {// 1. 让大模型思考：现在啥情况？下一步该干嘛？const nextStep = await llm.invoke({task,history,tools: availableTools.map(t => t.description)})// 注意这一行！每走一步都要调用一次大模型做决策// 别问我为什么知道这很费钱，试了三次账单懂的都懂if (nextStep.actionType === 'finish') {finalAnswer = nextStep.contentbreak}// 2. 按大模型的决定去调用工具const toolResult = await availableTools[nextStep.toolName].invoke(nextStep.params)// 3. 把结果记进历史，下一轮接着思考history.push({thought: nextStep.thought,action: nextStep.toolName,observation: toolResult})}return finalAnswer}

看到没？它不是一次跑完，而是 “思考 → 行动 → 观察 → 再思考” 这么一圈一圈循环，直到大模型自己觉得任务做完了。

其中的大模型承担决策者角色，每一步如何推进都由它决定。你只负责提供工具和目标，无法直接规定具体做法。

这也是 Agent 最让人头疼的地方 你永远没法 100% 预测它下一步会干嘛。它可能突然去调用一个你没想到的工具，可能陷入死循环反复查同一个东西，甚至可能觉得任务做完了，但其实根本没达到你的要求。

我经历的误区：不要把 Agent 当成万能钥匙

回到最初的简历筛选项目。当时我偏不相信，执意尝试 Agent 版本，觉得更“智能”总不会有错。

最后的结果让我彻底破防。

原本 Workflow 三秒钟即可完成的任务，Agent 往返调用五六次工具，耗时接近半分钟。更夸张的是，面对一份简历，它认为“技能描述不够详细”，竟然自行上网搜索候选人的博客。

看着控制台输出的执行日志，我当场愣住了。

后来我才意识到，这是典型的拿着锤子找钉子。

Workflow 与 Agent 并无高低之分，只是两者适用的场景完全不同。

• 面对固定、重复且强调稳定可控的任务，应选择 Workflow，例如数据清洗、表单处理、客服问答和审批流程。此类场景采用 Agent，只会增加成本与风险，收益约等于零。
• 任务若是开放、复杂且不存在固定解法，就应使用 Agent，例如市场调研、问题排查、方案设计与多步骤推理。此时若强行编写 Workflow，仅分支逻辑就足以让人崩溃。

我还踩过另一个坑：觉得 Workflow 就不能有智能。其实完全不是。Workflow 里的每个节点，都可以用大模型来做，比如信息提取、内容生成，这些都没问题。只是 “下一步走哪” 这件事，是规则定的，不是大模型定的。

同样，Agent 也不是毫无约束。你可以明确它可使用的工具和必须遵循的规则，只是边界之内仍由它自由行动。

最后说点实际的：两者从来不是非此即彼

讲到这里可能有人会问，真正做项目时究竟应该选择哪一个？

坦率地说，如今稍微复杂一些的 AI 应用并非二选一，而是将两者结合使用。

我最近见到的不少工程化方案采用相同思路：底层以 Workflow 构建骨架，确保核心流程稳定可控；关键节点则引入 Agent，由它处理灵活多变的部分。

以招聘系统为例，整体的简历筛选、初评及邀约流程必须由 Workflow 固定，不能随意改变。但“匹配岗位需求”节点可以交给 Agent —— 它能够依据候选人经历灵活判断适配程度，甚至提出具体面试建议，不必机械依赖关键词匹配。

客服系统也是如此。多数常见问题通过 Workflow 自动回复即可，既稳定又快速；只有遇到复杂且未曾出现的问题，才交由 Agent 查询知识库和订单，并协调人工处理。

概括而言：Workflow 是骨架，负责稳定；Agent 是大脑，负责灵活。 Workflow 缺少创造性，却可靠、省心且成本低。 Agent 富有想象力，但成本高、难控制且容易出现意外。将两者组合起来，才是工程实践中最务实的方案。

最后总结这次思考带来的三个最深感受。 第一，不要迷信 Agent，并非加入 Agent 就代表场景更高级，许多任务用简单 Workflow 便能快速稳定地解决。 第二，不要混淆本质，两者最关键的区别从来不是能否调用工具，而是“谁来决定下一步”—— 是遵循人为规则，还是交给大模型。 第三，不必非黑即白，真实业务中混合架构最合适，需要稳定之处保持稳定，需要灵活之处保留灵活。

回看自己的项目，你更常采用 Workflow 还是 Agent？如果也遇到过有趣的坑，欢迎在评论区分享，让我也增长见识。