万字长文：从 Workflow 到 Multi-Agent，企业级 AI 架构到底怎么选？（附决策树）

Agent 架构设计的核心命题，从来不是“要不要用 Agent”，而是“到底把多少控制权交给 Agent”。

企业 AI 领域的关注点正在发生显著转移。从早期的模型选型、RAG 应用和 Prompt 工程，转向了更深层的架构设计：多 Agent 拆分、Planner 与 Router 的设计、Agent 间协作机制以及 Workflow 的必要性。

常见的架构图往往描绘了一个总控 Agent 下辖多个子 Agent，各自挂载工具并连接 MCP。然而在实际落地中，许多团队面临“Agent 越多，系统越不稳定”的困境。简单的任务被拆解为路由、规划、执行、评估、汇总等八个节点，导致 Token 消耗激增、响应延迟高企，且故障定位困难。

本文将围绕这一核心问题，探讨不同设计模式下的控制权分配演进。

本文看点

以典型的企业流程为例：

若流程中每一步都是确定的（输入、系统调用、异常处理均可预定义），让 Agent 每步自行决策“下一步做什么”纯属冗余。此时应直接使用代码串联流程，即 Workflow 模式。模型仅在需理解自由文本或生成审批意见等环节介入，其余由代码管控。

现实中常见误区是“先定目标做 Agent，再凑功能”。正确顺序应为：分析业务任务形态 -> 决定控制模式 -> 判断是否需要 Agent。

区分标准如下：

Workflow 路径预先固定；Agent 则通过“观察状态-决策-调用工具-重新判断”的循环直至任务结束。本质变化在于掌控流程的主体从代码部分转移至模型。

控制权移交模型后，需解决路径错误、死循环、上下文溢出、权限越界及失败恢复等问题。因此，生产级 Agent 并非简单的 LLM + Tool，而是包含决策、状态、工具、编排、护栏和评估的综合运行时（Runtime）。

对于可拆分为固定步骤的任务，适用 Prompt Chaining。例如企业方案撰写：需求分析 → 方案设计 → 风险分析 → 最终报告。前一步输出作为后一步输入。

关键在于步骤间需设置“Gate”（关卡）进行校验。例如检查 JSON 格式完整性、字段合法性等。若校验失败，则重试或终止，防止错误累积放大。

建议：能确定的流程代码化，能写死的逻辑不让模型猜测，能用代码校验的不依赖模型自检。

用户提问往往不按预设路径，如“查订单”、“改等级”、“分析流失”虽均涉及客户，但执行路径迥异。此时需引入 Router 进行意图分流。

Router 仅负责判断请求路径，不执行具体任务。企业级路由通常分层收窄：意图 → 任务 → Agent → Skill → 工具。

以“分析客户 C001 流失原因”为例：

• 第一层：意图判断为客户分析。
• 第二层：具体任务为流失分析。
• 第三层：分发至客户分析 Agent。
• 第四层：调用流失分析 Skill。
• 第五层：查询 CRM、订单等系统数据。

Router 是企业 Agent 的关键基础设施，适用于任务类别明显且处理流程差异大的场景。

当子任务相互独立时，可采用并行处理以提升效率。例如代码审查可同时进行安全、性能、架构、规范四个维度的检查，最后汇总。

并行模式分为两类：

• Sectioning（切分）：将任务拆分为独立子任务并行执行。
• Voting（投票）：多个模型对同一问题给出结果，综合或投票决策。

优点在于缩短等待时间、获取多视角；代价是 Token 消耗增加、资源占用高及结果合并复杂。判断依据：子任务间无依赖即可并行。

传统生成流程缺乏质量判断。Evaluator-Optimizer 模式引入“生成-评估-优化”闭环：Generator 生成内容，Evaluator 依据明确标准打分，不合格则反馈修正。

此模式类似人类工作的“草稿-修改-评审”过程。关键在于 Evaluator 必须具备可衡量的明确标准，而非模糊指令。

• 代码评估：Correctness, Security, Performance, Architecture, Test Coverage
• 文档评估：Completeness, Accuracy, Compliance, Format, Business Rules, Risk

针对任务结构在运行时才能确定的复杂场景（如大型代码重构），固定 Workflow 难以应对。Orchestrator-Workers 模式中，Orchestrator 动态分析并拆解任务，分派给不同 Worker 执行，最后由 Aggregator 汇总。

