每天吃透一个 AI 知识点 ——AI Agent 架构选型指南 6 种主流架构解析

转载：小红书 AI产品赵哥

前言 🔖

最近帮一个做企业知识管理的朋友看他们的 Agent 架构设计。一张图摊开：五个 Agent、一个 Supervisor、再加一套消息总线，说是打算升级智能客服。

我问了句: “你们现在的客服场景里，用户问的问题和标准答案，对得上吗？”

对方愣了一下，说: “对得上，无非就是查订单状态、解释退货政策、或者转人工。”

我说: “那根本用不着 Multi‑Agent。搞个简单工作流，加几个判断分支就够用了。成本至少能砍掉八成。”

这种情况我这两年遇到很多次。很多开发者，特别是刚入行的，容易觉得架构越复杂越显得有技术含量。好像不提 “多智能体” 就显得自己不够 Agentic。但我做过的项目里，有一半的返工和失败，起因都是架构选大了、选重了 —— 用宰牛刀去杀了一只鸡。

今天咱把当前几种主流的 Agent 架构逐个拆开给你看：ReAct、Workflow、Planner‑Executor、Multi‑Agent、Supervisor 和 Swarm。我不想讲太多空理论，咱们用一个案例，来说清楚它们各自在解决什么问题、什么时候该用、什么时候是过度设计，以及资源有限的时候，该怎么做出最明智的选择。

一、先搞清楚：架构为什么会越来越复杂？🔖

Agent 架构这几年花样越来越多。但追到底层，所有这些变化都在做同一件事 —— 打补丁，修补 LLM 天生的三个缺陷。

🔹 第一个缺陷：LLM 不会动手

LLM 本质上是个文本生成器，只能 “说”，不能 “做”。它没法调用 API、读本地文件、写代码执行。它活在纯文本的世界里，跟现实世界是脱节的。
这就是 ReAct 架构要解决的问题。

🔹 第二个缺陷：LLM 不会规划

LLM 擅长预测 “下一步说什么”，但不擅长全局性的战略思考。你给它一个模糊的、多步骤的目标，它很难自己拆解成有先后依赖的任务链。
这就是 Planner‑Executor 架构要解决的问题。

🔹 第三个缺陷：LLM 不会分身

再强的单个模型，知识面和能力都是有边界的。你很难让一个模型同时精通法律审查、财务分析和市场营销。
这就是 Multi‑Agent 架构要解决的问题。

Agent 架构的演进：层层递进，解决核心短板

搞清楚了上面这些，你在做选型时就不容易被越复杂越先进这种错觉牵着走。每代新架构都是在上一代基础上补特定的坑，不是推倒重来。接下来用同一个案例贯穿全文：

假设你是个 OPC，接了个不大不小的项目：帮一家小型电商公司做一个社交媒体运营 Agent。

每周一早上十点，这个 Agent 需要自动完成这些事：

- 分析上周产品的销售数据；
- 抓取近期的网络热点；
- 写 3 篇核心产品的推广文案（小红书风格）；
- 每篇配一张图；
- 把图文发到公司社交账号上；

现在看看，不同架构分别会怎么应对这个需求。

二、架构一：ReAct‑让 Agent 学会 “动手” 的基础 🔖

ReAct 是所有复杂 Agent 架构的地基。它的全称是 Reason（推理）+ Act（行动）。核心逻辑，就是让模型在一个 “思考 → 行动 → 观察” 的循环里反复迭代，直到任务完成。

拿上面那个案例的第一步 “分析上周销售数据” 来走一遍：

Thought: 我需要分析上周销售数据，但手里什么都没有。先得找到数据。我有个 query_database 工具可以用，先查一下。
Action: 调用 query_database，执行 SQL:

SELECT product_name, SUM(sales) FROM sales_records
WHERE date >= '上周一' AND date <= '上周日' GROUP BY
product_name ORDER BY SUM(sales) DESC;

Observation: 查询返回了数据: [{"product_name": "智能咖啡机", "sales": 52000}, {"product_name": "便携吸尘器", "sales": 38000}, ...]
Thought: 数据到手了。上周卖得最好的是智能咖啡机，52000 元。我的任务是分析，不是简单展示数字。得解读一下：智能咖啡机是上周的明星产品，销售额远超其他。这步完成了。

🔹 什么时候用 ReAct?

任务比较简单，步骤少，一般五步以内能搞定。比如查个天气、查个数据，我们案例里分析销售数据那一步就属于这种。
对路径没有严格要求，允许 Agent 边想边做，有一定探索空间。

🔹 ReAct 的致命缺陷

ReAct 最大的问题是没有全局视野，走一步看一步。它就像一个没地图、只靠路牌走路的人。前期一步走偏，后面可能越走越远，彻底偏离最初的目标。

在我们这个案例里，如果 ReAct 分析完销售数据之后，直接跳去写文案，忘了还要结合热点，那整个任务就不算完成。

