跳到主要内容

92-Agent面试题精讲：Agent篇

前言​

什么是 Agent？与大模型有什么本质不同？​

我理解Agent本质上是一个能自主完成目标的AI系统，跟传统AI最核心的区别在于「自主性」和「能行动」。

传统AI是你问一个问题它回答一个问题，每次都是独立的，被动响应

而Agent有自己的规划能力，你给它一个复杂目标，它会自己把任务拆成多步，通过调工具、访问记忆、感知环境来一步步执行，直到完成。

Agent 的基本架构由哪些核心组件构成？​

我理解Agent的基本架构有四个核心组件:LLM、工具、记忆、规划模块。

LLM是整个系统的大脑，负责理解任务和做决策

工具让Agent能跟外部世界交互，搜索、执行代码、调API都靠它

记忆让Agent在任务执行过程中保持状态，不会失忆

规划模块负责把复杂目标拆解成可执行的步骤。

这四个组合在一起，才让Agent具备了自主完成任务的能力。

Workflow，Agent，Tools 这三个的概念和区别介绍一下？​

我理解这三个概念是粒度从小到大的三层结构。

Tools是最小的能力单元，就是封装好的可调用函数，比如搜索、执行代码、发邮件，它只负责「执行」，本身没有任何决策能力。

Agent是一个完整的决策系统，内部用LLM做大脑，自己判断什么时候调哪个Tool、要不要继续、什么时候结束，是主动的。

Workflow是更上层的编排框架，是开发者预先定义执行路径，把Agent、LLM、Tools组织成一条确定性流程，每个节点做什么、按什么顺序流转都是开发者事先写死的。

三者最核心的区别就一句话:Tools不做决策只执行，Agent自己做决策，Workflow是开发者替所有节点把决策提前写好。

了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？​

我理解Agent和Workflow最核心的区别是「谁来决定下一步」。

Workflow是开发者预先定义执行路径，每一步怎么走都是固定的，确定性高、好控制

Agent是让LLM自己决定下一步做什么，灵活但不可控。

常见的设计范式除了纯 Agent 之外, 还有 ReAct、 Plan-and-Execute、Reflection 这几种。

我在实际工程里用得最多的反而是把两者混用，固定流程的部分用Workflow，需要灵活决策的节点嵌入Agent能力，这样既保住了整体可控，又有局部的灵活性。

范式核心思想适用场景
ReAct思考 → 行动 → 观察 → 再思考通用 Tool Calling Agent
Plan-and-Execute先制定完整计划，再逐步执行复杂、多步骤任务
Reflection / Self-ReflectionAgent 自我检查、反思并修正代码生成、内容生成
Agentic RAGAgent 动态决定检索什么、是否继续检索、使用什么检索策略复杂知识库问答

Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？​

Agent的推理模式我用过几种。

最基础的是直接输出答案，没有中间推理;CoT是让LLM先把推理过程写出来再给答案，准确率更高;ReAct是在CoT基础上加了「行动」，让LLM交替输出思考和工具调用，每次行动后再根据结果继续思考，形成一个循环。

我觉得ReAct是目前Agent用得最广的模式，因为它推理过程可见，又能动态利用外部工具，两个优点都有。

ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？​

我理解这三者是Agent开发里最主流的三种设计范式，核心区别在于「决策和执行的关系」。

ReAct是边想边干，走一步看一步，单步迭代实时调整，灵活度最高

Plan-and-Execute是先想全再干，先定完整计划再分步执行，适合长流程复杂任务，不容易跑偏

Reflection不是独立的完整流程，而是给前两者加的「检查修正buff」，用来提升输出质量。

实际选型就看三个维度:任务复杂度、流程确定性、输出质量要求，新手入门首选ReAct，复杂任务用Plan-and-Execute,高要求场景再加 Reflection。

复杂任务怎么做的任务拆分？为什么要拆分？效果如何提升？​

我理解任务拆分的原因是LLM一次性处理太复杂的任务很容易出错，把大任务拆成小步骤，每步聚焦一件事，准确率会明显提升。

拆分方式主要有两种:一种是静态拆分，提前把步骤写死;另一种是动态拆分，让LLM自己根据目标规划步骤，更灵活但也更难控制。

拆完之后步骤之间可能有依赖关系，我的经验是把能并行的步骤并发跑，端到端延迟可以降很多，有时能降40%到60%。

请你介绍一下 AI Agent 的记忆机制，并说明在实际开发中应该如何设计记忆模块？​

Agent需要记忆才能在多步任务中保持状态、跨任务积累知识。

记忆机制分四层：感知记忆(当前输入的原始内容)、短期记忆(contextwindow里的对话历史)、长期记忆(存在外部数据库、语义检索召回)、实体记忆(结构化提取的关键事实，如用户偏好什么的)。

