跳到正文

Agent 规划记忆工具分工

规划、记忆、工具调用间的数据流和责任边界

原题:请描述AI Agent系统的核心组件及其功能

Agent · 百度真题

30 秒回答

  1. 明确Agent四大核心组件(规划、记忆、工具、行动)及其功能
  2. 能区分短期记忆与长期记忆
  3. 理解ReAct等推理-行动循环机制
  4. 说明工具调用的实现方式(Function Calling)

回答与解析

答案要点

  • 明确Agent四大核心组件(规划、记忆、工具、行动)及其功能
  • 能区分短期记忆与长期记忆
  • 理解ReAct等推理-行动循环机制
  • 说明工具调用的实现方式(Function Calling)
  • 提及多Agent协作场景

AI Agent系统的核心架构可拆解为四大组件

1. 规划模块(Planning)

  • 将复杂任务拆解为可执行的子步骤
  • 常用方案:CoT(思维链)、ReAct(推理+行动交替)、ToT(树状搜索)
  • 关键能力:自我反思、错误修正、动态调整计划

2. 记忆模块(Memory)

类型 作用 实现方式
短期记忆 当前对话上下文 系统Prompt + 多轮对话历史
长期记忆 跨会话知识积累 向量数据库存储 + RAG检索

3. 工具模块(Tools)

  • 扩展LLM能力边界:计算器、搜索引擎、API调用、代码执行器等
  • 核心机制:Function Calling,模型输出结构化JSON决定调用哪个工具
  • 工具描述需包含:功能说明、参数Schema、返回值格式

4. 行动模块(Action)

  • 执行规划结果,调用工具并获取反馈
  • 形成观察→推理→行动的闭环循环
  • 支持多轮迭代直到任务完成或达到终止条件

系统工作流程

用户输入 → 规划拆解 → 检索记忆 → 选择工具 → 执行行动 → 观察结果 → (循环或结束)

实际落地中,多Agent协作是进阶方向,通过角色分工(如规划Agent、执行Agent、反思Agent)提升复杂任务成功率。

口语版讲法(约4分钟)

  • 一句话定位:Agent本质是让LLM从对话走向自主决策
  • 四大组件:规划、记忆、工具、行动
  • 边界划分:短期记忆与长期记忆,单Agent与多Agent
  • 业务场景与风险:客服退款场景,工具调用失败与幻觉
  • 工程师取舍:我更看重规划与工具的闭环,多Agent是进阶

这道题其实是在问,当我们说一个系统是AI Agent时,它到底比普通聊天机器人多了什么。我的理解是,Agent的核心是把大模型从被动的问答角色,变成了一个能主动拆解目标、调用外部资源、并自我纠错的决策执行体。它的架构我一般拆成四个组件:规划、记忆、工具、行动,但真正落地时这四个不是孤立的,而是通过一个循环串起来的。

先说规划。规划模块负责把用户的一个模糊目标,比如“帮我处理一笔退款”,拆成可执行的子步骤。常见做法有Chain-of-Thought,就是让模型一步步想;还有ReAct,推理和行动交替进行,每走一步看结果再决定下一步。这里有个边界要划清:CoT适合纯推理任务,比如数学题;但一旦涉及外部操作,比如查订单、调API,ReAct更靠谱,因为它每步都能观察反馈。实际落地时,我通常把两者结合,先CoT做整体规划,再ReAct执行每一步,这样既保证逻辑连贯,又允许动态调整。

然后是记忆。记忆分两种:短期记忆就是当前对话的上下文,靠System Prompt和多轮历史维护;长期记忆是跨会话的知识积累,比如用户的历史偏好或者企业政策,我一般用Vector Database加RAG来存和检索。这里有个常见的坑:很多人以为长期记忆只存事实就好,但其实要区分知识类型。比如客服场景,退款规则是静态知识,适合向量检索;但用户的历史行为是动态的,更适合用结构化数据库。所以真正落地时,我倾向于 混合记忆,短期靠Prompt,长期按类型选存储,而不是一刀切用向量库。

工具模块是Agent能力的放大器。大模型本身不会算数、不会查库存,所以通过Function Calling让模型输出结构化JSON来调用外部工具,比如计算器、搜索引擎、API。这里的关键是工具描述要写清楚:功能说明、参数Schema、返回值格式。我踩过一个坑:工具描述太模糊,模型会瞎调用,比如用户问“订单状态”,它去调了退款API。所以上线前我会特别关注 工具描述的精准度,并且加一层校验,防止模型幻觉导致错误调用。

行动模块就是执行规划的每一步,调用工具、拿回结果,然后形成“观察→推理→行动”的循环。这个循环不是一次性的,而是多轮迭代,直到任务完成或达到终止条件。比如客服退款场景:用户说“我买的东西没收到”,Agent先规划出查物流、查订单、判断责任、执行退款四步;然后第一步调物流API,发现显示已签收,那就需要推理矛盾,再调订单详情确认地址,最后决定是否升级人工。这个过程中,如果某步失败,比如API超时,Agent要能自我反思,重新规划或报错,而不是卡死。

讲到这,其实有个延伸点值得提:多Agent协作。单Agent在复杂任务里容易出幻觉或者规划死循环,所以业界开始用角色分工,比如一个规划Agent拆任务,一个执行Agent调工具,一个反思Agent检查结果。但多Agent的通信开销和一致性控制是新的挑战,不是所有场景都适合。我目前更倾向于在单Agent内把规划和工具闭环做扎实,再考虑多Agent,因为很多失败其实是基础组件没做好。

所以我的总结是:Agent不是简单的组件堆叠,而是 规划-记忆-工具-行动 的闭环设计。我会把重点放在规划与工具的闭环上,因为这是Agent区别于聊天机器人的本质。记忆和行动更多是支撑,但做不好同样会崩。真要上线,我会先确保工具调用的准确率,再优化规划的灵活性,否则空有规划但执行不了,就是画饼。

关键一句:多Agent协作是进阶方向,但单Agent闭环没做好时不要盲目上多Agent,否则通信和一致性问题会放大失败。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个智能客服Agent,用户问“帮我查订单”,Agent需要先查数据库再回复。你觉得这个Agent系统里应该包含哪些核心模块?每个负责什么?

  2. 问法 2 · 层层追问

    如果要做一个能自主完成任务的AI Agent,你觉得它需要具备哪些能力?……那这些能力怎么拆成具体的组件?……比如它得能记住之前聊了什么,这个记忆怎么实现?

  3. 问法 3 · 直球架构

    请描述一个AI Agent系统的核心组件,包括规划、记忆、工具、行动,并分别说明它们的功能和典型实现方式。

同模块相关题目