1. 从调度器到协调者工作流框架的“身份”变了早年聊工作流框架大家脑子里浮现的东西高度统一一个定时任务引擎、一张 DAG 图、一串节点的执行顺序外加失败重试和告警。这套东西解决了非常具体的问题——把复杂的业务过程拆成可编排、可观测、可重跑的步骤让系统按预设顺序自动运转。今天的AI工作流则完全是另一套逻辑它不再把步骤当作固定的流水线而是把每个节点当作一个有决策能力的执行者过程本身会根据中间结果反复调整。工作流框架和AI工作流之间正在发生的不只是功能迭代更像是一场代际替换。1.1 旧工作流的基本盘是“任务生命周期”传统工作流能撑起无数核心业务靠的是四件事状态机、持久化、补偿机制、重试策略。用电商订单流程举例下单以后进入“待支付”支付回调触发“已支付”仓库任务完成进入“待发货”物流回传进入“已签收”。每个状态之间的跳转是明确的每条边都有触发条件失败的时候可以回滚或补偿。这套模型的优点非常突出——可解释、可测试、可控。工程师能一眼看出一个订单卡在哪一步也能通过重放日志还原整个执行过程。这种模型反映到实现层就是大家都用过的 DAG 编排。每个节点定义输入、输出和动作框架负责按拓扑顺序调度。节点的依赖关系在启动前已经写好运行中不会长出新的边。即使有分支判断分支条件也都是确定性的要么看数据库里的字段要么看上游节点的返回值要么看某个外部接口的状态码。这个时代的框架有一种很强的“调度器”气质。它像一座工厂的传送带原料从一头进去经过一道道工位最后从另一头出来。每个工位做什么是固定的流程不会因为原料本身的特性临时创造新工序。1.2 AI 工作流的出现把重心从“排顺序”挪到了“做选择”到了AI工作流这里场景完全变了。以一个大模型客服机器人为例用户的自然语言进来之后系统要先判断意图是咨询、投诉还是闲聊然后从知识库检索相关内容接着决定要不要调用某个外部工具再组织成回答最后还要判断回答是否需要人工兜底。这个流程看起来也有节点、有顺序但关键差异在于——很多节点的输出不是确定性的字段值而是概率化的语义结果。意图分类的结果不是“strcmp 相等”这种布尔判断而是多个可能性的概率分布检索排序的结果也不是固定的数字索引而是向量相似度排序最终的拦截校验还要靠另一个模型打分。传统工作流的 if/else 在结构上依然存在但判断条件从“数值比较”变成了“语义相似度比较”从“等于/不等于”变成了“可能是/倾向于”。这个变化直接改变了框架的定位。框架不再只是一个把步骤串起来执行的外部工具它必须理解“当前这一步产生的语义结果是下一步选择路径的依据”。用行话讲AI 工作流做的不再是“任务调度”而是“决策编排”。开发者从编写一张静态的执行计划表变成了定义一组可供决策的候选路径和决策规则。2. 确定性 DAG 与语义路由两代核心架构的分水岭要说这两代技术最大的分水岭不在代码写法上而在“图的形态”上。传统框架跑的是静态有向无环图AI 工作流跑的是动态生成图。前者是施工图纸后者是导航地图——路线要跟着实时路况变。2.1 静态图到动态图结构不再先验传统工作流的 DAG 在部署时就已经固定运行中唯一能变的是某条边是否被跳过。比如一个审批流程如果金额小于 1000就跳过总监审批节点但这张图本身的节点集合不会变。AI 工作流则不同因为它承接的任务本身就是开放式的它甚至允许运行到一半时发现需要新建一个节点、换一个模型、插入一次人工确认。拿一个实际的内部文档助手举例。第一版的时候团队按传统的思维把它做成一条线接收问题 → 检索知识库 → 生成回答 → 返回。结果上线后很快发现问题用户会问“帮我整理一份合同模板”也会问“上个月的周报有哪些内容”还会问“今天的会议纪要在哪”。这些请求需要的处理路径差异很大。有的要调文档接口有的要查数据库有的只要直接读文件。如果全部走同一条链路要么检索质量差要么浪费时间。最佳的答案是让系统根据用户问题动态规划一条合适的路径。这就是动态图的出现图的节点和边由决策模型在上一步输出后决定而不是在部署时写死。2.2 AI 工作流的“路由协议”从布尔判断到语义匹配传统引擎里分支判断长这样if (order.amount 5000) { await routeTo(manager_approval); } else { await routeTo(auto_approve); }这是标准的确定性路由它依赖的是结构化字段的精确比较。AI 工作流里同样的分支可能长这样{ node: intent_router, decision: { type: semantic_match, candidates: [ {route: document_search, description: 用户想查找或检索文档}, {route: data_query, description: 用户想查询业务数据}, {route: general_chat, description: 闲聊或通用问题} ], fallback: manual_review } }路由节点收到的输入是一段自然语言它通过 embedding 计算用户请求与每个候选路由描述之间的相似度然后选择得分最高的路径。这种模式在中间件领域有销售式的先例比如意图识别但传统工作流框架根本不会在核心调度逻辑里内置这种组件。这背后的本质是控制流信号的来源发生了变化。传统分支靠的是“状态字段”AI 工作流靠的是“语义向量”。在工程实现上一个是查表一个是算相似度前者 O(1)后者需要向量检索、阈值校准、降级策略复杂度和不确定性都高出好几个量级。2.3 代价从可预测流程到概率性编排必须承认这种演进是有代价的。静态 DAG 最迷人的特性是“可重现”同一份输入跑一百次只要外部依赖不变结果完全一致。这让排错和回滚非常轻松。AI 工作流引入了概率模型之后“同样输入跑两次可能得到不同结果”成了常态化现象。模型参数有随机性top_p 采样有随机性连外部 API 的负载都会影响结果。真实项目里我见过不少团队在这个地方栽跟头。运营反馈某个流程偶尔会执行错误的分支开发检查代码逻辑发现没有任何 bug最后定位到是意图路由模型的相似度分数在阈值附近抖动。同一个问题换个说法就被路由到了另一条链路。这类问题已经不是传统工作流的排错思路能解决的它要求团队建立一套新的机制语义路由的可观测性、阈值回归测试、人工接管兜底。这是沿着 AI 这条路继续往前走必须习惯的东西。3. 当 AI 成为节点的执行者状态管理随之反转框架设计的另一大核心是“状态”。传统工作流里状态掌握在框架手里节点是无状态的执行单元。AI 工作流把这个关系彻底拧了过来每个 LLM 节点本身是携带状态的框架反而成了轻量的协调壳。这是两代框架姿态上的根本差异。3.1 重试、幂等与智能节点的矛盾传统工作流的重试机制建立在“任务幂等”这个隐含假设上节点执行失败后重新执行一次不会产生副作用或者副作用已经被框架妥善处理。数据库写入可以做幂等键外部接口调用可以用请求 ID 去重这些都是成熟套路。但 AI 节点尤其是直接调用大模型生成的节点并不天然幂等。同一个 prompt 发两遍模型生成结果大概率有差异。如果第一遍超时了框架按惯例自动重试第二遍虽然成功了但生成的内容可能已经变了。更麻烦的是AI 节点经常伴随副作用比如调用了外部的邮件发送接口第一遍调用其实已经成功只是响应超时重试就可能导致邮件重复发送。这时候如果沿用传统框架的“自动重试”策略就会把稳定性搞得很糟。一些团队开始在 AI 节点外套一层“结果指纹”机制——把模型输入、参数、上下文哈希后作为幂等键重试时先查缓存命中就直接返回同一份结果。这个思路听起来像缓存实际上是在为概率性执行引入确定性缓存层。框架本身并不能彻底解决这个问题它只能提供生命周期钩子由节点实现者来保证语义上的稳定。3.2 会话状态和上下文窗口新一代框架的“缓存”另一个被 AI 工作流逼出来的状态管理需求是会话状态。传统工作流的“状态”通常是字段值、进度标记、任务间传递的数据结构。AI 工作流的“状态”里多了一样东西——对话历史。对话历史不是普通的数据它影响后续每一步生成的结果。同一个问题在用户连续追问“那然后呢”的时候必须结合前几轮内容才能给出合理的回答如果把每次都当作独立请求回答就会变得支离破碎。为了应对这个需求现在的 AI 工作流框架普遍内置了会话存储让每个节点都能读取全量上下文。于是状态管理的内容从“当前流程走到哪一步”扩展为“当前对话的完整语义环境”。这对框架的存储设计影响很大。传统框架只需要为每个执行实例存一个轻量上下文对象AI 工作流则要给上下文做截断、摘要、向量化索引。开发者在设计节点时也多了一项职责明确这个节点需要多少上下文哪些历史信息应该传给模型哪些必须过滤掉。我见过有人把所有历史消息一股脑全塞进 prompt结果 token 超限回答质量急剧下降。正确的做法通常是保留最近的 N 轮完整对话更早的内容做摘要或用作向量检索的知识片段。3.3 “状态”已经从流程标记变成了语义记忆如果说传统工作流的状态是“坐标”AI 工作流的状态就是“记忆”。坐标刻画的是执行位置记忆刻画的是上下文理解。前者可以序列化成一个简单的对象后者则涉及向量数据库、短期记忆、长期记忆之间的协作。这个反转还影响到框架的事务处理思维。传统流程可以靠 Saga 模式做分布式事务补偿节点 A 失败就执行补偿节点撤销 A 的副作用。AI 工作流里一个节点生成了一段文本并发送给用户下个节点发现生成内容有问题理论上可以做“撤销”但消息已经发出去了实际撤销只能靠道歉或修正消息来完成。这时候的补偿逻辑不再是“回滚数据库状态”而是“追加一次修正动作”。这是语义层级的补偿框架只能提供机制真正的判断得靠业务决策者。4. 混合编排是更实际的路线框架选择与边界划定听到这里可能有人会觉得 AI 工作流会彻底取代传统工作流框架。我的结论恰恰相反。在绝大多数生产系统里你需要的不是二选一而是混合编排确定性流程负责稳定的事务链路AI 负责需要判断力的决策环节。两组引擎各管一段这才是目前最靠谱的实践。4.1 四种编排形态对照先看选项。过去一年我评估过的项目基本上跑不出四种形态形态核心控制逻辑典型场景优缺点确定性编排为主静态 DAG、状态机、规则引擎订单、审批、账单、任务下发稳定可测但无法处理开放语义输入AI 节点嵌入确定性流程主流程固定局部节点由 AI 完成客服工单自动分类后再走人工流程结构清晰AI 的边界被牢牢框住确定性工具嵌入 AI 流程大模型做主决策调用工具执行智能助手调用数据库、API、文件系统灵活但需要极强的上下文管控全语义编排图结构由 AI 动态生成复杂研究助理、自适应规划最灵活也最难控成本与风险从这张表可以看出越往下的形态对框架的智能要求越高同时稳定性和可预测性也越差。生产系统的主流选择其实都集中在前三种。4.2 我倾向的接线方式AI 做决策舱框架做执行底座个人实践中比较顺手的方式是把 AI 工作流当作一个“决策层”传统工作流框架当作“执行层”。决策层收到请求后规划出最优路径执行层则忠实地把路径上的每一步落地该调库调库该发消息发消息。这样有两个明显的好处一是 AI 的失误可以被限定在“选择哪条路”这个层面不至于直接破坏数据二是执行层还能复用成熟的补偿、重试、监控能力。拿一个自动化运维工单系统举例。用户提交一个工单“生产环境某个接口的报错率突然升高”。AI 决策层分析工单内容判断这是一个日志分析任务于是规划出执行路径从监控系统拉取指标提取最近日志并聚合异常尝试给出根因分析。真正的拉取动作、写日志、通知相关人员全部由执行层的传统工作流完成。如果 AI 判断错了比如把日志分析误判成配置变更申请执行层也能基于确定的规则拒绝这个规划避免误操作。4.3 迁移的最佳路径先包一层壳再逐步下沉很多团队手里已经有一套跑得挺稳的传统工作流不想推到重来。这个思路完全可以理解生产系统的重构风险极高AI 工作流又自带不确定性一上来就大拆大建很不明智。我建议的迁移路径是从外围包一层“AI 网关”开始保持现有流程不变在前面加一个 AI 入口负责理解用户意图并转换成传统流程的触发参数。这一步只增加了一个语义理解和参数抽取层对下游完全是透明的。跑通这一步之后再把里面真正需要动态判断的节点逐步替换成 AI 节点。比如原来靠规则关键词做工单分类改成模型分类原来人工审核的相似案例推荐改成向量检索加模型排序。每替换一个节点都单独做灰度验证。这个节奏虽然慢但每一步都可回退、可解释适合对稳定性要求高的业务。5. 从流程资产到决策资产数据管线和观测方式的变化工作流框架演进的过程中有一个容易被忽视但是影响深远的变化——观测体系。传统工作流留下的是执行日志和状态流转记录AI 工作流留下的是决策路径和语义打分记录。前者回答的是“发生了什么”后者要额外回答“为什么是这条路径”。这个词的落点已经从“流程资产”偏向了“决策资产”。5.1 传统日志记录的粒度不够用了传统工作流排查问题时核心看三样执行状态、输入输出参数、异常堆栈。代码逻辑是确定的定位到数据就能反推原因。AI 工作流不一样经常碰到的问题是整个流程执行成功状态全绿但结果就是不符合预期。这时候传统日志基本帮不上忙你需要的是知道模型看到了什么上下文、路由节点计算出哪些候选分、选择了哪条路径、阈值是多少、采样参数是什么。有一次排查一个项目用户反馈某个特定类型的问题老是分错类。从仪表盘上根本看不出异常所有节点都显示“成功”。后来把意图路由节点的内部日志拉出来看才发现问题描述的文本和另一个候选路由的描述相似度过高多次超过阈值。这不是程序错误而是语义空间的建模偏差。要发现这类问题必须记录每次路由的 top-k 候选和分数而不是只记录最终结果。5.2 改造观测体系的三件事针对这种差异我自己做项目时会在传统链路追踪的基础上做三件事。第一给每次模型调用采集一份“决策档案”包括完整 prompt、模型版本、参数配置、输出内容、token 消耗、延迟。第二给每个语义路由节点记录候选列表和相似度分布而不是只记命中结果。第三建立“案例回放”机制把线上的真实输入保存下来离线对模型迭代版本做批量回归——这个机制相当于给 AI 工作流加上了传统框架早就具备的回归测试能力。这套观测改造不便宜尤其是 token 消耗和存储成本。但在生产环境里省掉这笔开销几乎等于把决策过程变成黑盒。5.3 一条常见失败链缺少兜底导致雪崩另外值得写一笔的是兜底设计。传统工作流的兜底很简单——失败重试、失败分支、人工介入。AI 工作流的失败模式更隐蔽它不是“抛异常”而是“自信地给出了一个错答案”。这种失败不触发任何告警机制。解决办法是在关键节点后加一道“自检”或“互检”。自检是让同一个模型或另一个模型审查输出是否符合约束互检是引入一道规则引擎检查结果中的硬性条件约束。比如说AI 生成的 SQL 语句在真正执行前过一遍语法检查器和字段白名单校验AI 生成的客服回复在发给用户前用确定性规则检查是否包含违禁内容。这些兜底既不复杂又能显著降低语义节点的失误扩散。6. AI 工作流的真正差异在全局回路最后想说一个我观察到的真正的“代际分化”点是不是具备全局反馈回路。6.1 回路让框架从执行器变成规划器传统工作流是单向的输入进输出出错误就停或重试。没有一条边是“从终点回到起点”的。AI 工作流不一样它天然允许一种新的边——再思考一次。输出结果如果校验不通过可以回到检索节点换一种查询方式可以回到路由节点换一条路径也可以回到模型节点换一个 prompt 重新生成。这就是全局回路。没有回路的 AI 工作流本质上还是传统 DAG 加了个大模型节点有了回路才真正具备了“自我修复”的可能性。这也是很多 Agent 框架的核心设计Agent 不是一个会执行 DAG 的程序而是一个能循环“感知-决策-行动-观察”的个体。拿研究型任务举例第一步检索可能不够充分模型会基于不足的结果判断出“需要更多信息”然后发起第二轮检索甚至更换数据源。这种能力在静态 DAG 里很难优雅地实现因为图结构不知道什么时候需要回头。6.2 快速检验清单你的“AI 工作流”处在第几代作为一个阶段性收尾我整理了一份快速检验清单拿去对照手上的项目基本就能看出它是在用 2018 年的思路做 2025 年的工作流还是真的完成了代际切换路由节点用的是“是否等于”这种硬判断还是相似度/评分这种软判断流程的执行图是部署时写死的还是运行中可根据中间结果动态调整的状态管理是否包含对会话上下文和记忆的处理还是只有任务字段失败补偿是否考虑了“生成了错误答案”这种情况还是只考虑“异常中断”观测系统能不能回答“这个流程为什么选这条路”整个系统是否允许“回退一步换个方式再走一次”还是一旦执行只能向前这六条里如果大部分答案是前一种那无论代码里接入了多少大模型 API本质上你还在传统工作流的延长线上运行。要真正迈入 AI 工作流的代际控制流、状态、观测和补偿四个层面同时都得做出改变。我在实际项目里最深的体会是工具和框架迭代得再快真正拖住团队的不是框架能力而是思维惯性——总觉得让工作流框架去调一个大模型接口就算上 AI 了。等到某一天你开始接受“流程图在运行时会自己生长出新的分支”这个想法并且愿意为此构建配套的可观测性和兜底机制这个项目才算真正做进了下一代工作流。保持一个朴素的判断任何 AI 工作流如果不能解释自己为什么选择了当前路径那么它在生产环境中的价值都会大打折扣。先把这个基础打好框架怎么选都是容易的事。