【旷视】【Agent 开发】【暑期实习一面】面经（八股+大模型项目+手撕）

背景

海外一年制硕士在读，投递旷视 Agent 开发暑期实习，一面时长约 55 分钟，面试官为部门技术骨干，全程围绕项目和八股展开，无闲聊。

题目摘要

• Go 语言基础：goroutine 与 channel 的底层实现、内存逃逸分析、sync.Pool 适用场景
• MySQL/Redis 八股：索引失效场景、MVCC 原理、Redis 持久化机制对比（RDB vs AOF）、缓存穿透与布隆过滤器
• Agent 项目深挖：RAG 检索质量优化、Function Calling 的容错设计、上下文窗口管理策略、推理成本优化手段
• 手撕算法：LeetCode 原题变体——「设计一个支持按时间戳获取快照的类」（含构造函数、set、get 方法），要求 O(log n) 复杂度
• 系统设计：一个多 Agent 协作场景下，如何保证消息不丢不重、如何做超时降级

项目深挖

面试官对项目细节的追问密度很高，每个回答都会引出 2-3 个 follow-up，核心逻辑是「你做了 X，为什么不用 Y？Y 的问题是什么？」。以下为三个典型追问方向及参考回答思路。

追问一：RAG 检索质量差时，你具体怎么定位问题？

参考回答方向：不要只说"调 embedding 模型"，要给出可验证的链路。我的回答是——先拆召回和重排两段。召回阶段看 recall@k，如果低，优先检查 chunk 切分粒度（是否把语义完整段落切断）和 query 改写（是否缺少同义扩展）；重排阶段看 NDCG，如果低，检查 reranker 的输入拼接方式（query 与 passage 之间是否加了分隔符，位置编码是否被截断）。面试官追问"你怎么判断是 chunk 问题还是 embedding 模型问题"，我答：用同一批 query 跑不同 chunk 策略，对比 recall 曲线，如果增大 chunk 长度后 recall 明显上升，说明是切分问题；如果变化不大，再换 embedding 模型做 A/B。

追问二：Function Calling 在真实调用中，模型返回了不存在的函数名或参数格式错误，你怎么处理？

参考方向：三层容错。第一层是 schema 校验，用 JSON Schema 做强校验，不合法直接拒绝并触发重试（带错误信息回填给模型）；第二层是函数名模糊匹配，用编辑距离或 embedding 相似度做候选召回，如果 Top1 相似度低于阈值，走人工兜底；第三层是超时熔断，函数执行超过 3 秒直接返回超时占位符，避免阻塞主流程。面试官追问"重试次数怎么定"，答：最多 2 次，且第二次重试时给模型附加「上一次调用失败原因」的 system message，而不是简单重试——这能显著降低重复犯错概率。

追问三：上下文窗口有限，你如何处理超长对话？

参考方向：三层策略——摘要压缩、关键信息抽取、滑动窗口。我的做法是维护一个「核心事实表」（用结构化 key-value 存储用户偏好、关键结论），每轮对话后增量更新；当 token 接近阈值时，将最早的历史消息做摘要，但保留事实表中的结构化内容。面试官追问"摘要会丢信息怎么办"，答：摘要只做兜底，优先触发「关键信息抽取」——用模型抽取对话中的实体、数值、决策点，存入事实表，这样即使摘要丢失细节，核心信息仍在。

准备建议

一、项目准备要「可量化、可对比」

面试官对项目的追问，本质是验证「你是否有真实工程经验」。每个优化点都要准备「量化指标 + 对比基线」，比如检索 recall 从 0.72 提升到 0.85，推理成本降低 40%。没有数字的项目描述，会被视为「课程作业」。建议为每个项目准备一张「优化记录表」，列出改动点、基线值、优化后值、验证方式。

二、八股要「背到能推导」

MySQL 和 Redis 的考点非常常规，但面试官会追问「为什么」。比如 MVCC，不能只背「三个隐藏列 + undo log」，要能推导「RC 和 RR 下 read view 的生成时机不同，导致不可重复读和幻读的差异」。Redis 持久化，不能只背「RDB 快照、AOF 追加」，要能对比「AOF 的 everysec 策略下最多丢 1 秒数据，但 rewrite 期间的内存峰值会翻倍」。建议把每个八股点都写成「现象 → 原理 → 代价 → 适用场景」四段式。

三、手撕算法要「练变体」

面试官明确说「这题是 LeetCode 1146 的变体」，说明他们不会直接出原题，而是改条件。我的建议是：把高频题（快照、LRU、线段树、并查集）的「变体方向」都过一遍。比如快照类题目，变体可能是「支持按版本号删除」「支持批量 set」「要求 get 返回最近有效值」。练变体的核心不是背代码，而是理解「为什么用二分而不是哈希」——因为快照版本是单调递增的，天然有序。把每个题的「数据结构选择理由」写出来，比刷十道新题更有效。

结果反馈

一面通过，两天后约了二面，整体节奏紧凑，面试官不拖泥带水，问题密度高但都在射程范围内。

想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。