智能体编排平台近两年几乎是"言必称Agent"，但真到了搭建生产级应用的时候，很多人卡在同一个问题上：这个需求到底应该画成工作流，还是应该丢给Agent去自由发挥？我见过不少团队在Coze、Dify里反复推翻重来，今天用Agent爽了一下，明天发现上下文被塞爆，后天又改回纯工作流，然后抱怨"太死板"。老实说，这个问题没有标准答案，但有非常明确的判断逻辑。这篇文章就把我在实际项目里趟出来的经验整理一遍，聊清楚智能体编排平台里工作流和Agent各自的边界、挂接方式，以及到底该怎么分工，才能既扛得住业务复杂性，又不会让成本和失控风险把你拖垮。

1. 先分清本质：工作流是确定性管道，Agent是穷尽解释权的决策器

1.1 同一个编排平台，藏着两种完全不同的执行模型

很多刚接触智能体编排平台的人容易把"工作流"和"Agent"混为一谈，因为从界面看它们太像了：都是拖拽节点、连线、配置参数。但底层执行模型完全不同。

工作流（Workflow）本质上是一张有向图。节点之间的连线是唯一路径，数据沿着边流动，每一步做什么在运行前就已经完全确定。换句话说，工作流描述的是"怎么做"，它把达成目标的步骤提前固化下来。

Agent则是一个循环：接收任务、调用工具、观察结果、继续推理，直到它认为目标达成。Agent描述的是"做什么"，至于每一步具体怎么做，是由大模型在运行时根据上下文临时决定的。同一个任务，这次跑和下次跑的路径很可能不一样。

这个差异我用一个类比来解释：工作流是地铁线路图，Agent是出租车。坐地铁，你提前知道每一站停靠顺序，正点率几乎可以预测；坐出租车，司机根据实时路况选择路线，可能上高架也可能钻小巷，你能保证的是到达目的地，不能保证的是经不经过某个特定路口。

1.2 确定性程度决定可靠性、可控性和可解释性

确定性程度直接决定了后面三件事：

第一，可靠性。工作流里没有任何"智能化"的部分，只要输入格式对了，输出格式永远稳定。Agent因为依赖大模型推理，存在概率性，同样的输入可能产生完全不同的输出，极端情况下还会出现幻觉。

第二，可控性。工作流中出了问题，你可以直接定位到具体节点，因为它只有这一条执行路径。Agent的执行路径是运行时才生成的，要复盘它为什么选了工具B而不是工具A，只能靠日志一层层回溯，排查成本高得多。

第三，可解释性。工作流整个路径可以截图给客户、给审计看，每一步都有据可查。Agent的中间推理过程虽然也能记录，但那是海量的Token和思考链，业务方很难一眼看懂。

所以结论先行：凡是"必须按固定SOP执行、输出结果要稳定可预测、出了错要能快速定位"的部分，应该放进工作流；凡是"没有标准答案、需要综合判断、允许不同路径达到同一目标"的部分，才适合交给Agent。

1.3 常见误区：Agent更智能所以应该全面替代工作流

我见过不少人抱着"Agent比工作流高级"的想法，把原本简单的流程改造成一个巨大的Agent，让它在工具清单里翻来翻去找答案。比如做个订单查询功能，明明只需要三步：解析用户输入、查数据库、格式化回复。放进Agent之后，模型每次都要先决定"我该不该用查询工具"，一次查询多出来几百Token的推理开销，还时不时把工具参数填错。

反过来也有另一个极端：把所有逻辑都画成密密麻麻的工作流节点，连"判断用户这句话是问价格还是问库存"都要用条件分支做关键词匹配，结果遇到没覆盖到的表述就犯傻。

正确的姿态是不要搞"路线之争"，而是把两者当成不同规格的零件。一流智能体编排平台的做事方式，永远是"哪里需要确定性，哪里就上工作流；哪里需要灵活性，哪里就上Agent"。

2. 流程负责"扛住"，Agent负责"判断"：各自的能力边界

2.1 工作流的核心能力：编排、状态管理、错误重试、数据转换

智能体编排平台里，工作流擅长的事非常明确：

• 编排调用顺序：先做A再做B，B的结果作为C的输入，这种顺序依赖关系是工作流的主场。
• 状态管理：整个流程运行过程中的中间变量、分支上下文、循环变量，工作流平台帮你管理得明明白白，你只需要在节点间传参。
• 错误重试：某个API偶发超时，工作流可以配置重试次数和退避策略，这在一个完全由大模型驱动的Agent循环里很难精准实现。
• 数据转换：格式清洗、字段映射、批量处理，工作流的代码节点或内置转换器处理这类任务干净利落，不需要消耗大模型Token。

