Agent面试高频追问速查#

一句话答案#

本篇汇总跨主题的高频 Agent 面试追问，按”综合架构 → 生产踩坑 → 设计决策 → 成本效率”四类组织，每题 30 秒口述版。

综合架构类#

Q: Agent 和传统后端微服务有什么本质区别？

微服务是确定性流程（输入→固定逻辑→输出），Agent 是概率性循环（输入→LLM 推理→可能调工具→观察结果→再推理）。核心区别：控制流从代码转移到 LLM，每次执行路径不确定。这带来新的工程挑战：不可预测的延迟、不确定的资源消耗、难以用传统单测覆盖的行为。

Q: 如果让你从零搭一个 Agent 系统，技术选型和架构是什么？

结合 DocMind 实践：Spring Boot + Spring AI（Java 生态原生 Function Calling）、Milvus（向量库，HNSW 索引）、Redis（语义缓存 + 用户记忆）、MCP 协议（工具标准化暴露）、Langfuse（LLM 全链路追踪）。架构九步流水线：二级意图路由（正则快筛 + LLM 分类）→ 规则引擎工具选择（<1ms）→ Supervisor-Worker 并行检索 → RRF 融合 + Rerank → CRAG 置信度分流 → 流式生成 → Self-Reflection → 置信度分级 → 缓存回写。

Q: 你会怎么向不懂 AI 的后端同事解释 Agent？

Agent 就像一个”会自己查资料、调接口的智能客服”。它不是写死的 if-else，而是 LLM 自己判断下一步该做什么——像一个实习生，给它工具箱和操作手册，它自己决定查数据库还是搜网页，做完一步看结果再决定下一步，直到任务完成。

生产踩坑类#

Q: Agent 上线后最容易出什么问题？

三大坑：①死循环烧 token——LLM 陷入重复调用相同工具，需要 max_steps 上限 + 相同工具调用检测 + token 预算硬控；②幻觉返回给用户——检索质量差时 LLM 照样编，需要 CRAG 置信度分流 + 低分拒答而非强行生成；③延迟不可控——LLM 响应时间波动大（P50 800ms vs P99 5s），需要超时兜底 + 流式输出让用户感知首 token 快。

Q: Demo 效果很好但上不了生产怎么办？

生产四维检查清单：可靠性（幻觉检测 + 工具调用降级链路 + 循环终止控制）、延迟（流式输出 + 语义缓存 + 模型分级路由）、成本（token 预算 + 模型级联 + 批量 API）、可观测（全链路 Trace + Metrics 告警 + 回归评测）。DocMind 经历 6 个 Phase 迭代，每个 Phase 都是发现一个”Demo 里没暴露的生产问题”然后工程化解决。

Q: Agent 的回答质量怎么保证？怎么量化？

DocMind 评测体系：构建 52 query × 7 类别（factual/howto/comparison/reasoning/adversarial/unanswerable/multihop）的测试集，跑 4 个 pipeline 变体（纯向量→+BM25→+Rerank→+Reflection）× 3 轮取均值。指标：Recall@5 衡量检索质量、MRR 衡量排名、Faithfulness/Relevance 用 LLM-as-Judge（qwen-turbo 降成本）。关键发现：Self-Reflection 在流式模式下无法改写（SSE flush 阻止回溯），但置信度分流本身仍有独立价值。

Q: Agent 线上突然变差了怎么排查？

按链路逐段排查：①检索端——Recall@5 下降？看是否有新文档未索引或 Embedding 模型 API 异常；②生成端——Faithfulness 下降？看是否模型版本更新或 Prompt 被意外修改；③工具端——工具调用失败率上升？看外部 API 是否限流或超时。全链路 Trace（Langfuse）可以定位到具体哪一步出问题。

设计决策类#

Q: 为什么用规则引擎而不是 LLM 做工具选择？

工具选择是 4 个布尔信号（ambiguous? precise? timely? needs memory?）→ N 个工具子集的映射，确定性规则空间。LLM 做这件事增加 ~300ms 延迟、引入不确定性（temp>0 时结果不稳定）、零测试覆盖。规则引擎 <1ms、100% 可测、PathDecision.reason 全程可追溯。当规则不够用时再降级到 LLM 分类。

Q: 为什么选 Supervisor-Worker 而不是单 Agent？

单 Agent（DocMindAgent.java）膨胀到 1400 行，路由/检索/生成逻辑耦合，新增 Worker 要改核心类。重构后 Supervisor 586 行只管编排，每个 Worker 80-120 行独立可测。新增 Worker = 实现 Worker 接口 + 在 PlanExecutor.resolveWorker() 注册，零侵入。额外好处：Worker 失败不阻塞其他 Worker，可以独立超时和降级。

Q: 你们的 RAG 为什么用混合检索而不是纯向量？

纯向量漏掉精确关键词（API 名、版本号、订单号这类精确匹配场景），纯 BM25 缺语义理解（“怎么退款” ≈ “退货流程”）。评测数据证明：factual（事实类）查询 Recall@5 从 0.73（纯向量）→ 0.93（+BM25 融合），提升 +0.20 主要来自 BM25 对精确关键词的召回补充。RRF 融合不依赖分数归一化，简单鲁棒。

Q: 为什么 Self-Reflection 在流式模式下是 no-op？

SSE 流式输出是边生成边推送到前端，已经 flush 的内容无法回溯修改。所以 V3（+Rerank）和 V4（+Reflection）的答案质量指标完全一致——Reflection 的”改写”实际没有生效。但 Reflection 的价值在于：70% 高分查询直接短路省 LLM 调用，30% 低分触发 Web Search 兜底。下一步方案：非流式场景做回填改写，或将 Reflection 前置为 Pre-generation 质量门控。

成本与效率类#

Q: Agent 成本怎么控制？

DocMind 四板斧：①模型级联——qwen-plus 做生成（质量要求高），qwen-turbo 做决策类任务（Query 理解/工具选择/Self-Reflection），单次成本 -28%；②语义缓存——命中率 45%（频率阈值从 3 调到 2 提升 +15%），命中直接返回；③Self-Reflection 70% 高分短路——rerank top1 ≥ 0.85 且候选 ≥ 3 时跳过反思，省 LLM 调用；④规则引擎替代 LLM 工具选择——<1ms vs ~300ms。月度综合降本约 50%。

Q: 增量索引怎么设计？

SHA-256 content_hash 做 diff：每个 chunk 计算内容哈希，更新时按 (kb_id, content_hash) 比对。相同 hash → 复用 vector_id 跳过 Embedding；新 hash → 新建 Embedding + 写入 Milvus；缺失旧 hash → 精确删除对应 Milvus 向量。效果：100 页文档改 1 个字 = 1 次 Embedding 而非 200-400 次。知识库 version 字段每次 chunk 变更自增，语义缓存以 version 做失效判断。

Q: 你们的延迟预算怎么分配？

以 3 秒总预算为例：Embedding 计算 200ms + 向量检索 100ms + 重排序 300ms + LLM 生成 2000ms（流式首 token <500ms）+ 其他开销 400ms。关键优化：RetrievalPlanner 规则引擎 <1ms（替代 LLM 工具选择 ~300ms），语义缓存命中时直接返回（~50ms），流式输出让用户感知延迟大幅降低。