04 · Agent System 有哪些类型？ - System Types
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：技术分类、架构比较与工程实践专题研究
版本：v1.0
更新日期：2026 年 10 月 28 日
核心问题：Agent System 应按哪些独立维度分类？单 Agent、多 Agent、工作流驱动、事件驱动、集中式与分布式系统有什么区别？如何根据任务的不确定性、协作依赖、外部副作用、运行时长、并发和安全要求选择系统类型，并通过工程证据验证选择？
专题导读
本篇属 Fundamentals。本篇承接 Definition & Boundaries、Core Components、Execution Mechanism，研究不同 Agent System 的分类维度、执行拓扑与适用条件。分类不是产品排行榜，也不是“多 Agent 比单 Agent 更高级”的成熟度排序。下一篇 Completeness & Maturity 讨论完整性与成熟度；L4 / L5 深入运行时和编排实现；Engineering & Governance 深入治理。
一、为什么需要多维分类，而不是单一类型清单？
“单 Agent 系统”“多 Agent 系统”“工作流系统”“事件驱动系统”“分布式系统”经常被并列介绍，但它们回答的是不同问题：有多少行为主体、谁决定下一步、什么触发执行、如何部署，以及谁控制协作。一个系统完全可能同时是多 Agent + 工作流驱动 + 事件触发 + 分布式部署。若把这些术语当作互斥类型，就会错误推断架构能力。
本篇采用五条主要分类轴：主体数量与职责组织、决策与编排方式、触发与执行时序、部署与状态拓扑、协作控制模式。再补充自主权与副作用风险两个横切维度。分类的目的不是贴标签，而是识别不同架构带来的复杂性：状态一致性、失败传播、任务拆分、工具授权、资源成本、可观测性与测试方式。
1.1 分类维度总览
| 分类轴 | 典型取值 | 决定的核心问题 | 不决定什么 |
|---|---|---|---|
| 行为主体 | 单 Agent；多 Agent | 决策职责由多少 Agent 承担 | 是否分布式、是否动态规划 |
| 决策与编排 | 预定义工作流；动态 Agent 循环；混合 | 谁选择下一步与执行路径 | 是否多 Agent |
| 触发与时序 | 请求响应；异步任务；事件驱动；定时/持续运行 | 任务何时开始、等待和恢复 | 决策主体数量 |
| 部署与状态 | 单进程；模块化服务；分布式 Worker | 资源、隔离、故障与状态如何分布 | Agent 的智能水平 |
| 协作控制 | 中心编排；层级委派；去中心化协商；共享工件 | 多主体如何分工与汇总 | 是否一定有效率优势 |
| 横切约束 | 只读/可写；自动/需审批；短任务/长任务 | 授权、持久化、恢复与审计需求 | 是否属于 Agent System |
判别规则： 描述一个具体系统时，应使用组合标签，例如“单 Agent、动态决策、异步任务、单进程、人工审批高风险操作”，而不是只称“自主 Agent 系统”。
二、第一分类轴：单 Agent 与多 Agent
2.1 单 Agent System
单 Agent System 中，核心目标导向决策由一个可识别的 Agent 承担。它仍可调用多个模型、工具、检索器、数据库和确定性子程序；调用多个模型不等于拥有多个 Agent。一个 Agent 可以在多个执行阶段切换角色提示词，但若缺乏独立的任务契约、决策责任与协作边界，也不应机械地把每个提示词称为独立 Agent。
典型拓扑：
flowchart LR
U[任务请求] --> T[Task / Run]
T --> R[Agent Runtime]
R <--> A[单一 Agent 决策主体]
R --> G[授权与执行控制]
G --> M[模型服务]
G --> X[工具 / 外部环境]
R <--> S[运行状态 / 事件]
R --> O[结果]优势： 决策责任集中、上下文与状态边界较清楚、交互开销低、调试与审计相对简单。局限： 当任务涉及大量异质专业能力、可并行子任务或相互独立的验证职责时，单一上下文可能变得庞大；但这些问题未必需要通过增加 Agent 解决，也可以使用确定性工具、分阶段处理、子任务队列或上下文压缩。
适用场景： 单人研究助理、限定范围的浏览器任务、单仓库代码修复、具备明确审批边界的业务助理。优先采用单 Agent 是一种合理的工程基线，而不是通用最优结论。
2.2 Multi-Agent System
多 Agent System 包含两个或更多具有可区分决策职责的 Agent，系统需要管理它们之间的任务委派、消息、共享工件或结果合并。多 Agent 不要求每个 Agent 独立进程，也不要求它们使用不同模型。核心判据是行为主体与责任边界，不是进程数或模型实例数。
flowchart TB
U[用户任务] --> C[协调 / 编排]
C --> A[检索 Agent]
C --> B[分析 Agent]
C --> D[审核 Agent]
A --> E[(共享证据工件)]
B --> E
D --> E
D --> C
C --> O[交付 / 返工]潜在收益： 职责隔离、独立审核、并行探索、专用上下文和工具权限。主要代价： 多次模型调用、消息与上下文传递、结果冲突、错误放大、共享状态一致性、归因困难和协作死循环。将一个任务拆成四个 Agent 并不自动提高准确率；如果子任务高度耦合、接口不清晰，反而可能降低可靠性。
最重要的设计问题： Agent 之间交换什么？交换自然语言消息、结构化任务、带证据的工件，还是共享可变状态？建议优先定义输入/输出契约、证据来源、失败处理、重试责任和最终裁决权，再决定 Agent 数量。
2.3 多 Agent 的必要性判定
可以依次检查：①是否存在可明确拆分且相对独立的目标；②拆分后是否能够限制各 Agent 的上下文或权限；③是否存在可验证的交付接口；④并行或专业分工的收益是否超过协作开销；⑤失败与冲突由谁裁决。若这些问题无法回答，先以单 Agent 或固定工作流建立基线。
三、第二分类轴：工作流驱动、动态决策与混合系统
3.1 Workflow-driven Agent System
工作流驱动系统以预定义步骤、条件分支或任务图组织执行。Agent 可以参与某些节点的决策，但整体流程主要由显式图结构和调度规则控制。
flowchart LR
A[接收任务] --> B[检索]
B --> C[证据检查]
C -->|充分| D[写作]
C -->|不足| B
D --> E[审核]
E -->|通过| F[交付]
E -->|退回| D这种系统不应被误认为“没有 Agent”。若其中某个节点依据目标与反馈自主选择行动，该节点可以包含 Agent 行为；如果全部节点都是固定程序调用，则整体更适合描述为工作流自动化，而非 Agent System。工作流引擎不是 Agent 存在的充分条件。
优点是路径可解释、验收和权限边界清楚、易于设置检查点；缺点是对未预料到的任务变化适应性有限，复杂条件分支可能膨胀。适用于审批流程、固定报告生产线、强合规任务和重复性批处理。
3.2 Dynamic Agent-driven System
动态决策系统允许 Agent 根据当前目标、上下文、执行结果和约束选择下一步操作。它的执行图可能在运行时形成，实际路径不完全由开发者预先枚举。
目标与当前状态 → 决策下一步 → 权限检查 → 执行动作
↑ │
└──────── 观察与状态更新 ────────┘
│
满足终止条件
▼
交付优势是面对开放式任务和环境变化时更灵活；代价是运行路径不确定、难以预估成本、验证空间较大、权限和停止条件要求更高。动态决策并不意味着无限自主；系统可以对可选工具、步骤数、预算、外部副作用和人工审批设置严格限制。
3.3 Hybrid System
混合系统将确定性编排与 Agent 决策组合。例如，系统预定义“检索 → 分析 → 审核 → 交付”的主要阶段，但允许检索 Agent 在阶段内动态选择搜索与阅读动作；审核失败则由确定性工作流路由回分析阶段。
这类架构常具有较好的工程可控性，但并非在所有场景下最优：如果任务极其简单，混合架构可能过度设计；如果任务路径高度开放，过于僵硬的外层流程也可能阻碍有效探索。
选型原则： 将能够明确表达和验证的业务规则固化在程序/工作流中，将确实需要不确定性判断的部分交给 Agent；同时保持系统级授权和终止控制独立于模型输出。
四、第三分类轴：请求响应、异步、事件驱动与持续运行
4.1 同步请求响应
调用方提交任务并等待结果。适合执行时间短、可在请求超时内完成、外部副作用少的任务。关键约束是端到端延迟、超时与客户端断连。HTTP 连接断开不应被直接视为任务已取消或外部操作已回滚。
4.2 异步任务系统
任务提交与任务执行解耦：submit → task_id → queued/running → result。适合长任务、并发任务或需要独立 Worker 的系统。必须定义任务 ID、状态查询、取消语义、重试、执行租约、幂等提交和结果保留期限。异步不等于分布式；单进程后台队列也可以异步。
4.3 事件驱动系统
外部消息、Webhook、文件变化、数据库事件或人工审批触发 Agent System 的运行或恢复。事件驱动重点是触发与控制流，不是 Agent 数量。需要处理重复事件、乱序、事件版本、重放、授权和来源真实性。事件至少一次投递的环境中，消费端必须考虑幂等与去重。
4.4 定时与持续运行系统
定时任务按照计划启动；持续运行系统可能周期性检查外部状态或长时间等待信号。需要处理跨重启的调度持久化、错过执行窗口、重复触发、预算上限、运行时长和安全终止。持续运行不等于模型必须持续推理；大多数等待期可以由调度器或事件系统承担。
| 执行形态 | 主要优势 | 主要风险 | 推荐关注 |
|---|---|---|---|
| 同步 | 接口简单、反馈直接 | 请求超时、客户端断连 | Deadline、取消语义 |
| 异步 | 长任务、并发、独立执行 | 重复执行、状态漂移 | Queue、Lease、Idempotency |
| 事件驱动 | 与环境变化解耦 | 重复/乱序/伪造事件 | Event ID、签名、重放 |
| 定时/持续 | 自动化与长期任务 | 失控成本、漏跑、重复触发 | Scheduler、预算、审计 |
五、第四分类轴：单进程、模块化服务与分布式系统
5.1 单进程或模块化单体
Agent Runtime、工具适配器、状态和任务入口可运行于同一进程。优点是部署和调试简单、数据交换成本低；缺点是进程崩溃影响面较大、隔离与横向扩展受限。可以使用外部数据库增强持久化而不拆成微服务。
5.2 多服务系统
将任务 API、模型网关、执行 Worker、工具执行器、状态存储和观测服务按职责拆分。适合需要独立扩容、权限隔离或团队分工的场景，但增加网络失败、版本兼容、跨服务追踪和运维成本。
5.3 分布式执行系统
多个 Worker 并发执行任务，可能跨机器或容器调度。系统需要处理执行租约、心跳、Worker 故障、重复领取任务、检查点恢复和外部副作用。分布式部署不会自动带来高可用；缺少状态与失败语义的分布式系统可能比单体更脆弱。
| 设计问题 | 单进程 | 多服务/分布式 |
|---|---|---|
| 状态访问 | 可使用内存或本地持久化 | 通常需要共享/可恢复存储 |
| 任务并发 | 线程/进程/协程 | Worker 池、队列、调度 |
| 故障边界 | 进程级 | 服务/节点/网络级 |
| 执行隔离 | 进程内或子进程沙箱 | 独立容器/节点等 |
| 调试 | 相对直接 | 需要跨服务追踪与关联 ID |
| 扩展成本 | 初始低 | 初始较高，规模化灵活 |
部署方式是工程拓扑，不是 Agent 智能水平或系统成熟度的直接指标。
六、第五分类轴：多 Agent 的协作与控制模式
6.1 中心编排（Central Orchestration）
一个协调器维护任务图、分派子任务、收集结果并决定下一步。Agent 可以自主完成被分派的子任务，但总体流程由协调器控制。优势是责任清晰、全局状态可见；风险是协调器成为复杂度中心或瓶颈。
6.2 层级委派（Hierarchical Delegation）
主管 Agent 可以分解目标并向子 Agent 委派，子 Agent 返回结果或继续委派。必须限制委派深度、循环、预算、权限继承和任务终止；否则容易出现重复工作和责任模糊。
6.3 去中心化协作（Decentralized Coordination）
多个 Agent 根据消息或共享协议自主协商任务，可能没有单一决策中心。适合需要分布式协商的特殊问题，但通信复杂、冲突与一致性处理困难，审计和全局终止也更复杂。不能仅凭“Agent 互相聊天”就认为实现了可靠的去中心化协作。
6.4 共享工件与黑板（Shared Artifact / Blackboard）
多个 Agent 通过共享文档、结构化任务表或黑板交换结果。它是信息共享模式，可以与中心编排或去中心化协作组合，而非独立互斥类别。需要定义工件所有权、版本、并发更新、审计和冲突解决。
6.5 协作模式比较
| 模式 | 控制权 | 优点 | 主要风险 | 典型适用条件 |
|---|---|---|---|---|
| 中心编排 | 协调器 | 全局可控、易审计 | 中心瓶颈、耦合 | 有明确任务阶段与交付标准 |
| 层级委派 | 上级与下级 | 适合递归任务分解 | 委派循环、预算扩散 | 子任务边界可清晰定义 |
| 去中心化 | 多主体协商 | 局部自治、灵活 | 协议复杂、冲突难追踪 | 需要分布式协商的场景 |
| 共享工件 | 依赖具体控制模式 | 便于异步协作和证据追溯 | 版本冲突、共享污染 | 多主体协作产生可验证工件 |
七、典型系统组合：不是互斥的四种产品
| 场景 | 主体 | 编排 | 时序 | 部署 | 为什么这样选 |
|---|---|---|---|---|---|
| 个人技术研究助理 MVP | 单 Agent | 动态循环 + 固定交付校验 | 同步或简单异步 | 单进程 | 优先验证任务质量与行为边界 |
| 定期生成研究报告 | 单或多 Agent | 混合工作流 | 定时 + 异步 | 单体/Worker | 稳定阶段固定，开放研究阶段动态 |
| 代码仓库修复系统 | 单 Agent 起步 | 动态执行 + 测试门禁 | 异步 | 隔离执行环境 | 命令副作用和环境隔离优先 |
| 多专题并行研究系统 | 多 Agent | 中心编排 + 共享工件 | 异步 | 多 Worker 可选 | 子任务可并行，需统一证据与审核 |
| 企业审批型业务助手 | 单或多 Agent | 强约束工作流 | 事件驱动 | 多服务可选 | 权限、审批、审计高于自主程度 |
以上是研究性设计示例，不是经过性能实测的最佳实践。实际选型需用任务集、失败注入、成本记录和安全验证进行比较。
八、真实框架和项目：如何映射分类轴
框架往往同时支持多个架构类型，因此不应把框架名称当作系统类型。
| 代表性技术 | 公开设计重点 | 可以研究的分类维度 | 使用时应避免的推断 |
|---|---|---|---|
| LangGraph | 状态化图执行、节点与边、持久化/中断机制 | 工作流、动态分支、状态、人工介入 | 使用图框架就一定是多 Agent |
| OpenAI Agents SDK | Agent、工具、交接、运行与追踪等抽象 | 单/多 Agent、交接、执行控制 | 存在 handoff 就自动获得可靠编排 |
| Microsoft AutoGen | 多 Agent 对话与团队协作相关抽象 | 协作拓扑、消息、角色分工 | Agent 数量越多效果越好 |
| Temporal | 持久化工作流执行与活动调度 | 异步、长任务、恢复、确定性编排 | 工作流引擎自身就等于 Agent |
| Kubernetes | 容器编排、调度与运行环境管理 | 分布式部署、隔离、扩缩容 | 使用 K8s 就解决业务级幂等和状态一致性 |
这些映射仅用于确定后续源码研究的对象；本篇未运行上述框架，也未验证其 2026 年 10 月的具体 API 或版本行为。实际案例应先锁定版本，再阅读官方文档、核心源码与测试。
官方研究入口：
- LangGraph 文档：docs.langchain.com/oss/python/langgraph/overview
- OpenAI Agents SDK 文档：openai.github.io/openai-agents-python
- Microsoft AutoGen 项目：github.com/microsoft/autogen
- Temporal 文档：docs.temporal.io
- Kubernetes 概念文档：kubernetes.io/docs/concepts
九、工程选型：从需求而不是技术热度出发
9.1 选型决策树
flowchart TD
A[明确任务契约与失败风险] --> B{任务路径是否基本确定?}
B -->|是| C[固定工作流为主]
B -->|否| D[引入受约束的动态 Agent 决策]
C --> E{存在独立且可验证的子任务?}
D --> E
E -->|否| F[优先单 Agent / 单决策主体]
E -->|是| G{并行/专业分工收益是否超过协调成本?}
G -->|否| F
G -->|是| H[评估多 Agent 分工]
F --> I{是否长任务/高并发/需恢复?}
H --> I
I -->|否| J[单进程或模块化单体]
I -->|是| K[异步任务 + 持久化状态]
K --> L{是否需要独立扩容/隔离?}
L -->|否| M[单体 + Worker/队列]
L -->|是| N[多服务/分布式执行]这不是机械规则。某些高风险操作即使任务很短，也可能需要强隔离和审批；某些长任务可以通过单机持久化实现可靠恢复。真正的选型依据是约束，而不是流程图标签。
9.2 需求 - 机制 - 验证矩阵
| 需求 | 可能的技术机制 | 验证方式 |
|---|---|---|
| 动态检索与探索 | 受限 Agent 循环、工具选择 | 未知任务集、行动轨迹审查 |
| 多专题并行 | 子任务分解、并发 Worker | 端到端耗时、汇总质量、冲突率 |
| 长任务恢复 | 检查点、持久化状态、恢复游标 | 关键步骤故障注入、重复副作用检测 |
| 高风险工具 | 权限门禁、审批、沙箱 | 越权测试、审批绕过测试 |
| 事件触发 | Webhook/消息消费、去重 | 重复/乱序/伪造事件测试 |
| 成本可控 | 步数预算、模型路由、配额 | 同一任务集的成本与质量对照 |
| 可审计协作 | 结构化工件、事件关联 ID | 从结果反向追踪来源和责任 |
十、可复现实验：用标准库比较系统拓扑
为了验证“类型是多个独立维度”的结论，可以构建一个不依赖外部模型的分类与架构约束实验。它不声称证明某个架构更智能，只验证：同一系统能够同时具备多种类型属性；某些组合需要额外工程保障。
下面的代码是可执行的参考示例，不依赖第三方包。配套文件 04-Agent-System-Types-v1.0-demo.py，Python 3 标准库（含 3.9）。运行：python3 04-Agent-System-Types-v1.0-demo.py。
from dataclasses import dataclass
@dataclass(frozen=True)
class SystemProfile:
agents: int
orchestration: str # workflow / dynamic / hybrid
trigger: str # sync / async / event / scheduled
deployment: str # single_process / distributed
durable_state: bool
idempotent_effects: bool
def labels(self):
return (
"multi-agent" if self.agents > 1 else "single-agent",
self.orchestration,
self.trigger,
self.deployment,
)
def risks(self):
issues = []
if self.trigger in {"async", "event", "scheduled"} and not self.durable_state:
issues.append("Long-lived/decoupled execution may lose state after restart")
if self.trigger in {"event", "scheduled"} and not self.idempotent_effects:
issues.append("Duplicate triggers may repeat external side effects")
if self.deployment == "distributed" and not self.durable_state:
issues.append("Distributed workers need recoverable shared execution state")
return issues
profiles = [
SystemProfile(1, "dynamic", "sync", "single_process", False, True),
SystemProfile(4, "hybrid", "event", "distributed", True, True),
SystemProfile(4, "hybrid", "event", "distributed", False, False),
]
for p in profiles:
print(p.labels(), "risks=", p.risks())
assert profiles[0].labels() == ("single-agent", "dynamic", "sync", "single_process")
assert profiles[1].labels() == ("multi-agent", "hybrid", "event", "distributed")
assert profiles[1].risks() == []
assert len(profiles[2].risks()) == 3
print("3 classification checks passed")本地执行通过：输出 ('single-agent', 'dynamic', 'sync', 'single_process') risks= []；('multi-agent', 'hybrid', 'event', 'distributed') risks= []；('multi-agent', 'hybrid', 'event', 'distributed') risks= ['Long-lived/decoupled execution may lose state after restart', 'Duplicate triggers may repeat external side effects', 'Distributed workers need recoverable shared execution state']；3 classification checks passed。
实验解释： 第一个系统是单 Agent、动态决策、同步、单进程；第二个同时是多 Agent、混合编排、事件驱动、分布式；第三个展示缺少持久化与幂等机制的风险提示。该示例仅验证分类逻辑与静态规则，不验证实际消息投递、并发调度、状态一致性或故障恢复。真实系统还需要模拟 Worker 崩溃、重复事件和工具副作用。
十一、常见误区与失败模式
误区一：多 Agent 一定优于单 Agent。 多 Agent 增加协调成本，只有当任务可分解、职责可验证、收益超过成本时才有意义。
误区二：工作流与 Agent 相互排斥。 固定工作流可以包含 Agent 决策节点，动态 Agent 也可以受确定性工作流控制。
误区三：事件驱动意味着系统更自主。 事件驱动只描述触发和通信机制，不决定模型或 Agent 的决策权限。
误区四：分布式部署代表高成熟度。 复杂部署可能引入重复执行、网络分区和状态一致性问题，成熟度应由可靠性证据判断。
误区五：多个角色提示词等于多个 Agent。 应检查是否存在独立任务契约、决策责任、消息或工件交互，而不是只数提示词数量。
误区六：Agent 之间自由对话就能可靠协作。 缺少任务契约、停止条件、冲突裁决和证据追踪时，系统可能出现协作死循环和责任不清。
误区七：有数据库就支持恢复。 恢复需要状态与外部副作用的语义约定，仅保存上下文不足以证明恢复正确。
十二、与后续专题的衔接
本篇解决“Agent System 有哪些类型、如何描述组合、何时选择”的问题。下一篇 「05 · 怎样才算完整的 Agent System？ - Completeness & Maturity」 将研究最低成立条件、系统完整性、工程成熟度和评价证据，明确“类型”和“成熟度”是两条不同的轴。
随后 「06 · 如何理解 Agent System 的架构？ - Architecture & Design Principles」 将进一步研究职责边界、模块化、控制平面与执行职责、故障域、状态所有权和演进策略。技术架构中的 L4 / L5 将深入 Runtime、Workflow 与 Multi-Agent 协作的具体实现；H4 / H7 / H10 则深入持久化、可靠性与验证。
十三、核心结论
Agent System 不能用“单 Agent / 多 Agent / 工作流 / 分布式”这样的单选题分类。更合理的方法是沿着主体数量、决策与编排、触发与时序、部署与状态、协作控制等独立维度描述其系统形态，并结合自主权、外部副作用与风险条件选择架构。
单 Agent 是一种完整且常见的系统形态；多 Agent 是职责组织方式；工作流与动态决策可以混合；事件驱动描述触发机制；分布式描述部署与故障拓扑。它们既不互斥，也不构成由低到高的成熟度阶梯。
工程选型的核心原则是：先确定任务契约和约束，再选择最简单且可验证的系统结构；只有在明确获得收益时，才引入多 Agent、复杂编排或分布式执行。
十四、研究说明与证据边界
本文的多维分类法、决策树和场景映射属于知识库提出的综合性分析框架，不代表行业统一标准。代码为教学用静态分类示例，不包含真实 Agent Runtime、外部模型或消息系统。本篇未对官方框架进行当前版本的实际运行测试，也未进行在线资料检索，因此不对 2026 年 10 月最新版本的 API 或性能作出保证。后续框架专题需锁定版本并完成源码与运行验证。