我自己最常用的一个场景是"多数据源拉取 + 聚合"。比如给一个项目做竞品信息汇总，工作流里并行调用三个搜索API，各自返回JSON，然后用一个代码节点把结果统一成相同的schema，再交给后续节点。这套逻辑如果用Agent做，模型得自己决定调用顺序，还可能串行等待，浪费大量时间。

2.2 Agent的核心能力：拆解任务、动态决策、多工具联动、记忆

Agent的能力是对任务空间做动态规划。相比工作流的固定路径，Agent擅长以下几点：

• 任务拆解：一个模糊的描述，比如"帮我整理这批客户电话会议的要点"，Agent能自己拆成抽取会议记录、按主题归类、提炼行动项、生成纪要几个子任务，而不是像工作流那样需要你手动把子任务全部定义好。
• 动态工具选择：你有20个API工具，Agent会根据用户需求挑合适的调，甚至组合调用。工作流则要求你在设计时就把工具调用顺序写死，无法覆盖所有可能组合。
• 记忆与多轮对话：用户说"再详细一点"，Agent能结合之前的上下文理解"再"字指什么。工作流更像单次请求响应，多轮对话的记忆维护不是它擅长的事。

2.3 从上下文窗口看边界：工作流省Token，Agent好吃Token

这一点在"dify工作流上下文超长"这个热搜里体现得特别明显。很多人把大量参考材料塞进Agent的上下文，跑不了几步就把上下文撑爆，费用还高得吓人。

原因在于Agent每次做决策时，都要把当前所有对话历史、系统提示词、工具描述都送入模型推理，这些都属于"每轮都要付钱的Token"。如果一段业务逻辑可以拆成工作流节点之间的数据流转，那么数据只在节点内部传给大模型一次，而不是反复打包进Agent循环。

举个数字上的对比：假设一次完整的申报审批要经过5个判断环节，每个环节需要2条事实数据支持推理。Agent模式会把这5轮判断和10条数据全部累积在上下文中，后几轮推理时前几轮内容再次计费，最终Token消耗可能是工作流模式的3到5倍。

所以我要给一个很朴素的建议：能放进工作流节点传给模型的数据，就不要提前塞进Agent上下文。这个习惯能让你的Token账单至少瘦身一半。

3. 主流平台的工作流与Agent分工，其实长得很像

3.1 Coze/扣子：画布型工作流 + 独立Agent的"人设"层

Coze给用户的直觉是：左边一个Agent编辑器，右边一个工作流画布。Agent负责"交互层"，工作流负责"执行层"。比如你在Coze里建一个建站Agent，它的工作方式是理解用户需求后用自然语言转成指令，然后触发建站工作流去跑固定流程，最后再把结果组织成回复。

这样一个设计的好处是职责清晰：Agent面向用户，做意图理解、语气控制、多轮对话；工作流面向系统，做确定的业务流水线，比如发请求、解析数据、渲染模板。平台里还有个细节是Agent可以调用"知识库""工作流""插件""触发器"等多类资源，所谓"Agent调用工作流"其实就是把工作流注册成一个工具，Agent在推理时决定要不要触发它。

3.2 Dify：Chatflow与Workflow两种模式的分野

Dify把这件事拆得更明显：创建应用时让你选"聊天助手（Chatflow）"还是"工作流（Workflow）"。聊天助手本质上是带对话记忆的Agent形态，工作流是无状态的自动化流水线。

Dify里一个典型分工是：主流程用Chatflow接收用户请求，通过意图识别节点分流，然后调用一个独立的工作流处理后台数据清洗、排序、入库，最后再用Chatflow组织回答返回。Dify的工作流节点里同样支持Agent节点，节点内部可以配上下文、工具列表，作为工作流的一条支线存在。

我之前遇到过一个"上下文超长"的翻车案例就出在Dify上：同事把工作流节点里的系统提示词写了两千多字，又把参考文档全文塞进节点上下文，加上用户问题，每次调用直接突破模型窗口。排查后发现，那两千多的提示词里真正有用的不到800字，参考文档根本可以拆成检索片段按需拉取——这就是典型的没有遵守"工作流内Agent节点只喂必要数据"原则。

3.3 n8n：把Agent当作节点，用工作流编排Agent本身

n8n和国内平台思路不太一样。n8n本身是通用自动化/工作流工具，Agent是它支持的一种节点类型。你在n8n里画一条工作流，中间放一个Agent节点，让模型在这个节点里去调用其他工具节点。也就是说，n8n的编排对象不仅是普通API，也包括Agent本身。这相当于"用工作流管Agent"，很适合做复杂的后台自动化场景：先由工作流触发器决定何时启动Agent，Agent在内部做动态决策，结束后把结果交还给工作流继续下一步。

