这两年我接触过不少搭 AI 工作流的团队。一开始大家普遍选可视化工作流构建器理由是效率高、不写代码产品同事也能参与。可等流程真的要在生产环境跑起来问题就集中爆发了新增一个判断分支要重新梳理节点改一次提示词要看半天日志最要命的是没有可靠的版本控制团队三个人改过几轮之后谁也说不清线上版本到底长什么样。所以当我看到 The death of AI workflow builders 这个话题时觉得标题有点绝对但它确实点到了一个正在发生的结构变化——AI 工作流构建器并没有消失只是正在从生产工具滑向原型工具。1. 先搞清楚AI工作流构建器到底在“死”什么1.1 “死亡”不是工具退出历史而是优先级发生转移这里先要澄清一个理解偏差。所谓死亡不是明天开始这些工具就不能用了。到今天市面上依然有大量团队在用可视化工作流构建器搭应用很多工具也还在快速迭代。真正发生变化的是它在技术栈中的位置。过去三四年AI 应用落地最顺手的路径之一就是打开一个可视化构建器把模型调用、知识库检索、条件分支、HTTP 请求、消息推送这些节点拖到画布上连成一条线一个客服问答、内容总结、文档处理流程就跑通了。这种工作方式把 AI 应用的门槛拉到很低也让大量非工程背景的人第一次能亲手搭建 AI 流程。但现在出现了两个明显变化。一是 AI 应用正在从“提前画好的静态流程”走向“由模型自主决策的 Agent 形态”二是基于 AI 的编程工具成熟速度很快写代码的门槛被大幅拉低。前者改变了工作流的核心编排者后者则把“代码优先”的成本降到了过去不敢想的水平。所以死亡更准确的说法是它从地基变成了脚手架。地基决定建筑能盖多高脚手架只是在施工期帮忙搭一下。工具还在角色却变了。1.2 为什么大家开始关注“死亡”而不是“进化”一个很直观的原因是体感变化。过去要做一个复杂流程你必须在画布上把每一步写死先调用什么再判断什么然后走到哪条分支。今天你只需要给 Agent 一个目标、一组可用工具和一段上下文它能自己决定先看哪些资料、调用哪个工具、中间是否需要问用户。工作流构建器里最核心的概念是“节点”而现在人们讨论更多的已经是“工具”“上下文”“记忆”这些概念。节点是静态的工具是可动态选择的。这种变化看起来只是词汇层面的实际上代表完全不同的编排哲学前者靠人画路线图后者靠模型理解目标和约束。一个更现实的信号是越来越多团队在复盘时会承认构建器搭出来的流程只是用来验证业务方向并不是最终交付形态。等验证完成他们还是会回到代码里把流程重写成一套可测试、可审计、可维护的 Agent 程序。这类案例积累到一定数量就会变成行业共识。所以问题的关键不是“构建器是否还能用”而是“我们是否还该把它当成默认的生产工具”。我的判断是不再应该。2. 构建器曾经解决的真实问题不是画布而是让半自动化不用求人2.1 它把“会写代码”的依赖降了下来很多人讨论工作流构建器时喜欢把重点放在“能不能实现某个复杂逻辑”上却忽略了一件更重要的事它真正解决的是资源协调问题。在 AI 应用流行之前企业内部很多流程自动化需求其实并不复杂比如把表单提交触发一条消息通知把新客户信息同步到客户管理系统把指定的表格数据定期汇总并发送。这些需求不是做不了而是需要排到开发队列里等排期。一个几十行的脚本可能只需要一个工程师写十分钟但因为优先级、上下文切换和沟通成本最后往往要等上一两周。可视化构建器把这些小需求从工程队列里解放了出来。市场、运营、客服团队的人自己上手拖几个节点就能完成。它不一定效率最高但确实让大量“半自动化”需求不用再求人。2.2 早期 AI 应用为什么大量依赖构建器到了 AI 应用阶段构建器的重要性又被放大了。原因很简单早期 AI 应用的不确定性太高。模型选型会变、提示词要反复调、输出格式不稳定、知识库的切分策略要验证。如果每次调整都要改代码并重新发版迭代效率会非常低。可视化构建器天然适合这种场景你可以直接在一个节点里看到模型输入输出快速调整 prompt马上看到效果。这种可视化反馈对早期验证极其重要。所以早期 AI 应用大量使用构建器不是因为开发者不写代码而是因为这样能最快定位问题。AI 开发在初期更像是在做实验而不是在写业务系统实验工具当然要越快看到结果越好。2.3 “死亡论”不是否认过去价值而是提醒角色转变如果只看上述优点构建器几乎不可替代。但这里有个关键点实验工具和生产工具的评价标准完全不同。实验阶段你要的是快错了可以推翻重来。生产阶段你要的是稳出了问题要能回滚、能排查、能快速修复。很多团队恰恰在第一个阶段体验很好进入第二个阶段后才发现自己手里没有一个能支撑稳定性的基础设施。这就解释了为什么会有“死亡”这种说法。不是构建器不好用了而是它把团队带到一个阶段之后不再能继续带队。凡是只擅长实验、不擅长生产的工具在规模化之后都会遇到类似问题。3. 画布的终点可视化不等于可维护流程不等于逻辑3.1 核心痛点画布上的流程图是静态的业务逻辑是动态的可视化工作流构建器最常见的底层模型是有向无环图也就是 DAG。节点和连线一旦画好执行顺序基本是确定的。这个模型在处理“确定性的步骤链”时非常合适但真实的 AI 业务流程往往不是一条单行道。举一个常见的客服工单处理场景意图识别、情绪判断、是否需要转人工、多轮追问、等待用户补充信息、超时处理、追加知识库检索。随着需求完善分支会越来越多有些节点需要循环有些节点需要根据上一轮结果重新选择路径。这类逻辑在画布上不是不能表达只是表达出来之后维护成本会急剧上升。当画布上的节点超过三五十个整个流程看起来已经像一张密密麻麻的电路图。你不是在维护一个业务逻辑而是在维护一张越来越难读懂的地图。更麻烦的是很多构建器不支持直接在画布上做复杂的循环和状态管理于是团队只能靠各种转接方式实现结果是逻辑变得更难理解。3.2 调试方式从“看流程”变成了“找节点”可视化构建器在早期调试时很直观每一步都能看到输入输出。但这种直观是有上限的。节点少的时候你可以按顺序点开每一个节点看哪一步出了问题。一旦节点数量上来或者流程中有并行分支调试就变成了一场灾难你首先要判断问题发生在哪个分支再顺着连线找到具体节点然后还原那一次运行时的输入和上下文。整个过程非常依赖人工记忆和耐心。代码优先的方案在这一点上完全不同。所有日志可以统一输出到一个地方每次执行的输入输出可以记录成一条完整的 trace可以下断点可以为每个分支写单测。它不是天生的“更直观”但它把调试变成了一套可以沉淀、可以自动化、可以被整个团队共享的方法。3.3 版本、测试、协作是生产系统的三座大山构建器另一个长期被低估的问题是它离真正的工程化体系太远。版本控制是最直接的一个痛点。画布的修改很难做 diff今天领导说改一个判断条件同事把几个节点挪动了位置从外面看整个画布像变了一个样。想回滚到三天前的版本依赖导出文件一个 JSON 文件拖来拖去散落在各个聊天窗口过两周连自己都分不清哪个是最新版本。测试更是基本靠手工。你可以人工点一遍流程确认结果正常但没法把“这个流程应该输出什么”固化成回归测试。下次任何人改一个节点的提示词你都要重新手动验一遍全链路。协作也一样。多个开发者在同一张画布上工作几乎不可能做到互不干扰。要么排队编辑要么各自导出再合并效率远低于代码仓库里的合并请求模式。这三座大山叠加起来就会得到一个反直觉的结果构建器看似比代码更容易上手但在真实的生产环境里它能承担的复杂度反而更低。3.4 一个客观的边界小流程不需要慌当然这里要给一个边界。并不是所有场景都必须抛弃构建器。如果流程节点很少、业务稳定、不需要频繁调整构建器依然是很舒服的方案。比如一个内部的信息通知流程五个节点跑了一年都没变过那完全不需要为了“先进”去重写成代码。真正需要警惕的是那些已经长出大量分支、需要多人长期维护、对稳定性有明确要求的流程。这种流程一旦在画布上失控迁移成本会比一开始就写代码高得多。风险提示判断是否需要迁移可以看一个简单信号——如果每次修改流程都要把整张画布重新看一遍你已经不是在维护业务而是在维护一张越来越复杂的地图。4. AI Agent 不是画布上的一个新节点而是一次范式切换4.1 静态编排与动态编排之间隔着一整套工程体系工作流构建器把“编排”变成了画布上的连线。AI Agent 则把编排从画布上移到了模型内部。传统工作流是人先定义好所有路径流程引擎按路径执行。Agent 是人只给定目标、工具和约束模型在执行过程中自主判断下一步做什么。这看起来只是“要不要提前画好”的区别实际上意味着整个流程系统的设计重心完全变了。画布时代核心设计对象是节点和连线Agent 时代核心设计对象变成三样东西工具定义、上下文结构、决策策略。你在代码里写的不是“第二步调用什么”而是“在什么条件下应该调用什么工具”“出现什么结果时应该停下来问用户”“拿到什么信息后才能继续”。这种变化带来的一个直接影响是工作流不再必须是一张看得见的地图它更像一组可以被测试、被替换、被组合的策略。流程的复杂边界从“画布所能容纳的节点上限”变成了“模型对上下文和工具的理解能力”。4.2 工程化三层决策动态化、工具可插拔、上下文驱动Agent 给工程实践带来的具体变化可以拆成三点。第一决策动态化。分支不再固定模型可以根据中间结果选择下一步。这意味着 AI 应用可以处理那些没有预设路径的输入而不是把所有可能都提前画出来。第二工具可插拔。你不再需要在画布上画几十个节点而是维护一个工具库让模型按需选用。新增一个工具像在配置中心加一条记录调整工具描述就能影响模型的选择结果。这个流程更容易被版本管理。第三上下文驱动。工作流的行为在很大程度由 prompt 和上下文决定。你需要把上下文组装、截断、压缩、持久化当成一等公民来设计。比如多轮对话里历史消息怎么取舍知识库结果怎么排序这些都会直接影响 Agent 决策质量。代码方案能做更细的定制而画布通常只能提供固定组件。4.3 为什么 AI 编程工具加速了这次切换这里还有一个很容易被忽略的变化AI 编程工具正在把“代码优先”的门槛拉低到与画布差不多。过去不选代码是因为写代码的门槛高于拖拽。现在基于 AI 的编程工具可以在几分钟内帮助生成一版可运行的 Agent 代码并把关键逻辑解释清楚。开发者甚至可以把“在画布上搭一个什么流程”的需求直接描述给 AI 编程工具让它先把代码结构搭出来再人工审查和修改。这一点的意义不只是效率而是让代码方案同时获得了两个优势一是保有传统工程体系的一切能力版本管理、测试、CI/CD、权限控制二是获得了和构建器相近的“快速生成”体验。所以与其说 AI Agent 杀死了工作流构建器不如说 AI 编程工具把代码优先的门槛拉到了与工作流构建器同级的水平。当两个方案站在同一起跑线构建器过去的差异化优势“不用写代码”就明显变弱了。5. 哪些构建器真会死哪些反而活得更久5.1 一条分水岭你能否离开那张画布不是所有构建器都会死。真正会死的是那些把自己做成封闭黑盒的工具能活下来的往往会在“可视化”和“代码可编程”之间找到新的位置。判断一个构建器未来还有没有生命力可以问五个问题能不能导出源代码或标准化的 DSL能导出的好歹留了一条迁移路径只能存在平台服务器里的风险最高。有没有完整的编程式 API 或 SDK如果所有操作都要靠鼠标完成自动化、集成、测试都无从谈起。能不能被常规的 CI/CD 和自动测试覆盖不能测试的流程在生产里永远是不定时炸弹。能不能被外部系统调度比如通过 API 触发、传入参数、接收结果。如果只能打开网页手动运行应用范围会非常受限。超过一定节点数之后画布还清晰吗这个需要体感判断但通常过了 30 到 50 个节点很多画布的维护成本就开始指数上升。5.2 容易死和活得久的形态对比判断维度容易死亡的形态还能活下来的形态编排方式只能界面拖拽可导出 DSL可生成代码测试与调试只能在画布里逐个节点查有日志 API、回放工具、可跑测试版本控制导出 JSON 后人工 diffGit 友好diff 可读可入仓开放能力封闭运行时提供 SDK、API可嵌入宿主适用场景复杂业务逻辑长期生产快速原型、小型内部流程协作模型单人编辑同步靠手动多分支、合并请求、可评审这个表格不是绝对的但它能帮你快速判断一个团队或者一个产品的发展方向。5.3 更重要的是场景判断而不是工具对比对普通使用者和开发者来说比“选哪家构建器”更重要的问题是“我的场景到底需要什么”。如果只是临时验证一个想法或者想快速看一个 AI 流程能不能跑通那构建器仍然是最省事的选项。比如做一个周末 Demo验证某个客户的场景用构建器可能一两个小时就完成。这种情况下代码优先反而显得小题大做。但如果这个东西要放进真实业务里长期运行涉及多部门协作、数据安全、异常处理、持续迭代那从一开始就要考虑代码优先或至少代码可编写。因为生产环境真正考验的不是第一周的上线速度而是半年后的可维护性、可排查性和可迭代性。很多人纠结“哪个工具更好”其实是没想清楚“这次交付是一次性的还是长期资产”。一次性交付用构建器没有任何问题长期资产如果没有代码化能力后期一定痛苦。6. 从可视化优先到代码优先一条现实的过渡路线图6.1 不要一上来就推翻分三个阶段迁移如果你已经有一个用构建器跑着的 AI 流程不要急着全部重写。更稳妥的做法是分阶段迁移。第一阶段原型验证期。先用可视化构建器把整体业务跑通快速确认方向、模型选择、输入输出格式。这个阶段的关键产出是一份完整的需求记录每一步的输入是什么、输出是什么、有哪些边界情况、哪些分支是真实高频的。这些记录比画布本身值钱得多。第二阶段逻辑抽离期。开始把核心逻辑写成代码。可以先把最复杂、最不稳定、最需要测试的那段逻辑抽出来比如多分支判断、状态管理、异常重试把它写成一个独立函数或模块。不要一次全量替换而是一个模块一个模块地替换每替换一个就要验证一次。第三阶段生产工程化期。当主要逻辑都已经代码化后把测试、日志、可观测性、权限控制补上接入 CI/CD。此时画布可以退居二线只作为整体流程的可视化说明层而不是唯一运行入口。实操提醒迁移过程中最容易踩的坑是“为了统一而统一”。不要把已经稳定的节点也拆掉重写先动那些维护成本最高的地方。6.2 一个简化版的工程骨架代码优先的 Agent 流程不需要一上来就引入特别复杂的框架。更推荐的起步结构是这样的# 示意结构根据实际框架 API 调整 def run_ticket_classify(request): # 1. 组装上下文 context build_context(request) # 2. 让模型基于工具定义做决策 action call_llm_with_tools(context, tools) # 3. 根据决策执行下一步 if action create_ticket: return create_ticket(request) elif action ask_human: return hand_over_to_human(request) else: logger.warning(unknown action: %s, action) return fallback(request)这段代码本身不复杂关键在于它把流程拆成了“上下文构建、决策、工具执行、兜底”四层。每一层都可以单独测试也可以单独替换。这在画布上虽然也能表达但很难做到同样的细粒度控制。6.3 排查链路流程失败时你该先看什么从可视化切换到代码优先后调试习惯也要跟着变。过去很多人习惯打开画布找节点现在应当按顺序排查先看输入。这次请求的上下文是否完整关键字段是否丢失历史消息是否被截断。再看日志。运行的 trace 是否完整失败发生在模型调用、工具调用还是外部请求超时。再看状态。重试次数、中间状态、人工确认流程是否卡住。最后再看逻辑。确认是规则写错了还是边界情况没考虑到。这个排查链路在工程化体系里很重要。因为 Agent 流程的行为有随机性你不先把输入和日志查清就直接改逻辑往往改完还是错的。排查习惯生产环境里每次运行都应该能对应到一条完整的 trace否则今天修好明天复现根本无从下手。7. 最后一句话工具选择不能替代架构思考7.1 工具选型里最值得问自己的三个问题判断自己该不该继续用某个工作流构建器不需要追新词也不需要看评测。回到三个实际问题上就行。第一个问题这个流程会活多久如果只是跑一次活动、验证一个想法构建器没问题。如果要变成长期服务它背后必须有一套工程体系支撑。第二个问题有几个人长期维护一个人维护画布再乱也能接受三个人以上维护就必须考虑 diff、评审、回滚这些基础能力。代码方案在这一项上优势非常明显。第三个问题出问题后需要多久定位构建器里的报错日志往往分散在节点里而代码化方案可以统一收集、统一检索、可回放。定位速度不是体验问题而是生产事故的恢复时间问题。这三个问题不是让你选工具而是让你知道这次工程决策到底在为什么服务。7.2 把“死亡论”当成一次重新评估的机会如果你现在团队里已经有稳定运行的 AI 流程还不想马上动完全合理。但建议每周或者每个迭代做一次评估这段流程还在稳定吗每次修改要花多少时间如果核心人员临时请假剩下的人能接得住吗如果答案里出现“越来越吃力”“没人敢改”“一改就挂”这些信号那就说明构建器已经把能给的便利给完了接下来需要的是一个更稳固的容器。过去两年里我见过太多项目经历了同一个轮回用构建器三周上线用三个月维护最后在某个周五下午决定重写。重写的成本并不低但每个重写完成的团队都会承认产品的复杂度并没有降低只是终于被装进了一个能测试、能审计、能协作的壳里。工具会更替判断力才是长期能力。AI 工作流构建器的“死亡论”可以被当成一个提醒当你把流程可视化变成一张越来越复杂的画布时就应该停下来问自己你是在用画布表达业务还是已经让画布限制了业务。对于准备踏出新一步的读者我的建议很简单下一个新项目开始时先别急着选工具。先写清楚这个流程的逻辑、边界和生命周期再决定要不要上画布。你会发现这个思考过程才是真正决定项目成败的东西。