为什么Dify Workflow不适合做对外应用？大模型架构选择的深度思考(收藏版)

Workflow方法在处理开放性问题时面临瓶颈，工作量指数级增长。相比固定的流程设计，AI Agent更适合处理复杂开放领域。大模型产品开发应从'固定流程'转向'弹性能力集合'，迭代思维需从解决具体问题转变为赋予通用能力。选择Agent是将产品未来与大模型进化绑定，而非被当前技术局限。

AI小白熊

714人浏览 · 2025-10-11 10:44:54

AI小白熊 · 2025-10-11 10:44:54 发布

为什么不建议使用 Workflow 比如 Dify （主要是 dify 中的 workflow、chatflow 等）去做一个对外（也就是给除了自己以外的人用，尤其是给不会微调的人来使用）的应用？

结论：因为在一些细节、深刻、专业的知识、习惯、领域来说，没有任何两个人的思路、习惯是能 100% match 的，能 match 70% 以上都很难。使用 Workflow 极有可能落入不停构建与优化的循环中。

一个 BI 项目的 Workflow 尝试

Demo 很简单

我之前在一个BI场景做过数据交付的。我们坐拥着海量的数据，计划给用户提供一种对话式服务，方便用户基于我们的数据来帮助他们做生意上的决策。最初，这个问题很简单。其实就是将数据库的数据呈现出来？也就是最通常的 Text2SQL 场景。（我记得当时大模型应用火爆之初的时候，公司里90%以上的应用都是 Text2SQL）

当时这个项目的demo，我大概用了一周就搭建完成。它能准确地将“上个月A产品的销售额是多少？”这类问题转换成 SQL 并返回结果。

在这里插入图片描述

这里不得不提一下，据我现在观察，现在所有的 AI 产品，几乎都有这个毛病：从零到一做得很好，但是从一到100就很费劲。

问题初现

随着业务的深入，越来越多的要求也就来了。比如说，数值结果的结果返回非常不人性化，需要增加解读。又比如，如果用户问的是一个和数据毫无相关的问题，比如说今天天气怎么样，或者和数据相关，但是我们根本查不到；这种情况按照需求，应该是拒绝回答的。那此时有两种选择：

第一就是在原有的 Text2SQL 模块上通过 Prompt 将要求明确一下。-- 但是后来测试效果不好，当时（2023年）模型的智能程度还不够。
这时我们不得不选择第二种方法，就是通过类似服务编排的功能，将多个流程串联，也就是 Workflow。 – 这应该当时是大部分 AI应用的主流选择了，像 dify、n8n 等工具平台也随着这股潮流崭露头角了。

在这里插入图片描述

一开始 Workflow 这种方法去得到惊人的效果。

这里不得已的历史背景：在2022-2023年初，GPT-3.5的上下文只有4K，思维链和规划能力远不如今天的模型。用人类的“预设工作范式”（Workflow）去引导和弥补模型的能力不足，是一种非常务实和不得已的工程策略。这相当于给模型提供了“拐杖”，让它能在特定领域走得稳。

这也是 dify、n8n 等平台构建并火爆的原因之一。

Workflow 的“指数级”优化TODO

随时继续推进，但是渐渐的我发现有三个主要问题：

第一，LLM 模型在拆解思路的时候，总是很难 Match 业务专家的思路；算法同学通过不停地调优 + 记忆（RAG + 关键词检索）一直在推进优化，但是进展缓慢。
第二，在查询的时候速度非常慢，而我们的场景下客户是看不见我们完整的数据，用户并不会感受到这个问题是很难的问题。因此我们还做了一些数据库改造适配的工作。
第三，在后来业务专家又提了，如归因分析、市场诊断等需求。

这就导致这个 Workflow + 调优的工作量按指数级膨胀。Workflow 的方案正式走到尽头了。考虑到有一部分用户已经在使用了，方案前移做得比较谨慎。但是，虽然慢，我们不能停。同时也启动了 AI Agent 重构计划。

从重构计划启动，到落地，中间又浪费了三个多月。最重要的是，我们的 AI Agent 解决方案，相比于之前就是降为打击一般的优势。换而言之，之前的大部分工作都被“归零”了 …

反思，到底哪里不对劲？

Workflow 的选择，是人的本性，也是做产品的惯性

想象一下我们在教大模型去做事情的时候（调 Prompt 时），很容易会将我们专业领域的知识，分成一个一个的流程图。第一步、第二步、第三步、 … ，这些长久以往支持我们完成任务的经验和智慧，可能是从我们工作中来的也有可能就是来自于你的某位 mentor。我们本能的习惯将功能进行划分。

所以在面对大模型这样一个“看似”有智慧的家伙，我们很自然地就会用这种方式去教他：第一步、第二步、第三步、 … ，也就很容易陷入难以泛化的漩涡，及应用每往前走一步都需要大量的开发、调试，外加任何改动都会牵一发而动全身的“复杂感”。

另外，以往的软件产品迭代，我们也习惯了一步步去思考，一次次的迭代。但是在智能体这里，我们需要的是“抽象”，将不同个例的共性汇聚起来。

技术边界决定了产品形态，产品形态影响了技术选型

Workflow 问题的根源在于，我们试图用“流程图”去定义一个“开放世界”。我们可以用一个类似“光谱”的图来理解：

标准化工具：Workflow 的主场

当你的产品提供的是一套成熟、有明确边界的流程时，Workflow 是最佳选择。例如，一个“生成金融风控报告”的功能。用户点击按钮，系统严格按照“查询征信 -> 分析流水 -> 评估模型 -> 生成报告”的步骤执行。产品的边界就是 Workflow 的边界，用户的行为被牢牢锁定在你的设计之内。此时，Workflow 的确定性和稳定性是优点。

自由对话伙伴：Agent 的天命

但如果你提供的是一个“万能对话框”，比如真正的 ChatBI，用户的目标是“帮我分析上季度销售下滑的原因”，这就进入了 Agent 的领域。用户期待的是一个能理解他开放式目标的智能伙伴，而不是一个需要他去适应流程的死板工具。试图为所有可能性绘制流程图，是徒劳的。

试想一下，你给了用户一个开放的输入框，却用各种隐藏规则限制他（的需求范围），这会带来巨大的“挫败感”。用户会困惑：“你明明给了我方向盘，却告诉我只能在轨道上开？”

越来越模糊的边界

所以这也引出了在一个大模型产品的团队里面，其实技术和产品的边界越来越模糊。在传统软件开发中，产品经理定义“规则”，工程师负责“实现”，边界清晰。但在大模型产品团队里，这条线变得模糊。产品经理不能只画线框图，更需要理解技术的边界和可能性，从设计“固定的流程”转变为设计“弹性的能力集合（Tools）”；而开发者也不再是单纯的代码执行者，他们必须深入业务，因为他们构建的每一个工具、每一个API，都是在为 Agent 定义它能理解和感知的“世界”的一部分。

抽象、抽象、还是抽象

随之改变的，还有我们迭代产品的思维范式。以往的软件迭代，习惯于“一步步迭代”、“哪里出问题就修哪里”的线性思维，通过增加功能来满足特定需求。但在智能体的世界里，这种“打补丁”式的迭代只会让你被动的 follow 用户的需求。真正的 Agent 迭代，需要的是“抽象”能力。面对需求时、遇到失败案例时，我们不应只针对这个个例去优化，而应该反思：Agent 是缺少了哪种“通用的能力”才导致了这次失败？迭代的目标，不再是“解决这一个问题”，而是“赋予它解决这一类问题的能力”。这是一种从“归纳法”到“演绎法”的思维跃迁，也是通往更高智能的唯一路径。