3.4 三个平台的抽象模型对比

平台的呈现形式各不相同，但本质分工没变：能确定路径的用工作流，需要临场判断的用Agent，只是平台叫法不同、节点层级不同而已。

4. 实战复盘：简历筛选机器人改了三轮，工作流和Agent分别承担了什么

4.1 第一轮：全Agent方案，爽了一周就翻车

之前团队要做一个简历筛选机器人，需求是用自定义标准从几百份简历里筛出面试候选人，还要给HR输出评价摘要。第一版图省事，我们直接在智能体编排平台里建了一个大号Agent，把所有简历内容塞进知识库，让Agent检索并判断候选人匹配度。

前一周效果奇好，因为简历数量少，示例够多，模型判断得也算有模有样。等简历涨到几百份，问题全来了：上下文被长文档塞爆（就是"dify工作流上下文超长"同款场景），检索结果不准确，常常把不同候选人的经历混在一起，更崩溃的是同一份简历跑两次，前面模型说行，后面说不行，HR根本没法用。

4.2 第二轮：纯工作流方案，死板到无人维护

团队复盘后决定全部改成工作流：解析简历、提取字段、规则匹配、计算得分，一条流水线画到底。初筛阶段确实稳定了，但一到需要"软性判断"的环节就抓瞎。比如"该候选人的经验是否符合岗位的发展潜力"，这不是几张表能写清楚规则的，我们试着做了关键词匹配，结果把一堆技术关键词堆砌的简历全筛进来了。工作流版本跑了两周就积累了一堆补丁，条件分支越来越多，维护人员离职后根本没人敢动这坨流程。

4.3 第三轮：按"可否校验"分工，稳定与聪明各归其位

最后一版我们终于想明白了：凡是HR可以给出明确判断标准的步骤，全部交给工作流；凡是"需要结合案例、描述、印象打综合分"的步骤，才交给Agent。

具体拆法是这样的：

• 工作流部分：简历解析 → 字段清洗 → 硬门槛过滤（学历、年限、必备技能关键词） → 差异化打分。这些步骤完全可校验，同样的输入产生同样的输出，HR可以直接看到每部分的得分依据。
• Agent部分：一个Agent节点只在两道硬门槛都通过之后被触发，负责阅读简历的教育经历、项目经历、亮点描述，输出一段"综合能力评语"和推荐指数。Agent在节点内部只接收当前候选人结构化后的文本摘要，而不是把几百份简历全塞给它。

这一版跑下来，硬筛选的准确率接近100%，Agent评语也保留了主观判断空间，HR甚至反馈说Agent写的评语比某些初级HR的总结还到位。更重要的是，线上出错时路径清晰：如果是硬性规则错了，去工作流节点改规则；如果是评语跑偏，调Agent提示词或换模型。两者互不干扰。

5. 三种常见的挂接方式，以及各自的翻车姿势

5.1 工作流为主，Agent当节点：最适合交付稳定业务

这是我最推荐的生产环境默认模式。整个业务的主体流程是确定的工作流，在某个具体环节需要"智能判断"时，插入一个Agent节点。

好处有两点：一是Agent被限制在一个局部任务里，上下文和工具列表可以做到极简；二是即便Agent在局部跑偏，工作流外层还可以做兜底校验，比如对Agent输出做格式检查、做重试、做人工审批等待。

典型例子：客服工单处理流程。工作流负责创建工单、分派到队列、时限提醒、闭环归档，中间插入Agent节点负责把用户原文整理成结构化描述。即使Agent摘要有遗漏，工单照样能进队列，不会阻断整个流程。

5.2 Agent为主，工作流当工具：适合开放性任务

反过来，如果业务本身就是非结构化的，连主路径都没有，那就该Agent主导，把工作流封装成一个"能力"供它随时调用。Coze里把工作流注册为Agent的工具，Dify里把独立工作流添加为Agent的工具，都是这个思路。

典型例子是创作类、研究类应用。比如用户说"帮我写一个产品发布会方案"，主路径完全看用户需求，Agent需要做的是拆成市场分析、内容策划、执行清单，每块都可能调用一个固定的工作流去拉数据、汇模板、算预算。这些工作流对Agent来说就是一个人完成了"由它决定何时调用的一组API"。

这种模式我最想提醒的一点是：Agent在决定调用哪个工作流时，也会消耗不少Token去读工具描述。工具清单超过10个，模型就会开始混淆，所以Agent主导时，工具数量一定精简，并给每个工作流取一个高度语义化的名称和描述，降低误调率。

