直接说结论这三样东西不是难度递进的关系也不是越往上越高级。普通对话、工作流、Agent本质上是三条不同的技术路线选错了一个项目可能要多花三倍时间更糟的是上线后用户天天骂“这AI是傻子吗”。最近好多人在问这个问题尤其是那些刚把大模型接进业务的人经常在需求评审会上被问一句“你这个场景要不要做成Agent”然后整组人面面相觑。我结合自己跟过的几个实际项目把这个问题拆开讲讲希望能帮你少走点弯路。1. 三种模式的核心差异先分清“谁在决定下一步”想要选型第一步不是对比参数而是搞清楚这三套玩法的底层逻辑。它们之间的本质差异不在“智能程度”而在一个非常朴素的问题每一步动作由谁来决定。1.1 普通对话模型全权接管你的产品本质上是一个聊天窗口普通对话模式就是最简单的“你问我答”。用户发一句话模型直接给你一句回复。中间没有外部逻辑没有工具调用没有多轮状态管理。这是目前绝大部分聊天机器人、客服小助手的默认形态。这种模式的核心特征是模型拥有所有的决定权。它决定怎么理解你的问题、决定调用哪部分知识、决定用什么样的语气回复。你作为开发者能干预的地方只有一个——提示词。你可以把系统的身份、知识边界、回复风格写在提示词里让模型照着办。这种模式的优势非常明显实现成本极低只要接一个大模型API、写一段提示词、包一层接口就完事了。适合那些交互形态仍然停留在“问答”层面的场景比如FAQ知识库、产品说明、内容摘要。但它的问题也很突出模型回复是不可控的。同一个问题用词稍微换一换答案可能就不一样用户意图稍微绕一点模型就可能答非所问。没有流程约束没有内容校验纯靠提示词兜底说实话兜不住。1.2 工作流预先铺好轨道模型只负责在站点间移动工作流模式是把一个复杂的任务拆成固定步骤每一步用规则或模型完成。比如“用户提交订单→系统校验库存→调用支付接口→生成回执→发送通知”每走一步都有明确的条件判断和出口。在这种模式下决定权在流程本身也就是开发者写好的那套逻辑。模型只是某个环节的执行者它的输出会被下一个环节当作输入可以被校验、被修正、被拦截。我见过最简单直白的工作流是那种客服工单系统用户发起请求→第一步判断用户输入属于“咨询”还是“投诉”→咨询走FAQ通道投诉走人工介入通道→每一步输出结果都做格式校验→最终结果需要用户确认。这种模式可靠因为每一步都可控、可追溯、可回滚。排错时你只需要看是哪个环节出了问题不需要猜模型到底在想什么。工作流的代价是灵活度很低。你预先定了步骤就意味着你必须预料到绝大多数用户输入。一旦用户的需求超出你的预设路径整个流程就卡死了。1.3 Agent模型自己看着地图开车你只给目的地和交规Agent和上面两种有本质区别。Agent的核心是你给它一个目标、一组可用工具、几条约束规则然后由模型自己决定怎么拆解任务、按什么顺序调用工具、每一步做什么。这里决定权不在开发者、也不在用户而在模型本身。它根据当前对话上下文、工具返回结果、任务目标动态规划下一步动作。可以实现“我给它一个‘整理本周会议纪要给各部门’的指令它自己会列个计划、调日历接口、拉取会议记录、总结要点、找到各部门的通讯方式、逐个发送邮件”。听起来很爽对吧但代价也非常大一是结果不可完全预测。你没法保证它每次都走同一条路可能今天先查日历再拉记录明天先拉记录再查日历。大多数时候结果一样但不是每次都一样。二是调试成本成倍增加。普通对话最多调一个模型工作流调N个步骤Agent则是N个步骤加上M种模型决策路径的组合问题出现时你很难复现更别说定位了。三是对模型能力要求高。模型自身推理能力不行的话Agent完全跑不起来还不如工作流稳定。很多团队一上来就做Agent结果一个月下来还在跟“模型为什么不按计划调工具”作斗争。维度普通对话工作流Agent下一步由谁决定模型开发者预设的流程模型动态规划可预测性低高中低实现成本低中高调试难度低中高用户自由度高低高适用问题类型开放问答固定流程复杂任务注意这个表格是选型的骨架不是全部。真正拍板时还需要结合你业务的具体约束下面展开细说。2. 选型判断框架四个维度帮你把需求“翻译”成架构每次做技术方案评审我都会用四个维度来给需求“量体温”。不是凭空感觉而是有一套可复用的判断标准。这四个维度分别是稳定性要求、用户自由度、状态复杂度、可观测性要求。2.1 稳定性要求客户能容忍“跑偏”吗这是最重要的一票否决项。你的业务场景里模型输出如果跑偏了会造成什么后果如果后果只是“这次回答不够好用户重新问一遍”那选普通对话完全没问题没必要上复杂度。比如内容社区里的文章摘要、闲聊机器人、个人知识库问答这类场景就是“答错了无伤大雅”。但如果模型跑偏会导致资损、客诉升级、订单丢失比如金融交易、医疗预诊、工单自动处理、审批流、退款流程——那你就必须上工作流。用规则把每一步钉死模型只能在某些节点输出候选内容并且会被校验规则拦截。这不是出于技术洁癖而是出于最基本的风险控制。我见过一个团队做金融客服刚开始用纯普通对话让模型直接回答“退款什么时候到账”这类问题。结果模型某天为了讨好用户回复“您的退款已经到账”但实际上款还在路上。用户收到错误的确认信息后疯狂投诉最后整个项目被迫停了一周做改造。这个例子很典型——这就是没做稳定性评估的结果。2.2 用户自由度需求是点单还是开放式提问第二个维度是看用户输入的开放程度。如果你的用户输入是可以被枚举的比如“查余额”“转账”“改绑手机号”那恭喜你你根本不需要让模型来猜意图。直接用工作流把每种意图对应一个流程模型只负责把用户的话分类到某个意图剩下的走固定流程。这就是“点单式交互”——用户能点的菜就那些你需要的只是准确识别他点了哪个。但如果你的用户输入高度开放比如“帮我想一个周年庆活动方案”“分析一下我这个店铺的问题”这些需求你不可能预先列全。这时候你要么用普通对话让模型自由发挥要么用Agent让模型拆解后逐步解决。注意关键不是“问题是否难”而是“答案是否唯一”。我之前见过一个团队把“用户打开设备报修页面”做成了Agent让它自主规划“先问故障现象→再查设备类型→然后判断维修方案”。听起来很智能但实际上用户在这个流程里根本没有自由每个步都是固定的选择题完全可以用工作流实现Agent在这里纯属浪费——还增加了延迟和不可控性。判断标准很简单列一张表把你遇到的所有真实用户历史会话打开统计一下用户请求的类型数量。如果几十个请求能被归纳成五六个意图就用工作流如果每个请求都长得不一样就得认真考虑Agent或普通对话。2.3 状态复杂度任务需要长链条、多分支吗状态复杂度指的是完成一次用户请求系统需要维持多少中间状态、走多少步、有多少个分支条件。举一个对比场景A用户问“你们的退货政策是什么”。这个问题一次问答就结束不需要任何中间状态普通对话搞定即使要做成工作流也是“接收问题→检索政策→返回结果”三步结束。场景B用户说“我要退货但是我的订单超过了退货期当时买的时候有延保我应该找谁”。这个任务涉及订单信息查询、政策判断、时间计算、延保条件核实、人工介入路由……每一步之间需要传递数据且不同分支要去不同地方。这才是工作流该出场的场景。工作流能把“查订单”“算时限”“判断延保”“路由到人工”这些环节固化成可执行步骤每一步的结果都落在数据结构里下个环节接着用。场景C用户说“帮我处理掉这个库存积压的问题目标是减少30%的仓储成本”。这个目标太开放了连第一步该干嘛都不确定得先分析原因、再评估方案、可能要调库存数据、要拉销售报表、要给出多个方案并比较……这就是Agent的领域。判断状态复杂度的时候还有一个容易被忽视的细节有些需求看起来简单但中间状态非常多。比如一次跨部门审批虽然每一步都是“通过/拒绝”的二选一但这些状态要贯穿多个环节、多人参与整个流程拉得很长。这时候你该上的也不是普通对话而是工作流。2.4 可观测性与调试成本出问题了你找谁最后一个维度特别实际你上线之后系统出错时你能不能在半小时内定位到问题。普通对话的调试本质上是提示词调试。出问题了你去看日志确认模型输出了什么然后调提示词再把模型输出纠正过来。它的问题在于——出了错你只能改提示词改完还会影响其他对话的表现。工作流的调试相对舒服得多。流程是固定的每一步都有输入输出你在哪个环节看到异常数据就翻那个环节的逻辑。这个环节是规则写的就改规则是模型调的就调提示词或换模型。Agent的调试……我这么说吧一个Agent跑完之后你看到最终结果不对你想知道它中间经历了什么。如果你没有埋点、没有完整的链路追踪你只能看到它最后一步调了什么工具完全不知道它是怎么从用户指令一路漂移过来的。就算你加了日志你还要面对一个新的问题——同一个输入跑两次中间路径可能不同。你昨天复现的问题今天可能复现不出来。所以我的建议非常直白如果你的团队规模很小比如三五个研发、没有专门的日志分析系统、没有专人值班处理线上问题那就优先避开Agent。用工作流至少你能半夜爬起来的时候十分钟内搞清楚哪里出了岔子。四个维度都过一遍之后基本就能定方向了。我们把它们组合成一个简易的判断模型稳定性要求高 → 排除普通对话和纯Agent选工作流或在关键节点加人工审核用户输入高度开放、且路径无法枚举 → 排除工作流考虑普通对话或Agent取决于是否需要工具调用状态链条长、分支多 → 排除普通对话选工作流或Agent调试资源不足 → 排除Agent优先工作流3. 实战选型方案从对话到Agent的分层演进策略上面是判断框架但实际做方案的时候我从来不会一上来就选到“最优解”。我的习惯是反过来——用分层策略从成本最低的形态做起只有当需求明确超出当前形态的能力边界时才往上升级。3.1 单轮能解决的事绝不上流程先评估一个问题这个需求是不是能靠一次模型调用就解决比如“这个商品的卖点是什么”“这篇文档讲了什么”——你把用户问题和上下文扔给模型模型直接返回结果。没有工具调用没有中间状态没有后续依赖。这种需求的正确解法是普通对话甚至不需要做多轮。但很多团队会因为“想显得技术含量高”而强行套工作流。我之前见过有人把“总结一篇文章要点”做成了用户输入 → 判断语言 → 提取关键词 → 分段摘要 → 汇总。每个环节都是模型调用中间还嵌套了关键词、分类器、多个提示词模板。最后跑一遍下来时间和费用翻了五倍用户感知结果和三行提示词直接调用一次模型也差不多。在简单任务上叠流程成本是实打实的。每次模型调用都有延迟、有费用链路越长风险越大。除非你的确需要中间做结构性处理否则不要人为复杂化。3.2 有明确步骤的走工作流当用户请求对应一个“流程图”时就是工作流出场的时候了。实际上判断标准特别简单你能画出一张流程图吗能画出来就走工作流。比如“客户发起退款申请”校验订单是否属于该用户计算可退金额检查退货时效创建退款单通知仓库触发收货流程售后客服确认这个流程里有规则判断、有外部系统调用、有状态流转但它完全可预知。你给用户的选择就三五种每一种对应一条固定路径。工作流就是干这个的。有些人担心工作流太死板、用户体验不够自由。我的经验是大多数业务场景用户根本不想要自由他们想要的是确定的结果。用户说“我要退货”他不想被AI反问“您能具体描述一下您的退货原因吗”他想要的是看到一条明确的路能不能退、退多少、什么时候到账。工作流是对用户需求最好的尊重。3.3 真正的开放问题才交给Agent有一类问题确实没法预先画流程图。举个例子“我们公司的客户流失率连续三个月上升帮我分析一下原因并且给出一个可落地的挽回方案。”这个问题你没法预设步骤。因为它可能需要先查数、再做归因、再对标历史活动效果、再生成方案。每一步怎么做、先做哪个后做哪个取决于中途发现了什么。这种“探索型”的问题才值得用Agent。但即便是Agent也要做好边界约束。我认为Agent落地时最关键的一件事是限定工具集。你不能说“我有二十个工具你随便用”模型会迷路的。更好做法是给Agent三五个必要的工具并且加上在线状态和约束条件。比如让它处理数据分析就只给数据查询、指标计算、报告生成这三个工具不许调邮件、不许调财务系统。另一个我认为特别重要但常被忽略的事Agent必须有“知难而退”的能力。我在一个项目里见过Agent反复尝试一个失败的工具调用三次每次报错然后重试浪费了大量时间。后来在系统提示词里加了约束“工具调用连续两次失败后必须停止尝试并向用户说明情况转人工处理。”这样一来整体稳定性提升了很多。Agent是个好工具但它不是给你省心的是给你解决那些本来就无法预设流程的复杂任务的。3.4 混合架构一个产品里同时存在三种模式实际操作中很多项目不会只有一种模式。成熟的解法是做一个混合架构让不同环节用不同形态。以我熟悉的客服系统为例整体链路是这样的第一层普通对话。用户进来先自由提问模型负责理解意图、判断分类。第二层意图路由。如果模型判断这个请求属于“退换货”“物流查询”“开具发票”等标准业务就把请求转给对应的工作流。第三层工作流执行。标准业务走固定流程每个环节有校验完成后返回结果。第四层Agent介入。只处理那些无法归类到任何标准流程、需要跨多个系统查证、需要多步推理的复杂请求。这个架构里普通对话处理开放会话工作流保证标准业务稳定Agent兜底复杂任务。用户无感知但系统内部各司其职。混合架构对技术要求不高但对设计能力要求高——你必须先把场景摸清楚知道哪些用户请求属于哪一层而不是让所有请求都涌到同一个通道里。注意混合架构不是一次到位的最好是“从对话开始业务跑通后再逐步加工作流、加Agent”。这样能保证每一步都在为业务增量服务而不是为了技术炫技。4. 实操复盘一个客服系统的三次迭代选型光讲原则不给实例总感觉差了点意思。我把之前经手的一个客服项目拆给你看整个过程经历了三次选型切换每一步都有具体的迭代逻辑。4.1 第一期先做普通对话快速上线项目启动初期知识库内容比较少业务规则也不够清晰团队对用户到底会问什么都不确定。这时候做一个大而全的工作流风险很高——流程画不准等于白白浪费开发时间。所以我定下来的方案是先做普通对话。接一个大模型把知识库作为检索来源交给模型直接回答。用户自由提问模型在知识库里找到相关内容整理成回答并标注“参考来源”。这期上线后的大致效果是能解决大约60%的常见问题剩下40%需要人工介入。但架不住有一个好处——整个对话系统的上线周期只花了两周队列日志和用户反馈很快就收集到了一大堆。这期目标的本质不是为了“解决问题”而是为了“收集真实问题”。因为只有用户真实输入才能告诉你你的业务场景里到底有哪些高频意图、哪些问题是无法靠单个问答解决的。4.2 第二期基于会话数据梳理工作流第一期跑了大约一个月我们开始做会话分析。从日志里把所有用户问题做了归类发现高频请求就集中在四类查询物流进度申请退换货咨询保修政策修改订单信息这四类占到了全部用户问题的70%以上而且每一类都有固定的解决路径。这时候就是引入工作流的时机了。我们为每一类问题画了流程图。拿退换货来说用户发起退换请求调订单接口校验订单归属、是否在退换期内根据订单状态进入“退货”或“换货”分支计算可退金额或可换型号生成工单推送到后台仓库系统返回回执单号给用户模型在这个流程里的角色明显缩小了——它不再负责直接回答而是负责在第一步“把用户的话映射到某个意图”以及在某些分支里做小体量信息抽取。这期上线后这四类问题的解决率从60%提升到90%而且因为流程固定每步都可追踪出现了问题能直接在日志里定位是哪一步出了差错。4.3 第三期把开放问题交给Agent但90%不是100%。剩下的10%问题里有一部分连人工都觉得棘手。比如有个用户说“我这个订单本来要退货的但我发现退不了可实际上这个订单当时参加了一个无忧购的活动你们承诺过可以退我该找谁解决”。这种问题涉及订单状态、活动政策、客服处理记录、售后权限……单靠意图映射和工作流已经处理不了了因为它的路径没法预先画出流程图。这一部分我们接入了Agent。它的工具集是订单查询API、活动政策库、售后工单系统。它的工作方式是拿到用户描述自己查询订单信息、检索对应活动的政策细则、判断是否构成例外情况然后生成一个结论和处理方案如果涉及退款再调用工单系统生成一个特殊处理单。Agent从设计到上线花了比工作流更长的时间调了很多轮主要是两方面一是工具调用的指令写得不够清楚Agent经常把“活动政策库”查出来的内容当作“售后政策库”来用导致结论错误。后来在系统提示词里明确标注了每个工具的适用场景和边界问题才缓解。二是Agent偶尔会“过度满足用户”——用户只是问一个政策细节它却主动生成了工单。后来我们在Agent的约束里加上“未经用户确认禁止生成任何工单”这类问题就消失了。4.4 踩过的坑和迭代经验复盘整个迭代过程有三个经验对我后续做选型帮助极大分享给你不要让普通对话去做流程该做的事。我们早期版本里模型经常被用户引导做一些不在它权限范围内的事——比如“告诉我这个订单能退多少钱”模型会凭空算一个数字出来而这个数字没有任何字段来源。这不是模型的错是架构的错——这类请求就该交给有订单接口的工作流去算。Agent的边界比能力更值得关注。我们每次给Agent加一个工具都会明确写出“什么时候用这个工具、什么时候不用”。现实中看到太多Agent失控不是因为模型蠢而是因为开发者没把边界条件写清楚。每次切换形态都要先问“这能带来什么直接的业务提升”。不是从普通对话升到工作流就显得高级而是因为工作流能解决准确率问题和可追踪问题。同样上Agent不是因为工作流不够智能而是确有一些场景无法预设路径、确实需要动态规划。这套客服系统的故事其实就是大多数业务型AI项目的标准路径先用最小的成本跑通再用结构化方式提升稳定性最后用Agent应对长尾开放问题。每一步升级都在解决某一种具体的不足而不是为了追新技术概念。5. 常见误区与排查技巧避免过度设计最后聊几个我做技术方案评审时经常看到的误区。这些都是真实发生过的事情写出来供你对照自查。5.1 误区一凡是复杂功能都上Agent“这个需求有点复杂我们用Agent来做吧”——每次听到这句话我心里都会咯噔一下。很多人口中的复杂其实只是一种直觉感受用户问题绕、涉及系统多处、感觉动态规划能解决。但真正动起手来Agent的开发周期长、调试难度大、线上稳定性还要打问号。我见过最离谱的一个设计是把一个只需要三次固定判断的场景硬设计成Agent。用户输入 → Agent判断是否需要查库存 → Agent判断是否需要查物流 → Agent判断是否需要查售后中间每一步都调用一次工具每次调用都伴随一次模型推理和几十亿参数的概率采样。结果是一条最多三秒钟就能跑完的工作流硬是跑了十几秒还时不时在某一步自己“绕路”了。我的经验法则是能画图就用工作流画不了图才用Agent。如果你不确定能不能画图问自己一个问题——这个任务的正常解决路径是不是可以预测的能预测就是工作流。不能预测才轮到Agent。5.2 误区二工作流把用户路径锁得太死没有“逃生通道”工作流的确定性强是优势但也会带来问题——当用户输入超出预设分支时系统会不知所措。我在一个项目里见过这种设计用户已经明确表示“我的情况比较特殊能不能帮我转人工”但工作流不管只要识别到用户输入里有“售后”两个字就把用户拽回“售后问题处理”分支反复让用户描述故障现象。用户在流程里出不去体验非常糟糕。正确做法是在每一个工作流的重要节点都要检查有没有满足“转人工”或“退出”的条件。我在设计工作流时会强制留一个“用户表达明确不满或重复表达相同内容三次以上”的分支直接转人工。工作流是轨道但用户应该有随时下车的权利。5.3 误区三普通对话不需要考虑上下文我见过很多团队做普通对话直接把每次用户消息单独发给模型不带历史记录、不带用户画像、不带业务上下文。然后遇到用户发一句“那它呢”——模型一脸茫然根本不知道“它”是谁。普通对话虽然架构简单但“多轮记忆”是刚需。你至少要做一个上下文缓存把最近N轮对话传给模型让模型知道用户在说什么。更进一步可以在对话开头注入一个“记忆摘要”用户之前在聊什么、已经解决了什么、这次进来还想解决什么。这一招对提升多轮对话体验非常明显而实现成本很低。5.4 排查技巧给Agent设计降级路径Agent最让人头疼的问题是当它在开放规划中“失控”时你怎么收场。我在做Agent设计时一定会加入一个降级策略当Agent的判断明确不可用时自动降级回工作流或普通对话。比如Agent在调任务规划的时候如果连续两次输出的步骤不合理比如步骤之间明显矛盾或依赖顺序颠倒系统就不让它继续执行直接转到一个较为保守的工作流去处理或者转人工。这个降级策略不需要很复杂一个简单的兜底分支就行。我见过某个团队就靠这个降级路径救了两次线上事故——Agent在某个特殊情况下疯狂调工具每分钟调用几十次接口如果没有降级策略那个月的账单会非常难看。注意降级不是“重试”而是“换路”。重试意味着还在Agent体系里做尝试降级是直接切到一个更简单、更可控的流程上。两者看着都是兜底但思路完全不同。我个人在实际操作中的体会是选型这件事没有“标准答案”但有一个非常稳定的判断顺序——先看用户输入自由度和业务对稳定性的要求再看这个任务能不能绘制成流程图最后才看是不是真的需要Agent来动态规划。排序对了方案基本就定了。实在拿不准的就选成本最低的方案试跑用真实数据说话不要用会议室里讨论出来的“感觉”说话。再多说一句技术选型不是一次性的。普通对话、工作流、Agent完全可以共存、可以互相升级、可以按业务规模逐步引入。别想着一次到位也别为了“省事”停留在一个处处别扭的方案上。每个阶段都用当时最合理、最可维护的形态就好。