企业官网建设流程全解析

这是一个在项目启动会上经常被问到的问题：我们要做 AI，是用 Workflow 还是 Agent？

不过这里先要澄清一个概念：Workflow 是执行模式，工作台是产品形态。本文讨论的不是界面长什么样，而是数字员工背后的执行方式是否以 Agent 为中心。换句话说，真正需要比较的是预编排的 Workflow，和以 Agent 为核心的动态执行环境。

问题本身没有问题，但回答这个问题需要先放弃一个隐含的假设，两者之间存在优劣之分，选对了就比选错了好。实际上两者解决的是不同结构的问题，用错了场景，再好的技术也会表现糟糕。

把选型框架搭清楚，比记住结论更有用。

两者的本质差异

AI Workflow 的核心特征是预编排。开发者在设计阶段把任务的执行路径写清楚：先做 A，再做 B，根据 B 的结果走 C1 或 C2，最后汇总输出。LLM 在这个流程里是一个特殊的处理节点，它的输入由上游节点提供，输出交给下游节点处理。整个流程的主控制权在预先写好的逻辑里，不在 LLM 手里。

AI Agent 的核心特征是动态推理。任务接收之后，Agent 可以根据上下文决定执行步骤、调用顺序、中间结果的处理方式。开发者提供的不只是界面，而是环境和约束——本体、工具、记忆机制、权限边界、校验规则、人工确认点，Agent 在这个环境里运行。控制权更多地交给 Agent，但不是完全放任，开发者仍然需要定义目标、边界和兜底机制。

这个差异决定了两者各自擅长什么。

六个维度的选型框架

为此，我们列出了六个判断维度，每个维度有明确的倾向判断。把它们展开来说。

1、任务结构：任务的执行步骤是否可以在设计阶段确定？

举例来讲。

规章制度问答的步骤是固定的，接收问题、检索文档、生成回答。不管用户问什么，流程都是这三步。这类任务适合 Workflow。

采购补货方案的步骤取决于用户的具体要求，要不要排除某些品类、要不要结合历史数据做趋势分析、输出格式是 Excel 还是直接在页面展示。不同的要求会走完全不同的执行路径，没有办法在设计阶段把所有路径都写出来。这类任务适合 Agent。

判断标准可以先抓主线，如果主要执行路径能在设计阶段定义清楚，而且例外分支也有限，优先用 Workflow；如果任务在运行时经常需要补充信息、改写计划、临时选工具，优先用 Agent。

2、交互模式：任务需要几轮对话才能完成？

Workflow 适合单轮或少轮触发。用户提交一个问题，系统返回一个答案，交互结束。即便有多轮，每轮的交互内容也是预先定义好的。

Agent 适合需要多轮确认或动态补充信息的场景。Agent 在执行过程中可能发现需要追问用户，用户的回答会改变后续的执行方向。这种交互无法预先脚本化，需要 Agent 在运行时动态判断。

3、业务价值：这个任务产生的业务价值是高是低？

这个维度主要影响的是愿意为推理成本支付多少。Agent 通常需要更多轮模型调用、更长上下文和更多工具交互，成本与延迟往往高于固定流程。如果任务的业务价值很高，比如 AI 辅助生产异常根因分析，单次推理节省的人工成本远超推理费用，工作台的成本结构就是合理的。如果任务业务价值不高，比如自动生成周报摘要，用 Workflow 固定流程生成已经够用，不需要为动态推理支付额外成本。

4、容错要求：这个任务能不能接受错误，如果有错误能不能被发现和纠正？

容错要求高的场景，不适合让 Agent 无约束地闭环执行。生产线上的质检结果直接影响产品放行，结果出错的代价极高，而且错误可能在很晚才被发现。这类场景需要每一步的结果都可以被验证，Workflow 的固定流程更容易插入验证节点。即便使用 Agent，也通常只适合放在分析、建议、解释这些辅助手环节，而不适合直接做最终放行。

Agent 适合"可以试错"的场景通常有人类兜底。AI 生成的补货方案，采购主管审核之后才会执行，错误在人工审核阶段被拦截，代价可接受。AI Coding 生成的代码，开发者跑测试并做 Review 之后再合并，很多错误能在这个阶段被发现，代价也相对可接受。

5、执行闭环：任务执行主要靠 Agent 在运行时闭环，还是靠多个确定性组件协同完成？

规章制度问答里，文档检索依赖 Embedding 模型和向量数据库，召回、过滤、权限控制、答案生成往往由多个组件协同完成。这里的重点不是 LLM 能不能"独立完成"，而是整个闭环天然更适合被拆成若干可验证节点，用 Workflow 把各组件编排起来是自然的选择。

