面试面经 · 百度
【百度】【Agent 开发】【暑期实习二面】面经（八股+大模型项目+手撕）
海外一年制硕士，投递百度 Agent 开发暑期实习，二面约 60 分钟，面试官是组内做 Agent 平台方向的工程师，全程围绕项目细节和工程落地能力追问，八股问得不算多但很挑关键点。
题目摘要
- Go 语言基础：
slice的底层结构与扩容策略，append在什么情况下会触发底层数组重新分配；map为什么不是并发安全的，sync.Map的适用场景与代价。 - MySQL / Redis 八股：聚簇索引与回表的执行过程，
EXPLAIN里type、key、rows怎么看；Redis 缓存穿透、击穿、雪崩的区别与各自解法，布隆过滤器为什么会有误判。 - Agent 项目深挖：RAG 链路里文档切分策略怎么定、召回后为什么要做重排、如何评估召回质量；Function Calling 的工具描述怎么写才能提升调用准确率；多轮对话的上下文如何裁剪与压缩。
- 推理成本优化：同一个 Agent 请求里如何降低 token 消耗与延迟，Prompt Caching、模型分级路由、工具结果截断分别解决什么问题。
- 手撕算法：给一个整数数组
nums和一个整数k，返回所有和为k的连续子数组的个数（元素可正可负）。关键思路是用前缀和 + 哈希表，遍历时记录prefix_sum出现次数，对每个位置查prefix_sum - k的计数累加，时间 O(n)、空间 O(n)。注意初始化{0: 1}，否则会漏掉从下标 0 开始的子数组。
项目深挖
追问一：你的 RAG 为什么用固定长度切分，而不是按语义切分？效果差在哪？
参考回答方向：先说清固定长度切分的代价——容易把一段完整语义从中间截断，导致召回片段信息不完整，模型拿到半句话反而更容易幻觉。再讲自己实际做过的改进：按标题层级或段落边界切，超长段落再叠加滑动窗口与 overlap，overlap 一般取 chunk 的 10%~20%。最后补一句评估方式，比如用一组标注好的问答对算 Hit Rate 和 MRR，对比切分策略改动前后的召回指标，而不是凭感觉说"效果更好"。面试官想听的是你有没有量化意识。
追问二：工具调用失败或者模型返回的参数格式不对，你怎么处理？
参考回答方向：分三层。第一层是 schema 约束，工具参数用 JSON Schema 定义清楚类型和必填项，描述里写清每个字段的含义和示例，减少模型瞎填。第二层是运行时校验，解析失败不直接抛给用户，而是把错误信息回灌给模型让它重试，设置最大重试次数（比如 2 次）避免死循环。第三层是兜底，重试仍失败就降级到固定话术或人工介入，同时把失败样本落库，作为后续优化工具描述和 few-shot 的素材。这里能体现你有没有真正上线跑过，而不是只跑通 demo。
追问三：多轮对话上下文越来越长，你怎么控制成本和效果？
参考回答方向：不要一上来就说"做摘要"。先分层——系统 Prompt 和工具定义是固定的，可以走 Prompt Caching 缓存；历史对话按重要性裁剪，最近几轮完整保留，更早的做摘要压缩；工具返回的长结果（比如一坨 JSON 或网页正文）只保留关键字段或前 N 个字符，其余丢弃。再讲取舍：摘要会丢信息，所以关键实体（订单号、用户 ID 这类）要单独抽出来结构化保存，不依赖摘要。最后提一句监控，记录每轮请求的 token 数和首 token 延迟，成本异常时能定位到是哪段上下文膨胀了。
准备建议
- 把项目里的每个技术选型都准备好"为什么不用另一个"。面试官不会问你做了什么，而是问你为什么这么做、换一种方案会怎样。RAG 的切分、重排、向量库选型，Function Calling 的工具粒度，每一个决策都要能说出 trade-off，最好带上你实测的数字。
- 八股只背高频且能延伸的点，别铺开背。MySQL 重点吃透索引和
EXPLAIN，Redis 重点吃透缓存三兄弟和持久化，Go 重点吃透 slice、map、channel、GC。每个点准备一个"我在项目里怎么遇到的"例子，比干背定义强很多。
- 手撕算法按题型刷，不按题号刷。前缀和、滑动窗口、双指针、二叉树遍历、TopK 这几类覆盖大部分实习手撕。每道题写完主动说清时间空间复杂度，并想一下边界情况（空数组、k 为 0、元素为负），面试官很看重这个习惯。
二面结束当天收到反馈，评价是项目细节问得比较透、回答还算扎实，3 天后约了 HR 面。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
