产品经理和技术团队开会最怕听到的其实是同一个词——明明大家说的是中文含义却完全对不上。我见过太多次评审会上的拉扯业务方拿Agent立项技术侧实际交付的是自动化流程或者反过来产品经理觉得这不就是个if-else吗技术说这里必须上Agent。两边各说各话需求失真最后做出来的东西既不是A也不是B四不像。自动化工作流和Agent的区别表面看是技术概念本质上是产品经理必须建立的技术边界感。你不需要会写代码但你得知道哪些需求应该用规则去约束哪些需求必须容忍不确定性哪些环节可以交给机器自主决策哪些环节一旦放手就会失控。这篇文章我会用实际踩过的坑、评审会的真实场景和一个贯穿始终的案例把这两个东西的边界、取舍、验收方式讲透。适合正在设计智能产品、写PRD时被智能化卡住的产品经理也适合想和算法团队顺畅沟通的运营和业务负责人。1. 为什么你会被自动化工作流和Agent绕晕术语混用背后的行业现实先说我自己的经历。某次内部评审新来的实习生提了一版智能客服机器人方案方案里写用户进线后由Agent自动判断意图并回复。评审会上技术负责人问了一句你说的Agent是指大模型自主对话还是基于关键词的自动分流实习生愣了一下说不就是智能自动回复吗两边对Agent的定义差了三个档次那场评审基本是在无效讨论中度过的。这不是个例。当下行业里Agent智能体自主代理智能自动化这些词被当成了营销话术供应商、售前、甚至技术团队自己都在混用。你很难从名字判断一个系统到底是真的有自主决策能力还是只是披了一层大模型外衣的固定流程。产品经理如果不去追问本质就会在需求文档里写出一个掩盖边界模糊的智能化需求最终交付时才发现完全不是一回事。1.1 三种说法可能指向三种不同的东西我自己的经验是把市面上所有智能前缀的产品拆成三层你一听就明白第一层是传统自动化。规则固定、流程固定执行的是人预先写好的每一步。比如订单金额大于100元自动发优惠券这就是一段硬编码逻辑跟人工操作的区别只是速度快、不会累。第二层是智能增强的工作流。中间某个环节引入了大模型或机器学习能力但整体路径仍由人定义。比如用大模型做意图识别识别结果落回一个预先设计好的分流节点。你看着它聪明实际上聪明只发生在某个模块整个骨架依然是确定的。第三层是真正的Agent。它接收一个目标自己决定拆成几步、用什么工具、怎么检查结果中间路径不是预先设计好的。比如你告诉它帮我订一张后天去上海的高铁票并定好住的地方它自己规划步骤、查询车次、比较酒店、确认下单——每一步具体怎么走连它的开发者都无法提前枚举。产品经理在需求阶段的第一个任务就是分辨自己说的智能到底落在哪一层。1.2 产品经理不需要懂实现但必须懂边界很多PM会陷入一个误区觉得边界是技术概念自己只需要提需求技术怎么实现是别人的事。这种想法在传统软件开发里勉强成立但在智能产品领域会出大问题因为技术边界直接决定了产品边界。我举个最直白的例子你想想餐厅后厨。自动化工作流就是一份标准化SOP什么人负责洗菜、切菜切多粗、炒菜几成火候、出锅撒什么料每个动作都写死在手册里。只要按步骤执行出品稳定、可复现、成本低。而Agent是什么是一位主厨。你只需要告诉他今天有十二桌客人口味偏清淡预算八百他会自己决定做什么菜、怎么搭配、如何调整火候他甚至可能临时改菜单。好处是灵活、能处理没见过的局面坏处是你无法预判他每一步在干什么也无法在出现问题时精准指出哪一步错了。产品经理要建立的边界感就是清楚知道你的产品里哪部分是后厨SOP哪部分是主厨临场发挥。这个判断存续于需求定义、资源评估、验收标准制定的全过程它决定你写下的每一个智能需求是能落地还是纯属画饼。1.3 边界不清的代价两个真实方向的失败经验模糊边界带来的损失往往是攒到最后一次爆发。我见过某团队立项了Agent客服业务目标是用户问什么都能答。结果交付后大家发现所谓Agent其实是一个关键词匹配固定问答知识库换个问法就答不上来。用户满意度没提升技术团队被质疑能力不行产品经理被打上需求不清的标签。回头看如果当初定义为智能知识库检索人工兜底工作流预期管理会好得多评价也会公平得多。另一个方向同样常见某团队要做一个报销单据自动审核功能负责的产品经理觉得这不就是规则判断嘛没认真投入。结果真正做的时候发现发票种类上百种、金额校验规则模糊、异常情况层出不穷固定工作流根本无法覆盖。改造成Agent识别单据画风、理解报销政策、异常时转人工反而效果拔群。这两个案例说明了同一个道理边界判断失误要么高估了系统的自主性要么低估了场景的复杂性两次都踩在同一个坑的两侧。2. 同一件事两条实现路径以一个自动处理退款工单需求为例有案例才有真实感我们用一个我实际设计过的需求来逐步拆解用户提交退款申请后系统需要自动判断是否符合政策、决定是否同意退款、给用户发送结果通知。请你把这个需求记在心里后面所有差异点都用它来讲。这个需求表面看很简单但其实每个环节都隐藏着能不能预先枚举的问题。你会发现同一个需求工作流和Agent的做法截然不同输出物、可控性、用户体验、迭代方式也完全不同。2.1 自动化工作流的做法:每一步都被严格定义工作流的实现逻辑是节点判断动作。研发会先和我一起画出一条主干路径收到退款申请 → 校验用户身份 → 校验订单状态 → 判断是否符合退款政策比如未发货自动退款发货后退款需审核→ 符合则执行原路退款 → 发送通知 → 关闭工单不符合则转入人工审核队列。请注意这里的每个环节都依赖人预先定义。所谓智能的体现最多是在某个判断节点引入一个模型。比如判断用户情绪如果检测到用户很生气就走优先人工处理的分支。但模型输出之后的行为路径依然是设计者写死的。用餐厅类比这是今日特供限套餐——厨师有没有发挥有但选择空间被框定在A、B、C三个套餐里。工作流的优点在退款场景里非常突出全流程留痕、可控、出了纠纷可以回查每一步。缺点是面对没预定义过的情况会直接卡住。比如用户说我不想要了但我要保留优惠券——工作流里的判断节点没有这个选项工单就会流进人工队列这是预期内的倒也不算缺陷只是需要人盯。2.2 Agent的做法目标驱动路径自发规划如果用Agent来做同一个需求定义方式就完全不同了。我不会告诉它第一步干什么、第二步干什么而是给它一个目标在合规前提下尽可能高效处理退款申请需要人工时及时转交。具体怎么处理那由Agent按当下情况自行拆解。它会自己理解退款政策、自己判断当前订单属于哪种场景、自己起草给用户回复的话术甚至在政策模糊时主动去历史工单里找相似案例做参考。如果中途发现信息缺失它还可以自己调用订单查询、调用客服知识库、调用财务校验接口中途换工具是家常便饭这一切都在你没有预先定义的情况下发生。这里必须强调一个产品经理容易忽略的事实Agent不是独立存在的它需要工具支持。没有可调用的数据接口、没有知识库、没有可操作的业务系统Agent只能生成看起来合理的回复没法真正执行动作。所以在设计Agent类需求时你需要和技术团队一起盘点接入了哪些工具、能在多少种系统里产生真实操作这和设计工作流时的关注点完全不同。2.3 核心差异维度决策归属、状态记忆、失败处置这几个差异点如果你只记得一个那就记谁在决策。自动化工作流中所有决策点都是人定义的Agent系统中部分决策点被交给了模型和运行时的自我规划。差异维度自动化工作流Agent决策归属人的设计决策运行时无自主判断系统内自主规划路径实时决策状态记忆靠数据库记录传参流程间无主动记忆可记忆上下文、历史动作、中间结果连续推理失败处置走到异常分支按预设处理严格执行兜底方案自主判断失败原因尝试换方案重试或转人工可解释性每条路径都可追溯能够精确复盘部分决策路径不透明依赖日志和复盘解释变更方式修改流程定义后发布调整目标和工具效果变化非直接对应这个表里面最微妙的是失败处置这一行因为它直接决定你的产品出bug时的用户体感。工作流出错了你可以指着一行日志说看这个分支没走到因为它的设计初衷就是确定性执行Agent出错了你只能看到模型预期什么、最终动作是什么中间的自我规划过程像一段你没写过的草稿需要一个行为追踪的组件介入才能还原全部过程。2.4 边界不是断崖而是连续谱系写到这里我想插一个很重要的观点你不需要非得把需求完全归入工作流或Agent两个篮子。真实产品里绝大多数系统是骨架工作流血肉Agent的组合我自己在退款工单案例里就是这么做的。具体怎么组合第一阶段用户提交退款申请先走Agent做全局意图理解和场景归类。它可以看懂用户一次提交多张订单、夹带情绪化描述、涉及特殊商品等复杂状态。第二阶段归类完成后交给工作流去执行沉淀好的标准动作比如校验账户、计算退款金额、更新库存。第三阶段工作流遇到无法归类的异常时再唤起Agent做一些策略判断比如协商部分退款、给出补偿方案生成建议后交回工作流执行。如此设计工作流提供了稳定骨架和完整留痕Agent提供了柔性和长尾场景覆盖。这个组合思路说白了就是把确定的部分交给规则把不确定的部分交给智能规则有边界、智能有兜底。产品经理真正要做的是在这个连续谱系里为你的需求找到一个恰当的落点。3. 判断该用工作流还是Agent五个问题加一个打分表现在你已经理解了两者的差异但只理解概念还不够你需要的是一套能在需求定义阶段快速用起来的判断方法。我自己在评审会之前都会先做这套内部推演它帮我挡掉了不少过度智能化和假自动化的方案。3.1 五个判断问题先过一遍问题一这个问题集合可以完整枚举吗如果一进来就问退款原因都有哪些A、B、C、D好穷举完了那就别再请Agent出场了工作流是更低成本、更快、更稳的选择。反过来如果需求方说用户申请的退款原因千奇百怪还不断有新增那你就得认真考虑Agent。问题二输入是不是高度不确定、格式多种多样固定格式表单提交的信息每个字段都有明确含义工作流就能处理。如果是自由文本、图片、语音、混排信息需要先理解语义再做后续动作那先理解再行动这个环节更适合用Agent的能力实现。问题三任务路径是否需要中途规划或调整退款工单里的标准路径是固定的校验、判断、执行、通知谁都能提前想清楚。但研究竞品政策并生成对比分析报告这种需求路径取决于你能找到哪些竞品、数据长什么样、自己怎么组织信息这是没法提前枚举的必须由Agent实时规划。问题四出错后的可逆性如何这个判断标准太关键了。退款转错了账户可能会引发客诉纠纷这类高风险动作的核心决策一定要保留给确定性流程或人来兜底。低风险试错类动作比如数据检索、内容草拟、分类标注出错代价小更适合让Agent放手试。产品经理要记住可逆性越差越要保守不要随便用黑盒。问题五要不要向用户或监管解释为什么这么决策金融、医疗、法务领域用户要的不是快而是为什么。工作流能完整呈现决策链路Agent需要额外的解释模块来事后复盘成本高很多。如果你的产品必须百分百可解释即便场景开放也应倾向工作流或Agent产出建议规则解释的混合模式。3.2 把感觉变成判断场景打分表单个问题还容易武断我习惯把五个问题量化打分一共20分看总分倾向。这套打分表不需要特别严谨主要是避免现场拍脑袋。实际操作中我会在需求文档里直接放一张这样的表格评审会直接逐项过。判断维度打分方向分数越高越倾向Agent。判断维度打分参考评分1-4分问题/场景可枚举程度可完全枚举打1分完全无法枚举打4分—输入格式多样性固定结构化输入打1分开放自由输入打4分—路径可预期性路径固定打1分路径高度动态打4分—出错可逆性错误代价高不可逆打1分低风险可反复试打4分—解释需求强度强解释需求打1分弱解释需求打4分—我自己的经验阈值是总分在5-9分直接老实做工作流10-14分采用工作流为骨架Agent做局部能力增强的混合方案15-20分才认真考虑以Agent为主要架构。你当然可以不迷信这个分数但它至少让评审会从一个词汇辩论会变成一个标准对齐会。3.3 三个别硬上Agent的场景结合我踩过的坑整理几个前现场特别容易头脑发热的场景。合规审计类场景。有个项目要自动审批营销活动物料需求方觉得用Agent检查所有文案有没有违规词。结果讨论下来发现合规审查要求的不是聪明而是每一步都有据可查、每个判断都有法规来源。这种场景用规则引擎敏感词库人工复核的工作流才是正解Agent顶多能做初筛不能做决策。高频低风险操作类场景。比如某内容平台的自动给违规评论扣分功能每分钟可能处理几千条。Agent只在极少数环节被使用判断语义是否违规扣分规则本身必须写成硬编码工作流。有人做过一次对比用Agent跑全流程的响应延迟是工作流的三到五倍成本高出十倍不止收益却几乎相同。用户核心体验链路场景。支付、登录、下单、优惠计算这些环节一旦出现不可解释的异常用户会瞬间流失。别在高频刚需路径上用黑盒Agent去做关键决策那是在拿用户耐心做实验。工作流 埋点 监控 人工兜底才是最稳妥的组合。3.4 三个该认真考虑Agent的场景反向的场景我的经验是这三类最早值得上Agent。开放域对话服务。用户问题没有固定边界早期方案做关键词匹配的体验我已经不想再提。用Agent做意图理解、检索上下文、生成答复配合人工质保体系才算是及格水平的对话产品。跨系统信息检索和汇聚。比如汇总各门店本周的销售、库存、差评情况生成一份管理简报。这个需求需要同时查询多个系统、理解多个格式、自己组织输出路径没法预写Agent的主要发挥场景正是这种跨系统跑腿总结汇报。长尾内容分析与归纳。有一堆非结构化长文本比如几百份合同、事故报告或用户评论要求提炼关键风险点。Agent可以自己分段阅读、交叉印证、定位相关段落并摘录原句。这种内部消化型任务出错影响面小、价值却很直接适合让Agent放手跑。4. 评审会上识别伪Agent并拆穿模糊话术背后的真实需求我们是Agent架构这句话在业界频繁出没。它可能是一句准确描述也可能是在给你打烟雾弹。产品经理不需要技术较真但需要对话术背后的东西是什么有清晰的判断能力。4.1 供应商或内部团队说的Agent通常有三种真实内涵我把评审会遇到的Agent话术拆成三类对应完全不同的验收标准。第一种套壳自动化。大模型只做了一个开场白或结果润色背后的流程、判断、分支完全预置。典型表现是用了大模型API但不接入任何工具所有动作都靠if-else完成。这类系统换个角度说就是个加强版工作流。第二种大模型包装的固定流程。中间某几步用了模型能力比如意图识别、摘要生成但整条主路径和分支逻辑仍是人预设的。这类系统是混合架构不等于全自主Agent但它的确比普通工作流更灵活。第三种真正的自主系统。能自主规划、调用外部工具、按中间结果调整计划、失败后自行重试修正。判断标准很简单让它在没有任何人预先编排步骤的前提下完成一个从来没见过的复合任务它行不行。你在评审会上需要做的不是争论算不算Agent而是让描述人明确你说的Agent是上述哪一种。这个区分直接决定你对它是否满足需求的验收预期。4.2 评审会上可直接追问的三个问题第一问换一个大模型供应商你的流程还成立吗 如果回答是会受影响但整体流程不变那么你的核心骨架其实是工作流模型只是增强模块如果回答是很可能整个规划逻辑就崩了那你面对的就是一个真正依赖模型推理能力的Agent。第二问你的系统能自主修改执行计划吗还是只能按预设路径走 大多数人会含糊其辞因为能自主修改计划是硬实力的体现能说清楚这个才算真正的Agent。追问时不妨举个具体例子如果第一步查不到结果它会自己换别的搜索途径还是会直接报错停下第三问失败的时候谁会收到通知谁负责兜底 注意这不是技术问题是产品责任问题。工作流里失败清晰责任人明确Agent失败时则需要一套机制判断要不要转人工、有没有降级路径。如果对方答不上来你就知道这个设计里根本还没想清楚可控性。4.3 把话术翻译成需求PRD里的验收标准该怎么写产品经理的职责是把模糊词翻译成可验收的行为。所以在我看来PRD里最不该出现的描述就是系统智能地处理退款或Agent自动回复用户。有效写法是描述用户可观察行为不写实现方式。同一个退款需求我改写过两种验收表达你可以直接拿去做模板对比写法问题所在改进建议系统智能判断是否能退款并自动回复无法衡量、无法测试分场景列具体行为系统查件后可自动退款的条件清单是什么不符合时转入人工的触发条件是什么回复用户的通路文案版本包括哪些Agent可根据问题自动处理用户请求混淆了Agent与工作流的验收差异确立行为指标问题闭单率目标单次对话处理轮数上限转人工触发条件不满意反馈的回落路径每项都需要可量化下面给一段目标导向的验收标准草拟样板核心是验收标准写的是系统要达成的边界和结果而不是系统内部用什么实现。这套写法不管你最后采用工作流还是Agent都具有同等约束可执行性验收标准示例当用户提交退款申请系统应在10秒内给出处理结果结果分为自动通过、转入人工、条件拒绝三类。自动通过需满足订单未发货且退款原因属于七天无理由转入人工需至少保留上下文片段与用户原话条件拒绝须明确理由和下一步操作。系统在24小时内完成率目标不低于85%超过2分钟等待预警。所有关键决策需生成可追溯事件日志含规则或模型版本信息。写到这里你应该发现了我刻意没有用Agent这个词写进验收条款。只要锚定行为、阈值、兜底路径、日志实现方式自然会被倒逼着选对。反过来说如果PRD里全是智能、自动、聪明这类词那你的验收就是零约束后面怎么交付都没人挑得出毛病。5. 落地与验收两种架构的验收方法、监控指标和灰度策略确定架构之后别以为需求就结束了。真正的考验在验收环节工作流和Agent的验收方式差异巨大甚至可以说验收方法反过来会决定你产品最终给人什么印象。5.1 工作流的验收重点链路覆盖率和异常分支工作流是确定性的所以验收逻辑也类似单元测试把每条主路径和每个异常分支都测一遍。我会特别关注三类分支是否被覆盖——业务主链路正常无异常、边界分支极端时间、极端金额、罕见状态组合、异常兜底接口超时、数据缺失、并发冲突。测异常分支常见的问题是自己把自己坑了。某团队做优惠券发放工作流主链路明明通过了但没考虑券池已空这种情况用户领券时直接报错且没有提示文案差评如潮。工作流的验收清单要细到每个失败中断点是否都有礼貌提示和下一步动作。5.2 Agent的验收重点目标达成率、安全边界、成本消耗Agent的验收不能靠能否跑通它永远没有跑通一说它只有这次表现好与坏。我自己验收Agent类需求会锁定四项第一目标达成率。随机抽样一千条真实场景请求人工评估系统是否达成用户目标。注意达成的标准要先定义好比如退款场景不是是否给用户回话就叫达成而是是否真正解决了退款问题。这个指标是整个产品的北极星必须由产品经理亲自看样本。第二安全边界与越界行为。有没有偷偷承诺了政策之外的东西有没有编造不存在的退款依据有没有在不确定时强行给出确定答案这类边界问题不靠指标发现靠的是红队测试式的人工对抗。我会准备一批刁钻问题让Agent去处理专门看它在规则裂隙处的反应。第三兜底链路生效。真正评估产品胜败往往发生在Agent失败时刻它失败后有没有快速转人工人工是否收到完整上下文用户是否经历了糟糕的我说了半天发现对面是个机器人体验兜底链路顺畅与否直接决定用户对整个系统的口碑。第四成本消耗。Agent每跑一次都会产生模型调用成本不像工作流是固定服务器开销。我会盯每单处理成本和每百次对话失败的浪费成本。这两个数决定你的智能化功能能不能规模化铺开而不是只能活在Demo里。5.3 灰度与监控产品经理要盯住的四个关键看板无论工作流还是Agent都不要直接全量上线这是我屡次付出代价后的教训。灰度期间我会同时盯四类指标指标关注原因异常信号自动完成率反映系统能独立处理多少比例的任务下降过快说明模型或流程退化用户有效求助率反映用户对自动处理结果的真实满意度上升说明自动处理用户体验不可接受流程卡点/超时占比反映工作流断点与Agent自我循环问题卡在中间无动作说明路径规划失效人工介入率反映兜底链路的负担和压力大幅波动对应系统行为不可预测灰度策略上我的建议是按用户身份场景风险双重维度做小流量切入。先在低风险用户、低风险场景里试跑收集足够日志后再扩大到中高风险场景。中途退出机制必须预设好如果核心指标连续一小时跌破红线立刻全量切回旧流程不要让问题在灰度状态里发酵过夜。5.4 从技术边界到产品边界把架构选择翻译成用户体验最后一个经验想留给那些已经把以上都讲清楚的PM技术选型最终会体现在用户体验上的具体差异你应该主动将这个信息界定成产品承诺的一部分。如果选工作流你对用户的承诺可以是稳定、可预期、7×24小时不抽风如果选Agent你对用户的承诺应该是灵活、能处理复杂问题但切记坦诚它的不确定性。很多产品出了问题不在实现不好而在它从来没有对用户明示过这个东西有时候会需要人工复核。我在退款案例里就在页面上直接写明特殊申请将由客服复核处理结果反而提升了用户满意度因为预期被校准了。产品经理在这个环节容易犯的最大错是把技术实现的技术含量当成了给用户的产品价值。用户不关心你是用工作流还是Agent做的他们只关心你承诺的稳定做到了多少、承诺的灵活兑现了多少。你用规则做得又快又稳那是本事你用Agent把复杂问题消解得够人性化那也是本事。边界感的核心始终是用最合适的手段去兑现产品该兑现的承诺。最后分享一条我个人最实在的心得做智能产品别急着证明自己在用最新的Agent技术先证明你那套系统在失控时有落点、在出错时有交代、在翻车时讲得清原因。技术边界这件事不是为了跟风而是为了让你在产品翻车之前就知道车会往哪翻以及翻的时候的保险带在哪。踩过几次坑之后你会跟我有一样的感觉边界感清晰的PM其实比会说技术黑话的PM更受技术团队尊重。