AI Coding 里，从理解需求到生成代码到解释设计，再到调用测试、读取日志、继续修复，往往需要 Agent 在运行时反复规划和调整。执行闭环更多由 Agent 主导，所以，Agent 是更合理的容器。

6、工具依赖：任务执行需要的工具集是固定的，还是动态变化的？

Workflow 的工具集在设计阶段就确定了，流程里的每个节点知道自己要用什么工具。如果任务需要的工具是固定的几个，Workflow 对工具的管理更精确。

Agent 则会根据任务动态选择工具。一个查询任务可能用 TableBinding，一个创建任务可能用服务端命令，一个分析任务可能同时用多个工具然后汇总。工具集是开放的，调用顺序由 Agent 在运行时决定。

决策原则

六个维度不需要全部指向同一侧才能做决策，但也不适合简单按票数相加。更稳妥的原则是分层判断。先看容错要求和任务结构，再看交互模式、工具依赖和执行闭环，最后看业务价值与成本。

容错要求是第一主裁维度，因为它影响的是风险，而不只是效率。一个任务对错误零容忍，即便其他维度都指向 Agent，也应该优先考虑 Workflow，或者采用"Agent 负责分析，Workflow 或人工负责最终执行"的混合架构。

任务结构是第二主裁维度，因为它最直接地影响实现的可行性。步骤不确定的任务强行用 Workflow 实现，意味着要把大量可能路径都写出来，代码复杂度会迅速上升，维护成本极高，而且仍然无法覆盖所有边界情况。

三个案例的实际判断

AI Coding。

• 任务结构不确定：需求理解、方案设计、代码生成、测试修复，每一步依赖上一步的结果动态调整
• 交互多轮：需要开发者审查代码、确认设计方向
• 业务价值高：替代或加速工程师的核心工作
• 容错要求可接受：代码可以通过运行测试验证，错误通过多轮 Review 发现
• 执行闭环偏向 Agent：需要在运行时读代码、调工具、看日志、改计划
• 工具依赖具有动态性：不同任务会调用不同的仓库、命令和环境能力

多数关键维度都指向 Agent，结论清晰。

规章制度问答。

• 任务结构确定：接收问题、检索文档、生成回答，步骤固定
• 交互单轮为主：用户提问，系统返回答案
• 业务价值中低：辅助查询，不是核心业务流程。
• 容错要求较高：答案偏差会影响员工对规章的理解
• 执行闭环偏向确定性编排：检索、过滤、权限控制、生成各自职责清晰
• 工具依赖相对固定：主要就是文档库、检索和生成链路

多数维度指向 Workflow，结论清晰。

生产质检异常处理。

这是最复杂的一个案例，因为它在不同维度上指向不同侧。

合格/不合格的一次判定，步骤固定，容错要求极高，适合 Workflow。异常根因分析，步骤不确定（设备问题？原料问题？工艺漂移？），需要结合历史工单、设备日志、原料批次动态推理，适合 Agent。

这两个子任务在同一个业务场景里，但性质完全不同。混合架构是这里的自然答案：Workflow 负责实时判定，输出合格或不合格；触发异常后启动 Agent 的子流程做根因分析，人工最终确认。两条链路职责清晰，互不干扰。

这个案例说明了一件事：选型的边界不在系统层面，而在任务层面。同一个系统里可以同时运行 Workflow 和 Agent，分别处理它们各自擅长的部分。没有必要为了技术一致性而把所有任务都强行纳入同一种范式。

一个容易犯的错误

在实际项目里，有一个偏差方向值得单独提出来：过度依赖 Agent。

众所周知，Agent 在演示时效果通常比 Workflow 更惊艳，因为它能处理用户随口说出的复杂任务，而 Workflow 的演示更像在展示一个固定功能。这让很多团队产生了"Agent 更先进"的印象，倾向于把所有任务都放进 Agent。

代价在生产环境里才会显现，推理成本和响应时延高于预期，某些关键任务的准确率与稳定性波动更大，Workflow 本来可以提供的一致性，在 Agent 里变成了需要额外治理的问题。

Agent 的动态推理能力是为不确定性设计的。把结构确定的任务放进 Agent，不是在利用这个能力，而是在为用不上的能力付出成本。Workflow 处理确定性任务的成本更低、结果更稳定，这不是局限，是它在这类场景下的优势。

本文是"企业AI落地"系列的第17篇。下一篇用生产质检这个混合案例做更细致的拆解：一个场景怎么被拆分成两条链路，两条链路怎么协作，知识库应该放在哪一层。