#为什么 Workflow 往往比 Agent 更适合生产环境

Agent 很吸引人，因为它承诺“给一个目标，系统自己完成”。这听起来像是 AI 应用的最终形态。

但在生产环境里，很多团队最后发现：真正稳定交付的不是完全自主的 Agent，而是设计良好的 Workflow。

这不是因为 Agent 没价值，而是因为生产系统关心的不是“看起来聪明”，而是可预测、可审计、可恢复、可控成本、可解释责任边界。对于大多数业务流程，Workflow 更容易满足这些要求。

#先区分两个概念

Workflow 是预先定义好的多步流程。工程师明确设计步骤、顺序、分支、审批点、重试策略和失败处理。模型可以参与某些步骤，比如分类、抽取、摘要、生成、判断，但流程控制权主要在应用层。

Agent 是更自主的多步执行系统。它会根据目标观察环境、规划下一步、选择工具、读取结果，并决定是否继续。

二者不是绝对对立。现实系统经常是“Workflow 包 Agent”或“Workflow 某一步调用小 Agent”。区别在于：谁掌握流程控制权。

一个简单判断是：如果你已经知道完成任务需要哪些步骤，就优先用 Workflow。如果你不知道路径，需要系统探索环境，才考虑 Agent。

#Workflow 为什么更适合生产

#生产系统需要确定性骨架

LLM 的输出天然有不确定性。生产系统无法完全消除这种不确定性，但可以把它限制在局部。

Workflow 的优势是：流程骨架确定，模型只在特定节点处理特定任务。

例如一个客服工单自动处理流程：

1. 接收用户反馈。
2. 识别问题类型。
3. 提取订单号和关键字段。
4. 查询订单状态。
5. 生成回复草稿。
6. 高风险场景转人工。
7. 保存处理记录。

这里模型可以做分类、抽取和草稿生成，但它不应该自由决定是否查询订单、是否退款、是否通知用户。流程控制权应该由业务系统掌握。

Agent 也能做这件事，但它会把“步骤选择”也交给模型。这在 Demo 里很酷，在生产里会增加调试和验证成本。

#Workflow 更容易做权限边界

业务系统里的权限通常不是一句 Prompt 能解决的。

谁能查订单？谁能导出数据？谁能发邮件？什么金额需要审批？哪些客户信息不能进入模型？这些都应该由应用层和权限系统决定。

Workflow 可以在每一步明确权限：

Agent 如果拥有一组强工具，就必须在工具层重新实现同样严格的权限控制。否则模型一旦选错工具或生成错误参数，就可能造成真实影响。

#Workflow 更容易评估

Eval 最怕目标含糊、路径不稳定。

Workflow 的每个步骤都能单独评估：

• 分类是否正确。
• 抽取字段是否完整。
• 查询参数是否合法。
• 生成内容是否符合语气和事实。
• 分支是否走对。
• 失败时是否进入人工处理。

Agent 的评估更难，因为它不仅要评估最终答案，还要评估计划是否合理、工具是否选对、顺序是否正确、失败后是否恢复。对于许多业务场景，这个复杂度不值得。

这个评估结构很朴素，但非常适合持续集成。每次改 Prompt、模型或检索策略，都能看到哪个步骤退化。

#Workflow 更容易恢复

多步 AI 系统一定会失败。工具会超时，模型会输出不合法 JSON，检索会找不到资料，用户输入会缺字段。

Workflow 的恢复策略通常是确定的：

• 第三步失败，从第三步重试。
• 字段缺失，请用户补充。
• 工具超时，重试两次后转人工。
• 生成不符合 schema，要求模型修复或使用默认模板。
• 高风险判断不确定，进入审批。

Agent 的失败恢复更复杂。它可能不知道自己错在计划、工具、参数还是理解目标。你当然可以给 Agent 加 recover loop，但这会继续增加系统复杂度。

生产系统不怕失败，怕的是失败后不知道发生了什么，也不知道该从哪里恢复。

#Workflow 更容易控制成本和延迟

Agent 的成本和延迟通常更难预测。一次任务可能调用模型 3 次，也可能调用 20 次；可能搜索一次，也可能不断搜索；可能很快结束，也可能循环到上限。

Workflow 的成本结构更清楚：

如果你的产品需要稳定响应时间，Workflow 的工程收益非常明显。

#面向前端工程师的差异

前端做 Workflow 和 Agent，体验设计完全不同。

Workflow UI 更像一个有明确阶段的任务流。用户知道当前在哪一步，下一步是什么，哪些字段需要补充，哪些结果需要确认。

Agent UI 更像一个动态执行视图。系统可能临时增加步骤，工具调用顺序可能变化，用户需要看到 Agent 为什么这么做。

