别再无脑上Agent！Agent和Workflow到底该怎么选？

“做个 Agent 吧。”

这两年，这句话出现的频率高得离谱。产品要加 Agent，客服要换 Agent，连内部报销流程，都有人提议“搞个智能体来跑一跑”。

好像谁不把业务 Agent 化，谁就错过了互联网的下一班地铁。

但最近我看到一篇有点意思的文章，来自 Dify 的官方博客——就是那家靠 Agent 编排平台吃饭的公司。

一家卖 Agent 平台的厂商，文章开门第一句不是“Agent 有多强”，而是——

不是每个任务，都需要 Agent。

这就好比健身房主动劝你别办年卡：卖卡的亲口说这话，分量才不一样。

这篇文章，连同它引用的几篇实战文，我都读完了。就一个感受：这话早就该有人说透了，值得掰开讲一遍。

一、先回答一个问题：下一步，谁来定？

Agent 和 Workflow 的区别，网上一万种说法，什么自主性、什么编排能力、什么智能体架构，越说越玄。

Dify 这篇文章给的标准却朴素得惊人，一句话就能说完：

Workflow：下一步干什么，你在搭建那天就写死了。

Agent：下一步干什么，模型在运行时自己决定。

你写一个报销流程：提交 → 校验发票 → 金额超 5000 转总监审批 → 打款。每一步都是你提前画好的，模型顶多在“校验发票”这一格里当个零件。这叫 Workflow。

你写一个运维助手：只告诉它“服务器告警了，去处理”。它自己看日志、自己判断是不是磁盘满了、自己决定先扩容还是先回滚。每一步走哪，都是它临场拍板。这叫 Agent。

看出来了吗？

Workflow 里，人是流程的主人，模型是零件。Agent 里，人是目标的甲方，模型是包工头。

哪种更可靠，不言自明。哪种更灵活，也不言自明。

那到底怎么选？往下看，一个例子讲透。

二、一个 IT 工单，讲透全部

原文里有个例子特别妙，员工给 IT 部门提请求，两种典型：

请求一：帮我重置密码。

这事有悬念吗？没有。核验身份 → 开工单 → 重置 → 发通知，全世界公司的密码重置都长一个样，步骤 100% 已知。

请求二：我电脑感觉不太对劲。

这事有悬念吗？太有了。可能是网络断了，可能是中了挖矿木马，可能是硬盘快挂了，也可能只是他没插电源。

哪个该用 Workflow、哪个该用 Agent，答案已经写在问题脸上了：

重置密码，用 Workflow。 几秒出结果，成本约等于零，跑一万次都是同一个样子，审计的时候每一步有据可查。

“电脑不对劲”，用 Agent。 因为连人都不知道下一步该查什么，你没法提前写死一条路径。让模型边问边查边想，问一句、诊断一步、再决定下一步——这恰好是它擅长的。

真实的事故现场，往往反着来：

有人给“重置密码”上了 Agent——一个步骤完全固定的流程，非要模型每次运行时“思考”一遍该走哪步。多烧钱、多耗时，还时不时整点新花样：心情好的时候，连身份核验都能给你跳过去。

也有人在“电脑不对劲”上画 Workflow——吭哧吭哧画了 20 个分支节点，试图穷举所有故障可能，最后发现现实世界总能开出第 21 个分支。

把固定流程交给 Agent，是用不确定性换掉到手的确定性；把开放问题画成 Workflow，是用确定框架去硬套不确定的世界。

两个方向，都是灾难。

那现实里的企业流程，绝大多数属于哪一类？报销、审批、开户、进销存……坦白讲，十有八九，步骤都是已知的。

这就是为什么我要喊这一嗓子：别无脑上 Agent。

三、真正落地的系统，从来不是二选一

讲到这里，你可能以为结论是“能画流程就别用 Agent”。

不。企业级的真实答案是：全都要，而且是嵌在一起要。

Dify 那几篇实战文章里反复出现同一个架构，我把它压缩成三句话：

第一句，Agent 当前台。 人的话是乱的、碎的、带情绪的——“那个啥，我电脑蓝屏了还是死机了来着”。这种话别指望画成流程图，让 Agent 站在门口听懂人话。

第二句，Workflow 当执行器。 Agent 听懂意图之后，别让它自由发挥。真正干活的每一段——查工单系统、跑诊断脚本、走审批链——全部封装成确定性 Workflow，交给 Agent 当工具来调。

第三句，中间卡一道人工审批。 涉及钱的、涉及删库的、涉及对外发消息的，模型先把草案跑出来，人按一次确认，再放行。

一句话总结这个架构：

模型的判断力用在入口，业务的确定性锁在流程里。

Agent 负责从 0 到 1 理解问题，Workflow 负责从 1 到 100 不出幺蛾子。这是我目前看到的、真正能在企业里活下来的形态。

顺带说个我印象很深的案例。有位作者用了很多年 Calendly，一款预约软件，功能都在，但总有些地方不顺手。他没迁移数据，没重买系统，而是给这个老软件套了个 Agent，让模型自己摸索，把它“掰弯”成想要的样子。

这个案例妙在哪？“让旧软件听话”，就是个典型的路径未知问题——没有现成流程可画，只能让模型边试边走。

这才是 Agent 该干的活：目标清晰，路得自己趟。

四、铺给全公司之前，先过四道关

前面讲的都是“怎么选”。但这篇文章真正值钱的部分，是文末给 IT 团队的检查清单——一个 Agent 在 demo 里跑通，和在全公司铺开，中间隔着四道关。

第一道，结果关。 这个 Agent 什么叫做“做完了”？写不出验收标准、列不出测试用例，项目就不该启动。别笑，一大半 Agent 项目的立项文档里，“完成”两个字压根没有定义。

第二道，权限关。 Agent 能读哪些系统、能写哪些数据、能不能删东西，每一条权限都收窄到刚好够用。给 Agent 开管理员账号，等于让实习生掌管整个机房的 root，这不是信任问题，是概率问题。

第三道，质量关。 模型不确定的时候，它不会举手说“我不会”，它会一本正经地编一个答案。所以兜底策略、评测集、全量日志，必须在上线前就位，而不是出事之后补。

第四道，责任关。 Agent 重置错了一个高管密码、给全员群发了错误通知，谁负责？响应流程是什么？日志留多久？这道关跟技术无关，但没有它，前面三道全白搭。

这四道关，建议直接收藏。以后任何一场“我们要不要上 Agent”的会，照着过一遍，能省掉后面百分之九十的撕扯。

五、说到底，这不是一道技术选型题

标题喊的是“别再无脑上 Agent”，但真正的结论是另一句话：

别把 Agent，用在已经有标准答案的地方。

流程确定的任务，Workflow 又快又稳又便宜，模型在里面当好零件就够了。

真正配得上 Agent 的，是那些“目标明确、路径未知”的活——诊断、排查、研究、把不顺手的旧系统掰成自己的形状。

把确定性交给流程，把判断力留给模型。

下次开会，又有人提议“这个流程咱们也 Agent 化一下吧”——把这篇文章甩给他。

---

最后给一张速查表，存下来，选型的时候照着对：

你的任务长什么样	该用什么
步骤固定，跑一万次都一样	Workflow
目标明确，但路径未知	Agent
真实的企业级需求	Agent 当入口，Workflow 干活，人工审批把住关键关
说不出“做完了”长什么样	先别立项，回去想清楚再来