面试题 · Agent
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请介绍当前大模型Agent系统的主流架构设计，包括核心组件、工作流程以及不同架构方案的优缺点比较。
当前Agent系统主流架构可分为三类：
核心流程：Thought → Action → Observation → ... → Answer
按学习路线查看教程、项目和面试题。
核心流程：Planner生成多步计划 → Executor按序/并行执行
核心组件：
Router/调度器：意图识别+Agent分发
专用Agent：各垂直领域（如查询、下单、售后）
通信机制：消息队列/共享内存
优点：模块化、可扩展、并行处理
缺点：协调复杂，可能出现循环调用
| 组件 | 作用 | 典型方案 |
|---|---|---|
| Memory | 上下文持久化 | 短期(对话历史)、长期(向量库) |
| Tool Calling | 外部能力扩展 | OpenAI Function Calling、Toolformer |
| Reflection | 自我纠错 | Self-Refine、Reflexion |
场景切入
假设你做一个电商客服Agent，用户问完订单状态，又说想退掉其中一件商品——你是让Agent先查单、再判断、再调用退款接口，还是一口气规划好所有步骤？这种场景下你怎么设计Agent的架构？
层层追问
你平时怎么让大模型调用外部工具？……那如果任务需要连续调好几个工具呢，比如先查天气再定酒店？……如果中间某一步报错了，整个流程怎么恢复？这就涉及到Agent的主流架构了，你一般了解哪些？
直球架构
给我讲讲目前大模型Agent系统的主流架构设计吧。核心组件有哪些？工作流程怎么走？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跑起来很容易失控。