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 个部件：

所以 Agent 架构的本质是：安排好“什么时候想、什么时候做、什么时候改、谁和谁协作”。

下面这张图先把单 Agent 的三种主流节奏放在一起：

2. 单 Agent 架构：ReAct（边想边做）

ReAct 来自论文ReAct: Synergizing Reasoning and Acting in Language Models。它的核心很朴素：

不要让模型一次性把所有步骤都想完，而是每走一步就观察外部反馈，再决定下一步。

典型循环是：

举个例子：用户问“某公司最近一季度营收是多少？”
ReAct Agent 不会直接凭记忆回答，而是：

1. 先想：这个问题需要最新财报。
2. 再做：调用搜索工具或财报数据库。
3. 再看：观察工具返回的季度、币种、营收口径。
4. 再想：如果结果不完整，再查公告或电话会纪要。
5. 最后答：确认后输出。

这就是 ReAct 的关键：推理被外部观察校准，行动被当前推理驱动。

ReAct 的优点

ReAct 的缺点

什么时候选 ReAct？

选 ReAct 的典型场景：

• 任务链路不长，比如问答、检索、简单数据查询。
• 需要频繁根据工具结果调整方向。
• 你希望先做一个可运行的 Agent 原型。
• 外部工具返回信息比较可靠。

不要选 ReAct 的典型场景：

• 任务天然很长，比如“完成一份完整调研报告并生成 PPT”。
• 步骤之间依赖复杂，需要先有全局路线图。
• 每次调用大模型的成本很敏感。

一个极简 ReAct 伪代码大概长这样：

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 可以理解为“先写施工图，再进场干活”。

它通常有两个角色：

执行完一轮后，如果发现计划不对，还可以 Replan，也就是重新规划。

它和 ReAct 最大的差别是：

举个例子：用户要“写一篇某技术的调研文章，并配图、代码、参考资料”。
ReAct 可能会一步步查、一步步写，但容易漏结构。
Plan-and-Execute 会先拆成：

1. 明确读者和文章结构。
2. 搜索权威资料。
3. 提炼核心原理。
4. 画架构图。
5. 写正文。
6. 检查 Markdown、图片和引用。

这类任务一开始就有“路线图”，会稳很多。

Plan-and-Execute 的优点

Plan-and-Execute 的缺点

什么时候选 Plan-and-Execute？

适合：

• 长链路任务，比如报告生成、代码迁移、复杂数据分析。
• 任务有明显阶段，比如“调研、设计、实现、验证、总结”。
• 需要把过程展示给用户确认。
• 需要把步骤分配给不同执行器。

不适合：

• 一问一答的小任务。
• 环境变化特别快，计划刚写完就失效。
• 需求本身还没澄清，需要先和用户多轮互动。

4. 单 Agent 架构：Reflection（做完反思）

Reflection 的核心不是“让模型再想一次”，而是：

先做一版，再用反馈信号指出问题，然后把失败经验写进下一轮。

它的基本闭环是：

1. Execute：先完成一次尝试。
2. Evaluate：用测试、规则、评分器或人工反馈评估。
3. Reflect：总结哪里错了，为什么错。
4. Retry：带着反思再次尝试。
5. Memory：把有效经验沉淀下来。

比如写代码时，Reflection Agent 可以先生成代码，然后运行单测。如果单测失败，它不只是把报错复制回模型，而是会总结：

• 哪个用例失败？
• 失败是边界条件、类型错误，还是业务理解错？
• 下一轮要避免什么？

这就是 Reflection 的价值：让失败变成可复用的改进信号。

Reflection 的优点

Reflection 的缺点

什么时候选 Reflection？

适合：

• 代码生成、SQL 生成、数据清洗这类有明确验证信号的任务。
• 文案、报告、问答等需要多轮打磨的任务。
• 需要把失败经验沉淀为下次提示词或规则的场景。

不适合：

• 没有任何评价标准的开放式任务。
• 对延迟极敏感的在线链路。
• 外部反馈很噪，无法判断好坏的任务。

5. 单 Agent 各个架构对比

如果只记一句：
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？

适合：

• 企业内部自动化流程。
• 需要权限控制、审计日志、人工审批。
• 多个专家能力边界清晰。
• 任务结果必须由一个中心统一把关。

不适合：

• 高度开放探索，无法提前定义专家边界。
• 强实时、低延迟任务。
• 需要 Agent 之间频繁自由交接的场景。

8. Swarm，平等协作

Swarm 可以理解为“没有固定项目经理的协作网络”。每个 Agent 都有自己的职责，也可以把任务交接给另一个更合适的 Agent。

OpenAI 的 Swarm 仓库把这种思想抽象成两个核心概念：Agent 和 handoff。一个 Agent 既有自己的 instructions 和 tools，也可以在合适的时候把会话交给另一个 Agent。

注意：Swarm 在工程语境里更像一种协作模式，不是说一定要用某个同名库。

Swarm 的优点

Swarm 的缺点

什么时候选 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：

A2A 的优点

A2A 的缺点

什么时候选 A2A？

适合：

• 多个业务系统都要暴露 Agent 能力。
• 不同团队独立开发 Agent，但需要互相调用。
• 需要跨厂商、跨框架集成。
• 你在做 Agent 平台，而不是只做单个应用。

不适合：

• 单应用内部的小型多 Agent 流程。
• 还没确定 Agent 能力边界，就急着上协议。
• 没有认证、权限、审计基础设施的场景。

10. 怎么选型？先问这 6 个问题

选型不要从框架开始，先从任务特征开始。

选型速查表

一个很实用的判断顺序

1. 先问：这是单 Agent 能解决，还是必须多 Agent？
2. 如果单 Agent 能解决，再问：任务短不短？
3. 如果任务短，优先 ReAct。
4. 如果任务长，优先 Plan-and-Execute。
5. 如果有明确反馈信号，把 Reflection 加进去。
6. 如果必须多 Agent，再问：要中心管控还是自由交接？
7. 要中心管控，选 Supervisor。
8. 要自由交接，选 Swarm。
9. 要跨系统标准互通，再引入 A2A。

注意一个细节：这些架构不是互斥的。工程里经常组合使用。

比如：

• Supervisor 负责分工，每个专家内部用 ReAct 调工具。
• Plan-and-Execute 负责大任务规划，每个步骤失败后用 Reflection 修正。
• Swarm 负责角色交接，跨组织调用时通过 A2A 通信。

可以把它们理解成不同层次的积木：

11. 一个极简选型函数

下面这段不是生产代码，只是把上面的判断逻辑写成伪代码，帮助你把“架构选型”变成可讨论的规则。

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"

真正落地时，不建议只返回一个字符串。更好的做法是输出“主架构 + 辅助机制”。比如：

12. 学习 Agent 架构时一定要顺手理解

12.1 Tool Calling

Tool Calling 是 Agent 能“做事”的入口。没有工具，Agent 就只能回答；有工具，Agent 才能搜索、执行、查询和写入系统。

需要注意的是，工具不是越多越好。工具太多会让模型选择困难，常见解决办法是：

• 给工具写清楚描述和参数。
• 给不同 Agent 分配不同工具集合。
• 用 Router 或 Supervisor 先缩小工具范围。

12.2 Memory

Memory 分两类：

Reflection 架构尤其依赖长期记忆，因为它要把“这次错在哪里”变成“下次不要再错”。

12.3 Handoff 和 Routing

这两个词很容易混：

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 架构的核心，其实就是一句工程老话：
先把问题拆对，再决定谁来做、怎么做、做错了怎么改。

学习资源推荐

如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！​

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示

​因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

四、AI大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。