完整题目
请介绍当前大模型Agent系统的主流架构设计，包括核心组件、工作流程以及不同架构方案的优缺点比较。
本文目录
答案要点
- 能清晰描述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：各垂直领域（如查询、下单、售后）
-
通信机制：消息队列/共享内存
-
优点：模块化、可扩展、并行处理
-
缺点：协调复杂，可能出现循环调用
关键组件对比
| 组件 | 作用 | 典型方案 |
|---|---|---|
| Memory | 上下文持久化 | 短期(对话历史)、长期(向量库) |
| Tool Calling | 外部能力扩展 | OpenAI Function Calling、Toolformer |
| Reflection | 自我纠错 | Self-Refine、Reflexion |
选型建议
- 简单任务（单工具查询）：直接Function Calling
- 多步骤推理：ReAct或Plan-and-Execute
- 复杂业务场景（如美团外卖）：Multi-Agent + 意图分层路由
换一种问法，检查是否真正理解
场景切入
假设你做一个电商客服Agent，用户问完订单状态，又说想退掉其中一件商品——你是让Agent先查单、再判断、再调用退款接口，还是一口气规划好所有步骤？这种场景下你怎么设计Agent的架构？
层层追问
你平时怎么让大模型调用外部工具？……那如果任务需要连续调好几个工具呢，比如先查天气再定酒店？……如果中间某一步报错了，整个流程怎么恢复？这就涉及到Agent的主流架构了，你一般了解哪些？
直球架构
给我讲讲目前大模型Agent系统的主流架构设计吧。核心组件有哪些？工作流程怎么走？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拿到错误信息会越跑越偏。