全栈开发指南

Agent 基础面试题 ​

什么是 RAG？完整的处理流程是怎样的？ ​

难度：中等 ｜ 标签：RAG, 检索增强, 向量数据库

RAG（Retrieval-Augmented Generation，检索增强生成）是在调用大模型之前，先从外部知识库中检索与问题相关的内容，再把这些内容作为上下文一起交给模型生成答案的技术方案。它解决的是模型知识过期、私有数据缺失以及幻觉问题。

典型流程分为两个阶段：

  1. 离线索引：文档解析 → 文本切分（chunk）→ Embedding 向量化 → 写入向量数据库，同时保留原文和元数据。
  2. 在线检索：用户提问 → 问题向量化 → 向量检索（可结合关键词检索做混合召回）→ 重排序（Rerank）→ 拼接 Prompt → 调用 LLM 生成答案。

工程上需要重点关注：

  • 切分策略：按语义或标题切分，保留少量重叠，避免把一条完整信息切断；
  • 混合检索：向量检索 + BM25 关键词检索，兼顾语义相似和专有名词；
  • 重排序：先召回较多候选，再用 Rerank 模型精排，控制进入 Prompt 的 token 数量；
  • 引用溯源：答案中附带来源文档，便于核对，降低幻觉风险。

Function Calling 的实现原理是什么？ ​

难度：中等 ｜ 标签：Function Calling, 工具调用, Agent

Function Calling（Tool Calling）让模型能够根据用户意图，输出结构化的工具调用请求，而不是直接给出自然语言答案。

一次完整调用的过程：

  1. 开发者把可用工具的 name、description、parameters（JSON Schema）随请求一起传给模型；
  2. 模型判断需要调用工具时，返回 tool_calls，其中包含函数名和 JSON 参数；
  3. 业务代码解析参数、执行真实函数，把结果作为 tool 角色的消息追加到对话中；
  4. 再次调用模型，模型基于工具结果生成最终回答。
text
用户问题 → LLM（带 tools 定义）
        → tool_calls: get_weather({"city": "北京"})
        → 本地执行函数
        → tool 消息回填给 LLM
        → 最终自然语言回答

需要注意：模型只负责「决定调用什么、传什么参数」，真正的执行和参数校验必须由业务代码完成，不能信任模型输出的参数。

Agent 和普通 Chain 有什么区别？ReAct 模式是什么？ ​

难度：中等 ｜ 标签：Agent, ReAct, 规划

普通的 Chain 是固定编排：步骤在代码里提前写死，模型只在固定节点做生成。Agent 则是动态决策：由模型自己判断下一步做什么、调用哪个工具、是否继续循环，直到任务完成。

ReAct（Reasoning + Acting）是最常见的 Agent 范式，核心是把「思考」和「行动」交替进行：

text
Thought: 我需要先查询用户订单状态
Action: query_order(order_id="123")
Observation: 订单已发货
Thought: 已经拿到结果，可以回答用户了
Final Answer: 您的订单已发货……

实际落地时通常需要加上：最大循环次数、工具调用超时、失败重试、人工确认（Human-in-the-loop）等保护机制，避免 Agent 陷入死循环或执行高危操作。

如何设计一个 Agent 的记忆系统？ ​

难度：困难 ｜ 标签：Memory, 上下文管理, 向量检索

记忆系统一般分为三类：

  • 短期记忆：当前会话的对话历史，直接放在上下文窗口中，需要按 token 预算做裁剪或摘要；
  • 长期记忆：跨会话保存的用户偏好、历史事实，通常向量化后存入向量库，按相关性检索；
  • 工作记忆（Scratchpad）：Agent 执行任务过程中的中间结果、计划和工具返回，用于当前任务的推理。

设计时的关键点：

  1. 写入策略：什么信息值得记？可以由模型抽取事实后写入，避免把所有对话原样存储；
  2. 检索策略：按语义相似度 + 时间衰减 + 重要程度综合排序；
  3. 遗忘与更新：过时或冲突的记忆需要合并、覆盖，否则会污染后续回答；
  4. 上下文预算：记忆不能无限塞进 Prompt，要结合摘要、分层检索控制长度。

如何评估一个 Agent 应用的效果？ ​

难度：困难 ｜ 标签：评估, 可观测性, LLM

Agent 的评估要同时看最终结果和执行过程：

  • 结果指标：任务成功率、答案准确率、人工评分、端到端耗时和成本；
  • 过程指标：工具调用次数、无效调用率、循环轮数、检索命中率、上下文 token 消耗；
  • 稳定性：同一输入多次运行的结果一致性，异常输入下的兜底表现。

工程上通常采用分层评估：

  1. 用固定测试集做离线回归，覆盖典型问题和边界问题；
  2. 用 LLM-as-a-Judge 对开放式答案打分，但要校准评分 Prompt 并抽样人工复核；
  3. 线上通过 Trace 记录每一次模型调用、工具调用和耗时，结合用户反馈做持续分析。

评估集要随着业务迭代不断补充 bad case，否则很容易出现「离线指标很好、线上效果很差」的问题。