Agent 框架核心组件怎么搭?

30 秒回答

1. 明确Agent四大核心组件（规划、记忆、工具、执行）的定义与职责
2. 阐述模块间数据流与协作机制（如观察-思考-行动的循环）
3. 说明记忆的分层设计（短期/长期/外部知识）
4. 体现对实际工程权衡的思考（同步vs异步、容错机制）

回答与解析

答案要点

• 明确Agent四大核心组件（规划、记忆、工具、执行）的定义与职责
• 阐述模块间数据流与协作机制（如观察-思考-行动的循环）
• 说明记忆的分层设计（短期/长期/外部知识）
• 体现对实际工程权衡的思考（同步vs异步、容错机制）

核心架构：ReAct范式扩展

智能Agent的本质是**"观察-思考-行动"的闭环系统**，我将其拆解为四个核心模块：

1. 规划模块（Planning）

• 职责：将用户目标拆解为可执行的子任务，选择策略（单步/多步/树状搜索）
• 关键设计：支持Plan-and-Solve（先规划后执行）与ReAct（交错推理）两种模式切换
• 实现要点：利用LLM的CoT能力生成计划，同时预留人工干预接口

2. 记忆模块（Memory）

分层设计解决不同时间尺度的信息需求：

3. 工具调用（Tool Use）

• 统一接口：所有工具遵循OpenAPI规范，描述（description）必须精准
• 动态选择：基于工具描述做语义匹配，而非硬编码路由
• 执行模式：支持串行（依赖关系）与并行（独立工具）两种调度

4. 执行引擎（Execution）

负责状态机管理：

待执行 → 工具调用 → 结果观察 → 判断完成？
   ↑___________________________|

• 异常处理：工具超时/失败时触发重试或备选方案
• 人机协同：置信度低时主动请求确认

模块协作机制

数据流：用户输入 → 记忆检索（相关背景）→ 规划生成 → 工具选择 → 并行/串行执行 → 结果整合 → 记忆更新 → 响应输出

关键循环：执行结果反馈到规划模块，支持动态重规划（如工具结果不符合预期时调整策略）。

口语版讲法(约4分钟)

• 一句话定位：面试官问的是Agent怎么把LLM的思考能力落地成闭环系统
• 规划模块：两种模式的边界，以及为什么落地常混合用
• 记忆模块：分层设计，重点讲工程上的短期记忆压缩和长期记忆的检索
• 工具调用与执行引擎：统一接口、动态选择、异常处理，以及一个具体业务例子
• 风险与取舍：重规划的开销、容错、人机协同，最后抛可延伸点

面试官问Agent框架，我觉得本质上是在问一个问题：你打算怎么把大模型的思考能力，落地成一个能真正干活的闭环系统。不是简单调个API，而是让LLM能自主观察、推理、行动，并且承担后果。

我一般会把Agent拆成四个模块：规划、记忆、工具调用、执行引擎。先说规划。规划的核心是拆解任务，但这里有个边界划分：Plan-and-Solve 和 ReAct 两种模式，到底选哪个？Plan-and-Solve适合任务步骤明确、环境稳定，比如帮用户生成一份周报，先列提纲再逐段写；ReAct更适合动态环境，比如客服场景，用户中途改需求，你得边想边做。真正落地的时候，我很少只用一种，通常是先让模型用 Chain-of-Thought 快速生成一个粗计划，然后进入ReAct循环，每一步执行完都检查是否要调整计划。说白了，规划不是一次性的，它要能动态重规划。

再说记忆。记忆分三层：短期记忆、工作记忆、长期记忆。短期记忆就是当前对话的上下文，我会用滑动窗口加摘要压缩来管理，窗口大小要调，太大浪费token，太小丢失信息。工作记忆存中间结果，比如工具返回的临时数据，我一般用结构化缓存比如Redis，方便快速查询。长期记忆存用户画像、历史经验，用Vector Database加实体关系图。这里有个坑：长期记忆的检索如果太慢，会拖死整个Agent。所以上线前我会特别关注检索延迟和召回率，通常用Hybrid Search把关键词和向量结合起来，不然纯向量检索在冷门实体上容易丢。

工具调用和执行引擎我放一起说。工具这块，关键是统一接口，所有工具按OpenAPI规范描述，description要写精准，因为LLM靠它选工具，写模糊了就会乱调。执行引擎是个状态机，从待执行到工具调用到结果观察，再判断是否继续。举个例子，在电商客服场景里，用户问'我的退款怎么还没到'。Agent先规划：查订单状态、查退款进度、查支付渠道。然后并行调用工具：订单查询、退款查询、支付系统接口。如果退款查询超时了，执行引擎要能自动重试或走备选方案，比如直接调支付渠道的接口。这个异常处理是上线最容易被忽视的，工具调用失败是常态，不处理好Agent就卡死了。

说到重规划，这里有个延伸点：当工具返回的结果和预期偏差很大时，是让模型重新规划好，还是直接回退到人工？我倾向于设定一个置信度阈值，低于阈值就主动请求确认。这个阈值怎么定，需要根据业务场景调，比如金融风控场景阈值设得很高，宁可多问一次。

所以整体来看，我更倾向于把Agent看成一个有容错能力的半自主系统，不是全自动。前提是你得把每个模块的失败场景都想到，不然上线就是灾难。

关键一句:工具返回结果与预期偏差大时，是重新规划还是回退到人工，取决于置信度阈值和业务场景

面试官还可能这样问

1. 问法 1 · 场景切入

   我看你做过智能客服。假设用户说'帮我查一下上个月的订单'，Agent 需要先查用户信息，再查订单，如果订单多还得筛选。你怎么设计这个流程，让 Agent 能一步步拆解并调用不同工具？

2. 问法 2 · 层层追问

   你设计过 Agent 吗？大概有哪些模块？……那规划和执行怎么配合？如果中间某步工具调用失败，整个流程怎么处理？

3. 问法 3 · 直球架构

   设计一个智能 Agent 框架，核心组件包括规划、记忆、工具调用和执行。你讲讲每个组件的职责，以及它们之间怎么协作完成一个任务？