面试题 · Agent
请系统阐述大模型智能体（Agent）的基本工作原理，详细说明其核心组成部分（如规划模块、记忆机制、工具调用和执行反馈）的功能与协同机制，并结合实际场景解释各模块如何共同支持Agent的自主决策与任务执行。
Agent以大模型为中央控制器，通过四大模块形成"感知-规划-执行-反馈"的循环。
职责：任务分解与策略制定
例：用户问"明天北京适合户外吗"，规划为：查天气→分析温度/降雨→给出建议
按学习路线查看教程、项目和面试题。
职责：状态持久化与上下文管理
| 类型 | 功能 | 典型实现 |
|---|---|---|
| 短期记忆 | 当前对话上下文 | 窗口缓存、摘要压缩 |
| 长期记忆 | 用户偏好、历史经验 | 向量数据库存储+检索 |
| 工作记忆 | 任务执行中的中间状态 | 结构化变量/数据库 |
职责：扩展LLM能力边界
职责：闭环优化与错误恢复
用户：帮我订一张下周去上海的最便宜机票
规划 → 拆解：查航班→比价→预订确认
记忆 → 读取：用户常飞航线、座位偏好
工具 → 调用：航班API获取数据，比价工具筛选
反馈 → 确认：价格/时间是否符合预期，失败则换日期重查核心洞察：LLM不直接解决问题，而是调度各模块形成决策闭环，这是Agent区别于简单Prompt工程的本质。
建议从经典Agent架构（如ReAct、Reflexion）入手，理解感知-思考-行动循环，结合RAG与工具调用案例加深对模块协作的理解。
场景切入
假设你做一个智能客服Agent，用户说“帮我查一下上周的订单”，接着又说“那再帮我申请退款”。Agent怎么知道先查订单再退款？它内部是怎么一步步做决策的？能具体说说各模块怎么配合吗？
层层追问
你觉得大模型Agent和普通对话机器人最大的区别是什么？……它怎么自主做任务？……那比如要订机票，它得查航班、比价、下单，这些步骤怎么拆解和执行？……失败了呢？……能不能把背后那套机制讲清楚？
直球架构
系统讲讲大模型Agent的工作原理，包括规划、记忆、工具调用、反馈这几个核心模块。每个模块负责什么，它们之间怎么协同形成闭环，举个具体场景说明。
这道题其实是在问，大模型怎么从对话机器人变成一个能自主干活的[[智能体]]。我的理解是，Agent的核心本质是让LLM做调度中心，通过一个感知-规划-执行-反馈的闭环来解决问题。下面我按模块展开说一下。
先说规划模块。它的任务是把一个复杂目标拆成可执行的步骤。现在主流做法有两种：一种是[[Chain-of-Thought]]，就是让模型一步一步想清楚再回答，适合像数学题这种确定性强的任务；另一种是[[ReAct]]，推理和行动交错进行，想一步做一步，更像人处理动态问题的过程。实际落地时，我通常会把两者结合起来，比如先让模型用CoT做全局分解，然后每个子步骤用ReAct来执行，这样既有方向又能灵活应对变化。举个例子，用户问'明天北京适合户外吗'，规划层会先拆成查天气、分析温度降雨、给建议三个子任务，然后逐个执行。
再来看记忆机制。这里要区分短期记忆和长期记忆。短期记忆就是当前对话的上下文，通常用[[滑动窗口]]或者摘要压缩来管理，保证模型不丢失本轮信息。长期记忆则用来存用户偏好、历史经验这些跨会话的信息，一般用[[Vector Database]]存储和检索。这里有个坑：长期记忆的检索质量直接影响Agent的决策，如果向量召回不准，模型可能会基于错误记忆做规划。所以我会对长期记忆的写入做过滤，只保留高置信度的信息，避免噪声污染。
工具调用这块，本质是扩展LLM的能力边界。模型通过[[Function Calling]]生成结构化参数来调用外部API，比如搜索、计算、数据库查询。工具需要注册成Schema让模型知道怎么用。实际场景中，比如电商客服处理退款，Agent会调用订单查询API获取状态，再调用退款规则引擎判断是否符合条件，最后调用执行接口完成操作。这里有个关键：工具返回的结果不一定是可靠的，所以必须有反馈闭环。
执行反馈就是闭环优化的核心。工具返回的结果作为观察注入上下文，模型根据观察判断是否继续、重试或者换方案。如果调用失败，模型应该能自我修正，比如换个参数重试或者换一个工具。对于高风险操作，比如金融交易，我会在关键节点引入人类确认，确保对齐真实意图。
举个完整的业务场景：用户说'帮我订一张下周去上海的最便宜机票'。规划模块先拆成查航班、比价、预订确认三步。记忆模块读取用户常飞航线、座位偏好这些长期信息。工具调用时，先用航班API获取数据，再用比价工具筛选。反馈模块在生成结果后，如果价格或时间不符合预期，模型会调整日期或航空公司重新查询，直到找到最优方案。
落地时我会特别关注几个前提。一是工具的质量必须稳定，如果API经常超时或者返回错误数据，Agent的整个决策链会崩溃。二是记忆检索的准确性，向量检索的召回率和精确率需要做线上监控，低于阈值要告警。三是规划的可解释性，我会让模型输出每一步的推理过程，方便定位问题。
另外，我觉得有一个方向值得深入：当任务需要多个Agent协作时，比如一个负责搜索、一个负责分析、一个负责执行，怎么设计通信协议和冲突仲裁机制。这涉及到[[Multi-Agent]]系统的设计，目前行业里还在探索阶段。
所以整体上，我更倾向于把Agent看作一个编排框架，而不是让LLM直接解决问题。它的价值在于通过模块化分工和闭环反馈，把LLM的泛化能力和外部工具的精确性结合起来。上线前我会重点测试边界情况，比如工具超时、记忆检索为空、规划步骤过多，确保系统能优雅降级。