普通对话 vs 工作流 vs Agent：大模型应用选型指南

直接说结论：这三样东西不是难度递进的关系，也不是越往上越高级。普通对话、工作流、Agent，本质上是三条不同的技术路线，选错了一个项目可能要多花三倍时间，更糟的是上线后用户天天骂“这AI是傻子吗”。

最近好多人在问这个问题，尤其是那些刚把大模型接进业务的人，经常在需求评审会上被问一句“你这个场景要不要做成Agent”，然后整组人面面相觑。我结合自己跟过的几个实际项目，把这个问题拆开讲讲，希望能帮你少走点弯路。

1. 三种模式的核心差异：先分清“谁在决定下一步”

想要选型，第一步不是对比参数，而是搞清楚这三套玩法的底层逻辑。它们之间的本质差异不在“智能程度”，而在一个非常朴素的问题：每一步动作由谁来决定。

1.1 普通对话：模型全权接管，你的产品本质上是一个聊天窗口

普通对话模式，就是最简单的“你问我答”。用户发一句话，模型直接给你一句回复。中间没有外部逻辑，没有工具调用，没有多轮状态管理。这是目前绝大部分聊天机器人、客服小助手的默认形态。

这种模式的核心特征是：模型拥有所有的决定权。它决定怎么理解你的问题、决定调用哪部分知识、决定用什么样的语气回复。你作为开发者，能干预的地方只有一个——提示词。你可以把系统的身份、知识边界、回复风格写在提示词里，让模型照着办。

这种模式的优势非常明显：实现成本极低，只要接一个大模型API、写一段提示词、包一层接口就完事了。适合那些交互形态仍然停留在“问答”层面的场景，比如FAQ知识库、产品说明、内容摘要。

但它的问题也很突出：模型回复是不可控的。同一个问题，用词稍微换一换，答案可能就不一样；用户意图稍微绕一点，模型就可能答非所问。没有流程约束，没有内容校验，纯靠提示词兜底，说实话，兜不住。

1.2 工作流：预先铺好轨道，模型只负责在站点间移动

工作流模式，是把一个复杂的任务拆成固定步骤，每一步用规则或模型完成。比如“用户提交订单→系统校验库存→调用支付接口→生成回执→发送通知”，每走一步都有明确的条件判断和出口。

在这种模式下，决定权在流程本身，也就是开发者写好的那套逻辑。模型只是某个环节的执行者，它的输出会被下一个环节当作输入，可以被校验、被修正、被拦截。

我见过最简单直白的工作流，是那种客服工单系统：用户发起请求→第一步判断用户输入属于“咨询”还是“投诉”→咨询走FAQ通道，投诉走人工介入通道→每一步输出结果都做格式校验→最终结果需要用户确认。这种模式可靠，因为每一步都可控、可追溯、可回滚。排错时你只需要看是哪个环节出了问题，不需要猜模型到底在想什么。

工作流的代价是：灵活度很低。你预先定了步骤，就意味着你必须预料到绝大多数用户输入。一旦用户的需求超出你的预设路径，整个流程就卡死了。

1.3 Agent：模型自己看着地图开车，你只给目的地和交规

Agent和上面两种有本质区别。Agent的核心是：你给它一个目标、一组可用工具、几条约束规则，然后由模型自己决定怎么拆解任务、按什么顺序调用工具、每一步做什么。

这里决定权不在开发者、也不在用户，而在模型本身。它根据当前对话上下文、工具返回结果、任务目标，动态规划下一步动作。可以实现“我给它一个‘整理本周会议纪要给各部门’的指令，它自己会列个计划、调日历接口、拉取会议记录、总结要点、找到各部门的通讯方式、逐个发送邮件”。

听起来很爽对吧？但代价也非常大：

一是结果不可完全预测。你没法保证它每次都走同一条路，可能今天先查日历再拉记录，明天先拉记录再查日历。大多数时候结果一样，但不是每次都一样。

二是调试成本成倍增加。普通对话最多调一个模型，工作流调N个步骤，Agent则是N个步骤加上M种模型决策路径的组合，问题出现时你很难复现，更别说定位了。

三是对模型能力要求高。模型自身推理能力不行的话，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 有明确步骤的，走工作流

当用户请求对应一个“流程图”时，就是工作流出场的时候了。

实际上判断标准特别简单：你能画出一张流程图吗？能画出来，就走工作流。

比如“客户发起退款申请”：

1. 校验订单是否属于该用户
2. 计算可退金额
3. 检查退货时效
4. 创建退款单
5. 通知仓库，触发收货流程
6. 售后客服确认

这个流程里有规则判断、有外部系统调用、有状态流转，但它完全可预知。你给用户的选择就三五种，每一种对应一条固定路径。工作流就是干这个的。

有些人担心工作流太死板、用户体验不够自由。我的经验是：大多数业务场景，用户根本不想要自由，他们想要的是确定的结果。用户说“我要退货”，他不想被AI反问“您能具体描述一下您的退货原因吗？”，他想要的是看到一条明确的路：能不能退、退多少、什么时候到账。

