Agent 核心组件架构

30 秒回答

1. 能清晰拆解Agent的四大核心组件（规划、记忆、工具、行动）
2. 理解各组件的交互关系和数据流向
3. 能结合具体范式（如ReAct）说明工作原理
4. 提到多Agent协作或反思机制等进阶设计

回答与解析

答案要点

• 能清晰拆解Agent的四大核心组件（规划、记忆、工具、行动）
• 理解各组件的交互关系和数据流向
• 能结合具体范式（如ReAct）说明工作原理
• 提到多Agent协作或反思机制等进阶设计

AI Agent的核心架构可拆解为四大组件，形成"感知-规划-执行-记忆"的闭环：

1. 规划模块（Planning）

• 功能：将复杂任务拆解为可执行的子步骤
• 原理：基于LLM的推理能力，常用ReAct（Reasoning + Acting）范式，交替进行"思考→行动→观察"
• 进阶：多步规划、反思修正（Self-reflection）、树状搜索（ToT）

2. 记忆系统（Memory）

3. 工具调用（Tools）

• 功能：扩展LLM能力边界（计算、搜索、API操作等）
• 关键机制：Function Calling（模型输出结构化JSON）→ 外部执行 → 结果回传
• 工具描述需清晰定义：功能说明、参数schema、返回值格式

4. 行动执行（Action）

• 将规划结果转化为具体操作，支持多模态输出（文本、代码、文件等）
• 与环境的交互接口，完成闭环反馈

组件交互流程

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

百度场景补充

• 搜索工具可对接百度搜索API，形成"LLM+搜索"的增强模式
• 多Agent架构：调度Agent分发任务，专业Agent各司其职

口语版讲法(约4分钟)

• 一句话定位：这道题问的不是组件罗列，而是LLM怎么在真实环境里落地成闭环系统
• 先给框架：四大组件，感知-规划-执行-记忆的闭环
• 重点拆两个：规划和记忆，讲清楚边界和落地坑
• 举客服退款场景，把工具调用串进去
• 收尾：工程师取舍，给出可延伸点多Agent协作

这道题问的其实不是让我把Agent的组件罗列一遍，它背后真正关心的是，LLM怎么在真实业务环境里落地成一个能稳定工作的闭环系统。我理解核心就四个模块：规划、记忆、工具、行动，它们串成一个“感知-规划-执行-记忆”的循环。

具体说一下。先说规划，也就是把大任务拆成小步骤。现在主流做法是用 ReAct 范式，让模型交替输出“思考”和“行动”。但这里有个坑：不是所有任务都需要复杂规划。简单任务像查个订单状态，一步工具调用就够了，强行多步反而容易让模型绕弯子。真正需要规划的是那种多步骤推理的，比如“用户说买了两件T恤但只收到一件，要查物流、对库存、再算差价”。这时候我会让规划模块先输出一个to-do list，但不会一次全执行，而是走一步看一步，每一步都从环境拿反馈，动态调整。说白了，规划要分层，高层的目标拆解和底层的步骤执行得分开，不能混成一锅粥。

再一个重点是记忆。很多人把记忆简单分成短期和长期，但落地时真正头疼的是工作记忆，也就是中间状态怎么管理。比如客服场景里，用户问“我上周买的手机现在降价了，能退差价吗”，Agent需要记住：用户是谁、订单号、当前价格、历史对话、退款政策。这些信息分散在不同工具调用里，如果工作记忆没管好，模型到后面就忘了前面查到的订单号，重新问一遍，体验就崩了。我的做法是把工作记忆设计成一个结构化的上下文槽位，比如固定几个字段：用户ID、订单ID、当前意图、已执行步骤、中间结果。每次行动完，显式更新这些槽位。长期记忆我用 Vector Database 存历史对话和知识，但有个前提：检索回来的信息必须做 重排，不然混进噪声反而干扰决策。

工具调用这块，说白了就是给LLM装插件。关键机制是 Function Calling，模型输出结构化JSON，我这边解析执行，再把结果塞回上下文。但有个容易忽略的点：工具描述要写得像给新同事看的操作手册，参数名、返回值格式、什么情况会报错，都得写清楚。比如对接搜索API，我会在描述里加一句“如果搜索结果为空，返回空列表”，避免模型瞎猜。

举个具体的业务场景吧。客服退款，用户说“我买了个包，用了个满减券，现在要退，券能退吗”。Agent先调订单查询工具拿到订单详情，发现用了满100减20的券。然后调政策知识库，检索到“券已使用且订单部分退款时，券不退回”。但这里有个风险：政策知识库可能版本旧，或者用户场景特殊（比如商品质量问题导致的退款）。所以我会在上线时特别关注知识库的版本对齐和异常兜底，如果检索结果置信度低，直接转人工，不能让Agent瞎承诺。

最后，整个流程走下来，我更倾向于把Agent看成是一个编排层，核心不是模型多强，而是组件之间的契约和失败处理。比如工具调用超时了怎么办？规划执行到一半用户不耐烦了怎么办？这些在架构设计阶段就得想清楚，而不是等上线再补。

其实还有一个方向我没展开，就是多Agent协作。当业务变复杂，比如一个客服要同时处理退款、物流、商品咨询，单Agent容易上下文爆炸。我会考虑拆成调度Agent和几个专业Agent，调度负责分发，专业Agent各管一摊，但这就引入了通信协议和冲突消解的新问题。这个方向如果面试官感兴趣，我们可以再细聊。

关键一句:多Agent协作是架构升级方向，但会引入通信协议和冲突消解等新问题

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们要做一个智能客服Agent，用户问“帮我查一下订单”，它需要拆解任务、查数据库、再回复。你能说说这个Agent内部应该有哪些核心部件？各自负责什么？

2. 问法 2 · 层层追问

   你觉得一个AI Agent系统需要哪些关键模块才能正常工作？……那这些模块之间怎么协作？……比如用户说“订机票”，从接收到输出，流程是怎样的？

3. 问法 3 · 直球架构

   请直接描述AI Agent的典型架构，包括核心组件、每个组件的功能以及它们之间的交互流程。重点说说规划、记忆、工具这几个模块是怎么配合的。