去年下半年到今年上半年，开沿陆陆续续接了十几个企业 AI Agent 项目，从制造业 ERP 旁边挂的「单据自动审核 Agent」，到一家连锁零售总部的「门店巡店 + 销售复盘 + 库存预警」三合一 Agent 矩阵，规模跨度很大。每接一个项目，客户技术负责人几乎都会在第一次评审会上问同一个问题：「我们这个场景，到底是用一个 ReAct Agent 搞定，还是要拆成多 Agent？要不要上 LangGraph？是不是该直接走 Coze？」
这个问题没法一句话回答。AI Agent 架构选错的代价，比传统软件选错框架更高——传统框架选错最多是重构一次，Agent 架构选错往往意味着 prompt、工具集、记忆层、评测集全部要重做，而且训练出的「这个 Agent 在什么场景下会失效」的隐性知识全部清零。本文把目前业内主流的 5 种 Agent 架构范式拆开讲，配上我们在真实项目里踩到的坑，最后给一张决策表，希望能帮工程师和架构师少走一些弯路。
一、AI Agent 架构的 5 种主流范式
如果把 2024-2026 年所有公开能查到的 Agent 框架和论文抽象一下，会发现绝大多数 Agent 系统都落在下面 5 个范式里。它们不是互斥的，一个复杂系统里往往同时存在 2-3 种，但选「主架构」时还是要二选一。
| 范式 | 核心思想 | 典型代表 | 适合任务长度 |
|---|---|---|---|
| 单 Agent ReAct | 思考-行动-观察循环 | 早期 LangChain Agent、OpenAI Function Calling Loop | 3-10 步内 |
| Plan-Execute | 先规划完整步骤再逐步执行 | BabyAGI、Plan-and-Solve 论文系派生 | 10-50 步 |
| Multi-Agent 协作 | 多个角色 Agent 互相沟通 | AutoGen、CrewAI、MetaGPT | 不确定步数、需角色分工 |
| Workflow 编排 | 人工预定义 DAG，AI 填空 | n8n+LLM、Dify Workflow、Coze 工作流 | 确定性流程 |
| Hierarchical | 上层调度 Agent 管下层执行 Agent | LangGraph 子图、Anthropic Computer Use 多层架构 | 企业级长期运行 |
后面我们一个一个拆。提前透露一个结论：开沿现在交付的企业项目里，单 Agent ReAct 和 Workflow 编排合起来占大约 70%，Multi-Agent 占大约 15%，Plan-Execute 和 Hierarchical 合起来不到 15%。这个比例和很多自媒体描绘的「Multi-Agent 是未来」并不一样，原因在后面几节会展开。
二、单 Agent ReAct：何时该用、什么场景会失效
ReAct（Reason + Act）是最早被广泛使用的 Agent 架构，逻辑非常直白：模型在每一轮决定「下一步是思考还是调用工具」，调用完工具拿到结果再决定下一步，循环到给出最终答案为止。
ReAct 的好处是实现简单、调试相对友好——你只需要一个 LLM、一组 Function Calling 工具、一个循环控制器，三百行代码就能跑起来。我们给一家化工厂做的「危化品台账查询 + 出库审批助手」用的就是 ReAct，整个 Agent 只有 7 个工具，平均一轮对话 3-5 步内结束，效果稳定到可以直接上生产。
但 ReAct 有几个明显的失效场景：
- 任务步数超过 10 步：模型上下文会开始忘记早期的目标，出现「走着走着忘了为什么走」的情况
- 任务存在并行子任务：ReAct 是严格串行的，让它处理「同时查询 5 个系统的数据再汇总」会很别扭
- 任务需要回滚：ReAct 没有原生的「撤销前面几步」的机制，出错只能整轮重来
- 多人协作的工单类场景：ReAct 默认单线程，遇到「等待另一个人审批后再继续」会卡住
我们去年有一个项目，最初按 ReAct 实现了一个「采购询价 Agent」，跑通了 demo 之后客户提需求说「要能同时给 5 家供应商发询价邮件、等他们回邮件再汇总」，这个需求就完全打破了 ReAct 的假设。后来重构成 Workflow + 短链 ReAct 子节点的混合架构才解决，多耗了将近 3 周。所以选 ReAct 之前，建议先做一份 AI Agent 落地前置自检清单，把任务的步数、并行度、回滚需求摸清楚。
三、Plan-Execute：长任务的鲁棒性更高
Plan-Execute 的核心改动是把「思考」和「执行」分成两个阶段：先让一个 Planner 模型把整个任务拆成一个有序的步骤列表，然后由 Executor 逐步执行，遇到失败时回到 Planner 重新规划。
这个范式适合任务步数较多、且步骤之间有较强逻辑依赖的场景。比如我们做过一个「年度财务报表自动汇总」的内部工具，需要从 6 个不同系统拉数据、做 12 种交叉校验、生成 4 张图表、最后写一份 5 页的总结。用 ReAct 跑过一次，跑到第 18 步就开始重复同样的查询动作，明显是上下文压力下的「兜圈子」。换成 Plan-Execute 后，整体任务完成率从 60% 出头提升到稳定的 90% 以上。
Plan-Execute 的代价是对模型推理能力的要求显著更高。Planner 阶段需要模型能在没有外部信息的前提下，做出一份还算靠谱的步骤拆解——这件事弱模型干不了，国内开源 13B 级别的模型几乎跑不下来。所以选 Plan-Execute 的时候，要先在 国产 LLM 企业级横评 里挑准模型。
另一个常被忽视的点是「Plan 重生成」的策略。如果每一步失败都重新生成完整 Plan，成本会爆炸；如果只在「关键路径失败」时才重生成 Plan，又需要事先定义什么是「关键路径」。我们的经验是：Plan 拆出 5-15 步最舒服，少于 5 步用 ReAct 即可，多于 15 步要先做 Hierarchical 切分。
四、Multi-Agent 协作：分工很美好，调试很骨感
Multi-Agent 这两年是热度最高的范式，AutoGen、CrewAI、MetaGPT 各种框架层出不穷。核心思想是把不同认知风格的子任务交给不同角色的 Agent，让它们通过消息互相协作——研究员、写作者、批评者、执行者各司其职。
| 维度 | 单 Agent ReAct | Multi-Agent 协作 |
|---|---|---|
| 单轮 token 消耗 | 1× | 通常 3-8× |
| 调试可观察性 | 较好，单一推理链 | 较差，需追踪跨 Agent 消息 |
| 角色专业化 | 弱，全靠 prompt | 强，每个 Agent 独立 prompt+工具 |
| 失败模式 | 单点失效 | 死锁、循环对话、责任漂移 |
| 适合任务 | 中短链路、流程明确 | 创造性任务、需要多视角对抗 |
Multi-Agent 真正发挥威力的场景，是**「任务本身就需要不同视角的对抗或互补」**——比如写一份调研报告需要「检索员-写作者-事实核查员-编辑」四种角色，或者做代码评审需要「实现者-评审员-测试编写者」三种角色。在这些场景里，硬塞进一个 Agent 用 prompt 切换角色，效果远不如让多个 Agent 独立思考再对话。
但是！Multi-Agent 的调试成本陡升，这是很多团队没估算的。我们在一个内容运营项目里上过 4-Agent 协作，第一次跑通后客户问「为什么这次输出比上次差？」我们花了将近 2 天时间才定位到是「批评者 Agent 这次过早妥协」，而且这种问题没法用传统日志看出来——它藏在多轮对话的「氛围」里。后来我们给所有 Multi-Agent 项目都加了一层完整的 企业级权限审计 风格的对话回放机制，调试效率才回到能接受的水平。
中小企业上 Multi-Agent 之前，强烈建议先用单 Agent 跑一遍 baseline。如果单 Agent baseline 跑得通 70%，再考虑要不要为剩下 30% 的提升付出 5 倍的调试成本。
五、Workflow 编排：确定性 + AI 灵活性的折中
Workflow 编排其实不算「严格意义上的 Agent」——它的主体是一个由人工设计的 DAG（有向无环图），AI 只在某些节点里发挥作用。代表产品是 Dify Workflow、Coze 工作流、n8n+LLM、以及钉钉 AI 助理里的工作流模式。
我个人很喜欢这个范式，它解决了一个 ReAct/Plan-Execute/Multi-Agent 都没解决好的问题：「业务部门看得懂、IT 改得动、合规审得过」。把流程图画在白板上，每个节点写明「这里是 LLM 提取意图」「这里是查数据库」「这里是人工审批」，所有人都能对齐预期。
我们交付的项目里有一类典型场景是「客户咨询自动应答」，最初用 ReAct Agent 做，发现客户最大的诉求其实不是「Agent 多聪明」，而是「Agent 不要在不该回答的时候乱回答」。最后改成 Workflow：意图识别节点→分流节点→不同类型走不同子流程→关键节点强制走人工审批。整体灵活度不如 ReAct，但客户的安全感提升了一个数量级。这部分实操可以对照 AI 工作流自动化案例 一起看。
Workflow 的局限性也很明显：
- 新增节点要改图：每次业务变化都要工程师介入，敏捷性不如纯 Agent
- 节点之间的状态传递容易碎片化：一个 30 节点的 Workflow，调试起来不比 Multi-Agent 轻松
- 不适合「探索性任务」：探索性任务的路径事先无法预知，硬编码 DAG 会丢掉灵活性
所以我们现在的默认推荐是：先 Workflow 兜住主干流程，再在某些「需要灵活推理」的节点里嵌一个短链 ReAct Agent——这套混合范式覆盖了开沿超过一半的项目。
六、Hierarchical：大型企业 Agent 系统的组织模式
当一家公司内部的 Agent 数量超过 10 个，分散在销售、客服、采购、HR、IT 等多个部门时，Hierarchical（层级式）架构开始变得有意义。
Hierarchical 的核心是：最上层有一个调度 Agent（或路由 Agent），它不直接做业务，而是判断用户请求该转给哪一个下层业务 Agent。下层业务 Agent 内部可以是 ReAct、可以是 Plan-Execute、可以是 Workflow，互不影响。这种架构在大型企业里几乎是必然演化方向——就像公司组织架构从扁平变成多层，Agent 系统也会。
| 层级 | 职责 | 推荐范式 |
|---|---|---|
| 入口层 | 意图识别、路由、安全过滤 | 轻量 Workflow + 短链 ReAct |
| 领域层 | 销售、客服、HR 等领域内主流程 | Workflow 或 Plan-Execute |
| 工具层 | 具体业务动作（建单、查询、推送） | 纯 Function Calling，不需要 Agent |
| 治理层 | 权限、审计、合规、成本控制 | 旁挂式监控，不参与业务推理 |
Hierarchical 落地最大的难点不是技术，而是组织协同。上层调度 Agent 和下层业务 Agent 通常由不同团队维护，接口约定、版本兼容、故障责任怎么划分都会成为问题。我们建议 Hierarchical 上线前，先做一次 AI Agent 落地路线图 级别的全局梳理，把哪些 Agent 上层哪些下层、谁负责什么先约定清楚。
中小企业有没有必要直接上 Hierarchical？答案通常是「先别」。一个只有 3 个 Agent 的系统硬塞调度层，相当于给两个人的团队配一个总监——成本远超收益。
七、五种范式横评：一张表看清开发成本与扩展性
把上面五种范式放在一起做横评，可以得到一张比较直观的对比表。下面的评分是 1-5 分（5 为最好），基于开沿过去一年多在 20+ 个项目里的真实交付经验，仅供参考。
| 范式 | 开发成本 | 调试难度 | 容错性 | 扩展性 | 合规可控性 |
|---|---|---|---|---|---|
| 单 Agent ReAct | 5 易 | 4 较易 | 2 弱 | 2 弱 | 3 中 |
| Plan-Execute | 3 中 | 3 中 | 4 较强 | 3 中 | 3 中 |
| Multi-Agent 协作 | 2 难 | 1 很难 | 3 中 | 4 较强 | 2 较弱 |
| Workflow 编排 | 4 较易 | 4 较易 | 5 强 | 3 中 | 5 强 |
| Hierarchical | 2 难 | 2 较难 | 4 较强 | 5 强 | 4 较强 |
几个值得展开的点：
第一，合规可控性这一栏，Workflow 拿了满分。原因很简单：监管和审计都更喜欢「能在白板上画清楚的流程」，纯 Agent 的「让它自己决定」在合规审视下天然吃亏。涉及个人信息、医疗、金融等强监管场景的项目，我们几乎一定会上 Workflow 主干，可以参考 企业 AI 合规与 PIPL 里的合规要点。
第二，Multi-Agent 在调试难度上只有 1 分，这个分数不是夸张。一个 4-Agent 系统的可能交互路径数是指数级的，单纯靠日志几乎不可能完整复现一次失败。我们后来给所有 Multi-Agent 项目都强制要求「对话回放 + 关键节点 LLM-as-Judge 评分」两套机制，否则不上线。
第三，ReAct 的扩展性只有 2 分——不是说 ReAct 不能加工具，而是工具数量超过 15 个之后，模型选错工具的概率会显著上升。这个时候要么换成 Hierarchical 路由，要么换成 Plan-Execute 让模型先规划再调用。
八、决策表：按场景选范式
讲了五种范式的优缺点，最实用的还是「我这个场景该选哪个」。下面是开沿内部用的决策表，已经在十几个项目里验证过，可以直接当模板用。
| 业务场景特征 | 推荐主架构 | 辅助选项 |
|---|---|---|
| 单一目标、3-5 步搞定、用户能等结果 | 单 Agent ReAct | 配 3-7 个 Function Calling 工具 |
| 流程明确、合规要求高、要给业务方看流程图 | Workflow 编排 | 关键节点嵌短链 ReAct |
| 任务步数 10+ 步、步骤间强依赖、可一次跑完 | Plan-Execute | 每 5 步做一次断点，可重启 |
| 需要不同视角对抗（写作+审核、研究+批评） | Multi-Agent 协作 | 必须配对话回放工具 |
| 全公司多个部门都要 Agent、内部已有 5+ Agent | Hierarchical | 下层各自选 ReAct/Workflow |
| 不确定，先做 MVP | Workflow 编排 + 单 Agent ReAct | 验证后再演化 |
| 任务存在长时间等待（人工审批、第三方回调） | Workflow 编排 | 不要用纯 Agent |
| 用户预期「秒回」的对话场景 | 单 Agent ReAct | 控制工具数 <8 |
一个常被问的问题是：「能不能在一个系统里混用？」 答案是肯定的，而且这是我们最推荐的做法。开沿最近交付的一套销售运营 Agent 系统，主干是 Workflow（处理 80% 的标准化流程），高层调度是轻量 Hierarchical 路由器，研究类节点嵌入了 Multi-Agent 的写作-审核对，对话类节点用 ReAct。混搭范式在团队具备相应能力后，是性价比最高的选择。
九、AI Coding 让架构落地的真实路径
讲完范式选择，绕不开一个现实问题：这些架构怎么真正写出来？
两年前做一个 Multi-Agent 系统，光是设计消息协议、写状态机、做对话回放工具，就要一个高级工程师投入 4-6 周。今天，借助 AI Coding（Claude Code、Cursor、Codex 等工具），同样的工作量可以压缩到 1-2 周。这不是夸张——我们最近一个 Hierarchical + Workflow 混合架构的项目，三个工程师配合 AI Coding 工具，6 周完成了过去预计 12 周的工作量。这背后的方法论我们在 AI Coding 怎么交付软件 里展开讲过，也建议看下 AI Coding 与团队业务知识断层，避免一上来就掉进「AI 写得快但是不懂业务」的坑。
具体到 Agent 架构落地，我们的内部实践是把 Agent 架构本身拆成几个可复用的模板：单 Agent ReAct 模板、Plan-Execute 模板、Workflow 节点模板、Multi-Agent 对话框架模板，全部沉淀到 AI Coding 团队技能库 里。新项目启动时，从模板出发改写，比从零写要快得多。
最后给一个架构自检清单，决定范式前一定要走完：
- 任务平均步数有多少？分布是什么？长尾在哪里？
- 是否存在并行子任务？是否需要回滚？
- 业务方需不需要「看得懂流程」？合规要求严不严？
- 单次任务允许多少 token 预算？延迟容忍度？
- 失败后是否要从中间步骤恢复？还是接受整体重跑？
- 这个 Agent 的工具数会不会在未来半年膨胀到 15+？
- 未来 12 个月公司内部会不会出现其他 Agent 需要协同？
把这 7 个问题答清楚，再回头看本文的决策表，范式选择会变得很顺畅。
结语
AI Agent 架构没有「最好」的选择，只有「最匹配业务约束」的选择。我们见过太多团队因为「想用最酷的架构」而选了 Multi-Agent，最后陷在调试成本里出不来；也见过保守团队因为「先用最简单的」而停在了 ReAct，错过了适合上 Plan-Execute 的长任务机会。
理性的做法是承认：架构是一种「以约束换效率」的工具。ReAct 用简单约束换实现速度，Workflow 用结构约束换合规可控，Multi-Agent 用协作约束换创造性输出，Hierarchical 用层级约束换组织扩展。先想清楚约束，再选范式，最后让 AI Coding 帮你把架构真正写出来——这条路径，我们走了一年多，至少在企业 Agent 项目上是行得通的。
希望本文的决策表和自检清单，能帮你在下一次架构评审会上少争论 2 小时。