Workflow 常见 UI：

• Stepper。
• 审批面板。
• 表单补充。
• 生成草稿预览。
• 错误步骤重试。
• 审计日志。

Agent 常见 UI：

• 动态任务时间线。
• 工具调用流。
• 中间观察结果。
• 暂停和取消。
• 人工介入请求。
• 最终报告和证据链。

如果一个业务流程本来就适合 stepper，却硬做成聊天式 Agent，用户会很难判断系统是否靠谱。

#系统设计

一个生产优先的 AI Workflow 可以这样设计：

这里的关键是 Workflow Engine。它决定下一步，不是模型决定下一步。

AI Step Runner 只处理局部任务，并输出结构化结果。Tool Step Runner 只执行经过权限检查的工具。Guard 负责 schema 校验、策略检查和必要的自动评估。

一个步骤定义可以长这样：

type WorkflowStep = {
  id: string;
  type: 'ai_extract' | 'ai_generate' | 'tool_call' | 'approval' | 'branch';
  inputKeys: string[];
  outputKey: string;
  retryPolicy: {
    maxAttempts: number;
    backoffMs: number;
  };
  timeoutMs: number;
  onError: 'retry' | 'ask_user' | 'fallback' | 'manual_review' | 'fail';
};

这种结构没有 Agent 那么迷人，但它能让系统进入生产。

#什么时候应该用 Agent

Workflow 优先，不等于永远不用 Agent。

Agent 适合这些场景：

• 目标明确，但完成路径未知。
• 环境信息需要探索，例如网页、代码库、文档库。
• 任务需要根据中间结果动态调整。
• 工具多且组合方式不固定。
• 结果允许一定延迟，用户能接受执行过程。
• 系统有足够的观察、限制、恢复和审计能力。

例如 Research Agent、代码库理解 Agent、浏览器操作 Agent、数据分析探索 Agent，都更接近 Agent 的适用区间。

但即使使用 Agent，也建议把它放进 Workflow 的边界里：

换句话说，Agent 可以负责探索，Workflow 负责边界。

#可靠性边界

选择 Workflow 还是 Agent，本质是在选择可靠性边界。

Workflow 的可靠性边界更窄：你知道每一步的输入、输出、失败模式和责任归属。模型出错时，通常能定位到某个步骤。

Agent 的可靠性边界更宽：模型可能在计划、工具选择、参数生成、结果解释、停止判断上任何一处出错。系统需要更多 guardrail 才能达到同等可信度。

一个实用分级是：

当你不确定该选哪个时，先问三个问题：

1. 我们是否知道完成任务的稳定步骤？
2. 出错后是否需要明确追责和恢复？
3. 工具是否会产生真实业务影响？

只要其中两个答案是“是”，Workflow 往往更合适。

#常见坑

#为了显得智能而使用 Agent

很多产品把固定流程包装成 Agent，结果用户只看到系统在“思考”，却不知道进度和边界。

如果流程本来确定，就应该清楚展示步骤。透明通常比拟人化更能建立信任。

#把 Workflow 写死成不可演进的脚本

Workflow 不是一堆临时代码。好的 Workflow 应该有步骤定义、状态持久化、版本管理、日志和评估。

否则它会变成另一个难以维护的业务脚本，只是中间调用了模型。

#在 Workflow 里让模型决定关键分支

模型可以提供建议，但关键分支最好由规则、权限和明确阈值控制。

例如模型可以判断“用户意图可能是退款”，但是否进入退款流程应该结合订单状态、用户权限、金额、风控规则和人工确认。

#忽略前端可解释性

生产 AI 流程需要让用户看懂。尤其是长任务，前端不能只显示“AI 正在处理中”。

你应该展示当前步骤、已完成步骤、失败原因、预计下一步、可编辑输入和确认按钮。

#过早追求全自主

全自主 Agent 的边界最难控制。很多系统更好的演进路径是：

1. 固定 Workflow。
2. 某些步骤引入 AI。
3. 增加可观察执行日志。
4. 在低风险子任务里引入受限 Agent。
5. 逐步扩大 Agent 自主范围。

这条路径慢一点，但更容易让团队和用户建立信任。

#小结

Workflow 往往比 Agent 更适合生产环境，因为它更确定、更容易评估、更容易恢复、更容易控制权限、成本和延迟。

Agent 的价值在开放探索和动态决策，但它不应该成为所有 AI 功能的默认形态。更稳妥的工程策略是：用 Workflow 承载业务边界，用 AI 增强局部步骤，在确实需要探索时引入受限 Agent。

当路径明确、风险较高、需要审计和恢复时，优先选择 Workflow。当前端能够把每一步状态清楚展示出来，用户会比面对一个黑盒 Agent 更安心。