2026年的多智能体系统：ReAct、监督器、群体、LangGraph与Strands
多智能体控制流模式指南——包括顺序、并行、中心辐射式、图结构、事件驱动、评价器以及人机交互模式——以及 LangGraph 和 Strands 等框架的适用性。
生成式 AI 的下一阶段不仅仅是更智能的模型，而是多个智能体能够进行推理、调用工具、分配任务、验证结果、从故障中恢复以及协同工作的系统。这正是多智能体系统（MAS）的范畴。
最简单的 LLM 应用看起来只是用户与模型之间的直接路径：
User
↓
LLM
↓
Response
而实际的生产级多智能体系统结构则更为复杂：
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
并没有统一的模板，常见的结构包括 ReAct 智能体、串行与并行处理流程、监督者（中心辐射式）设计、层级结构、任务交接机制、群体智能体、规划器与执行器分离架构、基于图的工作流、事件驱动型智能体、评价/评估循环，以及人类介入机制。LangGraph、Strands Agents 和 Amazon Bedrock AgentCore 等框架为这些结构提供了基础组件。以下内容会对相关概念进行分类，以便团队避免将不相关的概念视为竞争对手。
1. 什么是多智能体系统？
多智能体系统是由多个专用智能体协作以实现更宏大的目标。无需让一个模型承担所有任务：
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
各项职责可以分开分配：
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
每个智能体都可以拥有自己的指令、工具、内存、上下文窗口、模型选择、策略、职责以及评估标准。专业化是人们放弃单智能体设计的主要原因。
2. 智能体数量越多就越好吗？
额外的智能体会增加成本和复杂性。三个智能体往往意味着需要三组提示和三种上下文：
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
过多的智能体会加剧开发成本和调试难度：
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
合理的系统设计需要确定哪些职责应当分开处理，以及各智能体之间的控制流程应如何安排。
3. ReAct智能体
ReAct即“推理+行动”。该循环会进行推理、选择工具、观察情况，然后继续执行——例如调查数据库CPU使用率异常的情况：
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
优点：当下一步操作取决于上一次的观察结果时，可以动态选择工具。
缺点：过长的循环会导致延迟增加、计算资源消耗上升、成本提高以及失败概率增大。ReAct只是一种推理模式，并非完整的多智能体架构。
4. 顺序式多智能体架构
最简单的多智能体结构就是流水线：
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
类似银行的处理流程可能如下所示：
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
适用场景：操作顺序很重要，输出结果会传递到下一阶段，工作流程具有可预测性，且需要保留审计轨迹。
主要局限：中间环节出现故障可能会使整个流程停滞——因此在实际应用中需要采用重试、检查点以及恢复机制。
5. 并行/辐射式–汇聚式
独立任务无需依次等待：
Agent A
↓
Agent B
↓
Agent C
多个专家可同时开展工作：
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
云架构审查可通过辐射式分配分析任务：
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
随后汇总分析结果。
优势：减少总耗时。挑战：汇总过程必须可靠。
6. 中心辐射式/监督者模式
中央监督者将任务分配给各专家：
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
当收到用户请求时：
User:
"Analyze this AWS account and identify security and
cost problems."
监督者可按此方式分配任务：
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
优势：实现集中控制。挑战：若所有决策都需经过中心节点，该节点会成为瓶颈及关键基础设施：
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. 层级化多智能体架构
当一个主管不够时，可增加层级：
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
企业云通常会设置多层主管结构：
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
其结构类似于组织架构图，但代价是更高的协调成本。
8. 基于交接的架构
一个客服人员将对话的处理权移交给另一人：
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
支持流程中常常会将技术问题转交他人处理：
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
与固定的主管不同，接手方会成为实际的处理者——这适用于客户支持、专业人员分流、领域助手以及对话式工作流。
9. 群体架构
这种架构没有固定的中心节点，客服人员之间会进行动态协作：
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
每个人都可以认为另一位同伴更合适。灵活性也伴随着一些关键问题：谁来控制系统？如果没有边界约束，就可能出现循环、重复工作、上下文爆炸、不可预测的路径以及高昂的推理成本。因此，强大的状态管理机制和终止条件是必不可少的。
10. 规划者-执行者架构
将规划与执行分开：
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
对于“将此应用程序迁移到AWS”这一任务，规划者可能会列出相应的步骤：
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
随后执行者会逐一完成这些步骤。当复杂目标可以分解为明确的任务时，这种架构非常有用。
11. 基于图的智能体
LangGraph之类的框架在此类场景中表现优异。与其使用松散的链式结构：
Agent → Agent → Agent
不如考虑使用状态图：
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
节点可以是智能体、工具、函数、验证器、人工审批者或路由器。共享状态加上明确的边连接比让模型为每次转换即兴决策能提供更强的控制力。
12. Strands 智能体
AWS Strands Agents 是用于工具型智能体的 SDK。从概念上讲：
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
智能体会对工具进行推理，并根据观察结果继续执行操作。Strands 也可以嵌入多智能体架构中：
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
重要区别：Strands 是一种框架/SDK，而 supervisor 是一种架构模式。二者是互补关系，并非竞争关系。
13. LangGraph 智能体
LangGraph 强调将带状态的工作流程以图的形式明确表示：
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
你可以定义状态、节点、边、条件路由、检查点、重试机制、人工审批以及数据持久化——这些都是生产系统所必需的控制功能。
14. 基于事件的多智能体系统
并非所有流程都是同步的。事件可以唤醒智能体：
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
操作示例：
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
适用于云运维、安全监控、事件响应、FinOps以及自动化领域。
15. 评估者/审核者架构
一个智能体负责生成内容，另一个负责评估：
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
架构审查示例：
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
由于模型输出并不一定可靠，因此评估者起到了质量把关的作用。
16. 人机协同的多智能体系统
对于那些影响重大的变更，完全自主处理并不总是合适：
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
安全修复示例：
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
人工智能提出可能的解决方案，而政策与人类的审批则决定最终是否实施。
17. 重要的分类体系
这些理念存在于不同的层级之中：
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
这样的架构设计避免了诸如“LangGraph与supervisor与ReAct”这类错误比较，不会让人误以为它们是三种相互竞争的产品。
18. 它们如何结合使用
功能通过组合实现：
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
一种设计可以整合supervisor调度、并行扩展、ReAct推理、评估机制以及重试功能——这些功能可通过LangGraph、Strands、Bedrock、AgentCore、Step Functions或自定义代码来实现。
在约束条件下行模式选择
延迟、令牌数量以及故障处理复杂度等方面的预算应决定拓扑结构的设计。当监管机构关注处理顺序时，串行流程更便于审计。在独立分析占据大量处理时间的情况下，分支结构更为有效。当路由策略必须保持集中管理时，监督机制能起到辅助作用。需要检查点与人工审核环节时，图结构更为合适。而对于集群式及自由形式的任务传递，则需要最大的可观测性投入。应选择在保证故障模式清晰可见的同时，控制开销最小的方案。
19. 应该使用哪种架构？
并不存在通用的最佳方案。需根据具体问题选择合适的控制流程。关键问题不是“哪种框架最好？”，而是“该工作流需要何种控制流程模式？”
20. 新兴的生产架构
生产系统为智能体提供身份标识、权限设置、工具支持、状态管理、内存功能、约束规则、评估机制、可观测性保障、重试功能、成本控制以及人工审批流程。整个行业正在从“单个智能体”转向“智能体系统”。
21. 最终总结
多智能体系统的工作核心在于分解智能功能并管控协作流程——而非仅仅为了创建智能体而创建它们。ReAct框架负责推理与行动；监督者负责任务分配；图结构用于控制状态转换；群体架构实现去中心化；规划器负责任务分解；审核机制用于验证结果；最终由人工进行审批。LangGraph和Strands等工具提供了相应的实现基础。工程层面的关键问题包括：存在哪些智能体、它们如何协作、能够执行什么操作、决策如何得到验证，以及出现故障时会发生什么。
需要牢记的心智模型
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
那些跳过此系统视图的团队往往只关注模型规模的扩展，而将流程编排、权限管理及评估工作搁置一旁。这些疏漏会导致错误答案无人察觉、工具陷入无限循环，或是无法安全回滚的智能体。在控制流、验证机制及人工审核环节上投入资源，通常比频繁更换模型更能带来成效。
未来不仅仅是更智能的模型，更是围绕这些模型构建的更完善的系统。