Agent 面试题
高频问题地图
- 什么是 Agent？它和普通 LLM 调用有什么区别？
- Agent 的基本架构由哪些核心组件组成？
- Workflow、Agent、Tools 三者有什么区别？
- ReAct、Plan-and-Execute、Reflection 有什么区别？
- 复杂任务为什么要拆分？
- Agent 记忆机制如何设计？
- Single-Agent 和 Multi-Agent 如何选型？
- Multi-Agent 如何协作和动态切换？
- Agent 为什么需要 Evaluation？
核心概念速记
Agent：以 LLM 为推理核心，通过工具调用与外部环境交互，自主完成任务的系统。与普通 LLM 调用的区别在于 Agent 有感知-决策-行动的循环，能根据中间结果调整策略。
Tool：Agent 可调用的外部能力，如数据库查询、文件读写、API 调用。Tool 让 Agent 从"只能生成文本"变成"能执行实际操作"。
Memory：Agent 维护上下文的机制，包括短期记忆（当前对话）、中期记忆（可检索的历史会话）、长期记忆（提炼后的稳定知识）。
Planner：负责把复杂任务拆解为可执行步骤的模块。Plan-and-Execute 模式中 Planner 和 Executor 分离。
Executor：负责执行具体步骤、调用工具、产出结果的模块。
Reflection：Agent 对自身输出进行自我检查和修正的机制，可以提升输出质量。
Multi-Agent：多个 Agent 协作完成复杂任务的架构模式，常见角色包括 Coordinator、Worker、Reviewer。
Q1：什么是 Agent？它和普通 LLM 调用有什么区别？
标准回答
Agent 是以大语言模型为推理核心，通过工具调用与外部环境交互，自主完成任务的系统。它不是一个单次的请求-响应模型，而是一个具备感知、决策、行动能力的运行时循环。
普通 LLM 调用是"一问一答"：用户输入一段文本，模型返回一段文本，调用结束。模型没有能力去查询数据库、读写文件、调用 API，也没有能力根据中间结果决定下一步该做什么。
Agent 在此基础上引入了三个关键能力。第一是工具调用：Agent 可以在推理过程中决定调用哪些外部工具，并根据工具返回的结果继续推理。第二是状态管理：Agent 能维护对话历史和任务上下文，支持多轮交互和长任务执行。第三是自主决策：Agent 能根据当前状态动态选择下一步行动，而不是按预设流程走。这让 Agent 能处理那些需要多步推理、动态判断、外部交互的复杂任务。
面试官追问
- Agent 的自主决策能力是模型自带的，还是工程设计出来的？
- 如果 LLM 调用已经能通过 Function Calling 调用工具，为什么还需要 Agent 这个概念？
- Agent 的边界在哪里？什么场景不适合用 Agent？
工程化理解
从工程角度看，Agent 是一个包含 LLM 推理循环、工具注册表、状态管理、权限控制的完整运行时。普通 LLM 调用只需要一个 API 请求，而 Agent 需要设计工具注册、工具结果结构化、上下文窗口管理、循环终止条件、超时机制、错误重试等工程模块。Agent 的复杂度不在于单次 LLM 调用，而在于如何把多个 LLM 调用和工具调用编排成一个可靠的执行链路。
常见误区
- 把 Agent 等同于"带 System Prompt 的 LLM 调用"：没有工具、没有状态管理、没有自主决策循环，就不是 Agent。
- 认为 Agent 能完全自主完成任何任务：Agent 的能力边界取决于工具集和模型能力，超出范围的任务仍然需要人工介入。
- 忽略 Agent 的工程成本：Agent 比普通 LLM 调用多出状态管理、工具编排、错误处理等复杂度，不是所有场景都值得用 Agent。
背诵版总结
Agent 是以 LLM 为推理核心、具备工具调用和自主决策能力的运行时系统。和普通 LLM 调用的区别在于：Agent 有感知-决策-行动的循环，能维护状态、调用工具、根据中间结果调整策略。普通 LLM 调用是"一问一答"，Agent 是"多步推理 + 工具交互"。Agent 的工程复杂度主要在工具编排、状态管理和执行链路的可靠性保障上。
Q2：Agent 的基本架构由哪些核心组件组成？
标准回答
一个完整的 Agent 运行时通常包含以下核心组件：
推理核心是 LLM 本身，负责理解任务、生成计划、决定下一步行动。工具注册表管理 Agent 可以调用的所有外部工具，每个工具定义了名称、描述、参数 schema 和执行函数。状态管理器维护对话历史、任务上下文、中间结果等运行时状态。记忆系统分为短期记忆（当前会话上下文）、中期记忆（可检索的历史会话）、长期记忆（提炼后的持久化知识）。规划器负责把复杂任务拆解为可执行的步骤序列。执行器负责按计划调用工具、产出结果。评估器对 Agent 的输出进行质量检查，判断是否需要重试或修正。
这些组件不是每个 Agent 都必须全部具备，但缺少关键组件会限制 Agent 的能力范围。比如没有工具注册表，Agent 就只能生成文本；没有状态管理，就无法支持多轮交互和长任务。
面试官追问
- 这些组件是逻辑划分还是代码模块？实际代码中怎么组织？
- 规划器和执行器是分离好，还是合一好？有什么权衡？
- 记忆系统用什么存储？Redis、向量数据库、还是文件？
工程化理解
实际工程中，这些组件的边界并不总是清晰的。推理核心和规划器往往合并在同一个 LLM 调用中，通过 Prompt 引导模型同时完成理解和规划。工具注册表通常是一个 JSON Schema 列表，注册到 LLM 的 Function Calling 参数中。状态管理需要考虑上下文窗口溢出时的压缩策略。记忆系统短期记忆存在会话内存中，中期记忆用向量数据库存储和检索，长期记忆可能需要定期提炼和固化。这些工程决策直接影响 Agent 的性能和可靠性。
常见误区
- 把组件画成方框图就认为理解了架构：面试时要能讲清楚每个组件的具体实现方式和工程挑战。
- 认为所有 Agent 都需要完整的七组件架构：简单的单轮工具调用 Agent 可能只需要推理核心和工具注册表。
- 忽略组件之间的通信成本：组件越多，数据传递和状态同步的开销越大。
背诵版总结
Agent 核心组件包括：推理核心（LLM）、工具注册表、状态管理、记忆系统、规划器、执行器、评估器。不是每个 Agent 都需要全部组件，但推理核心和工具注册表是基本要求。工程实现中，这些组件的边界是灵活的，关键在于如何平衡功能完整性和系统复杂度。
Q3：Workflow、Agent、Tools 三者有什么区别？
标准回答
这三者代表了不同层次的抽象。
Tools 是最底层的能力单元。一个 Tool 就是一个可被调用的函数或服务，定义了输入、输出和执行逻辑。Tool 本身没有决策能力，只负责执行具体操作，比如查询数据库、调用外部 API、读写文件。
Workflow 是预定义的执行流程。开发者在设计时就确定了步骤顺序和分支条件，运行时按固定路径执行。Workflow 适合流程明确、不需要动态判断的场景。比如"用户提交工单 → 查询知识库 → 生成回复 → 发送邮件"就是一个典型 Workflow。
Agent 是动态决策系统。Agent 在运行时根据当前状态和中间结果，自主决定下一步调用哪个 Tool、是否继续执行、是否需要调整策略。Agent 的执行路径不是预先定义的，而是由 LLM 在每一步推理时动态决定的。
核心区别在于决策权的归属。Workflow 的决策权在开发者（设计时确定），Agent 的决策权在 LLM（运行时确定），Tool 没有决策权（只执行）。
面试官追问
- 实际项目中，Workflow 和 Agent 的边界在哪里？有没有"半 Agent"的情况？
- 如果一个任务 90% 的步骤是固定的，只有 10% 需要动态判断，应该用 Workflow 还是 Agent？
- Tool 的粒度怎么设计？太粗和太细各有什么问题？
工程化理解
实际项目中，Workflow 和 Agent 往往混合使用。主流程用 Workflow 控制关键步骤的顺序和依赖，在需要动态判断的环节嵌入 Agent 节点。这样既保证了流程的可控性和可预测性，又保留了 Agent 的灵活性。Tool 的粒度设计是一个关键工程决策：太粗的 Tool 会导致模型难以理解其用途，太细的 Tool 会导致调用链路过长、延迟增加。通常一个 Tool 对应一个原子操作，但也要考虑上下文连贯性。
常见误区
- 把 Agent 当作 Workflow 的升级版：两者解决不同问题，Agent 不是"更智能的 Workflow"，而是"需要动态决策的场景"。
- 认为 Agent 一定比 Workflow 好：如果流程固定，Workflow 更可控、更可预测、更易调试。
- Tool 设计过粗或过细：Tool 的描述和参数 schema 直接影响 LLM 的调用质量。
背诵版总结
Tool 是原子能力，没有决策权；Workflow 是预定义流程，决策权在开发者；Agent 是动态决策系统，决策权在 LLM。三者的核心区别是决策权归属。实际项目中通常混合使用：Workflow 控制主流程，Agent 处理动态判断环节，Tool 提供原子操作能力。
Q4：ReAct、Plan-and-Execute、Reflection 有什么区别？
标准回答
这三种模式代表了 Agent 的不同推理策略。
ReAct（Reasoning + Acting）是最基础的 Agent 推理模式。Agent 在每一步先进行推理（Thought），决定下一步行动（Action），执行后观察结果（Observation），然后进入下一轮循环。ReAct 的特点是"边想边做"，每一步都基于最新观察做出决策，适合步骤不确定、需要根据中间结果灵活调整的场景。
Plan-and-Execute 是先规划后执行的模式。Planner 先把任务拆解为完整的步骤计划，然后 Executor 按计划逐步执行。如果执行过程中发现计划不可行，可以回到 Planner 重新规划。这种模式适合任务结构明确、需要全局视角的场景，因为先规划可以避免"走一步看一步"导致的低效路径。
Reflection 是在 Agent 输出后增加自我检查的机制。Agent 对自己的输出进行审视，判断是否满足质量要求，如果不够好就修正后重新输出。Reflection 可以叠加在 ReAct 或 Plan-and-Execute 之上，作为质量保障层。
面试官追问
- ReAct 每一步都要调用 LLM，延迟和成本怎么控制？
- Plan-and-Execute 的计划如果一开始就错了，执行阶段怎么发现和修正？
- Reflection 会不会导致无限循环？怎么设计终止条件？
工程化理解
ReAct 的工程挑战在于循环终止条件和 token 消耗控制。每一轮 Thought-Action-Observation 都是一次 LLM 调用加一次工具调用，需要设置最大轮数和超时机制。Plan-and-Execute 的关键在于计划的质量评估和动态修正机制，执行器需要在每步完成后检查计划是否仍然有效。Reflection 的工程难点在于如何定义"质量足够好"的标准，以及如何防止无意义的反复修改。通常设置最大重试次数，并用明确的评估标准判断是否通过。
常见误区
- 认为 ReAct 就是"Chain-of-Thought + 工具调用"：ReAct 是一个完整的推理循环，不是单次思考。
- 认为 Plan-and-Execute 一定比 ReAct 好：如果任务本身不确定，过早规划反而是浪费。
- 忽略 Reflection 的成本：每次反思都是一次额外的 LLM 调用，需要权衡质量提升和成本增加。
背诵版总结
ReAct 是"边想边做"的推理循环，适合步骤不确定的场景。Plan-and-Execute 是"先规划后执行"，适合需要全局视角的任务。Reflection 是"输出后自我检查"，可以叠加在其他模式上提升质量。三种模式的核心区别是推理策略：ReAct 逐步决策，Plan-and-Execute 全局规划，Reflection 质量修正。工程实现中需要关注循环终止、成本控制和质量评估。
Q5：为什么复杂任务需要拆分？任务拆分有什么工程价值？
标准回答
复杂任务需要拆分的核心原因是 LLM 的上下文窗口和推理能力有边界。当任务包含多个步骤、涉及多个领域、需要调用多种工具时，把所有信息塞进一个 Prompt 会导致模型无法有效处理。任务拆分把一个大问题分解为多个小问题，每个小问题的输入更聚焦、上下文更精简、工具调用更明确。
任务拆分有三个工程价值。第一是可控性：每个子任务有明确的输入、输出和成功标准，可以独立验证和调试。第二是可复用性：拆分后的子任务可以在不同场景中复用，避免重复实现。第三是容错性：单个子任务失败时可以重试或降级，不会导致整个任务失败。
从工程角度看，任务拆分还带来了并行执行的可能性。如果子任务之间没有依赖关系，可以并发执行，显著减少总执行时间。同时，拆分后的子任务更容易做 Trace 记录和效果评估，方便定位问题和优化。
面试官追问
- 任务拆分是 LLM 自己做，还是开发者预先设计？两者各有什么优缺点？
- 拆分粒度怎么确定？拆得太细会不会引入额外的协调成本？
- 子任务之间的依赖关系怎么管理？有环依赖怎么办？
工程化理解
任务拆分在工程中有两种模式。一种是静态拆分：开发者在设计时就确定了任务的分解方式和执行顺序，适合流程明确的场景。另一种是动态拆分：由 LLM 在运行时根据任务内容自行拆解，适合任务内容不确定的场景。静态拆分更可控但灵活性差，动态拆分更灵活但可靠性需要额外保障。实际项目中通常混合使用：核心流程静态拆分，关键判断点动态拆分。
常见误区
- 认为拆分越多越好：每个子任务都有 LLM 调用开销和状态传递成本，过度拆分反而增加延迟和复杂度。
- 忽略子任务之间的上下文传递：拆分后需要设计上下文传递机制，否则子任务之间信息断裂。
- 不设计失败处理策略：子任务失败是常态，需要设计重试、降级、人工介入等处理机制。
背诵版总结
复杂任务拆分的核心原因是 LLM 的上下文窗口和推理能力有边界。工程价值在于可控性（独立验证）、可复用性（跨场景复用）和容错性（局部失败可重试）。拆分模式分静态拆分（开发者设计）和动态拆分（LLM 运行时拆解），实际项目通常混合使用。关键权衡是拆分粒度：太粗失去灵活性，太细增加协调成本。