为什么不建议使用 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 问题的根源在于，我们试图用“流程图”去定义一个“开放世界”。 我们可以用一个类似“光谱”的图来理解：

1. 标准化工具：Workflow 的主场

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

2. 自由对话伙伴：Agent 的天命

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

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

越来越模糊的边界

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

抽象、抽象、还是抽象

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

四、如何学习AI大模型？

如果你对AI大模型入门感兴趣，那么你需要的话可以点击这里大模型重磅福利：入门进阶全套104G学习资源包免费分享！

这份完整版的大模型 AI 学习和面试资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

这是一份大模型从零基础到进阶的学习路线大纲全览，小伙伴们记得点个收藏！

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

100套AI大模型商业化落地方案

大模型全套视频教程

200本大模型PDF书籍

👉学会后的收获：👈

• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

LLM面试题合集

大模型产品经理资源合集

大模型项目实战合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