AI Agent 面试题

1、简述 ReAct 和 Plan-Act 范式的核心区别，以及各自适用的场景？

答案要点：

• 核心逻辑：ReAct强调交替进行推理和行动，走一步看一步；Plan-Act强调先制定全局执行计划（Plan），再按照计划逐步执行（Act）。
• 优势与劣势：ReAct 灵活性高，能动态应对环境变化，但长程任务容易跑偏或陷入死循环；Plan-Act 适合步骤明确的长程任务，但对初始计划的准确性要求高。
• 适用场景：ReAct 适合信息探索、简单工具调用（如实时搜索）；Plan-Act 适合复杂数学求解、长篇内容生成、多步骤数据分析。

2、请详细描述 ReAct 的 Thought-Action-Observation 闭环是如何在代码层面实现的？

答案要点：

• 循环机制：通常通过一个 while 循环实现。LLM 生成包含 Thought（思考）和 Action（工具名及参数）的文本。
• 解析与执行：系统通过正则表达式或 JSON 解析器提取 Action，在本地环境中执行对应函数。
• 环境反馈：将函数执行结果封装为 Observation，追加到 prompt 上下文中，再次输入给 LLM。

3、在生产环境中，ReAct Agent 经常会陷入“工具调用死循环”，你该如何解决？

答案要点：

• 最大步数限制 (Max Iterations)：强制设置循环上限，超时则触发 Fallback 机制。
• 重复动作检测：在上下文中记录历史 Action，若发现连续调用相同工具且参数一致，强制打断。
• Prompt 强化：在 System Prompt 中明确规定“遇到连续报错必须更换策略或向用户求助”。

4、如何降低 ReAct 模式下的 Token 消耗和端到端延迟？

答案要点：

• Observation 截断：对工具返回的过长结果进行截断或摘要，避免上下文爆炸。
• 小模型路由：使用微调后的轻量级模型（如 8B/14B）专门做 Thought 和 Action 生成，仅在总结阶段使用大模型。
• 流式输出：在思考过程中向用户流式返回中间状态，提升用户体感速度。

5、Plan-Act 范式中，如果某一步执行失败，如何实现重规划（Re-planning）机制？

答案要点：

• 状态评估：在每个子任务完成后，加入一个评估节点，对比预期结果与实际结果。
• 错误注入：若失败，将失败原因及当前环境状态输入给 Planner 模型。
• 动态修正：指示 Planner 模型生成修补步骤，或丢弃原计划重新生成后续步骤。

6、什么是 Agentic-RAG，它与传统 Naive RAG 的核心区别在哪里？

答案要点：

• 传统 RAG：单向线性流程（Query -> 检索 -> 增强 -> 生成），检索策略固定，依赖用户输入的质量。
• Agentic-RAG：将 RAG 转化为一系列可被调用的工具。Agent 可以自主决定是否需要检索、如何改写 Query、是否需要多次检索、以及何时停止检索。
• 核心能力：具备 Query 规划、路由、反思（Reflection）和自我纠错能力。

7、Anthropic 提出的 MCP (Model Context Protocol) 解决了什么痛点？其核心架构是怎样的？

答案要点：

• 痛点解决：解决了 LLM 与外部数据源/工具集成时标准不一、开发成本高、安全性差的问题。
• 核心架构：基于 Client-Server 架构。包含 Host（如大模型 App）、Client（协议客户端）和 Server（提供具体能力）。
• 三大能力：暴露 Resources（静态数据）、Prompts（模板）和 Tools（可执行函数）。

8、在 Agentic-RAG 中，如何处理需要跨文档推理的多跳问题（Multi-hop QA）？

答案要点：

• 问题分解 (Decomposition)：利用 LLM 将复杂问题拆解为多个子问题。
• 逐步迭代 (Step-back/Iterative)：先检索子问题 A，将结果作为上下文，再去改写并检索子问题 B。
• 知识图谱结合 (Graph RAG)：利用图谱的边关系，天然支持跨实体跳跃检索。

9、Agentic-RAG 中频繁调用大模型会导致极高的延迟，如何优化？

答案要点：

• 语义路由 (Semantic Router)：在最前端使用极快的向量计算判断意图，直接路由，绕过大模型推理。
• LLM 缓存：缓存常见 Query 的检索计划和工具调用参数。
• 并行执行：对于被分解的互相独立的子问题，并行调用检索工具。

10、什么是混合检索（Hybrid Search），为什么在生产环境中它是必选项？

答案要点：