与 Workflow 相比，此模式下任务结构由模型决定，控制权进一步向模型倾斜。

上述模式构成一条连续的演进路线：从固定流程到动态选路、并行、动态判断、动态拆解。每向下演进一格，系统让渡更多控制权给模型，同时也承担更多不确定性。

复杂任务可组合多种模式。典型骨架为：Planner 制定计划，Generator 执行，Evaluator 检查结果。三者职责分离，便于单独评估和优化。

• Planner：回答“应该做什么”。
• Generator：回答“具体怎么做”。
• Evaluator：回答“做得对不对”。

这体现了软件工程中的职责分离原则，避免单一大模型身兼数职导致故障难查。

盲目增加 Agent 数量会导致架构图复杂化，并引发四大问题：

1. Token 成本：上下文在节点间反复传递，有效输出占比低，中间过程消耗巨大。
2. 延迟：串行链路导致总延迟累加，用户体验如同等待长流水线。
3. 错误传播：上游 Planner 的错误会导致下游 Worker 连锁出错，且难以在源头纠正。
4. Debug 困难：多 Agent 交互使得故障定位需追踪调用链、上下文、决策逻辑及数据流向，复杂度指数级上升。

因此，Trace、State、Audit、Evaluation 等能力在生产环境中至关重要。

OpenAI 提出两种典型多 Agent 编排方向：

1. Manager / Agents as Tools
Manager 始终持有控制权，子 Agent 作为可调用的能力组件。

2. Handoff（交接）
Agent 间移交控制权。例如分诊 Agent 将账单问题移交给 Billing Agent，后者再根据需要移交给 Refund Agent。

两者核心区别在于下一步由谁决定。

建议通过以下决策树从上至下判断：

1. 一次模型调用能否解决？能则用单个 LLM/Agent。
2. 流程是否固定？是则用 Workflow 或 Prompt Chaining。
3. 不同任务是否需不同路径？是则加 Routing。
4. 子任务是否独立？是则考虑 Parallelization。
5. 输出是否需反复检查优化？是则用 Evaluator-Optimizer。
6. 任务结构是否仅运行时确定？是则用 Orchestrator-Workers。
7. 是否真的需要多个职责独立的 Agent？需要才上 Multi-Agent。

原则：哪一关答“是”即停在那里，优先使用简单方案。

企业需要的不是万能 Agent 或多 Agent 聊天，而是一套可控的执行系统。

系统分工如下：

• Agent：负责“想”（理解、拆解、判断、选择）。
• Workflow：负责“编排”（流程、状态、审批、回滚）。
• Skill：负责“复用”（沉淀业务能力与规范）。
• Tool / MCP：负责“调用”（API、数据库、外部服务）。
• Ontology：负责“理解业务”（显式表达对象及关系，如 Customer-Order-Product）。

• Action：负责“受控执行”。Agent 提出高层动作（如 ChangeLevel(VIP)），经权限、规则、数据校验及审批后，才通过接口落库。

企业环境充满权限、状态、规则、审批、SLA、依赖、异常、回滚和审计要求，这些正是纯模型不擅长且不应全权负责的部分。

稳定的企业 Agent 结构应包含外围的 Runtime (Harness)，提供状态、上下文、权限、重试、超时、审计、可观测性及评估能力，起到兜底和约束作用。

由此，Agent 从“会调用工具的聊天机器人”进化为企业任务执行系统。

• 能固定的流程，就别交给 Agent：Workflow 的确定性即是生产力。
• 需要选择时，再让模型参与 Routing：让模型决定路径，而非所有细节。
• 需要并行就并行，不需要就别硬凑：权衡提速与成本复杂度。
• 需要质量闭环，就加 Evaluator：实现 Generate-Evaluate-Improve 循环。
• 任务结构仅运行时确定，才考虑 Orchestrator：此时模型才真正参与编排。
• Multi-Agent 的关键不在数量，而在控制权：核心始终是“谁控制下一步”。

Agent 技术的核心价值在于如何将模型智能融入可控的执行系统。架构演进已从单纯的 Prompt-LLM 发展为包含 Router、Planner、Agent、Skill、MCP、Ontology、Action 及 Enterprise System 的完整链条，并辅以 State/Audit/Evaluation。

模型决定“能想多远”，而控制边界的设计决定 Agent 能否在企业长期稳定运行。

这一问题值得每个企业 Agent 团队在绘制架构图前深思。