先从那个让我纠结了一下午的经历聊起

前阵子帮朋友做简历初筛工具时，我盯着 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？是否也遇到过值得分享的有趣问题？欢迎到评论区聊聊，也让我增长一些见识。