• 概念：结合密集检索（Dense Retrieval，基于向量语义）和稀疏检索（Sparse Retrieval，基于关键词如 BM25）的检索方式。
• 原因：向量检索擅长捕捉上下文和语义相似度，但对专有名词、产品型号、缩写（Out-of-Vocabulary）的精准匹配表现极差。BM25 则正好弥补这一短板。

11、简述 BGE 等双编码器（Bi-encoder）与重排模型（Cross-encoder）的原理差异？

答案要点：

• 双编码器 (Bi-encoder)：Query 和 Document 分别独立通过模型计算向量，通过计算余弦相似度匹配。速度快，适合初筛（召回阶段）。
• 交叉编码器 (Cross-encoder)：将 Query 和 Document 拼接成一段文本输入模型，模型直接输出相关性得分。精度高，但计算量大，适合精排阶段（Rerank）。

12、如何在代码逻辑中实现 RRF (Reciprocal Rank Fusion) 算法以融合混合检索结果？

答案要点：

• RRF 是一种无需权重的排名融合算法，公式为：$ Score = \frac{1}{k + Rank_{dense}} + \frac{1}{k + Rank_{sparse}} $
• 通常 $ k $ 取 60。遍历两路召回结果，利用其各自的排名计算 RRF 分数并重新降序排列，取 Top-N。

13、面对应垂直领域（如医疗）文本，开源向量模型效果不佳，应该采取哪些措施？

答案要点：

• 微调 Embedding 模型：利用领域内的数据构建正负样本对进行微调。
• 领域词典+混合检索：加强 BM25 的权重，并引入该领域的同义词表扩展 Query。
• 假设性提问 (HyDE)：让 LLM 先基于 Query 生成一段模拟答案，再用该答案的向量去检索，弥合语义鸿沟。

14、一个面向复杂 Agent 的生产级 System Prompt 应该包含哪些核心结构？

答案要点：

• Persona & Role：定义角色、语调和专业背景。
• Objective：明确核心任务和目标。
• Rules & Constraints：必须遵守的红线、输出格式限制（如严禁返回 Markdown 代码块）。
• Tools/Capabilities：可使用工具的说明及入参规范。
• Examples (Few-Shot)：提供优秀的输入输出范例。

15、Few-Shot 与 Chain-of-Thought (CoT) 结合使用的底层原理是什么？

答案要点：

• 原理：通过 Few-Shot 向模型展示“思考的中间过程”，而不仅是最终答案。这迫使大模型的注意力机制（Attention）在推理时展开计算步骤，降低了单步推理的复杂度，极大地减少了“幻觉”和逻辑跳跃。

16、如何在 Prompt 层面防止 Agent 遭遇“提示词注入攻击”（Prompt Injection）？

答案要点：

• 定界符隔离：使用随机字符串或 XML 标签（如 <user_input>...</user_input>）严格隔离系统指令与用户输入。
• 末尾强化原则：在 Prompt 的最后一行重申最重要的安全指令（因为 LLM 对末尾内容注意力更强）。
• 前置过滤 Agent：引入一个低成本模型专门用于检测用户输入是否包含越权指令。

17、什么是 Tree of Thoughts (ToT)？它适用于什么场景？

答案要点：

• 逻辑：将推理过程抽象为树状结构，每一步生成多个可能的分支（Thought），并引入评估器对各个分支进行打分（启发式搜索），保留高分路径进行下一步（如 BFS/DFS 搜索）。
• 场景：适用于需要深度探索和回溯的极其复杂的逻辑任务，如数独求解、创意写作排版规划。

18、如何在不损失模型表现的情况下压缩长 Prompt 降低成本？

答案要点：

• 信息抽取：移除冗余的寒暄语和停用词。
• 语义压缩库：使用 LLMLingua 等专门的压缩模型，根据困惑度（Perplexity）剔除对模型推理影响最小的 Token。
• 迁移为微调：当 Few-Shot 样本过多时，将其移除，转而采用对小模型进行指令微调（SFT）的方式固化行为。

19、什么是上下文窗口限制，目前业界常用的突破思路有哪些？

答案要点：

• 概念：LLM 单次能处理的最大 Token 数量（如 128K, 1M）。超出限制会导致截断或严重报错。
• 解决思路：RAG 检索增强、上下文滑动窗口（Sliding Window）、动态摘要（Summarization）、Prompt Caching（提示词缓存技术）。

20、在极长的多轮对话中，如何实现上下文的动态裁剪与状态保持？

答案要点：

• 双轨记忆策略：维护两个队列。一个是最近的 N 轮原始对话（保证短期连贯性）；另一个是将 N 轮之前的对话通过 LLM 总结成实体和核心事件（Entity/Summary），作为背景知识常驻 Prompt。

