Agent 主流架构怎么选?

30 秒回答

1. 能清晰描述ReAct、Plan-and-Execute、Multi-Agent三种主流架构的核心流程
2. 理解Function Calling与Tool Use的技术实现差异
3. 能对比单Agent与Multi-Agent的适用场景
4. 提到记忆模块(Memory)和反思(Reflection)等关键组件

回答与解析

答案要点

• 能清晰描述ReAct、Plan-and-Execute、Multi-Agent三种主流架构的核心流程
• 理解Function Calling与Tool Use的技术实现差异
• 能对比单Agent与Multi-Agent的适用场景
• 提到记忆模块(Memory)和反思(Reflection)等关键组件

当前Agent系统主流架构可分为三类：

1. ReAct架构（推理+行动交替）

核心流程：Thought → Action → Observation → ... → Answer

• 每步先推理当前状态，再决定调用工具或输出
• 优点：容错性强，可根据观察动态调整
• 缺点：步骤多、延迟高，复杂任务效率低
• 代表：LangChain ReAct Agent

2. Plan-and-Execute（规划-执行分离）

核心流程：Planner生成多步计划 → Executor按序/并行执行

• 优点：减少LLM调用次数，执行效率高
• 缺点：计划错误难以中途修正
• 优化：加入Re-planning机制（如LLMCompiler、DSPy）

3. Multi-Agent架构

核心组件：

• Router/调度器：意图识别+Agent分发

• 专用Agent：各垂直领域（如查询、下单、售后）

• 通信机制：消息队列/共享内存

• 优点：模块化、可扩展、并行处理

• 缺点：协调复杂，可能出现循环调用

关键组件对比

选型建议

• 简单任务（单工具查询）：直接Function Calling
• 多步骤推理：ReAct或Plan-and-Execute
• 复杂业务场景（如美团外卖）：Multi-Agent + 意图分层路由

口语版讲法(约4分钟)

• 一句话定位：Agent架构本质是LLM与外部世界的交互模式
• ReAct：思考-行动交替，灵活但慢
• Plan-and-Execute：规划先行，高效但僵
• Multi-Agent：分工协作，复杂但难协调
• 落地选型：按场景混搭，注意记忆和反思

这道题其实是在问LLM怎么跟外部世界交互，核心就两件事：怎么想、怎么动。现在主流的Agent架构，我把它分成三类，但真正落地的时候往往是混着用的。

先说 ReAct 架构，就是推理和行动交替。每一步先想当前状态，再决定调工具还是直接回答，观察结果后再继续。你可以把它理解成一个人在厨房做菜，尝一口咸淡再决定加盐还是加水。它的好处是容错性强，观察不对可以马上调方向。但坏处也很明显，步骤多、延迟高，简单任务来回绕好几轮。所以它适合那种不确定要几步才能搞定的任务，比如客服查订单异常，需要一步步查物流、查库存、查支付状态，每一步都依赖上一步结果。

再一个是 Plan-and-Execute，规划和执行分开。先让LLM生成一个多步计划，然后按顺序或并行执行。这就像做菜前先看菜谱，把步骤全列好，然后一气呵成。好处是LLM调用次数少，执行效率高。但这里有个坑：计划一旦错了，中途很难修正。比如计划第一步查用户信息，第二步查库存，结果第一步查错了人，后面全白干。所以现在很多方案会加Re-planning机制，像 LLMCompiler 或 DSPy，执行中发现异常就重新规划。这个架构适合步骤明确、不太需要中途变卦的场景，比如企业SOP流程，每一步都是固定的。

最后是 Multi-Agent 架构，多个专用Agent分工协作，中间有个调度器做意图识别和分发。比如一个客服系统，拆成订单Agent、售后Agent、退款Agent，每个只负责自己那摊事。优点很明显：模块化、可扩展、可以并行处理。但协调起来很头疼，容易出现循环调用，比如订单Agent让售后Agent查退款，售后又让订单确认状态，两个来回踢皮球。所以Multi-Agent的关键不是Agent本身，而是调度和通信机制，得防死循环、设超时。这种架构最适合复杂业务场景，比如美团外卖，一个订单涉及商家、骑手、用户、优惠券好几个系统，拆成Agent各管一摊，调度器做统一路由。

说到落地，我一般会这么选：简单任务，比如单工具查个天气，直接 Function Calling 就够了，没必要上Agent。多步推理任务，用ReAct或Plan-and-Execute。复杂业务场景，比如客服退款，我倾向用Multi-Agent加意图分层路由，但前提是每个Agent的边界要划清楚，不然协调成本比收益还高。

另外还有几个组件我觉得很关键。一个是记忆模块，短期记忆就是对话历史，长期记忆得用向量库存，不然上下文一长就丢。另一个是反思机制，像 Self-Refine 和 Reflexion，让Agent自己检查结果对不对，错了重来。但反思不是白送的，它多一次LLM调用，延迟和成本都在涨，得看场景值不值得。

其实现在还有一个趋势，就是把Agent和 RAG 结合起来，叫Agentic RAG。Agent负责规划查询策略，RAG负责检索，比单纯用Agent调工具更灵活。但这里有个前提：检索的准确度要高，不然Agent拿到错误信息会越跑越偏。

所以我的整体判断是：没有银弹，只有场景匹配。ReAct灵活但慢，Plan-and-Execute快但僵，Multi-Agent强但复杂。我更倾向根据任务复杂度动态组合，比如简单任务用Function Calling，复杂任务用Plan-and-Execute加Re-planning，再复杂就上Multi-Agent。关键是上线前一定要想清楚边界和失败场景，不然Agent跑起来很容易失控。

关键一句:Agent和RAG结合的趋势，即Agentic RAG，以及检索准确度对Agent效果的关键影响。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你做一个电商客服Agent，用户问完订单状态，又说想退掉其中一件商品——你是让Agent先查单、再判断、再调用退款接口，还是一口气规划好所有步骤？这种场景下你怎么设计Agent的架构？

2. 问法 2 · 层层追问

   你平时怎么让大模型调用外部工具？……那如果任务需要连续调好几个工具呢，比如先查天气再定酒店？……如果中间某一步报错了，整个流程怎么恢复？这就涉及到Agent的主流架构了，你一般了解哪些？

3. 问法 3 · 直球架构

   给我讲讲目前大模型Agent系统的主流架构设计吧。核心组件有哪些？工作流程怎么走？ReAct、Plan-and-Execute、Multi-Agent这三类各自的优缺点和适用场景是什么？