你把 Dify 的客服机器人从 Workflow 改成 Agent 的那天，它学会了一件你不想让它学会的事：自作主张。该查订单的时候不查，先跟客户寒暄；该转人工的时候不转，非要自己编一个答案。你在后台盯着运行日志，不知道是该骂模型，还是该骂当初做选择的自己。
我最早对这两个模式的判断特别简单：Workflow 是给人用的，Agent 是给 AI 用的。后来被线上事故教育了几个月，才发现这个二分法是错的。正确的问法不是 "哪个更聪明"，而是 "这个任务里，流程路径是可以穷举的吗？"
先搞清楚：Workflow 到底在做什么？
Workflow 模式的编排界面，本质上是一个有向无环图（DAG）。你拖一个开始节点，接上 LLM 节点、条件分支节点、知识检索节点，最后接一个回答节点。数据像流水线一样从上往下流，每个节点都有明确的输入输出，跑完一个才能进下一个。
Dify 的官方工作流文档里，所有流程都由节点和连接线组成，执行时按固定顺序跑。所有分支由你预先画好，模型只能在固定节点内部做生成，它不能自己跳到另一个节点。客户说 "我不想要了"，如果你的图里没有退款分支，它就走不到退款工具。
这意味着什么？意味着这种模式的优点和缺点是同一件事：确定性强，但不灵活。每个分支你都能预测，出了事，看节点日志就能定位是哪一步的问题。代价是，用户输入稍微超出你画好的范围，系统就死板得像一本没用过的说明书。
Agent 模式到底在做什么？
Agent 模式走的是另一条路。你不用画图，而是给模型一张工具清单，比如 "查询订单"、"获取物流信息"、"转人工"。模型按照 ReAct 这类推理框架自己循环：Thought（这一步该干什么）→ Action（调用哪个工具）→ Observation（看工具返回什么）→ 再 Thought，直到它觉得攒够了信息，给出最终答案。如果你选用支持 function calling 的模型，模型可以直接输出结构化的工具调用指令，平台来执行。
Dify 的Agent 模式文档说得很直接：它会根据用户的输入，动态规划接下来要调用哪些工具。你的业务规则没有变成一个图，而是变成了模型脑子里的临时想法。它在运行时才生成流程，而且每次运行时生成的流程都可能不一样。
一张表说清两者在五个关键问题上的分歧
| 维度 | Workflow 模式 | Agent 模式 |
|---|---|---|
| 流程定义 | 人预先画死 DAG | 模型在推理时动态生成 |
| 错误模式 | 规则错误，可复现 | 概率错误，不可复现 |
| 调试方式 | 看节点日志，按图索骥 | 看 Thought/Action 轨迹，猜模型意图 |
| 工具调用 | 适合固定、带强校验的调用 | 适合多变、语义模糊的调用 |
| 成本波动 | Token 和时延可预估 | 循环轮次不定，成本波动大 |
我为什么从 "全 Agent" 改成了混合架构
有一段时间，我几乎把所有 Dify 应用都配成 Agent 模式，用当时最强的模型，工具描述也自认为写得足够清楚。直到有次知识库问答任务，它放着检索工具不调用，直接用记忆编了一段回答。而且那种错误在日志里很难发现，因为它的 Thought 步骤写着 "我应该直接回答，不需要检索"——看起来非常合理。
后来我才想明白一个简单的数学事实：Agent 的每一步选择都是概率性的。就算每一步选对的概率是 95%，连续五步之后，最终路径完全正确的概率大约是 0.95^5 ≈ 77%。每多一步，误差就多积累一点。模型不会因为要对你负责，就自动提高每一步的成功率。
Workflow 的价值就在这里：它不是傻，它是用固定的规则把不确定性链条剪断了。该走哪条分支，由条件判断决定，而不是由模型猜。
遇到这几种情况，别犹豫
我的选型原则，先看流程能不能被枚举。
- 流程分支少、规则硬，选 Workflow。比如退款必须先验证身份、未支付订单不能发货。这些规则不应该由模型来 "领悟"，画图写死才安全。
- 输出格式强约束，选 Workflow。后端接口要求 JSON，多一个逗号都报错。让模型自由输出等于给自己找 bug，应该用固定节点把字段模板定死。
- 用户输入开放、意图没法穷举，选 Agent。例如 "帮我查一下北京明天的天气，顺便定个后天早上的高铁"。这类请求的组合方式近乎无限，人画分支会画到崩溃。
- 主干要可控、局部要灵活，选混合架构。Dify 允许在 Workflow 里嵌入 Agent 节点（Agent 节点文档）：先把用户请求分流，查询类走固定流程，复杂操作类丢给 Agent 自主调工具。
我把这个原则压缩成一句话：能在规则层解决的事情，就不要留给概率；必须在概率层解决的事情，才交给 Agent。
关于 Agent 和 Workflow，被问过最多的 5 个问题
Agent 模式是 Workflow 的升级版吗？
不是。它们是两种不同的编排思想。Agent 灵活但不确定，Workflow 死板但稳定。很多场景下 Workflow 反而更适合生产环境。
在工作流里加 Agent 节点，就等于 Agent 模式吗？
不完全是。整体应用还是 Workflow 在控制主流程，Agent 只是其中一个步骤。好处是你可以把 Agent 的不确定性限制在一个局部，不影响全局。
为什么我的 Agent 会反复调用同一个工具？
因为循环的终止条件也是模型决定的。工具返回结果如果不够明确，或者模型上下文被截断，它可能会认为任务没完成，继续调用。解决思路有两个：在 Workflow 外层包一个调用次数上限，或者把工具返回信息写得更结构化。
做 RAG 问答，该用哪个？
如果只是 "查询知识库-生成回答"，Workflow 更省心，路径固定，好调试。如果问题需要多次检索、对比多份资料，Agent 会更灵活，但你需要接受它偶尔漏检或乱检。
团队是新手，应该先学哪个？
先学 Workflow。它帮你理解节点、变量、条件分支这些基础概念，也更容易在出问题时定位原因。等你能把流程画清楚了，再学 Agent，才有对比的参照物。
想进一步了解 Function Calling 和 ReAct 的区别？
ReAct 是由这篇论文提出的一种推理框架，让模型用自然语言输出思考过程，再决定动作；Function Calling 是模型直接输出结构化函数调用，更省 token、更稳定。在 Dify 里，你可以按模型能力选择用哪一种。如果跑开源模型，ReAct 往往是更通用的选择；如果用 GPT-4o 或 Claude 这类支持函数调用的模型，优先选 Function Calling。
最后说说我的判断
现在再有人问我选哪个，我的答案不再是非此即彼。先数一下，这个流程如果让一个人来画，需要多少种分支。
分支少于 10 个，画出来；分支多到人脑维护不了，用 Agent。混合架构是大多数真实业务的答案：用 Workflow 守住底线，用 Agent 处理长尾。别追求 "最智能的架构"，追求 "最好出问题后能定位的架构"。
毕竟，AI 产品上线之后，你半夜爬起来看的不是模型有多聪明，而是日志能不能告诉你它错在哪。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/356.html