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