别再傻傻分不清：Workflow 和 Agent 其实不是一回事

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

前阵子帮朋友做简历初筛工具时，我盯着 LangChain 文档研究了整整一下午，始终绕不开一个问题：这个功能究竟该用 Chain 组合出 Workflow，还是干脆直接采用 Agent？

现在说来有点丢人，当时我确实没觉得这两样东西有多大区别 —— 不都是让 AI 按步骤完成任务吗？同样要调用大模型，也都得处理输入输出，名称不同又能怎样？

我凭直觉先做了 Workflow 版本，方式与平时搭 LangChain 链差不多：用 pipe 把 PDF 解析、信息提取、岗位匹配和打分排序几个节点依次串联。简历输入后沿流程跑完，结果便直接输出。成功跑通时我颇为得意，心想这样不就完成了，哪里还需要 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？又是否遇到过什么有意思的坑？欢迎在评论区交流，也让我增长一些见识。