5.3 事件驱动的并行编排：提升吞吐，也要防碰撞

第三种模式是用工作流的事件触发机制同时启动多个Agent，或者让多个工作流并行处理，解决"AI Agent怎么扛并发"的问题。

常规做法是：一个主工作流负责拆解大任务，然后并行发动多个子Agent，每个Agent负责一个小任务，最后聚合结果。这个模式非常吃性能设计：子Agent共享的数据必须提前拷贝，否则两个Agent同时写一份数据，会互相覆盖；子Agent的输出要设计好资源标识符，否则聚合阶段根本对不上号。

我踩过的坑是并行子Agent都用了同一个"输出变量名"，聚合节点拿到的是最后一个完成者的结果，前面几个任务的白做了。后来改成"每个子Agent绑定独立前缀的资源命名空间"才解决。

5.4 挂接方式不是越高级越好，关键是容错边界设在哪

说到底，以上三种模式的本质差别不在于谁的位置在前在后，而是你把容错边界设在了哪层。纯工作流方案里，容错靠节点重试；Agent当节点时，容错靠外层工作流拦截；工作流当工具时，容错只能靠Agent自己判断，很多团队都在这一层用了大量心力，需要写极复杂的系统提示词和工具描述来补偿模型的随机性。

所以做架构决策时别总问"能不能让Agent更聪明"，换个问法："如果这里必须出错，我能不能在出错后毫发无损地兜底？"能兜底，就用Agent；不能兜底，就退回工作流。

6. 给自己定一条分工判据：可校验还是不可校验

6.1 两条区分线：输出是否可校验、失败是否可容忍

我最后留下一个在团队里反复使用的判据，总共就两条：

第一条，这个步骤的输出能被另一个程序或规则校验吗？比如"提取发票金额并计算税额"，你写个脚本就能验证计算器对不对，这类必上工作流。比如"判断这份简历是不是潜力股"，没有硬规则能校验，只能靠AI给意见，那就上Agent。

第二条，如果这一步失败，业务还能继续吗？如果不能继续，风险有多大？如果失败会导致钱打错账号、数据被删除、法律风险，那必须工作流加人工确认，绝不能让Agent一个人决策。如果失败只是产出质量差一点、响应用户晚几秒，交给Agent无所谓。

这两条画出来，绝大多数场景的答案都是清晰的。我甚至把这两条印在了团队Wiki首页，新同事设计流程时先对照一下，再决定用哪种节点。

6.2 避坑清单：提示词、变量污染、重试设计

几个实操中反复出现的坑，值得单独列一下：

• 变量污染。并行节点或子工作流共享同一变量空间时，一定要用独立前缀或局部变量，否则结果互相覆盖，排查又极难。
• 提示词超长。工作流里的大模型节点提示词写太长会导致每轮调用都浪费Token，还容易把模型的注意力转移到无关内容上。我习惯先保证逻辑完备，再逐段删减，800字以内的提示词往往效果最好。
• 错误重试策略。工作流里的HTTP节点建议配置2到3次重试加指数退避，但Agent节点的重试要谨慎：模型同一个错误可能会反复犯，重试三次可能等于烧三次钱又错三次。更聪明的做法是重试前把上一次的错误信息注入提示词，让模型"看到教训"后再跑。
• 上下文漏传。很多人在Agent节点只配了System提示词，忘记把工作流的中间数据映射到Agent节点的上下文变量里，导致Agent在信息不足的情况下强行作答。这个在联调阶段经常耗掉一整天，建议设计节点输入时就把字段对应关系画出来再连线。

6.3 一个值得长期投入的小习惯：把Agent的每个决策都留痕

在使用智能体编排平台做生产项目时，我给自己的硬性要求是：所有Agent节点的输入、输出、工具调用记录、思考摘要全都落到日志存储。成本不高，但它的价值在于出了问题时，你能快速区分到底是"流程设计错误"还是"模型判断错误"，完全不影响工作流的运维节奏。

有时候客户在验收时一句"上次说的和这次说的不一样"，有了留痕，你就可以把两次Agent调用的完整上下文调出来，比较模型输入的差异点，多半会发现是外部数据变了，而不是模型发疯。这种归因能力，是Agent类应用上线后最值钱的东西之一。

智能体编排平台本身不会替你回答"用工作流还是Agent"这个问题，平台只提供零件，组装方案永远在你自己手上。我个人的经验是：先承认大多数业务八成是确定性流程，两成需要智能判断；把这两成做成Agent节点，用八成的工作流管住它、托住它、校验它。坚持这个比例一年多，我负责的项目既没爆过Token账单，也没出过不可控的生产事故，希望你也能摸索出属于自己的边界。