企业官网建设流程全解析

混合模式不是各打五十大板：把 Agent 节点嵌进 Workflow 时，“边界怎么画”才是选型的真问题

聊到 "Workflow vs Agent"，最常见的结论是一句选择题：步骤确定就 Workflow，不确定就 Agent。这个判断本身没错，但对真正要落地系统的团队来说，它只回答了三分之一的问题。企业里更常见的处境是：流程大部分是固定的，只有一两个环节说不清——这时候既不该把整条流程交给 Agent 自由发挥，也不必为了一个不确定的步骤把整个系统变成“硬编码 + 碰运气”。混合模式（Agentic Workflow）就是为这种处境准备的，而它真正难的地方不在“选不选”，而在“Agent 节点的边界往哪儿画”。

一、为什么“三选一”是个误导性的框架

博客园上《面试官：Workflow 和 Agent 有什么区别？如何选型?》一文给出了一个清晰的两问判断框架：先评估步骤的确定性——“这个任务的每一个步骤，我能否在设计阶段全部列出来”；再评估管控的必要性——如果步骤不确定，业务上是否允许模型自由发挥，有没有合规或风控要求。

文中对三种答案的划分也很明确：

• 能列全步骤：优先 Workflow，LLM 通常仅限于特定节点（如文本摘要或意图分类），只负责执行，不参与流程走向的决策；
• 列不全：优先 Agent，让模型通过 ReAct 循环自主规划路径，“不要试图把未知的步骤强行塞进固定的流程图里”；
• 部分确定：主流程固定，但核心环节灵活——考虑混合模式，把 Agent 作为一个节点嵌入到 Workflow 中。

注意第三条的措辞：“部分确定”。这恰恰是企业场景的常态。客服系统里退换货主流程是写死的，但用户那句“我收到货坏了，但我想要优惠券而不是退款”就是预设流程处理不了的缝隙。混合模式的的价值就在这里：不是在 Workflow 和 Agent 之间二选一，而是让两者各管一段。

二、混合模式的官方定位：窄且可观测

Dify 官方博客《AI Agent or Workflow? How to Choose the Right Approach》对混合模式的定位说得很精确。它把混合模式描述为：The workflow sets boundaries; an agent becomes a part of the workflow and handles a specific variable step——Workflow 划定边界，Agent 作为工作流的一部分，只处理某一个特定的可变步骤。适用情形是“流程大部分可预测，仅有一部分需要灵活的工具选择”。

更重要的是这句原则：Keep the agent's role narrow and observable——让 Agent 的角色保持窄且可观测。

这句话值得拆开看。“窄”意味着不要给 Agent 一个宽泛的目标（比如“处理好这个客户投诉”），而是给它一个定义清晰的子任务（比如“从用户描述中确定诉求类型并选择对应处理工具”）。“可观测”意味着 Agent 节点不是黑箱，它的输入、工具调用、输出都要能被上游检查和记录。

Dify 官方博客还给出了一个具体的嵌入模式：当 SOP 大体固定但某一步需要更灵活处理时，在 Workflow 中加入 agent 节点——workflow 负责运行周边的步骤，并定义如何检查、审核或路由 agent 的结果（defines how to check, review, or route the agent's result）。这句话其实就是边界设计的技术骨架：Agent 前面有入口约定，后面有校验和出口路由。

这也和 Dify 官网对 Workflow Studio 的产品描述一致：用 Workflow 和 Chatflow 定义 AI 应用如何“思考、检索、分支、调用工具、获取输入并返回结果”，逻辑一目了然，“可测试、可调试、可跨团队交接交付”；同时 agent 既可以独立使用，“也可以作为 agent 节点加入工作流”。可见“Agent 作为节点”不是权宜之计，而是被平台明确支持的一等公民形态。

三、边界怎么画：一张可交接的设计清单

落到工程实践，给 Agent 节点画边界可以拆成四个具体问题：

1. 哪些步骤留在确定性轨道里？

判断标准沿用前面说的确定性原则：凡是能事前列全的步骤——参数校验、数据查询、格式转换、通知发送、审批流转——都应该留在 Workflow 的普通节点里。文中对 Workflow 的优点总结是稳定性强、可审计、成本可控，这些好处只有当确定性步骤真的留在 Workflow 里时才能兑现。一个常见的反模式是“为了灵活”把整个流程塞给 Agent，结果是本来三行代码能搞定的数据同步也要经过模型决策，成本浮动、行为不可复现。

2. Agent 只接哪一段变量步骤？

变量步骤应当是单一、目标明确、输入输出可定义的一段。理想情况下，Agent 节点的输入是结构化变量（上游节点提取好的用户意图、上下文、可用工具列表），输出是约定好格式的结果。Dify 官方博客强调混合模式适用于“只有一个部分需要灵活工具选择”的场景——如果你发现需要给 Agent 塞三个以上的可变步骤，要么说明流程确定性评估出了问题，要么应该拆成多个窄的 Agent 节点，而不是一个全能 Agent。

3. 上游如何校验 Agent 的结果？

Agent 的输出在进入下游之前必须过一道检查。这一步在 Workflow 里天然好做：加一个条件分支节点，按 schema 校验输出，不合格就走重试或降级路径。这正是官方博客说的 "check" 环节。校验规则在设计阶段就要定义好，不能指望“模型大概会输出对的格式”。

4. 结果如何被审核与路由？

对于有风控要求的业务，Agent 节点产出的结论（比如给用户的补偿方案）可以设计成“建议 + 人工确认”再进入执行节点，这就是官方描述中的 "review" 和 "route"。Agent 建议怎么做，Workflow 决定是否照做、走哪条分支。决策权留在确定性轨道里，灵活性只用于生成建议。

四、适用范围与局限

混合模式适合的场景特征很明确：主流程有清晰 SOP、审计要求高，但存在一两个无法事先穷举的环节——客服分流中难以归类的诉求、数据管道中格式异常的脏数据处理、审批流中需要综合判断的个案。

它的局限也要说清楚。首先，边界画错了会两头不讨好：Agent 管得太宽，Workflow 的可审计性形同虚设；管得太窄，又浪费了模型的能力。其次，混合模式并没有消除 Agent 固有的问题——博客园那篇文章指出 Agent 类系统的执行过程不如 Workflow 直观透明，调试困难，错误不容易复现——嵌入节点只是缩小了这个风险的作用范围。最后，混合模式增加了一层设计成本：你需要维护 Agent 节点的输入输出契约、校验规则和降级路径，这部分工作量在小规模场景下可能不划算。

五、小结

"Workflow 还是 Agent" 是个入门问题，“Agent 节点的边界画在哪” 才是工程问题。前者靠两句判断题就能回答，后者需要一张写清楚“确定性步骤清单、Agent 职责范围、校验规则、路由策略”的设计文档，才能谈得上可交接、可维护。混合模式的要点不是折中，而是分工：让确定性的归 Workflow，让可变的归 Agent，并且始终记得那条原则——让 Agent 的角色保持窄且可观测。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

• 面试官：Workflow 和 Agent 有什么区别？如何选型? - 一枫说码 - 博客园
• AI Agent or Workflow? How to Choose the Right Approach - Dify
• Dify - 构建生产级 AI 应用