企业级智能体架构中工作流与智能体范式取舍教程

一、教程目标

本教程要解决的核心问题是：在企业级智能体架构中，应该如何在工作流驱动与智能体驱动之间做出合理选择，并如何在同一个系统内分层落地。

完成本教程后，读者可以：

1. 清晰区分“工作流外壳”与“智能体决策”两种不同机制；
2. 理解为什么许多工作流节点已经被大模型调用取代；
3. 掌握基于企业架构层级选择执行范式的判断方法；
4. 能够设计一套可验证、可维护、可回退的智能体执行链路；
5. 具备在开发环境与生产环境中分别落地和调整范式的通用思路。

本教程适合正在规划智能体应用的企业开发者、需要向技术管理层解释架构选型的负责人，以及希望把智能体从演示级推到生产级的技术团队。

二、适用场景

本教程适用于以下典型场景：

• 企业内部正在建设智能客服、智能运营、智能研发辅助、数据处理自动化等系统；
• 团队在“画流程图编排大模型调用”和“让智能体自主决策”之间反复摇摆；
• 某一版本的实现出现节点爆炸、流程难以维护、模型行为不可控等问题；
• 需要向非技术决策者解释为什么智能体系统不能完全用传统流程图画清楚。

如果业务本身是严格合规审批、权限路径固定、每一步都有明确责任人的场景，应优先采用传统流程管理范式，而不是强行引入自主智能体决策。

三、前置准备

在开始架构设计与实现前，建议先完成以下准备工作。

3.1 基础能力准备

• 了解大模型调用的一般流程，包括提示词构造、上下文管理、输出解析；
• 了解函数调用、工具调用或插件机制的基本概念；
• 了解工作流引擎中的节点、连线、条件分支、循环等基础元素；
• 了解企业现有系统中哪些环节已有确定性规则，哪些环节需要动态判断。

3.2 环境与权限准备

• 准备一套可访问大模型服务的开发环境；
• 准备一套可用于配置流程或编写编排代码的工程环境；
• 准备日志、追踪、监控等基础可观测能力；
• 为关键执行节点准备测试数据，覆盖正常路径与异常路径。

四、核心概念辨析

在进入实施步骤前，需要先厘清概念。

4.1 工作流驱动的本质

工作流驱动的核心是预先定义执行顺序和分支条件。它适合输入稳定、流程确定、输出可预判的业务环节。传统工作流的优势在于可解释性强、执行边界清晰、容易审计。

但在智能体场景中，很多工作流已经在发生变化。节点不再是固定接口调用，而是大量大模型调用节点。部分平台甚至在流程中加入智能体节点，让某一段流程由模型动态决定下一步。此时工作流视图更多承担的是可视化编排和解释说明的作用，而不是传统意义上的确定性流程控制。

4.2 智能体驱动的本质

智能体驱动的核心是由模型根据当前状态、历史上下文和可用工具决定下一步动作。它适合输入不稳定、目标复杂、路径需要动态探索的场景。智能体驱动的关键在于“决策权的转移”，即执行路径从人工预先定义变为模型动态生成。

4.3 关键判断维度

可以从以下维度判断当前环节更适合哪种驱动方式：

• 输入是否结构化；
• 目标是否固定；
• 路径是否可枚举；
• 输出是否需要严格审计；
• 失败后是否需要人工快速定位；
• 是否涉及资金、权限、合规等高风险操作；
• 上下文长度与模型判断能力是否足够可靠。

五、实施步骤

以下步骤按“分析—分层—配置—验证—优化”的顺序展开。

步骤一：对企业智能体系统进行层级划分

先不要直接争论用工作流还是智能体。应先将系统拆分为不同层级。

通常可以分为四层：

1. 交互层：接收用户输入、展示结果；
2. 编排层：决定调用哪些能力、按什么顺序执行；
3. 能力层：执行具体工具、接口、模型推理；
4. 治理层：权限、审计、成本、安全、监控。

层级划分完成后，再逐层判断适合的驱动方式。判断原则如下：

• 交互层通常不适合引入复杂自主决策，应保持清晰可预期；
• 编排层是工作流与智能体争议最集中的区域；
• 能力层应保持纯功能性，不承载业务判断；
• 治理层应保留确定性规则，不依赖模型裁量。

这样做的好处是可以把“哪个范式更好”的问题转换成“哪个层级需要多少决策自由度”，避免全局一刀切。

步骤二：识别确定性边界与动态边界

在编排层内部，继续识别两条边界。

