企业官网建设流程全解析

Agent 面试题 40+ 道全整理：先放这 8 道高频的，每道都连着生产环境的坑

这是 LangGraph 生产化系列第四篇（暂定收官）。前三篇分别讲了检索/熔断、HITL 状态管理、离线 Eval。这篇换个姿势：把做项目过程中整理的40+ 道 Agent 面试题库里的高频题拿出来精讲。

完整题库（含每题的术语铺垫、考察点、参考答案、进阶追问）：ai-service/docs/09-Agent面试题集.md，配套完整开源项目：github.com/muyiyang09/…⭐

先说我的核心观点：Agent 方向的面试，八股背不下来是正常的，因为八股本身还没定型。面试官真正在筛的，是"遇到没见过的问题时的工程判断力"。所以下面每道题的答案，我都按"30 秒要点 + 展开逻辑"组织，背要点，理解展开。

Q1 · 多 Agent 协作模式怎么选？Supervisor 还是 Handoff？🟢

考察点：协作范式认知——很多人只会说"用 LangGraph 的 Supervisor"，说不出两者边界。

30 秒要点：

展开逻辑：我的项目是推荐/摘要/审核三个 Agent，选 Supervisor 的理由就两条——任务边界清晰不需要控制权转移；推荐完教练继续追问评价的多轮场景，Supervisor 天然支持，Handoff 得转接回来链路爆炸。一句话：不确定时选 Supervisor，它退化的代价小；Handoff 只在"一去不回头"的流转场景里才占优。

Q2 · Supervisor 如何避免成为单点瓶颈？🔴

考察点：这是把"调过 API"和"上过生产"的人区分开的题。

30 秒要点：Supervisor 的单点风险不在性能（多副本 + 负载均衡能扛），在它自己调 LLM 可能失败——LLM 一挂，所有请求包括不需要智能决策的全 500（第一篇详细踩过这个坑）。

展开逻辑：给 Supervisor 配降级链，每一级都要能独立工作：

async def supervisor_route_with_fallback(query: str) -> str: """四级降级：缓存 → 关键词 → LLM → 默认。""" # Level 0: 缓存（相似 query 直接复用路由结果） # Level 1: 关键词规则（覆盖 80% 流量，0 token，永远可用） # Level 2: LLM 路由（5% 长尾，带超时 + 熔断） # Level 3: 默认路由到最高频 Agent（不让用户等死）

再加一层缓存穿透防护：恶意构造"减脂1""减脂2"十万个变体打穿路由缓存，靠语义归一化 + 布隆过滤器 + 新 query 限流三件套。答题的关键词是"Supervisor 自己也要有降级链"——把这半句说出来，面试官就知道你真跑过。

Q3 · 混合检索的融合，为什么用 RRF 而不是线性加权？🔴

考察点：RAG 深度。这是我自己真实踩过并写在代码注释里的决策，完整推导见第一篇。

30 秒要点：BM25 分数范围 0～几十，向量余弦相似度挤在 0.6～0.99——尺度完全不同，线性加权必须先归一化，而归一化策略本身又是一个新超参。RRF（Reciprocal Rank Fusion）只用排名不用分数，天然跨尺度兼容，k=60用社区默认值几乎不用调。

展开逻辑：还有个更容易被忽略的维度的答案——解释性。产品经理问"为什么这个教练排第二"，线性加权的两个 β 系数加一种归一化策略，你说不出人话；RRF 融进业务排序的单一维度（我们的五维加权里的"匹配维"），排序解释体系零破坏。收尾加分句："RAG 的鲁棒性不取决于最强的召回链路，而取决于最弱的那条能不能被安全旁路。"

Q4 · 向量库选型：pgvector / Milvus / Chroma / Faiss 怎么选？🔴

考察点：技术选型是否背口诀，还是有决策树。

30 秒要点：决策树比结论重要——

数据量 < 1 万？ → numpy 内存（最简，别羞于用它） 数据量 < 100 万？ → Chroma（嵌入式零运维，但多副本不共享） 已有 PostgreSQL？ → pgvector（复用现有库，生产折中首选） 数据量 > 1 亿？ → Milvus（分布式 + HA） 追求极致性能？ → Faiss（手动管理持久化）

展开逻辑：本项目选型 Milvus 的理由是 HA 和多副本共享；但要主动补一句诚实口径：pymilvus 未安装时自动降级 BM25 单路——依赖缺失退化而不是报错，这个细节比选型结论本身更加分。追问大概率是 HNSW vs IVF（图索引 O(log N) 召回高内存大 / 聚类分桶省内存适合亿级），答出参数名（efSearch / nlist / nprobe）就够。