作为 OPC，ReAct 是你必须掌握的入门级架构。很多简单的 toB 需求，一个稳定的 ReAct 循环就够用了。但任务超过五步，或者步骤之间有严格的依赖关系，就得考虑升级架构了。

三、架构二：Workflow‑用 “确定性” 换 “可控性” 的流水线 🔖

很多人把 Workflow（工作流）和 Agent 混为一谈，这是个常见的误区，我们在之前的笔记里讨论过这个问题。

严格来说，Workflow 不是 Agent。它是一个预先定义好的、确定性的流程图。AI 模型或工具只是被安排在流程的某个节点上干活。AI 自己没有决定 “下一步该走哪条路” 的权力。

我们把整个 “自动化社交媒体运营” 的案例用 Workflow 重新设计：

看到区别了没？在这个 Workflow 里，每一步做什么、按什么顺序、用什么工具，都是提前写死在代码里的。LLM 只是一个被调用的函数，负责在特定节点完成特定的文本生成任务。它不可能临时决定 “今天不想结合热点了” 或者 “跳过人工审核”。

🔹 什么时候用 Workflow?

任务流程高度固定、规则清晰。比如报销审批、工单流转、标准报告生成。
对结果的稳定性和可审计性要求极高，比如金融合同审查、病历处理。客户要的不是 AI 有多智能，而是每一步都有据可查。
你想快速交付一个稳定可靠、不会整活的 toB 项目。

🔹 Workflow 的短板

它的优点（确定性）同时也是缺点。一旦遇到流程之外的突发情况，它没有应变能力。而且流程越复杂，前期成本越高，后期修改越麻烦。

💡 我的建议是：toB 场景下，如果任务流程能清晰地定义下来，优先用 Workflow，别总觉得上 Agent 才显得更智能。稳定可靠，才是 B 端客户真正的第一诉求。

四、架构三：Planner‑Executor‑把 “思考” 和 “干活” 彻底分开 🔖

当任务复杂到需要多步骤规划，且步骤之间有依赖关系，ReAct 边想边做那套就不够用了。这时候该用 Planner‑Executor 架构。

核心思路很简单：把 “想” 和 “做” 分开。

Planner（规划器）：像项目经理，把一个模糊的大目标拆成具体的子任务，排出执行顺序。
Executor（执行器）：像工程师，不负责想全局，只管一步步执行规划好的任务，每完成一步就把结果汇报给 Planner。
循环迭代：Planner 根据执行结果判断计划要不要调整，比如某步失败了得换个方法。这样反复直到任务完成。

拿案例里 “写 3 篇文案” 这个子任务来细化：

Planner 收到指令：”根据销售数据和热点，写 3 篇小红书文案”。它开始规划，输出一个计划：
- 第一步：分析数据，确定主推产品是智能咖啡机。
- 第二步：抓取热点，找跟 “咖啡”、”早晨”、”生活品质” 相关的话题，比如 “早 C 晚 A”” 打工人续命神器 “。
- 第三步：第一个文案角度 —— 从 “早 C 晚 A” 切入，讲咖啡机怎么提升打工人的早晨幸福感。
- 第四步：第二个文案角度 —— 从 “懒人福音” 切入，讲一键制作、自动清洗有多方便。
- 第五步：第三个文案角度 —— 从 “家居美学” 切入，讲咖啡机的高颜值怎么点缀厨房。
- 第六步：调用 text_generation 工具，根据三个角度分别生成三篇文案。
- 第七步：检查文案是否符合小红书风格，比如多用 emoji、有分段标题。
Executor 按顺序执行这七步，每步调用相应工具，把结果返回。

🔹 什么时候用 Planner‑Executor?

任务链条长、步骤多，超过五步且步骤之间有明确依赖关系。
目标比较开放，需要创造性或策略性，比如深度报告、复杂开发、多角度商业分析。
用 ReAct 时 Agent 总是跑偏或失焦。

🔹 Planner‑Executor 的代价

这个架构有成本。规划阶段本身就要消耗额外的 LLM 调用，成本会明显增加。而且如果 Planner 的规划质量不高 —— 比如步骤拆解不合理 —— 整个链条从起点就歪了，后面执行得再细也没用。

💡 我的建议：一般只在**高价值、长链条的场景**里才考虑用 Planner‑Executor。普通简单任务用它，大炮打蚊子，纯属浪费钱。

五、团队协同架构：Multi‑Agent、Supervisor、Swarm 🔖

当任务复杂到需要同时具备多个领域的深度专业能力时，单个 Agent 再加 Planner 可能也扛不住了。比如我们这个案例，如果升级成 “不仅要发社媒，还要同步更新官网、写英文新闻稿、制作介绍视频”，那就得靠一个团队来配合了。

Multi‑Agent（多智能体）要解决的不是规划问题，是专业分工问题。Supervisor（监督者）和 Swarm（蜂群）则是 Multi‑Agent 框架下的两种不同的组织管理方式，决定了这群 Agent 之间怎么协作。

