前言：
今天，我们分为通用型AI Agent VS Workflow，以及Workflow的5种常见模式，这两个部分来详细阐述。
一、通用型AI Agent VS Workflow
最近做 Agent 的工作比较多，大部分都是聚焦在具体业务做 Agentic Workflow。
市场上也出现过非常多的通用型Agent，比如Manus Al，大厂的Deep Research，试了一下这些工具，表现确实不错，但也存在一些稳定性和准确性的问题。
TLDR: 通用型 Al Agent 虽然拥有强大的灵活性和问题处理能力，但目前仍无法完全替代Workflow。
要实现业务规模化、低成本、高效率以及可控可测的目标，最佳方案是将两者结合: 通过 "Workflow+LLM/Agent" 的模式在控制成本与风险的同时充分发挥通用型 AI的适应性和创造力。
1.Generalist VS Specialist: 先验知识的重要性
在实际项目中，我们往往已经积累了大量与业务领域相关的经验和先验知识。
例如，如何高效地从某个特定网站抓取所需信息，或者在某些流程环节上如何进行快速校验。
这些经验和知识可以帮助我们针对性地搭建更加高效、可靠的流程，而无需让通用型 Al Agent 进行大量无意义的探索和尝试。
这就好比在强化学习中，过度的 exploration(自由探索)往往带来成本和时间的浪费，而加入 domainknowledge 的 exploitation(利用现有知识)则能显著提升效率。
2.速度与成本考量: 精确聚焦与减少浪费
如果让通用型 Al Agent 完成所有流程环节，那么在执行一些我们已经非常熟悉、或无需大量推理的步骤时，往往会消耗许多不必要的 Token 与执行时间。
针对这些固定且结构化的任务，直接使用既定的 Workflow 会更加高效、廉价。
只有在流程中需要进行复杂的决策、处理非结构化信息或涉及高度不确定性的任务时，再调用 LLM(大语言模型)即可。
这种方法能够最大化地发挥 LLM 在推理上的优势，同时又有效控制了额外成本和不必要的计算浪费。
3.可扩展性: 保持流程的模块化和灵活度
当我们将任务切分为多个模块，各个模块可以独立地进行开发、测试和部署，形成一条完整的Workflow 流程。
这种模块化设计在大规模应用(scale up)时更具优势: 如果我们想扩展系统的功能或增加新的数据源，只需要对对应的部分进行扩展或替换即可，而不必让通用型 Al Agent 从头到尾一次次地"重新学习"整个流程。
4.可评估性:更易验证与控制整体稳定性
Workflow 模式的一大优势在于，它能让我们清晰地掌控每一个环节的输入和输出。
一旦某个环节出现问题，可以快速定位并进行针对性优化。对系统的可预测性和稳定性的需求，往往要求我们有足够精细化的评估与监控手段。
而单纯依赖一个全自动的通用型 Al Agent，则会给调试和质量把控带来更多挑战。
5.AI本质是搜索:缩小搜索空间 vs.全局探索
从广义上来说，Al的很多任务都可以视作一种搜索问题。通用型 Al Agent 相当于扩大了搜索空间，能够进行更多元的探索，但在某些场景下其实并不需要如此宽泛的搜索。
Workflow 更注重利用我们已知的先验知识、特定的业务流程，直接跳到最优(或接近最优)的解决方案，即"exploitation"。通用型Al Agent 则更加偏向于"exploration"。
如果我们毫无保留地交给它去探索，虽然可能会发现一些更具创造性的解决方案，但同时也会付出更高的成本并降低效率。
6.平衡与结合:在实际应用中取长补短
因此，在实际业务落地时，应当根据需求和资源状况合理设计系统:
针对重复性高、结构明确的工作，使用固化的Workflow 来保证稳定性与低成本。
在需要更灵活的认知能力和推理能力、或需要应对未知情况时，再借助通用型 Al Agent 的强大自然语言处理及思考能力。
通过制定清晰的输入输出规范，并对关键步骤进行精细化评估与监控，使两者能够相辅相成、取长补短。
二、Workflow的5种常见模式
从Block开始
无论是Workflow 还是 Agent，它们的基础调用单元都是Block(如下图)
一个Block就是一个增强的LLM: 通过调用检索、选择适当的工具、读写记忆构成。
被LLM调用各种工具所遵循的协议，即为ModelContextProtocol(MCP)
有了Block作为基础单元后，我们就可以开始拼接Workflow了。以下，理了五种常见的Workflow模式。
Workflow1:Prompt chaining(工作流:提示词链)
如下图，我们将一系列的Block串联在一起，每调用完一个block之后，基于其输出进行判断是否要调用下一环节，类似编程中的IF-THEN 逻辑。
这种工作流适合那些可以被清晰串行切分的任务，比如:
多语言营销文案: 生成营销文案;将其翻译成不同语言
制式文章撰写: 编写大纲；按照预先的标准检查大纲;如果合格的话就基于其编写文档。
Workflow 2: Routing(工作流:路由)
和提示词链的结构相比，增加了一个分类路由环节。基于输入的内容进行分拣，从而确定后续走哪一个下游流程。
类似编程中的SWITCH-CASE 逻辑。
这种工作流适合哪些需要被分拣分类的任务，比如:
客服场景:
识别用户反馈的问题(退款、咨询、技术支持)，将问题转交到不同的下游分支进行处理。
在LLM出现之前，这个工作更多的依赖专向训练的分类模型来实现。
大小模型分流:
通过识别问题，将简单的问题路由到较小的模型、复杂的问题路由到较大的模型从而优化成本、提升效率。
比如，在应用DeepSeek的过程当中，我们就会发现，并不是所有问题都需要DeepSeek"深思熟虑"之后再给出答案的，很多问题可能直接查询来得更简单。
Workflow 3:Parallelization(工作流:并行化)
当一个父任务可以被拆解为并行执行的几个子任务的时候，就可以采用并行化的工作流先拆分再聚合。
典型的场景如代码中的漏洞检查，不同的prompt触发不同角度的检查，然后聚合输出报告。
Workflow 4:Orchestrator-workers(工作流:协调器-工作器)
"协调器-工作器"模式的工作流就像是"路由器模式"+"并行化模式"的组合。
在这个模式中，协调器LLM节点负责动态的拆解任务，然后选择对应的1个或多个工作器LLM节点进行处理，最后进行合成输出。
Workflow 5:Evaluator-optimizer (工作流:评估器-优化器)
"评估器-优化器"的工作流将LLM节点分为两类，一类负责答题(生成)，一类负责判卷(评估)。
当我们对输出有着明确评估标准且多次迭代能够改进输出时，就适用于这种模式。
典型的场景如文学翻译，一些细微的措辞差别可能影响结果的质量，那么一个LLM评估器就能够给生成节点以反馈，从而改进输出的结果。
梳理完上述五种工作流模式，我们不难看出，各种工作流是可以不断叠加嵌套的。
比如，我们可以将前面4种Workflow作为"评估器-优化器"的生成节点，再引入一个新的评估节点来评估之前的结果、提出改进意见。
"我们的核心关注从来不是技术本身，而是如何通过现有技术体系解决实际业务问题，为客户创造更大价值。
我们不需要复制一个 OpenAl Deep Research 或 ManusAI，但我们利可以用我们的专业知识，在某个niche(细分领域)做得比他们好，这就够了，这才是我们的差异化竞争力所在。"