面试题 · Agent
在构建基于大模型的智能Agent系统时，如何设计和搭建Agent内部各组件（如规划、记忆、工具调用等）之间的连接路径与通信机制？请说明常见的架构模式及其优缺点。
学习内容与项目面试，在同一条路上。
Thought → Action → Observation → Thought → ...Planner生成完整计划 → Executor按序执行 → 根据反馈重规划| 机制 | 场景 | 实现方式 |
|---|---|---|
| 同步调用 | 工具快速返回 | 直接函数调用，阻塞等待 |
| 异步回调 | 工具耗时（如代码执行） | Future/Promise、Celery任务队列 |
| 状态共享 | 跨轮次记忆持久化 | Redis/数据库存储，结构化检索 |
| 事件驱动 | 多Agent协作 | 消息队列（Kafka/RabbitMQ）、Pub-Sub |
关键原则：规划与执行解耦、状态外置化、失败可重试。
场景切入
假设你正在做一个电商客服Agent，用户问“帮我查一下昨天订单”，Agent需要调用订单API，然后可能还需要根据结果追问“您要退款还是改地址”。这个过程中，规划、记忆、工具调用是怎么串起来的？你一般怎么设计它们的连接方式？
层层追问
Agent内部组件你一般怎么划分？……那组件之间怎么通信？如果工具调用要等很久，整个流程怎么处理？……再进一步，有没有考虑过多Agent协作的情况？通信机制又有什么不同？
直球架构
设计一个大模型Agent系统，内部有规划模块、记忆模块、工具调用模块，它们之间的通信机制和连接路径你怎么设计？请列举至少两种架构模式，并说明各自的优缺点和适用场景。
这道题问的是[[Agent]]组件之间的连接和通信，其实本质是在问：你怎么把规划、记忆、工具调用这些模块高效地串起来，让它们协同工作而不是互相打架。
先说架构模式。最基础的就是[[ReAct]]，推理和行动交替进行，每一步先想再干再看结果。这个模式优点是很直观，适合工具少、步骤短的场景，比如一个简单的问答机器人，查个天气、设个提醒，一步就完事。但它的缺点也很明显，就是没有全局视角，任务一长就容易在局部打转，比如让Agent安排一个三天的旅行行程，它可能订完酒店就忘了航班时间。
另一种模式是先规划后执行，就是让一个Planner先生成完整计划，然后Executor按计划执行，中间可以根据反馈调整。这个模式优点是有全局最优，适合多步骤的复杂任务，比如企业里的流程自动化，像处理客户退款，需要先验证订单、再检查库存、然后调用支付接口，最后发通知。但它的风险是计划可能太僵化，一旦某一步失败，回滚成本很高。
实际落地的时候，我不会只用一种模式，而是把它们组合起来。比如做一个客服Agent，处理像'订单异常'这种问题，我会先用一个Planner把流程拆成'查订单状态、看退款政策、执行退款'这几个大步骤，然后每个步骤内部用ReAct模式去具体执行，比如查订单状态可能需要调用多个API，那就用ReAct来动态决定先调哪个。这样既有了全局规划，又保持了局部灵活性。
再来看通信机制。组件之间怎么传消息？同步调用适合工具快速返回的场景，比如查一个简单的数据库；异步回调适合工具耗时的场景，比如调用一个代码执行器，或者等用户确认。还有一种事件驱动的方式，通过消息队列比如Kafka来通信，这在[[Multi-Agent]]场景下特别有用，多个专精Agent可以通过发布订阅来协作。
这里有个坑：状态共享一定要外置化。很多Agent系统失败是因为把所有状态都放在LLM的上下文中，一旦上下文太长或者崩溃，整个状态就丢了。我会用[[向量数据库]]或者Redis来存短期记忆和长期记忆，这样即使Agent重启，也能恢复状态。
选型上，如果是快速验证一个想法，比如做一个POC，我会用ReAct加同步调用，先跑通最小闭环。但如果是生产系统，比如电商平台的智能客服，我会用Plan-and-Execute加异步工具，再加上向量数据库做记忆持久化。对于更复杂的工作流，比如多个Agent协作处理一个跨部门的工单，我会用Multi-Agent架构，加上事件总线，每个Agent只负责自己的领域，比如一个负责库存，一个负责价格，一个负责物流。
最后说说风险。这种系统上线前，我一定会特别关注失败重试和回滚机制。比如计划执行到一半，某个工具调用超时了，怎么处理？常见失败场景是Agent在局部不断重试，或者干脆死循环。我的做法是给每个步骤设置最大重试次数和超时时间，重试失败就触发回滚或者上报给人工。还有一个前提是，工具的接口必须稳定，如果工具本身经常变，那Agent的规划就很容易过时。
其实还有一个有意思的延伸，就是当Agent需要处理[[多模态]]输入时，比如用户发了一张截图，那规划模块怎么和视觉理解组件通信？这个挑战更大，因为时序和空间信息都要融合。
所以整体上，我更倾向于把架构看成一套'规划-执行-反馈'的循环，组件之间通过外置状态和异步消息解耦，这样系统才可控、可观测。