🔹 5.1 架构四：Multi‑Agent —— 组建你的 “AI 专家委员会”

一个典型的 Multi‑Agent 团队，可能会有这样的角色划分：

Planner Agent: 总负责人，总负责，拆解任务、制定计划。
Data‑Analyst Agent: 数据分析专家，只和数据库打交道。
Market‑Researcher Agent: 市场研究员，只负责上网搜集信息。
Copywriter Agent: 文案大师，只写文本。
Designer Agent: 视觉设计师，只调用 AI 绘画工具。
Reviewer Agent: 质检员，对所有产出做最终把关。

Supervisor 模式：中心化的公司架构

这种模式下有一个绝对的领导 —— Supervisor Agent（主管）。像公司部门总监一样，负责接收最终目标、分配任务给下属、跟踪进度、整合所有人的工作成果，对最终质量负责。

其他 Agent 都只是 Worker（员工），听从 Supervisor 指挥，完成自己分内工作并向 Supervisor 汇报。它们之间一般没有横向沟通。

🔹 什么时候用 Supervisor?

任务目标清晰、质量要求严格、需要强管控的场景。
企业内部的标准流程自动化，比如客服工单处理、财务报销审批、金融风险分析。
你想对整个执行过程有最强的掌控力，不希望出现太多意外。

🔹 5.2 Swarm 模式：去中心化的 “开源社区协作”

Swarm 模式完全相反。它没有固定的领导角色。

所有 Agent 都是平等的。控制权和话语权在 Agent 之间动态转移。它们通过一种自主协商的机制来决定下一步该谁接手。

这有点像一个开源社区。一个 Agent 完成工作后，把产出广播出去，并说一句：”我完成了数据分析，现在需要有人接着写文案。”Copywriter Agent 听到这个信号，主动接手任务。

🔹 什么时候用 Swarm?

任务目标比较开放、探索性强，没有固定的最优路径。
需要应对环境的高度动态变化。
创意内容生成（比如让多个不同风格的设计师 Agent 互相激发）、科学研究、开放性的任务竞标系统。

🔹 Multi‑Agent 的巨大代价

无论用 Supervisor 还是 Swarm，引入 Multi‑Agent 的代价都很大：协调成本高、通信开销大、设计复杂度呈指数级上升。上下文传递过程中，很容易因为某个环节被精简或误解，导致信息损耗，影响最终结果。

💡 我给自己定了一条规矩：引入 Multi‑Agent 之前，先问自己一个问题 —— 这个任务，真的非要一个团队才能完成吗？单个 Agent 加一个好的 Planner，真的做不到吗？如果答案是否定的，硬要拆成多个角色协作，只会把系统搞得更脆弱，不会更聪明。

六、总结一下吧：一个实用的决策树 🔖

讲完了这几种架构，我们回到最实际的问题：作为资源有限的 OPC，到底该怎么选？

我通常会按照下面这个决策树，来快速地做判断：

我通常会按照下面这个决策树，来快速地做判断：

第一问：任务的流程，是固定的、可预测的吗？
- 是 → 果断选择 Workflow 模式。这是最稳定、最可靠、最容易向客户解释和交付的方案。
- 否 → 进入第二问。
第二问：任务是否简单，步骤是否很少 (比如 5 步以内)?
- 是 → 使用 ReAct 模式。简单直接，成本最低，能快速搞定。
- 否 → 进入第三问。
第三问：任务是否复杂，需要清晰的、多步骤的规划？
- 是 → 升级到 Planner‑Executor 模式。先规划，再执行，保证不跑偏。
- 否 → (这种情况很少见，通常是需求本身没理清楚，需要回去和客户重新沟通)。
第四问：任务是否需要多个不同领域的、深度的专业知识协同？
- 是 → 谨慎地考虑引入 Multi‑Agent 模式。
- 否 → Planner‑Executor 通常已经足够。
第五问 (如果选择了 Multi‑Agent)：我需要对流程进行强管控，还是鼓励探索和灵活性？
- 强管控 → 选择 Supervisor 模式。
- 灵活性 → 选择 Swarm 模式。

最后，一张我自己整理的架构成熟度与特性对比图，供你参考：

架构模式	复杂度 / 成本	能力上限	可控性	核心解决问题
ReAct	★☆☆☆☆	★★☆☆☆	★★★☆☆	让 AI 学会 “动手”
Workflow	★★☆☆☆	★☆☆☆☆	★★★★★	流程的 “确定性”
Planner‑Executor	★★★☆☆	★★★★☆	★★★★☆	复杂任务的 “规划”
Multi‑Agent (Supervisor)	★★★★☆	★★★★★	★★★★☆	专家的 “分工” 与 “管控”
Multi‑Agent (Swarm)	★★★★★	★★★★★	★★★☆☆	动态环境的 “协作” 与 “适应”

92IT

Just love IT.

每天吃透一个 AI 知识点 ——AI Agent 架构选型指南 6 种主流架构解析