Q5 · LangGraph 的 Checkpointer 和长期记忆是一回事吗？🔴

考察点：概念区分——答"都是存状态嘛"直接出局。

30 秒要点：不是一回事，两个 API、两种生命周期：

展开逻辑：结合第二篇的 HITL 实战：证书审核 interrupt 后等管理员 6 小时，靠的是 Checkpointer 的 thread 状态 + Redis TTL；而"用户上次偏好金牌教练"存在 Store 的 namespace 里，下次会话才召回。一个管"这次对话的现场"，一个管"这个用户的历史"。

Q6 · HITL 的 interrupt 本质是什么？🟡

考察点：是背 API，还是理解机制。

30 秒要点：interrupt 的执行机制八步——节点内调interrupt(value)→ 抛GraphInterrupt异常 → 框架捕获并序列化 state 到 Checkpointer → 返回 thread_id；稍后invoke(Command(resume=decision))→ 框架从 Checkpointer 加载 state → 把 decision 注入interrupt()的返回值 → 节点从暂停点继续。

展开逻辑：真正拉开差距的是追问："同一 thread_id 被两个管理员同时 resume 怎么办？"（第二篇整篇在答这个）：没有防护时第二个 resume 会把整张图重跑一遍，幽灵审核单就出现了。解法是独立的状态机管业务终态（pending → approved/rejected/cancelled），resume 前冲突检测，终态拒绝恢复。这题从"背机制"一路答到"并发防护设计"，就是一道题立住整个 HITL 认知。

Q7 · LLM-as-Judge 有哪些坑？🟡

考察点：是否用过度过、知道它的失效场景。

30 秒要点：四个经典坑——

1. 位置偏差：候选 A/B 顺序影响评分，要交换顺序评两次；
2. 自我偏好：强模型判自己的输出偏高；
3. 长度偏好：无脑偏爱长答案；
4. 成本失控：每次 CI 全量跑 judge，账单爆炸。

展开逻辑：更重要的是先回答"什么时候不该用它"——能用规则的用规则（字段匹配、Top-K 命中、关键词命中都是 0 成本确定性指标），规则真的定义不出来（文风自然度、可读性）才上 judge，而且用便宜模型（deepseek-chat / gpt-4o-mini）就够。我的项目三个 Eval 指标全是纯规则，一个 judge 都没上——这不是落后，是按需（第三篇详述）。

Q8 · Agent 的 Eval 和单元测试有什么区别？🟢

考察点：入门题，但答出"基线思维"的人不多。

30 秒要点：单元测试验证"代码对不对"（确定性 case、精确匹配、assert True、每次 push）；Eval 量化"AI 表现好不好"（人工标注 ground truth、允许误差、score ≥ threshold、改 prompt/换模型时跑）。

展开逻辑：核心句是——Eval 不追求 100% 通过，而是记一个 baseline 分数，每次改动对比，分数涨了 = 改对了。配合真实数字收尾更有说服力："我给推荐 Agent 建了 20 条标注集 + 三个纯规则指标，离线通过率 19/20，pytest 63 passed。"

⚠️ 比 8 道题更重要：面试不穿帮清单

整理题库时我干了一件自认为最重要的事：把"目标设计"和"已实现"逐条对齐，并写进文档开头。Agent 面试官最爱追问"这个数字怎么测的""这个组件怎么部署的"——把目标设计说成已实现，一追问就穿帮，一穿帮全盘皆输。

我的口径表（节选）：

唯一能外报的数字必须是实跑的：离线 Eval 19/20（95%）、Intent 准确率 1.00、理由质量分 76、pytest 63 passed。

说实话，把这张表亮给面试官看的那一刻，比任何一道题的答案都加分——知道自己系统边界的人，才敢让他上线。

写在最后

40+ 道完整题库（每题含术语铺垫 / 考察点 / 结合项目的参考答案 / 进阶追问）都在仓库里，按多 Agent 协作、RAG、记忆、工具、范式、HITL、评估、安全、服务化、性能十个板块组织：

• 40+ 道 Agent 面试题集（#09）
• Agent 场景面经（#11）
• 面试速记话术（#12）

如果题库帮你拿到了 offer 或者补上了认知盲区，请到仓库右上角点个 ⭐ Star——这是我持续更新系列的最大动力。

📌 系列暂定四篇完结。如果这篇数据不错，会继续写第五篇：《Agent 服务的 K8s 部署：LLM 容器的资源限制为什么不能照搬 Web 服务》。选题由你，评论区见。

项目地址：github.com/muyiyang09/…