Agent面试高频追问速查#

一句话答案#

本篇汇总跨主题的高频 Agent 面试追问，按”综合架构 → 生产踩坑 → 设计决策 → 成本效率”四类组织，每条都是”问题？→ 30 秒口述答案”。结合自己项目时，在通用答案后补一句：在哪一层做了取舍、用什么数据验证。

综合架构类#

Agent 和传统后端微服务有什么本质区别？ → 微服务是确定性流程（输入→固定逻辑→输出），Agent 是概率性循环（输入→LLM 推理→可能调工具→观察结果→再推理）。核心区别是控制流从代码转移到 LLM，每次执行路径不确定。由此带来新的工程问题：延迟不可预测、资源消耗不确定、行为难以用传统单测覆盖。
如果让你从零搭一个 Agent 系统，技术选型和架构是什么？ → 先问要不要 Agent（固定流程用 Workflow，只是查资料用 RAG），再按层选型：模型层（强模型做规划与生成、小模型做分类和判定类任务）；工具层（Function Calling，工具多或跨团队复用时用 MCP 标准化暴露）；知识层（向量库 + BM25 混合检索 + 重排）；记忆层（会话状态放 Redis/DB，长期记忆放向量库或记忆文件）；控制层（意图路由、结构化输出、Guardrails、置信度判定）；观测层（全链路 Trace + 评测集回归）。典型流水线：意图路由 → 工具/检索规划 → 并行检索 → 融合重排 → 质量判定 → 流式生成 → 缓存回写。详见 [AI Agent系统设计方法论](/topics/ai-agent/AI Agent系统设计方法论)。
你会怎么向不懂 AI 的后端同事解释 Agent？ → Agent 像一个”会自己查资料、调接口的实习生”。它不是写死的 if-else，而是 LLM 自己判断下一步：给它工具箱和操作手册，它自己决定查数据库还是搜网页，做完一步看结果再决定下一步，直到任务完成或碰到步数上限。

生产踩坑类#

Agent 上线后最容易出什么问题？ → 三类：①死循环烧 token——LLM 反复调用相同工具，需要 max_steps 上限 + 重复调用检测 + token 预算硬控；而且只在 prompt 里写”够了就停”通常不可靠，要在代码里加确定性终止条件；②检索质量差时照样编答案——需要生成前做证据置信度判定（如 CRAG 思路），低分时拒答或换检索源，而不是强行生成；③延迟波动大——LLM 响应时间长尾明显，需要每步超时 + 降级话术 + 流式输出让用户尽早看到首 token。
Demo 效果很好但上不了生产怎么办？ → 按四个维度补：可靠性（幻觉检测 + 工具调用降级链路 + 循环终止控制）、延迟（流式输出 + 语义缓存 + 模型分级路由）、成本（token 预算 + 模型级联 + 批量 API）、可观测（全链路 Trace + 指标告警 + 回归评测）。通常的节奏是：每发现一个 Demo 里没暴露的生产问题，就补一个对应的评测用例和工程防护，而不是只调 prompt。
Agent 的回答质量怎么保证？怎么量化？ → 建离线评测集：按问题类型分层（事实类、操作类、对比类、推理类、多跳、对抗、无答案），每类都要有样本，尤其是”应该拒答”的样本。做消融：从基线（纯向量检索）开始逐个加组件（BM25、重排、反思等），每个变体跑多轮取均值，看每个组件的增量。指标分两段：检索端看 Recall@K、MRR；生成端看 Faithfulness（是否被证据支撑）和 Answer Relevance，常用 LLM-as-Judge，并用少量人工标注校准裁判。
Agent 线上突然变差了怎么排查？ → 按链路逐段定位：①检索端——Recall 下降？看是否有新文档未索引、Embedding 模型或索引参数变了；②生成端——Faithfulness 下降？看模型版本是否被更新、Prompt 是否被改；③工具端——工具调用失败率上升？看外部 API 是否限流或超时。前提是有全链路 Trace（每步输入输出、耗时、token 都可查），并且每次变更前后都跑回归评测。

设计决策类#

为什么有时用规则而不是 LLM 做工具选择？ → 当工具选择能归结为少量布尔信号（是否要实时信息、是否要精确匹配、是否要历史记忆）到工具子集的映射时，它是一个可枚举的确定性问题。交给 LLM 会多一次调用的延迟（通常几百毫秒）、结果随采样波动、难以写单测；规则则几乎零延迟、可测试、每次决策可记录原因便于追溯。代价是规则覆盖不了开放场景，所以常见做法是规则优先、规则判不了再交 LLM 分类。
为什么选 Supervisor-Worker 而不是单 Agent？ → 单 Agent 随功能增加会把路由、检索、生成逻辑耦合在一个大类里，改一处影响全局。拆成 Supervisor-Worker 后，Supervisor 只管编排，每个 Worker 职责单一、可独立测试，新增能力只需实现 Worker 接口并注册。额外收益：Worker 可以并行，单个 Worker 失败不阻塞其他 Worker，可以独立超时和降级。代价是多了调度和失败传播的复杂度，职责单一时不必拆。见多Agent调度与失败传播。
RAG 为什么用混合检索而不是纯向量？ → 纯向量检索容易漏掉精确关键词（API 名、版本号、订单号、错误码），纯 BM25 缺语义理解（“怎么退款”≈“退货流程”）。两路并行再用 RRF 融合：RRF 只看排名不看原始分数，不需要把两路分数归一化，简单稳定。事实类、含专有名词的查询通常从 BM25 这一路获益最大；具体增益要用自己的评测集按问题类型分别测。
流式输出下 Self-Reflection 还有用吗？ → 事后改写基本没用：SSE 流式是边生成边推送，已经发到前端的内容收不回来，所以”生成后反思再改写”在流式模式下改不了用户看到的答案。可行的做法有两种：把质量判定前置成生成前的门控（证据不足就换检索源或拒答），或在非流式场景做完整的生成-评判-改写。反思的另一个价值是分流：高置信度请求直接跳过反思省成本，低置信度才触发补充检索。

成本与效率类#

Agent 成本怎么控制？ → 常见四招：①模型级联——强模型做最终生成，小模型做查询理解、分类、判定类任务；②语义缓存——相似问题直接返回缓存答案，配合知识库版本号失效；③按置信度跳过额外步骤——检索结果已经足够好时跳过反思或二次检索；④确定性决策用规则代替 LLM 调用。再配合 prompt 缓存（稳定前缀放前面）和 token 预算硬控。效果要用”单次请求平均成本”和质量指标一起看，避免省钱省掉质量。
增量索引怎么设计？ → 对每个 chunk 计算内容哈希（如 SHA-256），更新文档时按（知识库 ID, 内容哈希）比对：哈希相同→复用已有向量、跳过 Embedding；新哈希→生成新向量写入向量库；旧哈希消失→精确删除对应向量。这样一篇长文档只改一处时，只需重算受影响 chunk 的 Embedding。同时给知识库维护一个版本号，chunk 变更就自增，语义缓存用版本号判断是否失效。
延迟预算怎么分配？ → 先定端到端目标和首 token 目标，再按链路拆分。示意（以 3 秒端到端为例，数字需按实测调整）：Embedding 约 200ms + 向量检索约 100ms + 重排约 300ms + LLM 生成约 2000ms（流式首 token 争取 500ms 内）+ 其他开销约 400ms。优化方向：能用规则的决策不调 LLM、缓存命中直接返回、可并行的检索并行做、用流式输出降低用户感知延迟。