21、简述 Prompt Caching (提示词缓存) 的底层机制及其价值？

答案要点：

• 机制：主流模型（如 Claude, Gemini）将频繁出现的前置 Context（如长系统提示词、巨型文档）的 KV Cache 计算结果保存在显存中。当新请求具有相同前缀时，直接复用 KV Cache。
• 价值：大幅降低 TTFT（首字返回时间），并将长上下文的输入成本降低 50%-90%。

22、什么是“大海捞针”(Needle in a Haystack) 测试？它对长文本提示词编排有什么指导意义？

答案要点：

• 测试：在长文本的不同位置插入一个无关的事实（针），测试模型是否能将其准确提取出来。
• 指导意义：研究表明大模型存在“Lost in the Middle”现象。指导我们在编排 Context 时，将最关键的指令和检索到的最核心知识放置在文本的开头或末尾，而非中间。

23、如何在上下文中有效传递复杂的 JSON/XML 数据，以提高大模型的解析遵循度？

答案要点：

• Schema 定义：提供清晰的结构定义，并附带字段类型说明。
• 结构对齐：使用 Markdown 代码块包裹，明确指定语言类型。
• 减少层级：尽量扁平化数据结构，过深的嵌套容易导致模型注意力涣散。

24、Agent 和 Workflow 的本质边界在哪里？选型时如何权衡？

答案要点：

• 边界：Workflow 是“硬编码的图逻辑”，执行路径是确定的或基于预设规则分支的；Agent 是“大模型驱动的状态机”，下一步干什么由大模型实时推理决定。
• 选型：对可靠性、容错性、过程可控性要求极高的场景（如金融审批、流水线发文）首选 Workflow；对探索性强、不可预见情况多的场景首选 Agent。

25、如何基于有向无环图 (DAG) 实现 LLM 工作流的编排引擎？

答案要点：

• 节点定义：每个节点封装具体的业务逻辑（如 LLM 调用、HTTP 请求、代码执行），包含输入映射和输出映射。
• 拓扑排序：引擎解析图定义，生成拓扑排序，确定执行先后顺序。
• 状态总线：通过全局的 State 变量在图的各个节点之间传递数据。

26、在 Workflow 中如何设计高可用的重试 (Retry) 和回退 (Fallback) 机制？

答案要点：

• 局部重试：针对不稳定节点（如外部 API），设置最大重试次数和指数退避策略。
• 大模型降级：LLM 节点失败时，Fallback 到更强大的模型重试（如从 8B 切换到 GPT-4o），或切换 Prompt 策略。
• 人工介入：重试耗尽后挂起状态，流转至人工审批队列。

27、如何在 Workflow 中实现 Map-Reduce (散列-汇聚) 模式？

答案要点：

• Map 阶段：配置并行循环节点，接收数组类型的数据集，同时启动多个子任务进行并发处理（如对多篇文档并行总结）。
• Reduce 阶段：配置等待屏障（Barrier），确保所有 Map 实例完成后，将结果汇合成数组输入给 Reduce 节点进行最终汇总。

28、如何降低多节点长链路 Workflow 的端到端延迟？

答案要点：

• 最大化并行：剥离无状态依赖的节点，将其从串行改为并行（如同时进行翻译和情感分析）。
• 流式透传：如果前后节点都是 LLM，尝试将上游节点的流式输出直接作为下游节点的输入流缓冲，无需等待全量生成。

29、请对比 Agent 的短期记忆和长期记忆。

答案要点：

• 短期记忆：存在于单次会话或当前 Context Window 中的信息。随会话结束而清空。
• 长期记忆：持久化存储在外部数据库（如向量数据库、关系型数据库）中的信息。支持跨越多次会话提取个人偏好、历史事实。

30、如何使用向量数据库构建支持自我演进的 Agent 长期记忆系统？

答案要点：

• 抽取与向量化：后台任务定期利用 LLM 从短期对话中抽取出陈述句（如“用户喜欢喝美式”），进行 Embedding 存入向量库。
• 召回：新对话发生时，对 Query 进行 Embedding，召回相关的历史事实注入 Prompt。

B[意图/关键词提取]

B --> C[向量 DB 召回相关历史记录]
C --> D[拼接 Prompt 生成回复]
D --> E[异步任务: 提取对话中的新知识点]
E --> F[去重、合并现有记忆]
F --> G[更新/写入向量 DB]

-->

31、在 Agent 系统中，哪些关键节点必须引入 Human-in-the-loop (HITL)？

