面试问题Agent面试题满分回答Agent 的核心组件有哪些满分回答我认为一个生产级的完整Agent包含五大核心组件推理引擎、工具集、记忆系统、规划模块和执行控制五个缺一不可少一个就只能叫带工具的 LLM或者固定 workflow算不上完整的 Agent。第一推理引擎LLM。负责理解目标和做决策。看 prompt目标 历史 工具列表→ 决定下一步做什么 → 输出 action 或者最终答案。不直接干活。关键点说明核心职责理解目标、制定计划、选择行动、反思结果输入Prompt 目标 历史上下文 工具列表输出下一步 Action调用哪个工具传什么参数或 最终答案关键原则不直接干活——只做决策具体的执行交给工具性能瓶颈推理质量直接决定 Agent 上限。同样的架构GPT-4 和弱模型跑出来的效果可以差好几个数量级第二规划模块Planner。规划负责把用户目标翻译成可执行步骤序列。它的核心职责不是写流水账而是将模糊目标比如‘帮我调研竞品动态’转化为带依赖关系的DAG子任务。依赖关系清晰是线性执行还是可以并行需要一个 DAG 而不只是 list这里的关键是‘粒度控制’——子任务必须足够大以节省Token又足够小以便验证。更重要的是支持 replan计划中途失效时能局部调整不必全部推翻重来遇到执行失败时只修枝不砍树。关键点说明核心职责把模糊的用户目标翻译成可执行的子步骤序列输出形式DAG有向无环图而非简单的 List——显式标明哪些步骤可并行、哪些有依赖关系粒度控制关键子任务要“足够大以节省 Token又足够小以便验证”——太细了依赖爆炸、累计误差大太粗了执行器不知道怎么动动态重规划计划中途失效时局部调整只修枝不砍树不必全部推翻重来。一失败就整体 replan 是常见的反模式Token 成本扛不住第三执行模块(Executor)。把这些串起来负责调度、反馈处理和终止判断。它把规划好的DAG放进状态机里跑负责工具调用的参数绑定和返回值解析。执行控制最大的价值在于异常分级处理——网络超时它自己重试搜索无结果它尝试换词只有遇到逻辑死锁或连续3次失败它才触发全局重规划或请求人工介入。同时它内置步数熔断器杜绝死循环。关键点说明核心职责把 Planner 输出的 DAG 放进状态机里跑调度工具调用、处理反馈、判断是否完成参数绑定维护工作记忆Working Memory负责工具间的变量传递如 A 的输出{temp:26}自动注入 B 的入参异常分级处理核心价值①L1 瞬态错误网络超时→ 静默重试指数退避最多 2-3 次②L2 数据异常搜索无结果→ 换同义关键词再试③L3 逻辑死锁/连续失败→ 触发局部/全局 Replan④L4 高危操作→ Human-in-the-Loop 审批终止判定三重保险①硬上限max_steps、max_tokens、超时②LLM 自判每 N 步问一次“进展如何”③外部 Verifier用规则或另一个模型验证输出是否满足目标三个任意一个触发就结束不能只靠 LLM 自己说 finish第四工具模块(Tools)工具让 Agent 真正能做事而不只是说事。工具的几个设计要点描述要精准LLM 靠描述来选工具描述模糊就选错数量要控制超过 20 个工具时LLM 的选择准确率会明显下降大量工具建议分组或层级管理输出要可解析工具返回值要结构化方便 LLM 读懂 observation常见工具分类搜索类网络搜索、数据库查询、计算类计算器、代码执行、操作类文件读写、API 调用、消息发送关键点说明核心职责让 Agent 能真正“做事”而不只是“说事”——搜索、计算、API 调用、文件读写等描述要精准最关键LLM 完全靠描述来选工具。反面get_data: 获取数据正面search_flight: 当用户需要查询航班时使用参数包含出发地、目的地、日期返回航班号、价格列表数量控制超过20 个工具时LLM 的选择准确率会明显下降分组/层级管理解法先让 LLM 选“工具分类”再从分类里选具体工具把大问题变成两步小问题。工具数量极大时还可做工具检索向量化工具描述按需检索返回值结构化工具返回值要结构化JSON方便 LLM 读懂 Observation第五记忆模块(Memory)。维护上下文连贯性——短期放 context window长期放向量库。特别注意的是执行过程中的工作记忆比如上一步的API返回结果必须由Executor显式维护不能全塞给LLM的Context Window否则成本爆炸。关键点说明短期记忆当前 Context Window 中的内容存放本次对话或任务的上下文有容量限制一般 8K~128K tokens工作记忆Executor 维护执行过程中的中间状态、工具调用的参数和返回值、步骤间传递的数据——这部分不能全塞给 Context Window否则成本爆炸长期记忆向量数据库存的历史经验、知识文档用语义检索按需拉取窗口溢出处理①摘要压缩把早期对话压缩成一段话②向量化存储按需检索最相关的几条③ 两者可结合使用遗忘机制长期运行需加重要性评分访问频率 × 时效性衰减 × 任务相关度低分记录定期压缩或删除防止向量库被噪声塞满这五个组件缺失任何一个都只能叫‘带插件的聊天机器人’。规划负责想清楚‘做什么’执行负责保证‘做得稳’推理引擎负责‘怎么做好’三者在闭环循环Plan→Execute→Observe→Reflect中缺一不可。加分项高平追问一、规划与执行模块深度追问Q1ReAct 和 Plan-and-Execute 的本质区别是什么什么时候用哪个回答要点ReActReasoning Acting是“边想边做”——每走一步先思考Thought再行动Action拿到观察结果Observation后继续下一轮。它的核心价值在于让模型能基于中间结果动态调整后续动作把“静态提示词”升级成“可迭代决策过程”。Plan-and-Execute 是“先想好再做”——规划模块先输出完整任务 DAG执行模块按图依次或并行执行。选型原则任务步骤少≤5步、依赖简单→ ReAct 足够延迟低、实现简单任务步骤多、依赖复杂、需要并行→ Plan-and-ExecutePlanner 用强模型出框架Executor 用弱模型跑动作成本可降低 40%~60%面试加分句“ReAct 适合‘探索型’任务不知道几步能做完Plan-and-Execute 适合‘确定型’任务步骤边界清晰”Q2规划和执行控制可以合并吗小任务可以。ReAct 就是典型的“边规划边执行”没有独立的规划模块。但任务复杂度上来之后分离规划和执行效果更好——Planner 用强模型Executor 可以用弱模型省成本。【你已有的回答】Q3Plan-and-Execute 模式下Planner 和 Executor 用什么模型为什么回答要点Planner 用强模型GPT-4、Claude 3.5 Sonnet负责全局拆解和依赖分析对推理能力要求高Executor 可以用弱模型GPT-3.5、Llama-3、Qwen 轻量版工具调用遵循严格的 OpenAPI Schema只需要“按图执行 参数绑定”不需要强推理面试加分句“这种设计叫‘异构模型编排’——把推理密集型任务和执行密集型任务解耦是生产级 Agent 降本的核心手段”Q4Planner 输出的规划粒度怎么控制太细或太粗分别有什么问题回答要点太细如“抬起右手→握紧刀柄→向前移动 5cm”LLM 每步都要决策累计误差爆炸Token 成本扛不住太粗如“做好饭”Executor 不知道怎么执行正确粒度“可验证的原子任务”——每个子任务有明确的输入、输出和成功标准如“调用搜索 API 获取今日天气”面试加分句“判断粒度是否合适有一个标准——这个子任务能不能用 1-2 个工具调用完成如果需要 3 个以上说明粒度太粗还需要再拆”二、工具调用与管理Q5工具多了怎么管分组管理或层级管理。比如先让 LLM 选“工具分类”再从分类里选具体工具把大问题变成两步小问题。工具数目极多的情况下还可以做工具检索把工具描述做向量化按需检索相关工具。【你已有的回答】Q6Function Calling 到底是怎么工作的能不能说清楚完整链路这是面试官区分“看过概念”和“真正做过”的经典题。回答要点完整链路 5 步定义工具开发者把工具的名称、描述、参数 JSON Schema 传给模型模型推理模型根据用户输入判断是否需要调用工具返回意图如果需要模型返回结构化的工具调用意图工具名 参数程序执行业务系统先做参数校验再真正执行工具结果回传工具返回值结构化后传回模型进入下一轮关键澄清很多人会答错Function Calling 是“模型告诉你该调哪个工具、传什么参数”不是模型自己去执行。真正执行的是你的后端程序。Q7工具描述tool description为什么非常重要回答要点模型完全靠描述来选工具——描述模糊 选错工具好的描述应该包含何时用、何时不用、参数含义、错误示例、返回格式反面案例get_data: 获取数据→ 模型不知道是获取什么数据、从哪获取、什么格式正面案例search_flight: 当用户需要查询航班信息时使用参数包括出发城市、到达城市、日期返回航班号、价格、起飞时间列表面试加分句“工具描述本质上是在给 LLM 写‘API 使用说明书’说明书写得越清楚模型用错的概率越低”Q8工具调用的常见工程坑有哪些回答要点来自真实工程踩坑描述模糊→ 模型选错工具参数类型错乱→ 模型传参格式不对权限缺失→ 工具能调但没权限执行无降级方案→ 工具挂了整个 Agent 崩溃不可观测→ 不知道工具调用耗时、失败率连环调用打爆下游→ Agent 在循环里疯狂调 API越权访问→ 模型调了不该调的工具返回值非结构化→ LLM 读不懂工具返回了什么三、记忆系统Q9记忆超出上下文窗口怎么处理两种策略①摘要压缩把早期对话摘要成一段话压缩掉细节②向量化存储把历史存到向量库每步按需检索最相关的几条两者可以结合用。【你已有的回答】Q10上下文管理不只是“窗口满了怎么办”——上下文问题有哪几种这是面试官觉得你“有深度”的关键题。回答要点拆成 4 种问题窗口容量不够要塞的东西太多窗口爆了 → 解法摘要压缩、向量检索关键信息被淹没Lost in the Middle窗口没爆但模型忘了中间的重要信息 → 解法关键信息放开头或结尾、定期提醒工具返回撑爆上下文工具返回 5000 token80% 是噪声 → 解法工具返回值只取关键字段多步推理上下文膨胀每步的 Thought Action Observation 都留着越滚越大 → 解法压缩历史推理步骤Q11Memory 用向量库就够了吗回答要点不够。向量检索擅长“相似度匹配”但弱于“精确约束”和“多跳关系推理”工程上常见方案向量库 关键词检索 结构化库 知识图谱按需组合同时维护元数据和权限面试加分句“向量库适合‘模糊检索’如‘找类似的问题’但如果是‘精确查询’如‘订单号 ORD-2024-001 的状态’需要先用关键词或结构化索引精确命中再用向量做语义补充”Q12长期记忆的写入和遗忘机制怎么设计回答要点写入任务结束后异步写入不阻塞主链路遗忘用重要性评分 访问频率 × 时效性衰减 × 任务相关度低分记录定期压缩或删除避免向量库无限膨胀面试加分句“记忆系统如果不加遗忘机制长期运行后向量库会塞满噪声检索召回率反而下降——这不是存储问题是检索信噪比问题”四、容错与失败处理Q13Agent 的失败处理策略是什么分四级单步失败 → 重试最多 2-3 次反复失败 → 局部 replan方向性错误 → 整体 replanreplan 还不行 → Human-in-the-Loop。一失败就整体 replan 是常见的反模式token 成本根本扛不住。【你已有的回答】Q14工具调用失败了怎么办—— 更细致的追问这是面试官最常追着问的“工程落地题”。回答要点分层处理指数退避重试失败后等 1s、2s、4s 再试最多 3 次重试前让 LLM 反思“刚才哪里错了是不是参数不对要不要换一个工具”——这叫Self-Correction自我修正重试耗尽后降级换一个备用工具或走规则引擎写操作必须做幂等 Checkpoint失败后能回滚到上一个干净状态Q15LLM 幻觉Hallucination怎么处理回答要点幻觉比工具失败更难检测因为没有报错信号策略一Self-Consistency对关键推理结果采样 3 次少数服从多数策略二交叉验证用第二个模型做 Fact-check策略三高风险操作强制 HITL不管模型多确定写操作必须过人工确认Q16Human-in-the-LoopHITL的插入点怎么设计回答要点三种插入范式条件边中断、Tool 节点拦截、状态机断点判断标准信息检索类任务搜索、摘要失效率 2%状态变更类操作取消订单、修改配置、发送通知失效率 8%~15%设计原则低风险任务全自动高风险操作在执行前插入人工审核节点面试加分句“HITL 不是给 AI 加枷锁是让 AI 值得被信任——在 AI 跑偏之前先把它拽回来”五、终止与评估Q17如何判断 Agent 是否完成了任务三重保险硬上限max_steps、max_tokens、超时 LLM 自判每 N 步问一次“进展如何” 外部 verifier用规则或另一个模型验证输出是否满足原始目标。三个任意一个触发就结束不能只靠 LLM 自己说 finish。【你已有的回答】Q18终止条件具体有哪些能不能说全回答要点组合使用模型主动声明 finish任务清单全部完成Executor 维护的 DAG 所有节点 done达到步数上限max_steps达到 Token 预算上限超时连续无进展检测连续 N 步没有实质进展外部成功信号如测试通过、API 返回成功码生产环境必须有硬上限防止死循环——不能只靠 LLM 自己说 finishQ19怎么评估 Agent 的好坏有哪些指标回答要点任务成功率最主要完成目标的比例平均步数完成任务平均需要多少步Token 消耗单次任务平均消耗多少 Token直接对应成本工具调用准确率选对工具的比例工具失败率工具调用报错的比例幻觉拦截率被第二个模型或人工拦截的错误输出比例平均响应延迟面试加分句“生产上我会为每个 Agent 实例暴露健康度指标——工具失败率、幻觉拦截率、平均重试次数——超阈值自动熔断并告警”六、多智能体Multi-AgentQ20多 Agent 协作和单 Agent 多工具怎么选回答要点单 Agent 多工具实现简单、延迟低适合任务边界清晰的场景多 Agent角色分工、并行探索、对抗审查如“批评者 Agent”但带来协调成本与一致性问题选型看三点任务分解结构、组织边界、延迟与成本面试加分句“多 Agent 不是银弹——加一个 Agent 就加一份协调开销。如果单 Agent 能搞定绝不引入第二个”Q21多 Agent 之间怎么通信和避免死循环回答要点通信通过共享 Memory加版本号做乐观锁防止并发写入脏数据或消息队列避免死循环每个 Agent 设置独立的步数上限 全局协调者监控“是否在空转”终止所有 Agent 都报告完成或全局协调者判定超时强制终止七、框架与选型Q22你用过的 Agent 框架有哪些怎么选型回答要点LangChain/LangGraph生态最全适合复杂编排但抽象层次多、学习曲线陡AutoGen微软多 Agent 对话框架适合多角色协作Dify/Coze低代码平台适合快速原型和非技术团队选型原则项目复杂度、团队技术栈、是否需要可视化编排、成本预算Q23Agent 和传统 LLM Chain 的核心区别是什么回答要点LLM Chain固定流程驱动——预定义的线性硬编码工作流步骤不可动态调整Agent目标驱动自主决策——通过“观察-推理-行动”循环动态调整策略面试加分句“Chain 是‘铁轨上的火车’Agent 是‘有导航的汽车’——前者只能沿着铺好的路走后者可以根据路况自己选路”