实际设计时要解决三个核心问题:存什么、怎么存、什么时候取出来用，根据信息类型选合适的存储方式，再搭配主动检索和按需检索两种策略使用。

Agent 的长短期记忆系统怎么做的？记忆是怎么存的？粒度是多少？怎么用的？​

我理解记忆系统分两层。

短期记忆就是context window 里的对话历史，存当前任务的中间状态，任务结束就清掉

长期记忆用向量数据库存，把信息总结后写入，用的时候做语义检索拿回来注入提示词中。

粒度上我通常按「一次完整交互」或「一个关键事件」为单位存，太细碎检索噪音大，太粗糙又丢失细节，这个需要根据业务实际调整。

什么是 Multi-Agent？​

多智能体系统(Multi-Agent)就是多个Agent 协作完成任务，每个Agent 各有分工，有的负责搜索、有的负责写代码、有的负责做评审。

好处：

  • 决策准确率更高、token 消耗更低：每个 Agent 只带必要的最少prompt，没有冗余信息干扰，虽然调用 LLM 次数多了，但更省 token、决策更准、更稳定
  • 并行思考和任务处理：主管分派任务，子 Agent 并行处理，整体效率更高
  • 多角色互相讨论，纠错能力更强：多 Agent 有不同角色，可以互相监督、互相纠错，比单个 Agent 自己反思更靠谱，复杂任务表现更强

Multi-Agent通过专业分工和并行执行，能处理更复杂、更长流程的任务，这是我在实际项目里选择多智能体方案的核心原因。

说说 Single-Agent 和 Multi-Agent 的设计方案？​

Single-Agent适合任务流程清晰、复杂度适中的场景，实现简单、好维护

Multi-Agent适合需要专业分工、任务量大或者需要并行执行的复杂场景。

Multi-Agent 架构上主要有两种拓扑:中心化的Orchestrator 模式，由一个主Agent统一调度各个Worker;去中心化的Peer-to-Peer模式，Agent之间直接通信。

我在工程里用中心化用得更多，因为好控制、好调试，出问题链路清晰。

Agent 记忆压缩通常有哪些方法？​

记忆压缩常见有四种方法:摘要压缩、滑动窗口、重要性过滤、结构化抽取。

摘要压缩是把长对话总结成简短摘要

滑动窗口是只保留最近N轮对话

重要性过滤是打分筛选，只留重要内容

结构化抽取是把关键信息抽成结构化数据存起来。

我在实际项目里最常用的是摘要压缩和滑动窗口，而且经常组合用，滑动窗口丢弃前先做一次摘要，尽量不丢重要信息。

在工程实践中，为什么有时候选择「手搓」Agent，而不是直接用成熟框架？​

我的感受是框架用起来快，但有几个实际痛点。

第一是抽象层太多，调试的时候不知道哪步出了问题，得一层层往下扒;第二是版本升级经常有破坏性变更，线上稳定性难保证;第三是框架的通用设计往往和具体业务需求有偏差，定制起来反而更费劲。

手搓的代码完全在自己掌控之内，可观测性好、出问题好排查，也更方便做性能优化。

所以我现在的策略是核心逻辑手写，只在边缘功能上用框架的工具。

如何赋予 LLM 规划能力？​

给LLM加规划能力主要靠这几种思路。

  • CoT是让LLM把推理步骤写出来，线性地一步步推导到答案
  • ToT是让它同时探索多条推理路径，选最优的继续深入
  • GoT是图结构推理，推理节点可以复用和合并，适合更复杂的任务。

工程上我用CoT最多，因为实现成本最低，就是改个prompt;ToT效果更好但调用次数多，成本大概是3到5倍;GoT目前还比较学术，生产环境我没见过有人真正落地使用

讲讲 Agent 的反思机制？为什么要用反思？具体怎么实现？​

反思机制我的理解是:让Agent在完成一个步骤或整个任务后，自我评估输出质量，判断有没有问题，如果有问题就重试或调整策略。

用反思的原因是LLM第一次输出不一定是最优的，加一轮自我检查能显著提升质量，相当于人写完东西自己再看一遍。

代价是至少多一次LLM调用，token消耗和延迟都会增加，所以我在工程里通常只在质量要求高的关键节点启用反思，不是每步都做。

如何设计多 Agent 的协作与动态切换机制？​

协作靠两件事:消息传递和共享状态。消息传递是Agent完成自己的工作后把结果发出去，下一个Agent取用;共享状态是所有Agent共同读写一个状态对象，记录任务进展和中间结果。

动态切换靠Orchestrator来做，有两种方式:一种是静态路由，提前写好规则「任务类型A就找AgentX」;另一种是让LLM动态决策，根据当前情况实时判断该把任务交给谁。

我的实践是两种混用，主流程用静态路由保证稳定，边缘情况才交给LLM动态判断。

标签：