答案要点：

• 高风险操作前：如执行数据库写操作、发送真实付款、对外发送商业邮件。
• 系统不确定时：当模型针对下一步 Action 输出的置信度低于阈值，或者由于模糊意图无法生成有效计划时。
• RLHF 迭代期：系统上线初期，需要人工标注员对 Agent 给出的多个解决路径进行排序打分。

32、如何设计记忆衰退（Forgetting）机制以提高检索准确度？

答案要点：

• 时间衰减因子：为记忆条目增加时间戳，计算相关度时乘上时间衰减系数，越旧的信息权重越低。
• 访问频率控制：类似 LRU 缓存，频繁被召回且被验证为有用的记忆增加权重，长期未激活的记忆归档或删除。
• 冲突覆盖：当提取到新记忆与旧记忆主题相同但内容冲突时（如用户换了工作），利用 LLM 显式覆盖旧记忆。

33、简述 Supervisor 和 Debate 这两种多智能体拓扑结构的特点？

答案要点：

• Supervisor (分发/层级结构)：一个核心监督者 Agent 负责规划，把子任务分发给专业的 Worker Agent，汇总结果。效率高，可控性强。
• Debate (辩论结构)：多个 Agent 代表不同立场或专家角色，对同一问题相互反驳和补充。适合复杂开放性问题求解，能有效降低单一模型幻觉。

34、类似 LangGraph/Spring AI Alibaba Graph 的框架是如何实现多 Agent 状态机流转的？

答案要点：

• State 驱动：全局定义一个核心的 State 对象。
• 节点即函数：每个 Agent 是图中的一个节点，接收 State，返回对 State 的更新（如增量追加消息列表）。
• 条件边 (Conditional Edges)：一个路由器函数根据当前 State（如最后一个输出的字段）决定下一个激活的节点。

35、两个 Agent 相互配合时，陷入无休止的修改和争论（死循环），如何解决？

答案要点：

• 全局迭代计数器：在全局 State 中维护对话轮数，达到设定值直接终止。
• 引入判别者 (Judge Agent)：增加一个不参与生成、只负责打分的 Agent，一旦打分超过阈值强制通过。
• 强制收敛提示：在多轮交互后，动态修改提示词注入“妥协指令”（如“不要再挑剔细节，请给出你目前认为最好的最终版”）。

36、多智能体系统中，如何进行工具资源和权限的隔离？

答案要点：

• 工具绑定隔离：在初始化 Agent 时，严格只传入其角色所需的工具列表（例如 Researcher 只有 Search 权限，无权访问 Database 工具）。
• 运行时鉴权：在工具内部的执行逻辑中，验证当前请求的 User/Session Token 是否有执行此动作的权限。

37、分布式部署的多 Agent 系统中，如何处理状态同步问题？

答案要点：

• 外部状态存储：使用 Redis 或 PostgreSQL 作为集中的 State 存储，替代内存状态。
• 乐观锁/版本控制：为 State 增加版本号，处理并发写入时的冲突。
• 事件驱动消息队列：使用 Kafka/RabbitMQ 解耦 Agent，通过发布/订阅模式传递事件，取代同步 RPC 调用。

38、评估一个生产级 Agent 需要关注哪些核心维度和指标？

答案要点：

• 任务成功率 (Task Success Rate)：端到端完成用户目标的比例。
• 轨迹合理性 (Trajectory Evaluation)：执行步骤、工具调用顺序是否是最优解。
• 效率指标：Token 消耗量、API 调用次数、端到端响应时间。
• 安全性/幻觉率：是否泄露隐私、是否基于外部知识产生捏造。

39、什么是 LLM-as-a-Judge？在实施时如何避免其特有的偏差？

答案要点：

• 原理：使用能力更强的大模型（如 GPT-4）通过特定的评估提示词，对被测 Agent 的输出进行打分。
• 位置偏差：大模型偏好选项中的第一个或最后一个，需交换顺序测两次取平均。
• 长度偏差：大模型倾向给长文本打高分，需在 prompt 中强调“以准确性而非长度为标准”。
• 盲测：隐藏模型名称，避免 LLM 对自身生成的文本存在偏好。

40、构建 Agent 的可观测性 (Observability) 平台，需要埋点采集哪些 Trace 数据？

答案要点：

• 输入输出流：完整的 Prompt、System Prompt 及最终生成文本。
• 工具调用级 (Tool Span)：工具调用的名字、输入参数、工具返回结果、执行耗时、错误日志。
• 元数据：消耗的 Prompt Token、Completion Token 数、模型版本、Session ID。