确定性边界包括：

• 必须调用的接口；
• 必须满足的合规条件；
• 必须写入的字段；
• 必须执行的审计日志；
• 必须遵守的调用顺序限制。

动态边界包括：

• 根据用户输入判断走哪类处理；
• 根据工具返回内容决定是否重试；
• 根据中间结果选择下一步调用；
• 根据风险等级决定是否转人工。

实施建议是：凡是确定性边界内的逻辑，保留在显式工作流或配置规则中；凡是动态边界内的逻辑，交给智能体决策，但必须设置约束。

步骤三：设置智能体决策的约束条件

智能体驱动不等于完全放开。工程实现时必须加入约束。

常见的约束手段包括：

1. 工具白名单：智能体只能调用指定范围内的工具；
2. 步骤上限：限制单次任务的最大决策步数；
3. 输出模式约束：要求模型输出结构化决策结果；
4. 敏感操作阻断：涉及权限变更、支付、删除等操作时，必须走人工确认或独立校验；
5. 回退路径：智能体无法在规定步数内完成任务时，回退到预设的固定流程；
6. 可追踪性：每一步决策必须记录输入、输出、调用工具、消耗上下文。

这些约束可以用通用配置表达。以下是一个通用流程示意：

接收用户请求
  -> 命中确定性规则？
      -> 命中：进入固定处理链路
      -> 未命中：进入智能体决策区间
           -> 限制可用工具集合
           -> 限制最大决策次数
           -> 每次调用记录决策原因与工具返回值
           -> 命中敏感操作？-> 转人工确认
           -> 超时或超步数？-> 回退固定流程
  -> 返回结构化结果
  -> 写入审计日志

该示意图不依赖任何具体平台，可用于大多数企业级实现。

步骤四：开发环境验证

开发环境建议围绕以下维度进行验证。

4.1 流程覆盖测试

准备多组输入，覆盖以下情况：

• 高确定性输入；
• 模糊输入；
• 多轮任务输入；
• 工具调用失败输入；
• 需要转人工的输入；
• 需要回退固定流程的输入。

验证目标不是“模型聪明与否”，而是系统在约束下是否可预期。

4.2 决策可解释性验证

对于智能体做出的关键决策，需要记录：

• 当前输入；
• 可用工具；
• 模型选择；
• 工具返回；
• 下一步动作。

这样验证时可以回答：“为什么走到这一步”“能否复现”“能否审计”。

4.3 成本与延迟验证

记录每次任务的大模型调用次数、单次耗时、总耗时。通过调整约束条件观察成本与延迟变化。例如：

• 步骤上限从5改为8，任务成功率可能提高，但成本增加；
• 工具描述过长会增加上下文消耗，但能提升调用准确率；
• 输出结构过于复杂会增加解析失败概率。

这些都需要在开发环境用真实业务数据反复测试。

步骤五：生产环境灰度与监控

生产环境不建议一次性全局切换。建议采用“固定流程为主、智能体决策为辅”的灰度方式。

灰度策略可以按以下维度切分：

• 按用户群体切分；
• 按任务类型切分；
• 按风险等级切分；
• 按时间段切分。

灰度阶段重点监控：

• 智能体决策区间的进入率；
• 单任务平均大模型调用次数；
• 超时率与回退率；
• 敏感操作阻断率；
• 用户满意度或任务完成率；
• 因模型输出解析失败导致的重试次数。

一旦发现回退率持续升高，说明智能体在现有约束下难以胜任该任务，应将对应任务重新固化到显式流程中。

六、典型配置说明

以下是一个通用配置思路，供工程落地时参考。

6.1 任务分类配置

task_routing:
  rules:
    - match: "input_type == 'account_closure'"
      route: "fixed_workflow"
    - match: "risk_level == 'high'"
      route: "manual_review"
    - match: "intent not in known_intents"
      route: "agentic_zone"
  default: "agentic_zone"

上述配置的含义是：账号关闭类任务走固定工作流；高风险任务走人工复核；未知意图进入智能体决策区间。

6.2 智能体约束配置

agentic_zone:
  max_steps: 6
  allowed_tools:
    - "query_order"
    - "query_invoice"
    - "query_policy"
  sensitive_tools:
    - "cancel_order"
    - "refund"
  sensitive_policy: "manual_confirm"
  fallback_workflow: "default_agent_fallback"
  output_schema:
    - step
    - tool
    - reason
    - result_summary

