面试题 · Agent
请从零开始设计一个大模型智能体（Agent），详细说明其核心组件（如规划、记忆、工具调用、执行等）、工作流程（如任务理解、分解、决策、反馈循环），并阐述关键设计决策背后的考虑因素，包括如何与RAG系统结合以增强知识获取能力。
| 类型 |
|---|
按学习路线查看教程、项目和面试题。
| 作用 |
|---|
| 实现 |
|---|
| 工作记忆 | 当前对话上下文、中间结果 | 上下文窗口直接承载 |
| 短期记忆 | 近期多轮会话摘要 | 滑动窗口+LLM压缩 |
| 长期记忆 | 用户画像、领域知识 | 向量数据库+结构化存储 |
{name, description, parameters}标准化Schema用户输入 → 意图理解 → 任务分解 → 工具选择 → 执行 → 观察 → 判断完成？
↑___________________________________________________________↓
（反馈循环）关键决策点：
不是简单拼接，而是能力融合：
| 层级 | 集成方式 |
|---|---|
| 检索即工具 | RAG作为knowledge_retrieval工具，Agent按需调用 |
| 记忆增强 | 检索结果注入工作记忆，参与推理过程 |
| 主动检索 | 规划阶段识别知识缺口，触发预检索 |
| 双向反馈 | Agent的执行日志回流优化RAG的索引策略 |
设计考量：
| 决策 | 选择 | 原因 |
|---|---|---|
| 规划粒度 | 动态自适应 | 避免过细导致僵化，过粗导致失控 |
| 记忆压缩 | 语义摘要+关键实体提取 | 平衡信息保真与上下文长度 |
| 工具权限 | 分级管控+人工确认阈值 | 安全与效率的折中 |
| RAG触发 | 意图识别驱动，非每轮必检 | 减少延迟，聚焦必要场景 |
建议先掌握大模型基础原理，再学习Agent典型架构（如ReAct、Plan-and-Execute），通过开源项目动手实践，理解各模块协作机制。
场景切入
假设你现在要给一个电商客服系统设计一个智能助手，用户问“帮我查一下上周的订单，顺便跟这周的一起比较下价格”，这种多步任务你怎么让大模型自己去拆解、调用查询工具，还能记住两轮结果？
层层追问
Agent 工作流你了解吧？……那从用户一句话到最终执行，中间会有哪些关键环节？……如果任务复杂，比如要查天气再订机票，你怎么让模型自己规划步骤？……执行中工具报错了，怎么处理？
直球架构
从零设计一个大模型 Agent，要求说清楚规划、记忆、工具调用、执行这四个核心组件怎么分工，工作流程是怎样的，以及怎么跟 RAG 系统结合来增强知识获取能力。
这道题其实是在问，怎么把一个会说漂亮话的大模型，变成一个能自己动手干活的[[智能体]]。说白了，核心就是让模型从被动回答变成主动行动，而设计的关键，是搞清楚什么时候该让模型自己决策，什么时候该给它框死规则。
我先把几个核心组件过一下。规划模块是大脑，负责把用户目标拆成可执行的子任务。这里我倾向动态自适应，不走极端。简单任务比如查个天气，用单步 [[ReAct]] 直接调工具就行，复杂任务比如帮用户规划一个多城市出差行程，我会用 [[Tree-of-Thoughts]] 拆成DAG，子任务之间可能有依赖关系。但真正落地时，我会混着来：先让模型快速尝试ReAct，如果一步搞不定或者工具返回了异常，再触发重规划。这里有个坑，重规划不能太频繁，否则模型会原地打转，我见过一个案例，模型调用航班API返回超时，结果它不重试，反而重新规划出一个完全不同的行程，用户差点订错票。所以我会加一个失败计数器，超过阈值就降级为人工确认。
记忆系统我分成三层。工作记忆就是当前上下文，直接靠窗口承载；短期记忆存最近几轮对话摘要，我用[[滑动窗口]]加LLM压缩，只保留用户意图和关键实体；长期记忆存用户画像和领域知识，用 [[Vector Database]] 加结构化存储。举个例子，一个客服Agent处理退款，工作记忆里是当前订单号，短期记忆记得用户之前抱怨过物流慢，长期记忆知道这个用户是VIP。三层配合，模型才能理解上下文。但这里有个前提：长期记忆的写入时机很重要，不能每轮都写，否则索引会爆炸。我一般只在子任务完成或用户明确反馈后，才触发记忆更新。
工作流程上，就是用户输入进来，先做意图理解，然后任务分解，选工具，执行，观察结果，再判断是否完成。反馈循环里，我最看重反思这一步。每步执行后，模型要显式总结：这一步为什么成功或失败，经验写进长期记忆。比如调用库存查询工具返回了空结果，模型要反思是工具参数传错了，还是商品真的缺货，这个反思结果会直接影响下一次的规划。
再说怎么跟 [[RAG]] 集成。不是简单把RAG当成一个工具就完事了，而是让RAG深度参与推理。我会把知识检索封装成一个标准工具，Agent按需调用，但更关键的是主动检索：在规划阶段，模型如果发现某个子任务需要外部知识，比如用户问一个企业SOP里的合规条款，模型会先触发预检索，把相关文档拉进工作记忆，再开始推理。反过来，Agent的执行日志也会回流优化RAG的索引策略，比如哪个文档被频繁引用但总是答不对，说明索引质量有问题，我会调整 [[Chunk]] 策略或者加 [[重排]]。
这里我其实有个困惑还没完全想透，就是当工具调用链特别长的时候，中间任意一步失败，重规划的成本很高。我目前的做法是给每个子任务设一个最大重试次数，超了就整条链路回滚，但感觉有点粗暴。有没有更好的做法，比如只回滚到失败的前一个依赖节点？
最后说说落地风险。前提是工具的接口定义必须稳定，如果工具经常变，模型学到的调用模式就全废了。我见过一个失败案例，模型学会了调用一个库存查询工具，但后来工具改了参数名，模型还是按旧格式传，结果一直报错，重规划也救不了。所以上线我会特别关注工具的版本管理和接口兼容性。另外，复杂Agent的延迟是个大问题，每次规划都要调LLM，用户等不了。我更倾向把常用路径缓存成模板，命中模板就跳过规划直接执行。总的来说，Agent设计是取舍的艺术，我会把规划粒度看成动态调节的旋钮，根据任务复杂度和环境稳定性来拧。