工作流是对用户需求最好的尊重。

3.3 真正的开放问题，才交给Agent

有一类问题，确实没法预先画流程图。举个例子：“我们公司的客户流失率连续三个月上升，帮我分析一下原因，并且给出一个可落地的挽回方案。”

这个问题，你没法预设步骤。因为它可能需要先查数、再做归因、再对标历史活动效果、再生成方案。每一步怎么做、先做哪个后做哪个，取决于中途发现了什么。这种“探索型”的问题，才值得用Agent。

但即便是Agent，也要做好边界约束。我认为Agent落地时最关键的一件事是：限定工具集。你不能说“我有二十个工具，你随便用”，模型会迷路的。更好做法是给Agent三五个必要的工具，并且加上在线状态和约束条件。比如让它处理数据分析，就只给数据查询、指标计算、报告生成这三个工具，不许调邮件、不许调财务系统。

另一个我认为特别重要但常被忽略的事：Agent必须有“知难而退”的能力。我在一个项目里见过Agent反复尝试一个失败的工具调用三次，每次报错然后重试，浪费了大量时间。后来在系统提示词里加了约束：“工具调用连续两次失败后，必须停止尝试并向用户说明情况，转人工处理。”这样一来，整体稳定性提升了很多。

Agent是个好工具，但它不是给你省心的，是给你解决那些本来就无法预设流程的复杂任务的。

3.4 混合架构：一个产品里同时存在三种模式

实际操作中，很多项目不会只有一种模式。成熟的解法是做一个混合架构，让不同环节用不同形态。

以我熟悉的客服系统为例，整体链路是这样的：

• 第一层：普通对话。用户进来先自由提问，模型负责理解意图、判断分类。
• 第二层：意图路由。如果模型判断这个请求属于“退换货”“物流查询”“开具发票”等标准业务，就把请求转给对应的工作流。
• 第三层：工作流执行。标准业务走固定流程，每个环节有校验，完成后返回结果。
• 第四层：Agent介入。只处理那些无法归类到任何标准流程、需要跨多个系统查证、需要多步推理的复杂请求。

这个架构里，普通对话处理开放会话，工作流保证标准业务稳定，Agent兜底复杂任务。用户无感知，但系统内部各司其职。

混合架构对技术要求不高，但对设计能力要求高——你必须先把场景摸清楚，知道哪些用户请求属于哪一层，而不是让所有请求都涌到同一个通道里。

注意：混合架构不是一次到位的，最好是“从对话开始，业务跑通后再逐步加工作流、加Agent”。这样能保证每一步都在为业务增量服务，而不是为了技术炫技。

4. 实操复盘：一个客服系统的三次迭代选型

光讲原则，不给实例，总感觉差了点意思。我把之前经手的一个客服项目拆给你看，整个过程经历了三次选型切换，每一步都有具体的迭代逻辑。

4.1 第一期：先做普通对话，快速上线

项目启动初期，知识库内容比较少，业务规则也不够清晰，团队对用户到底会问什么都不确定。这时候做一个大而全的工作流风险很高——流程画不准，等于白白浪费开发时间。

所以我定下来的方案是：先做普通对话。接一个大模型，把知识库作为检索来源，交给模型直接回答。用户自由提问，模型在知识库里找到相关内容，整理成回答，并标注“参考来源”。

这期上线后的大致效果是：能解决大约60%的常见问题，剩下40%需要人工介入。但架不住有一个好处——整个对话系统的上线周期只花了两周，队列日志和用户反馈很快就收集到了一大堆。

这期目标的本质，不是为了“解决问题”，而是为了“收集真实问题”。因为只有用户真实输入才能告诉你：你的业务场景里到底有哪些高频意图、哪些问题是无法靠单个问答解决的。

4.2 第二期：基于会话数据梳理工作流

第一期跑了大约一个月，我们开始做会话分析。从日志里把所有用户问题做了归类，发现高频请求就集中在四类：

• 查询物流进度
• 申请退换货
• 咨询保修政策
• 修改订单信息

这四类占到了全部用户问题的70%以上，而且每一类都有固定的解决路径。这时候就是引入工作流的时机了。

我们为每一类问题画了流程图。拿退换货来说：

1. 用户发起退换请求
2. 调订单接口，校验订单归属、是否在退换期内
3. 根据订单状态进入“退货”或“换货”分支
4. 计算可退金额或可换型号
5. 生成工单，推送到后台仓库系统
6. 返回回执单号给用户

模型在这个流程里的角色明显缩小了——它不再负责直接回答，而是负责在第一步“把用户的话映射到某个意图”，以及在某些分支里做小体量信息抽取。

这期上线后，这四类问题的解决率从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完全可以共存、可以互相升级、可以按业务规模逐步引入。别想着一次到位，也别为了“省事”停留在一个处处别扭的方案上。每个阶段都用当时最合理、最可维护的形态就好。