41、如何高效构建针对特定业务场景的 Agent 测试数据集 (Golden Dataset)？

答案要点：

• 生产数据挖掘：脱敏并提取线上真实用户的复杂查询日志。
• 合成数据生成：利用强 LLM 基于业务文档逆向生成“Question-Action-Answer”对。
• 人工复核：建立业务专家标注平台，对生成的测试集进行清洗，确保“标准答案”的绝对准确。

42、在评估 Agent 时，Offline Eval 和 Online A/B Test 的核心差异及结合点是什么？

答案要点：

• Offline Eval：发版前基于静态数据集运行，侧重于回归测试，确保工具调用准确率和任务完成基线不下降。
• Online A/B Test：发版后对真实流量灰度，侧重于业务指标（如转化率、用户留存、点赞踩率）。
• 结合：离线过基线才能上线；在线 A/B 发现的不佳 Case 沉淀回离线数据集。

43、企业级落地 NL2SQL 的核心挑战通常不是模型能力不足，而是什么？

答案要点：

• Schema 复杂度：企业表数量成百上千，表名、字段名往往是难以理解的缩写且缺乏注释。
• 领域黑话与计算口径：用户常说“算一下北区的客单价”，但系统并不知道“北区”包含哪些门店，且“客单价”的计算公式在系统中并不直观。
• 安全性与幻觉：生成的 SQL 必须绝对安全（防止只读库出现删改），且防止产生看起来能执行但逻辑全错的“幻觉 SQL”。

44、一个高可用 NL2SQL Pipeline 的标准处理流程是怎样的？

答案要点：

• 包含四个核心阶段：意图理解与表路由 -> Schema Linking（链接字段与问题） -> SQL 生成 -> 校验与执行。

45、如何通过 Schema Linking 提升复杂 JOIN 语句的生成准确率？

答案要点：

• 精简上下文：不要把整个建表 DDL 塞给模型，而是只保留与当前问题相关的表名和字段名。
• 显式注入外键关系：在 Prompt 中明确提供图谱或文本说明（如“订单表 orders 通过 user_id 与用户表 users 关联”）。
• 样例注入：基于向量检索，找几个类似包含复杂 JOIN 的历史优质 SQL 样例注入 Prompt。

46、当生成的 SQL 执行抛出异常时，如何利用 Agent 机制实现自动修复？

答案要点：

• 捕获异常：捕获数据库引擎返回的具体错误堆栈（如 Column 'status' not found）。
• 构建反思 Prompt：将原始提问、生成的错误 SQL、表结构和错误日志拼接给 LLM。
• 强制指令：要求 LLM 分析错误原因并输出修正后的 SQL，循环重试，直至成功或达到最大阈值。

47、评估 NL2SQL 系统表现时，为什么仅看“SQL执行不报错”是不够的？还需要看什么？

答案要点：

• 执行不报错不代表业务逻辑正确（例如误用了 LEFT JOIN 导致数据翻倍）。
• 执行结果匹配率 (Execution Accuracy)：运行生成的 SQL 和标准答案 SQL，对比返回的数据集是否完全一致。
• AST 树对比：对比生成 SQL 和标准 SQL 的抽象语法树，验证条件从句、聚合函数是否逻辑一致。

48、什么是 Agent-Generated UI (AG-UI/生成式 UI)？它与传统静态 UI 的区别？

答案要点：

• 传统 UI：前端预先写死各种组件，后端只返回 JSON 数据，前端根据状态渲染。
• AG-UI：后端大模型根据用户意图，不仅生成数据，还直接决策应该展示何种组件界面（如用户问天气，直接生成并流式返回一个天气卡片组件），界面是高度动态和定制化的。

49、什么是 Agent-to-Agent (A2A) 通信？为什么它是未来的重要方向？

答案要点：

• 概念：不同域或不同厂商的智能体之间不通过人类中介，直接进行握手、协商、数据交换和任务调用的机制。
• 重要性：打破信息孤岛。未来的生态不是一个超级 Agent 统治，而是类似微服务架构，旅行 Agent 通过 A2A 协议直接调用银行 Agent 完成支付。

50、如何保证跨系统的 A2A 通信安全性？

答案要点：

• 标准化协议：采用标准协议及 Schema 定义数据交换格式。
• 身份验证机制：使用类似于 OAuth 2.0 或 JWT 的令牌机制，严格验证调用方 Agent 的身份及权限。
• 沙箱与审查：所有外部 Agent 调用的输入必须经过安全过滤，并对高危操作（转账、敏感数据读取）引入 Human-in-the-loop 审核。