该配置限制了智能体最多执行6步，只能调用查询类工具。取消订单和退款属于敏感工具，必须转人工确认。超出限制时回退到预定义流程。

6.3 配置风险说明

配置过紧会导致智能体无法完成任务，频繁回退；配置过松会导致成本上升、行为不可控。建议在配置初期先收紧，观察任务完成率与回退率后逐步放宽。敏感工具不应直接交给模型决策，至少应保留二次确认机制。

七、结果验证

完成配置后，需要从多个角度验证系统结果。

7.1 成功标准

• 固定流程任务按预定义路径执行；
• 动态任务能在约束范围内完成决策；
• 敏感操作均经过人工确认；
• 超时或超步数任务能回退；
• 关键决策均可追踪和复现；
• 审计日志完整覆盖调用链。

7.2 验证方法

1. 回放验证：用历史数据回放任务，观察路径是否符合预期；
2. 边界验证：构造极端输入，观察是否触发回退或转人工；
3. 约束验证：尝试让智能体调用白名单外工具，确认被阻断；
4. 成本验证：对比固定流程与智能体决策的成本差异，判断是否在预算内；
5. 恢复验证：在关键节点注入故障，确认系统可恢复并记录原因。

八、常见问题与排查

问题一：工作流节点越来越多，维护困难

原因：把本应由模型动态判断的逻辑硬编码到流程图里，导致节点数量随场景增长。

排查与处理：

• 统计节点中纯模型调用节点占比；
• 识别节点间是否存在大量条件分支；
• 对于输入高度不确定且条件组合多的部分，迁移到智能体决策区间；
• 保留必要的确定性节点和审计节点。

问题二：智能体决策不稳定，时好时坏

原因：输入跨度大、上下文不足、工具返回质量差、约束过松。

排查与处理：

• 缩小智能体决策区间的任务范围；
• 提高工具描述清晰度；
• 增加中间结果摘要要求；
• 减少每一步需要判断的选项数量；
• 增加步骤上限、回退条件。

问题三：成本突然上升

原因：智能体决策步数过多、模型调用频繁、上下文过长。

排查与处理：

• 观察单任务平均步数变化；
• 检查是否存在大量重试；
• 为智能体设置更短的回退路径；
• 对高确定性输入优先走固定流程，减少不必要的智能体调用；
• 从审计日志中统计工具调用失败后的重复调用次数。

问题四：业务方要求可视化流程图，但系统已大量使用智能体

原因：业务方对不可见图的决策过程存在信任疑虑。

排查与处理：

• 在流程图中保留业务层级节点，将内部动态决策表示为受约束的智能体区间；
• 用决策记录生成事后可视化路径；
• 向业务方展示关键约束和人工确认点；
• 用固定流程承担高风险环节，用智能体承担低风险、高不确定环节。

九、优化建议

9.1 性能优化

尽量将稳定能力下沉为可复用工具，避免每个任务都重新构造大量上下文。对高频查询类工具建立缓存，减少重复调用。为模型输出设置可容错的轻量解析方式，避免复杂结构导致高频重试。

9.2 安全合规优化

高风险操作不要进入模型直接决策链路。建议所有敏感工具都走统一确认机制。对智能体每一步的工具调用保留完整记录，确保事后可审计。对用户输入的敏感信息做脱敏后再进入模型上下文。

9.3 可维护性优化

将通用约束抽成独立配置，不要在代码或流程节点中散落。对固定流程、智能体约束、回退路径分别管理。定期抽检决策记录，把不稳定场景逐步固化或单独治理。

9.4 成本控制优化

对可明确枚举的任务直接走固定流程，减少模型决策环节。对智能体区间设置较短的步骤上限。定期统计不同业务类型的单价和总消耗，找出成本异常点。

十、总结

企业级智能体架构的关键，不是在工作流和智能体之间二选一，而是根据系统层级和任务特征分配不同程度的决策自由。

工作流适合确定性边界、高风险环节和需要审计的路径；智能体适合输入多变、目标开放、需要动态探索的环节。务实做法是把工作流逐步拆解为“固定控制 + 受约束智能体 + 回退机制”。流程视图可以作为表达与治理工具保留，但不应成为唯一执行范式。

落地时，团队应先在开发环境验证约束有效性，再在生产环境按用户、任务或风险维度灰度。通过持续监控任务完成率、回退率、成本与敏感操作拦截情况，逐步调整智能体区间范围。这样可以把架构讨论从“哪个范式更好”转变为“哪个环节该给多少决策自由度”，更有利于企业级系统稳定演进。