Agent 架构怎么选：ReAct、Plan-and-Execute、Reflection，到 Supervisor、Swarm、A2A
摘要：用工程视角讲清 6 类 Agent 架构：单 Agent 三派、多 Agent 三型，以及优缺点和选型方法。
很多人第一次接触 Agent，会把它理解成"一个会调用工具的大模型"。这个说法没错，但太粗了。真正做项目时，问题往往不是"要不要用 Agent"，而是：
这个 Agent 到底应该怎么组织自己的思考、行动和协作？
本文就围绕一句话展开：
单 Agent 有三派：边想边做（ReAct）、先想后做（Plan-and-Execute）、做完反思（Reflection）；多 Agent 有三型：层级管理（Supervisor）、平等协作（Swarm）、标准通信（A2A）。
别急着背名词，我们先把底层逻辑讲清楚。你理解了"为什么这样设计"，以后看到任何 Agent 框架，都不会只停留在调 API 的层面。
1. Agent 到底在解决什么问题？
普通大模型问答像是"坐在考场里答题"：它看到问题，然后直接输出答案。
Agent 更像是"带着工具做项目"：它可以搜索、查数据库、执行代码、读文件、调用 API、观察结果，再决定下一步。
可以把 Agent 拆成 5 个部件：
| 部件 | 作用 | 工程里常见形态 |
|---|---|---|
| LLM | 负责理解、推理、生成 | GPT、Claude、Qwen、DeepSeek 等 |
| Tools | 负责连接外部世界 | 搜索、数据库、浏览器、代码执行器、业务 API |
| Memory | 负责保存上下文和经验 | 短期对话、长期记忆、向量库、任务状态 |
| Policy / Planner | 负责决定下一步 | ReAct 循环、任务规划器、路由器 |
| Feedback | 负责告诉它做得怎样 | 工具返回值、测试结果、用户反馈、评分器 |
所以 Agent 架构的本质是：安排好"什么时候想、什么时候做、什么时候改、谁和谁协作"。
下面这张图先把单 Agent 的三种主流节奏放在一起：
2. 单 Agent 架构：ReAct（边想边做）
ReAct 来自论文 ReAct: Synergizing Reasoning and Acting in Language Models。它的核心很朴素：
不要让模型一次性把所有步骤都想完，而是每走一步就观察外部反馈，再决定下一步。
典型循环是：
| 阶段 | 含义 |
|---|---|
| Thought | 我现在知道什么？下一步该做什么？ |
| Action | 调用哪个工具？传什么参数？ |
| Observation | 工具返回了什么？结果是否改变判断？ |
| Answer | 信息足够时，生成最终答案 |
举个例子：用户问"某公司最近一季度营收是多少？"
ReAct Agent 不会直接凭记忆回答，而是：
- 先想：这个问题需要最新财报。
- 再做：调用搜索工具或财报数据库。
- 再看：观察工具返回的季度、币种、营收口径。
- 再想：如果结果不完整，再查公告或电话会纪要。
- 最后答：确认后输出。
这就是 ReAct 的关键：推理被外部观察校准，行动被当前推理驱动。
ReAct 的优点
| 优点 | 解释 |
|---|---|
| 简单好落地 | 一个循环就能跑起来，是很多 Agent 框架的默认形态 |
| 适合工具调用 | 搜索、查表、查库、浏览网页这类任务很顺手 |
| 可解释性较好 | 每一步行动都有上下文，方便调试轨迹 |
| 能减少闭门造车 | 通过 Observation 把模型拉回真实环境 |
ReAct 的缺点
| 缺点 | 解释 |
|---|---|
| 容易短视 | 每次只看下一步，长任务可能走弯路 |
| 调用次数多 | 每个工具调用前后通常都要模型参与，成本和延迟会上去 |
| 容易循环 | 如果没有停止条件，可能一直"再查一下" |
| 上下文会变长 | Thought、Action、Observation 堆多了，会挤占上下文窗口 |
什么时候选 ReAct？
选 ReAct 的典型场景：
- 任务链路不长，比如问答、检索、简单数据查询。
- 需要频繁根据工具结果调整方向。
- 你希望先做一个可运行的 Agent 原型。
- 外部工具返回信息比较可靠。
不要选 ReAct 的典型场景：
- 任务天然很长，比如"完成一份完整调研报告并生成 PPT"。
- 步骤之间依赖复杂，需要先有全局路线图。
- 每次调用大模型的成本很敏感。
一个极简 ReAct 伪代码大概长这样：
python
def react_loop(task, llm, tools, max_steps=8):
# state 保存任务、历史动作和工具观察，避免模型忘记上下文
state = {"task": task, "history": []}
# max_steps 用来限制最多执行几轮，防止 Agent 陷入无限循环
for _ in range(max_steps):
# 让模型基于当前状态判断下一步，可以是继续调用工具，也可以是直接回答
decision = llm.decide_next_step(state)
# 如果模型判断信息已经足够，就返回最终答案
if decision["type"] == "final_answer":
return decision["content"]
# 根据模型选择的工具名，从工具集合中取出对应工具
tool = tools[decision["tool_name"]]
# 执行工具调用，并拿到外部环境返回的观察结果
observation = tool.run(decision["tool_args"])
# 把本轮动作和观察写入历史，供下一轮推理使用
state["history"].append({"decision": decision, "observation": observation})
# 如果超过最大轮数还没完成，就返回一个可控的失败信息
return "任务未在限定步骤内完成，需要人工检查或扩大步数。"3. 单 Agent 架构：Plan-and-Execute（先想后做）
Plan-and-Execute 可以理解为"先写施工图，再进场干活"。
它通常有两个角色：
| 角色 | 作用 |
|---|---|
| Planner | 把大目标拆成步骤 |
| Executor | 按步骤执行工具调用或子任务 |
执行完一轮后，如果发现计划不对，还可以 Replan，也就是重新规划。
它和 ReAct 最大的差别是：
| 架构 | 思考方式 |
|---|---|
| ReAct | 每一步临场判断 |
| Plan-and-Execute | 先做全局计划，再局部执行 |
举个例子：用户要"写一篇某技术的调研文章，并配图、代码、参考资料"。
ReAct 可能会一步步查、一步步写，但容易漏结构。
Plan-and-Execute 会先拆成：
- 明确读者和文章结构。
- 搜索权威资料。
- 提炼核心原理。
- 画架构图。
- 写正文。
- 检查 Markdown、图片和引用。
这类任务一开始就有"路线图"，会稳很多。
Plan-and-Execute 的优点
| 优点 | 解释 |
|---|---|
| 适合长任务 | 先拆步骤，减少"做到一半忘了目标" |
| 结构更清晰 | 计划可以被展示、审阅、修改 |
| 成本可优化 | Planner 用强模型，Executor 可用便宜模型或确定性代码 |
| 更容易并行 | 如果步骤依赖少，可以拆给多个执行器 |
Plan-and-Execute 的缺点
| 缺点 | 解释 |
|---|---|
| 计划可能过时 | 外部反馈变化后，原计划可能不再适用 |
| 错误会传导 | Planner 一开始拆错，后面执行会越走越偏 |
| 实现比 ReAct 复杂 | 要处理计划格式、步骤状态、重规划条件 |
| 不适合小任务 | 为一句简单查询先写计划，反而显得笨重 |
什么时候选 Plan-and-Execute？
适合：
- 长链路任务，比如报告生成、代码迁移、复杂数据分析。
- 任务有明显阶段，比如"调研、设计、实现、验证、总结"。
- 需要把过程展示给用户确认。
- 需要把步骤分配给不同执行器。
不适合：
- 一问一答的小任务。
- 环境变化特别快，计划刚写完就失效。
- 需求本身还没澄清，需要先和用户多轮互动。
4. 单 Agent 架构：Reflection（做完反思）
Reflection 的核心不是"让模型再想一次"，而是：
先做一版，再用反馈信号指出问题，然后把失败经验写进下一轮。
它的基本闭环是：
- Execute：先完成一次尝试。
- Evaluate：用测试、规则、评分器或人工反馈评估。
- Reflect：总结哪里错了，为什么错。
- Retry：带着反思再次尝试。
- Memory：把有效经验沉淀下来。
比如写代码时，Reflection Agent 可以先生成代码，然后运行单测。如果单测失败，它不只是把报错复制回模型，而是会总结：
- 哪个用例失败？
- 失败是边界条件、类型错误，还是业务理解错？
- 下一轮要避免什么？
这就是 Reflection 的价值：让失败变成可复用的改进信号。
Reflection 的优点
| 优点 | 解释 |
|---|---|
| 适合可验证任务 | 单测、Lint、评分器、人工审核都能变成反馈 |
| 能提升多轮质量 | 第一版不完美没关系，关键是会改 |
| 有利于经验沉淀 | 反思内容可以进入长期记忆或规则库 |
| 更像真实工程流程 | 写代码、测代码、改代码，本来就是迭代 |
Reflection 的缺点
| 缺点 | 解释 |
|---|---|
| 成本更高 | 每轮都要执行、评估、反思 |
| 反馈质量决定上限 | 测试不准，反思也会偏 |
| 自我批评可能不可靠 | 模型可能"看起来反思了"，但没有抓住根因 |
| 容易过度修正 | 为了修一个小问题，把原本正确的部分改坏 |
什么时候选 Reflection？
适合：
- 代码生成、SQL 生成、数据清洗这类有明确验证信号的任务。
- 文案、报告、问答等需要多轮打磨的任务。
- 需要把失败经验沉淀为下次提示词或规则的场景。
不适合：
- 没有任何评价标准的开放式任务。
- 对延迟极敏感的在线链路。
- 外部反馈很噪，无法判断好坏的任务。
5. 单 Agent 各个架构对比
| 架构 | 一句话 | 最适合 | 最大风险 |
|---|---|---|---|
| ReAct | 边想边做 | 短链路工具调用 | 容易循环、成本随步骤增长 |
| Plan-and-Execute | 先想后做 | 长任务、复杂工作流 | 计划错误会传导 |
| Reflection | 做完反思 | 有反馈、可迭代任务 | 反馈差会导致越改越偏 |
如果只记一句：
ReAct 管"行动节奏"，Plan-and-Execute 管"任务结构"，Reflection 管"质量改进"。
6. 多 Agent：不是人多就强，而是分工方式不同
当单个 Agent 变得太臃肿时，多 Agent 就有意义了。
但多 Agent 不是把 5 个模型放在一起聊天。工程上真正要解决的是：
- 谁来分配任务？
- 谁能调用谁？
- 每个 Agent 看到多少上下文？
- 结果怎么合并？
- 出错了谁负责？
- 跨系统怎么通信？
下面这张图把多 Agent 的三种形态放在一起：
7. Supervisor，层级管理
Supervisor 架构像一个项目经理带多个专家。
它通常是：
用户任务 → Supervisor 分解/路由 → 专家 Agent 执行 → Supervisor 汇总/检查 → 最终结果
专家 Agent 可以是研究员、代码员、测试员、审核员，也可以是业务里的客服 Agent、订单 Agent、退款 Agent。
关键点是：所有任务入口和结果出口都经过 Supervisor。
Supervisor 的优点
| 优点 | 解释 |
|---|---|
| 控制力强 | 谁能做什么，由 Supervisor 决定 |
| 易于审计 | 调用链路集中，日志和权限更好管 |
| 适合企业流程 | 分工明确，责任边界清楚 |
| 上下文隔离 | 每个专家只看自己需要的信息 |
Supervisor 的缺点
| 缺点 | 解释 |
|---|---|
| 容易成为瓶颈 | 所有路由都经过中心节点 |
| Supervisor 质量很关键 | 调度错了，专家再强也白搭 |
| 可能损失灵活性 | 专家之间不能自然直接沟通 |
| 额外模型调用 | 分派、汇总、检查都会增加成本 |
什么时候选 Supervisor？
适合：
- 企业内部自动化流程。
- 需要权限控制、审计日志、人工审批。
- 多个专家能力边界清晰。
- 任务结果必须由一个中心统一把关。
不适合：
- 高度开放探索，无法提前定义专家边界。
- 强实时、低延迟任务。
- 需要 Agent 之间频繁自由交接的场景。
8. Swarm，平等协作
Swarm 可以理解为"没有固定项目经理的协作网络"。每个 Agent 都有自己的职责，也可以把任务交接给另一个更合适的 Agent。
OpenAI 的 Swarm 仓库把这种思想抽象成两个核心概念：Agent 和 handoff。一个 Agent 既有自己的 instructions 和 tools，也可以在合适的时候把会话交给另一个 Agent。
注意：Swarm 在工程语境里更像一种协作模式，不是说一定要用某个同名库。
Swarm 的优点
| 优点 | 解释 |
|---|---|
| 交接自然 | 当前 Agent 发现自己不擅长，就把任务交给更合适的 Agent |
| 灵活度高 | 不必所有事都绕回中心节点 |
| 适合多角色对话 | 客服、销售、技术支持、审核之间可以自然切换 |
| 可组合性强 | 新增 Agent 往网络里挂即可 |
Swarm 的缺点
| 缺点 | 解释 |
|---|---|
| 调试更难 | 任务路径可能不是固定的 |
| 容易来回踢皮球 | A 交给 B，B 又交回 A，需要终止规则 |
| 全局目标可能变弱 | 每个 Agent 只看局部，整体一致性要额外设计 |
| 权限管理更复杂 | 谁能交给谁、带哪些上下文，都要约束 |
什么时候选 Swarm？
适合：
- 多角色客服、复杂表单办理、咨询类工作流。
- 任务入口不确定，需要动态判断归属。
- Agent 之间需要频繁切换控制权。
- 你能接受更复杂的追踪和终止条件。
不适合：
- 需要严格中心审批的流程。
- 每一步都要固定、可审计、可复现的场景。
- 团队还没有完善的 tracing 和 eval 工具。
9. A2A，标准通信
A2A 是 Agent2Agent 的缩写。它和前面的 Supervisor、Swarm 不太一样：
Supervisor 和 Swarm 更像"编排架构"，A2A 更像"通信协议"。
换句话说，A2A 不规定你的 Agent 内部怎么想、怎么调用工具；它更关心：
- 一个 Agent 如何声明自己会什么？
- 另一个 Agent 如何发现它？
- 它们之间如何发送任务、消息和产物？
- 长任务如何返回状态？
- 不同框架、不同团队、不同厂商的 Agent 如何互通？
在 A2A 里，一个很重要的概念是 Agent Card。你可以把它理解成 Agent 的"能力名片"：这个 Agent 支持什么能力、认证方式是什么、接口在哪里、支持哪些输入输出。
另一个核心概念是 Task / Message / Artifact：
| 概念 | 含义 |
|---|---|
| Message | 一次消息交互 |
| Task | 可追踪的任务单元，适合长时间处理 |
| Artifact | 任务执行后产生的结果，比如文件、结构化数据、报告 |
A2A 的优点
| 优点 | 解释 |
|---|---|
| 跨系统互通 | 不同框架写的 Agent 可以用统一协议通信 |
| 边界清晰 | Agent 内部实现私有，外部只看协议接口 |
| 适合平台化 | 多团队、多厂商、多业务线更容易接入 |
| 有利于治理 | 认证、能力声明、任务状态可以标准化 |
A2A 的缺点
| 缺点 | 解释 |
|---|---|
| 它不替你编排 | A2A 解决通信，不自动解决任务分工 |
| 落地成本更高 | 要设计 Agent Card、认证、版本兼容 |
| 生态仍在演进 | 标准、工具链、最佳实践都需要持续关注 |
| 安全问题更突出 | 跨系统调用必须处理权限、审计、数据边界 |
什么时候选 A2A？
适合：
- 多个业务系统都要暴露 Agent 能力。
- 不同团队独立开发 Agent，但需要互相调用。
- 需要跨厂商、跨框架集成。
- 你在做 Agent 平台，而不是只做单个应用。
不适合：
- 单应用内部的小型多 Agent 流程。
- 还没确定 Agent 能力边界，就急着上协议。
- 没有认证、权限、审计基础设施的场景。
10. 怎么选型？先问这 6 个问题
选型不要从框架开始，先从任务特征开始。
选型速查表
| 你的任务特征 | 推荐架构 | 原因 |
|---|---|---|
| 简单查询、短链路工具调用 | ReAct | 边做边看反馈，成本低，上手快 |
| 长任务、步骤多、需要结构化产出 | Plan-and-Execute | 先拆计划，避免走一步看一步 |
| 有测试、有评分、有人工反馈 | Reflection | 反馈能驱动质量迭代 |
| 多专家分工且需要中心把关 | Supervisor | 便于权限、审计、汇总 |
| 多角色动态交接，流程入口不固定 | Swarm | Agent 可以自然 handoff |
| 跨团队、跨厂商、跨框架互通 | A2A | 协议层统一通信边界 |
一个很实用的判断顺序
- 先问：这是单 Agent 能解决，还是必须多 Agent？
- 如果单 Agent 能解决，再问：任务短不短？
- 如果任务短，优先 ReAct。
- 如果任务长，优先 Plan-and-Execute。
- 如果有明确反馈信号，把 Reflection 加进去。
- 如果必须多 Agent，再问：要中心管控还是自由交接？
- 要中心管控，选 Supervisor。
- 要自由交接，选 Swarm。
- 要跨系统标准互通，再引入 A2A。
注意一个细节：这些架构不是互斥的。工程里经常组合使用。
比如：
- Supervisor 负责分工，每个专家内部用 ReAct 调工具。
- Plan-and-Execute 负责大任务规划，每个步骤失败后用 Reflection 修正。
- Swarm 负责角色交接，跨组织调用时通过 A2A 通信。
可以把它们理解成不同层次的积木：
| 层次 | 典型选择 |
|---|---|
| 单个 Agent 的行动节奏 | ReAct |
| 单个 Agent 的任务结构 | Plan-and-Execute |
| 单个 Agent 的质量闭环 | Reflection |
| 多 Agent 的中心调度 | Supervisor |
| 多 Agent 的动态交接 | Swarm |
| 多 Agent 的跨系统接口 | A2A |
11. 一个极简选型函数
下面这段不是生产代码，只是把上面的判断逻辑写成伪代码，帮助你把"架构选型"变成可讨论的规则。
python
def select_agent_architecture(task):
# task 是一个字典，用来描述当前任务的关键特征
# 例如：是否跨系统、是否多专家、是否有反馈信号、任务是否很长
# 如果需要跨团队、跨厂商或跨框架互通，优先考虑 A2A 作为通信边界
if task.get("cross_system"):
return "A2A"
# 如果需要中心化权限控制、审计和结果汇总，优先使用 Supervisor
if task.get("needs_central_control"):
return "Supervisor"
# 如果任务会在多个角色之间动态切换，优先考虑 Swarm 的 handoff 模式
if task.get("needs_dynamic_handoff"):
return "Swarm"
# 如果任务有明确测试、评分或人工反馈，可以加入 Reflection 闭环
if task.get("has_feedback_signal"):
return "Reflection"
# 如果任务步骤很多、持续时间长，优先采用 Plan-and-Execute
if task.get("is_long_horizon"):
return "Plan-and-Execute"
# 如果只是短链路工具调用，ReAct 通常是最轻量的默认选择
return "ReAct"真正落地时，不建议只返回一个字符串。更好的做法是输出"主架构 + 辅助机制"。比如：
| 场景 | 更合理的组合 |
|---|---|
| 自动写代码并跑测试 | Plan-and-Execute + Reflection |
| 企业知识库问答 | ReAct + RAG + Guardrails |
| 多部门审批助手 | Supervisor + Human-in-the-loop |
| 多角色客服系统 | Swarm + 状态机 + 终止条件 |
| 企业 Agent 平台 | Supervisor / Swarm + A2A |
12. 学习 Agent 架构时一定要顺手理解
12.1 Tool Calling
Tool Calling 是 Agent 能"做事"的入口。没有工具，Agent 就只能回答；有工具，Agent 才能搜索、执行、查询和写入系统。
需要注意的是，工具不是越多越好。工具太多会让模型选择困难，常见解决办法是：
- 给工具写清楚描述和参数。
- 给不同 Agent 分配不同工具集合。
- 用 Router 或 Supervisor 先缩小工具范围。
12.2 Memory
Memory 分两类：
| 类型 | 作用 |
|---|---|
| 短期记忆 | 当前任务上下文、历史步骤、工具观察 |
| 长期记忆 | 用户偏好、项目经验、失败反思、领域知识 |
Reflection 架构尤其依赖长期记忆，因为它要把"这次错在哪里"变成"下次不要再错"。
12.3 Handoff 和 Routing
这两个词很容易混：
| 概念 | 解释 |
|---|---|
| Routing | 有一个路由器决定把任务分给谁 |
| Handoff | 当前 Agent 主动把控制权交给另一个 Agent |
Supervisor 更偏 Routing，Swarm 更偏 Handoff。
12.4 终止条件
Agent 最怕"看起来很努力，但一直不结束"。所以要设计终止条件：
- 最大执行步数。
- 最大工具调用次数。
- 最大重试次数。
- 预算上限。
- 结果质量达到阈值。
- 用户确认后继续。
尤其是 ReAct、Reflection、Swarm，这三个都很容易因为循环机制跑太久。
12.5 Observability
Agent 系统必须能追踪：
- 模型每次输入输出。
- 工具调用参数。
- 工具返回结果。
- 路由或 handoff 决策。
- 每一步耗时和成本。
- 失败位置和重试原因。
没有 tracing 的多 Agent 系统，出问题时很难定位到底是"模型想错了""工具错了"还是"编排错了"。
12.6 Guardrails
Agent 会调用外部系统，所以安全边界非常重要：
- 高风险工具要加审批。
- 写操作要比读操作更严格。
- 不同 Agent 只能看到自己需要的上下文。
- 重要结果要可回滚、可审计。
- 外部输入要防 prompt injection。
多 Agent 一多，权限边界就会变成架构问题，而不是简单的提示词问题。
13. 最后总结
这 6 个架构可以用一句话记住：
- ReAct：适合短链路，边想边做。
- Plan-and-Execute：适合长任务，先想后做。
- Reflection：适合可验证任务，做完反思再改。
- Supervisor：适合强管控，多专家由中心调度。
- Swarm：适合动态协作，Agent 之间自然交接。
- A2A：适合跨系统互通，用协议统一边界。
真正的工程选型不是"哪个最先进"，而是"哪个最贴合你的任务形状"。
小任务别上复杂编排，长任务别只靠临场发挥，有反馈就让 Agent 学会复盘，跨系统就把通信协议设计清楚。
Agent 架构的核心，其实就是一句工程老话：
先把问题拆对，再决定谁来做、怎么做、做错了怎么改。
参考资料（仅供参考）
- ReAct 项目页与论文：react-lm.github.io/、arxiv.org/abs/2210.03...
- Reflexion 论文：arxiv.org/abs/2303.11...
- Self-Refine 论文：arxiv.org/abs/2303.17...
- LangChain Plan-and-Execute Agents：www.langchain.com/blog/planni...
- LangChain Multi-agent 文档：docs.langchain.com/oss/python/...
- OpenAI Swarm GitHub：github.com/openai/swar...
- A2A Protocol Specification：a2a-protocol.org/latest/spec...