从单 Agent 到企业级 Workflow：一文讲透 Agent 的 7 种主流架构

让 LLM 处理需要推理的部分，让工程系统处理需要确定性的部分——每一种 Agent 架构，本质都是在这两者之间重新划定边界。

当前 Agent 开发中，Single Agent、ReAct、Plan & Execute、Multi-Agent、Router、Skill、Workflow、Graph 等概念层出不穷，架构图也日益复杂。从最初的“用户 → LLM → 答案”，演变为包含 Router、Agent 集群、Tools、MCP、RAG、Memory 及后端业务系统（ERP/CRM/MES）的复杂链路。

架构越复杂是否越先进？答案是否定的。在客服问答等简单场景强行使用 Multi-Agent 往往适得其反；而在跨系统、带审批的复杂业务流程中完全依赖 LLM 自由发挥则风险巨大。

核心问题并非“什么架构最先进”，而是“面对具体业务，应赋予 Agent 多大的自由度，又需施加多少工程约束”。

下文将拆解主流的 7 种 Agent 架构，探讨其适用场景与选型逻辑。

本文看点

早期 AI 应用主要解决问答与总结类需求。随着企业引入 Agent，需求转变为“让 AI 执行任务”。例如：“分析客户采购量下降原因，制定跟进计划并创建销售任务”。这一过程涉及多系统数据查询、分析判断及任务创建，引发了以下核心问题：

• 谁决定下一步行动？
• 谁管理上下文和中间状态？
• 失败后谁负责重试？权限如何控制？
• 何时必须引入人工介入？

Agent 架构的设计，正是为了回答这些问题。

LLM 具备强大的推理能力，但具有天然的不确定性。在探索型任务中，这种自由是优势；但在生产系统中，如“退款超过 5000 元需人工审批”等业务规则必须是确定性的。

后续介绍的每种架构，均是在这两者之间寻找平衡点。

1. Single Agent（单一智能体）

结构最简单：用户 → Agent → LLM → Tool → 输出。

Single Agent 常被低估。对于“查询今日销售额”等简单任务，理解、调用、返回三步即可搞定，无需拆分为多个专用 Agent。简单即能力：调试容易、成本低、延迟低、权限与状态易管理。

适用场景：知识助手、FAQ、文档助手、编程 Copilot、简单查询、单工具调用。

当任务复杂度增加，下一步动作不再显而易见时，Single Agent 便显得力不从心。

2. ReAct（推理+行动）

ReAct（Reason + Act采用“想一步，做一步，看结果，再想下一步”的循环模式。

适用于步骤无法预先固定的任务。例如排查“订单未发货”原因，需依次查询订单状态、库存、补货计划，每一步依赖上一步结果。ReAct 擅长此类动态探索。

潜在问题：

• 工具调用过多：简单任务可能引发多次无效调用。
• 陷入循环：可能出现 A→B→A 的死循环。
• 难以测试：同一任务每次执行路径可能不同。
• 成本不可控：每一步均需消耗模型 Token。

3. Plan & Execute（规划+执行）

为解决 ReAct 的不可控性，该模式先将任务拆解为计划（Planner），再由执行器（Executor）逐步执行。

例如“分析客户采购下降”，可拆解为：查信息、查订单、分析趋势、查记录、归因、出策略、建任务。其优势在于结构清晰、易于监控和定位故障。

局限性：仅适用于适合提前规划的结构化任务。对于探索性任务，初始计划往往不准确。

ReAct 与 Plan & Execute 并非替代关系，前者适合动态探索，后者适合结构化任务。

随着任务类型和工具增多，核心问题从“怎么决策”转向“怎么组织”。

4. Multi-Agent（多智能体协作）

典型结构由一个 Orchestrator（编排器）调度多个具备独立 Prompt、工具和权限的 Agent。

Multi-Agent 解决的不仅是任务复杂度，更是专业分工。例如在 AI Coding 中，需求理解、架构分析、编码、测试、审查所需的知识差异巨大，拆分 Agent 可避免 Prompt 和工具列表膨胀失控。

代价：协作复杂度呈非线性增长。环节越多，错误传导风险越高，通信关系越难梳理。拆分的前提是存在真实的专业分工。

5. Router + Skill（路由+技能）

在企业 AI Coding 或内部平台中极具价值。

• Router：识别用户意图，将任务分发给对应的 Skill。
• Skill：工程师处理某类问题的标准做法固化。例如代码审查 Skill 包含读规范、查依赖、检安全、跑测试等固定步骤，而非依赖模型临场发挥。

企业任务高度“类型化”，与其拆分大量 Agent，不如做好分流并沉淀 Skill。Multi-Agent 关注“谁来做”，Router + Skill 关注“用哪套方法做”，两者可叠加使用。

6. Blackboard（黑板架构）

为解决 Multi-Agent 中的信息共享难题，Blackboard 建立了一个共享状态空间，存放任务目标、事实、中间产物等。Agent 围绕黑板读写，无需两两通信。

Research Agent 写入事实，Analysis Agent 读取分析，Writer Agent 生成报告。这解决了长任务、多角色场景下的状态同步问题，但也引入了并发写、一致性校验等新挑战。

7. Graph / Workflow（图/工作流）

生产环境要求确定、可追踪、可审计。例如处理“重复扣款退款”请求，不能仅靠 LLM 生成回复，而需遵循严格流程：

Graph/Workflow 将任务拆分为明确节点，定义输入输出、权限、校验及重试策略。Workflow 强调业务流程（审批、执行），Graph 强调状态迁移（分支、并行、循环）。企业通常结合两者，用 Graph描述状态，用 Workflow 承载业务。

落地时无需盲目追求 Multi-Agent，可依据以下逻辑选型：

企业级系统通常是多种架构的叠加。以 AI Coding 平台为例：

各组件处于不同层面：Router 管决策，Skill 管能力，Workflow 管流程。此外，企业还需一套 Harness（缰绳）层，涵盖权限、工具编排、记忆、错误恢复、人工审批、审计、可观测性及成本控制。

更深层的问题涉及企业语义层（Ontology），即 AI 如何理解“客户”、“订单”等概念及其关系，这是实现深度集成的基础。

当前 Agent 开发易走两个极端：一是堆砌工具导致路径不可控；二是过度拆分导致系统复杂化却未解决实际问题。

稳健演进路径：Single Agent → ReAct → Plan & Execute → Multi-Agent/Skill → Router → Blackboard → Workflow/Graph。

成熟的 Agent 设计，核心在于平衡智能与确定性。LLM 负责理解、推理、规划；工程系统负责权限、流程、校验、审计。通过 Router、Skill、Workflow 等组件连接两端，让 Agent 知道何时自主决策、何时调用工具、何时遵循流程、何时等待人工介入。

这是 Agent 从 Demo 走向企业级应用的关键分水岭。